а какая версия монги?

3.4.5

попробуй mongoshell сессию перезапустить?

помогло?

нет, все также вопрос в том, что я вчера переносил данные из одной коллекции в другую с помощью скрипта на Perl и initialize_ordered_bulk_op для бысрого переноса (и взял буфер 10000), и execute по заполнению этого буфера и где-то в середине выдало ошибку MongoDB::Network Error: Unexpected end of stream

соединение отвалилось

бывает.

и после этого вот так

интересно. попробуй через aggregation framework сделать count

ну самый простой вариант: сделать дамп и восстановить из дампа

если ты переносил из другой коллекции, то сделать дамп той коллекции и его восстановить в другуб коллекцию (`-c` в mongorestore кажется)

А нет у нее никакого repair?

можно и repair, это всё примерно одно

Еще можно попробовать индекс пересоздать.

какой индекс ты собрался пересоздавать?

и зачем главное?

дамп есть, думаю проще перезалить

да, индекса на это поле нет, т.к. это массив

На поле, если по нему идет поиск. Но нет, так нет.

дамп есть, думаю проще перезалить

ради интересна действительно попробуй compact

я просто думаю, что индекс на массив будет большим

хотя могу ошибаться

прямо пропорицонально количеству элементов в массиве

а если в массиве лежит хэш (коллекция)

агхр

кто вообще это придумал называть вложенные документы «коллекцией»?

> db.col1.aggregate([{$count : "x"}]) { "x" : 2280000 }

s

кто вообще это придумал называть вложенные документы «коллекцией»?

в perl это хэш

хеш == документ == объект

в perl это хэш

да много где это "хеш"

а вот массив документов != коллекция

почему коллекция-то​

вот!

ок, понял ))

вобщем-то если оно отвалилось посредине, то вероятнее всего что у тебя там только половина данных. почему count и $count показывают разное — скорее всего поломался _id

afair именно по нему стата ведётся

в смысле count оттуда считается

т.е. получается лучше перезалить

но так как ты делаешь $count по неиндексированному полю, оно перебирает все документы и из-за этого разница в тысячу документов

да, я бы перезалил.

а если в массиве лежит хэш (коллекция)

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

можно делать индекс по полю во вложенном документе

и тут могут всплыть как хорошие, так и плохие вещи

а можно пример дока из базы?

зависит от кейса

еще такой вопрос - коллекция 5 ГБ, сколько нужно выделять памяти (cacheSizeGB), оперативки, чтобы нормально работало

нужно не трогать cacheSizeGB

т.е. как по-умолчанию - 50% ram - 1 GB?

50% of RAM minus 1 GB, or 256 MB.

если нет задачи ограничить жадность монги, то да, оставить как есть

ок, понял

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

давать 100% память под кеш — тоже

ага, понял

а оперативы сколько лучше для такого объема?

я так понимаю, чтобы хватало на индексы

я вообще не сторонник кручения ручек у монги, пока нет реального эксплутационного опыта

ответ на вопрос: сколько не жалко

объём памяти зависит от реального паттерна использования данных. минимально, да, именно так: в память должны влазить как минимум индексы. идеально если туда ещё влазят самые горячие документы. этим документами даже не обязательно влазить в кеш монги, они спокойно могут жить в дисковом кеше (это даже лучше, там они уже будут сжатыми, а в кеше монги они as is)

спасибо, буду анализировать

проведи нагрузочное тестирование своего сайта. И смасштабируй средствами штатных баз данных

кажется у нас появился штатный капитан «чоб сказать»

реши проблему

для этого используй методы решения проблем

Я к тому что нужно нагрузить сайт до уровня ожидаемой аудитории и понять во что упёрлось, в память в диск , во время отклика, и тогда станет ясно как действовать... А не искать как перейти на MongoDB )

Latest: 3.4.5 (June 14, 2017), Stable: 3.2.13 (May 1, 2017) 3.4.5: https://docs.mongodb.com/manual/release-notes/3.4/#jun-14-2017 3.2.13: https://docs.mongodb.com/manual/release-notes/3.2/#may-1-2017 Пришло время обновляться до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3

пост в блоге отличный

Я к тому что нужно нагрузить сайт до уровня ожидаемой аудитории и понять во что упёрлось, в память в диск , во время отклика, и тогда станет ясно как действовать... А не искать как перейти на MongoDB )

а ты попробуй опиши модель нагрузки, хоть как-то напоминающую реальность. ещё один свидетель абстрактных бенчмарков в вакууме

к своему стыду не подписан на блог, о релизах узнаю из документации :(

пост в блоге отличный

а дай ссылку? я что-то в блоге про релиз вообще ничего не вижу

ты ее запинил же

там запись в блоге про репликацию и протокол v1

а, ты про асфира

я щас ещё обнаружил что у монги ещё и инженерный блог есть

https://engineering.mongodb.com/

круто, спасибо, на досуге почитаю

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

а ты попробуй опиши модель нагрузки, хоть как-то напоминающую реальность. ещё один свидетель абстрактных бенчмарков в вакууме

Поскольку сайт уже работает, уже имеются основные кейсы поведения пользователя. Да и вручную набросать их не сложно

синтетика такая синтетика