Релиз mongodb 3.2 немного подробностей

[GubkaBob]

про memory managment изменений нет? там все так же плохо?

[Kluyg]

нет, все гораздо лучше, т.к. теперь за это отвечает WiredTiger, нет больше никаких memory mapped files.
мы используем (и ненавидим) MongoDB в продакшене с самых первых версий, когда пришла пора искать подходящее хранилище со следующими параметрами: поиск только по ключу, random access (по настоящему random, никаких там working set fits in memory), размер данных много больше свободной памяти; написали по сути 4 data layer под наши данные: MongoDB, Cassandra, Riak, Aerospike. Залили живые данные. MongoDB тогда как раз вышла версия с optional WiredTiger, решили попробовать чтобы был так сказать baseline, ожидания были что MongoDB покажет себя хуже всех. В итоге MongoDB показала себя лучше всех. Riak был просто супер медленный, Aerospike был чуть быстрее MongoDB (совсем совсем чуть-чуть) но ел гораздо больше памяти, Cassandra по записи была хороша, но постоянный compaction весь read performance убивал совсем. Как то так. Эксперименты проводили на серверах, которые в итоге и использовались в production — AWS, 15G RAM (M3 General Purpose Extra Large), EBS optimized, EBS volume с базой 400 GiB, Volume Type gp2, IOPS 1200 / 3000

[GubkaBob]

я вот про такой случай: есть монга, в которую пишут. много и часто. и потом скопом удаляют все, что старше 3 месяцев. И получается данных не очень много (например, 30Gb), а файлов на 130Gb. Лечится db.repairDatabase, но это вырубает базу на час, что вообще неприемлимо. А так процесс монги висит в памяти, у него виртуальной памяти на 100Gb (не помню точно, но не мало) — и это кажется некошерным

[hell0w0rd]

Так монга подразумевает наличие как кластера минимум из 3 машин. А значит на одной можно спокойно запускать repair?

[GubkaBob]

кем подразумевается? и почему таких проблем у mysql не наблюдается?

[hell0w0rd]

Ну для начала у mysql уйма своих проблем. А mongodb писалась изначально с расчетом на распределенность и ставить 1 машину можно только в development окружении.
Я сам не поклонник mongo, но ваш наезд выглядит странно.

[GubkaBob]

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

[hell0w0rd]

Ну погодите. Она работает, но работает плохо. Потому что 1 инстанс — это очень редкий случай. И скорее всего, раз вам не важен даунтайм (1 инстанс упасть же может), значит вам и даунтайм от db.repairDatabase не важно.

[GubkaBob]

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

вот тут от разработчиков записка про шардинг — https://docs.mongodb.org/v3.0/faq/sharding/. Там вполне себе написано, что пока влезает — играйтесь с одним сервером. А если нужно high availability and disaster recovery — то да, двигайтесь дальше.

Почему для них кейс, который я описал, не считается важным — у меня нет объяснений, кроме маркетинговых.

[hell0w0rd]

Я ничего не писал про шардинг. Есть возможность создавать реплики и менять мастера.
У яндекса где-то был рассказ под вашу проблему. Они правда ее по другому решают. Вырубают реплику из кластера, полностью очищают, заново наполняют. И так по очереди для всех.

[GubkaBob]

и разговор совсем ушел в сторону от первоначального юзкейса.

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

[Alex10]

Все что мне встречалось на тему ограничения памяти это CacheSizeGB для wiredTiger.

[CAJAX]

Разработчиками монго. На конференции один так и сказал этой осенью: «узнаю, что вы используете 1 сервер не в dev, приду и лично напинаю жопу».

[Kluyg]

Теперь, с WiredTiger, «у него виртуальной памяти на 100Gb (не помню точно, но не мало)» — такого не будет. Потому что нет больше memory mapped files, которые раздували размер виртуальной памяти. Что касается файлов на диске — предлагаю попробовать и посмотреть. Потому что за это тоже отвечает WiredTiger и он работает совсем по-другому, не как MongoDB раньше.

[Kluyg]

Но вообще, похоже что вам важны только последние 3 месяца. В таком случае предлагаю писать каждый месяц в отдельную database внутри MongoDB. Потом удалять скопом DB целиком, будет очень быстро. Application layer нужно будет немного изменить, чтобы он делал 3 запроса (последние 3 месяца).

[mannaro]

Compass нету под linux. Обидно.

[Scratch]

С него пользы как с козла молока. Юзайте MongoChef

[n0ne]

А есть уже где-то DaaS с wiredtiger?

[lega]

INNER JOIN

скорее это LEFT OUTER JOIN.

[lega]

Ок, автор поправил, ссылка на доку для минусующих — где сказано что это «left outer join».

[lega]

db.collection.bulkWrite() — Выполняет несколько операций записи

Стоит упомянуть, что если произойдет ошибка в середине упорядоченного bulkWrite, то этот «пакет» так и останется на половину записанным, т.е. то что записалось — не откатывается.

[webportal]

Подскажите как сейчас обстоят дела с мапредьюсом помнится он работал в один поток раньше?

[xenohunter]

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

[Amikko]

Очень хотелось бы поддержки агрегации в c#-драйвере в linq-стиле, как это сделано для обычных запросов.
Сейчас, если надо использовать агрегацию из c#-кода, всё печально: ручное формирование Bson-документов, текстовые имена полей, которые потом неудобно рефакторить...

[Scratch]

Дак вроде запилили, еще в драйвере 2.1 https://jira.mongodb.org/browse/CSHARP-935