да это понятно

ну и в случае если указатель на странице которая не в памяти, сходить на диск

можно закопаться и опять что при неселективном индексе это чем то будет напоминать Seq scan в RDBMS

на чтение

не проверял но скорее всего так и будет

почему чем-то? именно он и будет. seq scan по индексу

быстрее чем по документам, на порядок. но если нам надо чтоб 1 документ достать проехаться по 1кк ключей индекса — это пипец плохо

потому что не хочется делать голословных утверждений :) не сильно знаю как в монге это реализовано

в mmap всё иначе, а в wt там всё таблица wt

и данные (ключ _id, значение bson блоб)

ясно

и индексы (ключ — ключ, значение — указатель на документы)

Подскажите, может кто вкурсе: у монги закончилось место и демон сдох. Датасет прочекали с —repair, все завершилось как надою. После этого осталось 2 коллекции побитых, на запросах к ним монга выругивается таким вот образом: [conn190] WiredTiger error (0) [1491784952:284589][1:0x7ff4c70ae700], file:collection-653-9180463724287886924.wt, WT_CURSOR.search: read checksum error for 16384B block at offset 12676222976: block header checksum of 3612947089 doesn't match expected checksum of 321045208 дальше рестарт и до нового обращения к данной коллекции. Интересует собственно есть ли возможность без даунтайма починить, например удалением коллекции?

если данные в коллекции не нужны, то да, просто удаляешь

если данные нужны, то копируешь файл .wt с данными, потом удаляешь коллекцию и развлекаешься с чтением сырого .wt

да этот способ известен, копипаста делается только с выключеной базой?

fsync command with the lock option can ensure that the data files do not change for MongoDB instances using either the MMAPv1 or the WiredTiger storage engines, thus providing consistency for the purposes of creating backups

3.2+

Ага, благодарю, логично же) но сервис придется остановить который юзает коллекцию

вообще если в коллекцию никто не пишет, можешь скопировать на ходу

она у тебя и так уже битая

а любая операция на чтение с ошибкой падает?

или только конкретная?

я бы ещё праймари индекс снял

в смысле .wt который _id держит

Часть данных читается падает по одинаковому оффсету

по крайней мере можно будет получить список айдишников документов и попробовать по одному вытащить

а большая коллекция?

При обращении к определённому месту. Коллекция на 16 гиг да она не нужна в принципе

если не нужна, то дешевле дропнуть

Была ссылка на статью, могу позже поискать, там кроме wt файлов для расковыривания сырых данных копипастили еще и другие, вопрос на будущее хватит одного wt файла или остальные относящиеся к движку тоже тащить

поищи. но структура в .wt очень простая

у тебя есть .wt для bson и .wt для индексов. т.е. минимально всегда два хранилища: data & _id

исходя из того что _id тоже часть bson, просто .wt с данными хватит

но учитывая что wt это CoW, там есть ряд НЮАНСОВ

-rw-r--r-- 1 root root 4738772992 Feb 9 14:06 collection-2657--1723320556100349955.wt -rw-r--r-- 1 root root 1155072 Feb 9 14:05 _mdb_catalog.wt -rw-r--r-- 1 root root 26935296 Feb 9 14:05 sizeStorer.wt -rw-r--r-- 1 root root 95 Feb 9 14:05 storage.bson -rw-r--r-- 1 root root 46 Feb 9 14:04 WiredTiger -rw-r--r-- 1 root root 495 Feb 9 14:04 WiredTiger.basecfg -rw-r--r-- 1 root root 21 Feb 9 14:04 WiredTiger.lock -rw-r--r-- 1 root root 916 Feb 9 14:04 WiredTiger.turtle -rw-r--r-- 1 root root 10436608 Feb 9 14:04 WiredTiger.wt

Вот список из статьи

а что за статья?

Сек

sizeStorer.wt ммм

http://www.alexbevi.com/blog/2016/02/10/recovering-a-wiredtiger-collection-from-a-corrupt-mongodb-installation/

а

ну тут не сырое ковыряние :)

Ага тогда понял

но идея интересная!

Вобщем-то оно скорее всего использует последнюю корректную сессию, для того чтоб восстановить Point-in-time структуру, которая корректна

что на самом деле очень хороший способ вытащить хоть что-то

Понятно, спасибо) у нас не критично там сыгранные партии в пасьянс хранятся

последнее корректно нужно читать как консистента

А, да. Пока у меня острый пиздец не прошел, можно с пользой провести время: если кто-то готов побыть, гхм, /альфатестером/ (так-же круто как быть альфа-самцом!) штуки для мониторинга которую я начал клепать, напишите мне в личечку. Скажите какая у вас топология, сколько данных и сколько коллекций.

Я очень плохо скейлюсь, настало время себя автоматизировать!

господа, я тут наконец-то захотел заменить монго objectid на uuid но столкнулся с такой проблемой что не ищет чет по uuid в базе

создал поле с id: String

туда вставляю uuid.v4()

господа, я тут наконец-то захотел заменить монго objectid на uuid но столкнулся с такой проблемой что не ищет чет по uuid в базе

но зачем?

именно id, не _id?

хотя вру

в консоли находит

как лучше организовать id у документов по uuid?

сделать вместо _id?

или отдельно иметь id?

понял почему была проблема у меня. Юзал метод mongoose FindById который ищет по ObjectId. сменил на FindOne итд

Это не отменяет вопроса зачем uuid вместо objectid

uuid.v4 ничем не лучше чем objectid

почему не лучше?

в общем тут говорили что не секурно иметь дефолтовый монго id

я не знаю кто тут это говорил, но это звучит как бред

и что значит «не секурно»

о какой модели угроз мы говорим?

я думаю про какой нить enumeration attack

или как там это правильно называется

перебор айдишников?

имхо, скорее всего да

так как другие угрозы тут сложно увидеть

надо обладать исключительными умственными способностями чтоб использовать oid как какой-то секретный ключ

впрочем как и uuid :)

потому что дешевле просто сгенерировать случайный чанк из 256 бит и конвернуть его в base62 или bas64_urlsafe.

задача у меня простая

пилю REST API

нужны idшники

я думаю скорее тут проблема в том что люди вместо того чтобы проверять наличие прав на доступ к какому то объекту хотят это решить случайными значениями.

что как бы лол

пришел как-то я сюда

и мне сказали objectid хуета

юзай uuid

и привели детали, но я их подзабыл

вот теперь пришло время мигрировать

поэтому и думаю

я думаю права проверять всё же корректней.

права на что?

на доступ по ID

через API

все API у меня с авторизацией и без нее запросы не пройдут