на чтение

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

почему чем-то? именно он и будет. 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 структуру, которая корректна

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

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

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

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

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

но зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

что как бы лол

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

на доступ по ID

через API

кто сказал-то?

потому что просто заявлять что objectid — хуета, это очень глупо

исходить надо из применения.

если у тебя есть проверка прав, то зачем вообще что-то изобретать

всё что можно узнать из айдишника — machine id, pid и дату.

всё зависит от кейсов, но я в целом не вижу смысла заводить дублируюий _id ключ, за исключением редких кейсов

ехал кейс через кейс

главное чтобы проверял не только доступ к url но и наличие доступа к объекту у текущего пользователя

Рибята!

Кто как монгу учить начинал? Посоветуйте годных туториалов

Желательно там где в связке с NodeJS, а не с php

я придумал себе проект спецом для изучения ноды и монги