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

тебе бы доку почитать.. Эт вот так делается

С данными sli сложно считать в реалтайме

Всем привет! Подскажите, есть ли ограничение на кол-во коллекций создаваемых на инстансе? У нас кейс предполагает создание большого кол-ва коллекций долго живущих коллекций (чтения запись 50 на 50). Но с небольшим кол-вом данных. В среднем 500-5000 записей в коллекции. Структура данных в рамках коллекции однотипная. А вот коллекций может быть 10к-100к. В перспективе на каждой коллекции будут свои индексы, по мере необходимости Можем ли мы столкнуться с какими то лимитами при такой огранизации? Любые идеи пожалуйста. Заранее спасибо UPD Хоститься планируем на mongodb atlas если это имеет значение

вероятно лучше зайти со стороны чтения и понять целостность данных.

Вероятнее всего это будет не самая оптимальная организация. 5000*100 000, это максимум 500 млн документов, что вобщем-то не так уж и страшно.

Верификация данных эт оч сложно

_id: 0 ещё

_id: 0 ещё

в этом случае и его надо в индекс добавить

Вопрос, есть ли в mongoDb, аналог HashMap, TreeMap, т.е ключ значение который может хранить

Да, он в терминах BSON называется Document

Делаю телеграмм бота, с использованием монго. Надо в массив добавить новый объект. Подскажите как можно это сделать?

mongoose?

Ты имеешь ввиду новый элемент в коллекцию?

ой, да.. не уточнил

https://www.npmjs.com/package/mongoose-auto-increment есть такое, но чот хз

Господа, нужна подсказка: есть кластер из 2 нод. По нему распределена GridFS. На 1 ноде 1,8Тб данных, а на 2 только 720Гб. При этом sh.status говорит, что на 1 ноде 5014 чанков, а на 2 - 5013. Как бы поровнее распределить данные? А то 1 вчера колом встал, когда место закончилось. Надо что-то срочно решать...

Ок, спасибо, будем разбираться. Мне разработчики говорят, что чанк - это минимальная единица хранения данных в монго. И соответственно в 1 чанке лежит примерно 1 файл (фильм) в районе 1,5 гигабайт. Нужено это для того, чтобы по возможности файлы с фильмами не делились между серверами.

Парни, такая проблема... У меня на серваке почему-то установилась монго версии 2.6..... И я это понял не сразу, уже база в бою.... Как мне корректно смигрировать?

если у вас репликасет, то ещё возможен rolling upgrade по всем минорным версиям: 2.6 -> 3.0 -> 3.2 -> 3.4 -> 4.0 -> 4.2 -> 4.4

Буду разбираться, спасибо) Страшно конечно, базу уничтожить.... Посмотрю как проверить что у меня репликасет, надеюсь на это и поднимусь по минорным версиям

Если вы используете gridfs то при загрузке файла драйвер будет резать его на фрагменты, это gridfs чанки. Размер такого фрагмента можно регулировать в драйвере, это задача приложения. По умолчанию размер фрагмента 255кБ и делать меньше его в большинстве случаев бессмысленно. В шардированном кластере чанк имеет другое значение: это диапазон ключа шардирования, который покрывает какое-то количество документов. Размер чанка так-же ограничен, но уже настройками сервера db.setting.find({_id: ‘chunk_size’}). При превышении размера, диапазон будет разделен на два и соотвественно чанк разделится на два новых в соотвествии с двумя новыми диапазонами. Если ключ больше не делится, то чанк будет помечен как jumbo. Балансировщик чанков работает очень примитивно: он пытается равномерно распределить чанки по шардам, но не по размеру, а по количеству.