Комментарии 25
про memory managment изменений нет? там все так же плохо?
0
нет, все гораздо лучше, т.к. теперь за это отвечает 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
мы используем (и ненавидим) 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
+1
я вот про такой случай: есть монга, в которую пишут. много и часто. и потом скопом удаляют все, что старше 3 месяцев. И получается данных не очень много (например, 30Gb), а файлов на 130Gb. Лечится db.repairDatabase, но это вырубает базу на час, что вообще неприемлимо. А так процесс монги висит в памяти, у него виртуальной памяти на 100Gb (не помню точно, но не мало) — и это кажется некошерным
+1
Так монга подразумевает наличие как кластера минимум из 3 машин. А значит на одной можно спокойно запускать repair?
+1
кем подразумевается? и почему таких проблем у mysql не наблюдается?
-2
Ну для начала у mysql уйма своих проблем. А mongodb писалась изначально с расчетом на распределенность и ставить 1 машину можно только в development окружении.
Я сам не поклонник mongo, но ваш наезд выглядит странно.
Я сам не поклонник mongo, но ваш наезд выглядит странно.
+1
не наезд, а попытка выяснить откуда такое мнение возникло.
есть системы с кластеризацией и шардингом, но вот чтоб без них монго не должно работать — это я слышу впервые
есть системы с кластеризацией и шардингом, но вот чтоб без них монго не должно работать — это я слышу впервые
0
Ну погодите. Она работает, но работает плохо. Потому что 1 инстанс — это очень редкий случай. И скорее всего, раз вам не важен даунтайм (1 инстанс упасть же может), значит вам и даунтайм от db.repairDatabase не важно.
0
она работает как может. и три монги ведут себя также как и одна. только стоимость обслуживания и возможности управления разные.
статистики по поводу редкий или частый я не смог найти.
вот тут от разработчиков записка про шардинг — https://docs.mongodb.org/v3.0/faq/sharding/. Там вполне себе написано, что пока влезает — играйтесь с одним сервером. А если нужно high availability and disaster recovery — то да, двигайтесь дальше.
Почему для них кейс, который я описал, не считается важным — у меня нет объяснений, кроме маркетинговых.
статистики по поводу редкий или частый я не смог найти.
вот тут от разработчиков записка про шардинг — https://docs.mongodb.org/v3.0/faq/sharding/. Там вполне себе написано, что пока влезает — играйтесь с одним сервером. А если нужно high availability and disaster recovery — то да, двигайтесь дальше.
Почему для них кейс, который я описал, не считается важным — у меня нет объяснений, кроме маркетинговых.
0
Я ничего не писал про шардинг. Есть возможность создавать реплики и менять мастера.
У яндекса где-то был рассказ под вашу проблему. Они правда ее по другому решают. Вырубают реплику из кластера, полностью очищают, заново наполняют. И так по очереди для всех.
У яндекса где-то был рассказ под вашу проблему. Они правда ее по другому решают. Вырубают реплику из кластера, полностью очищают, заново наполняют. И так по очереди для всех.
0
Разработчиками монго. На конференции один так и сказал этой осенью: «узнаю, что вы используете 1 сервер не в dev, приду и лично напинаю жопу».
-1
Теперь, с WiredTiger, «у него виртуальной памяти на 100Gb (не помню точно, но не мало)» — такого не будет. Потому что нет больше memory mapped files, которые раздували размер виртуальной памяти. Что касается файлов на диске — предлагаю попробовать и посмотреть. Потому что за это тоже отвечает WiredTiger и он работает совсем по-другому, не как MongoDB раньше.
0
Но вообще, похоже что вам важны только последние 3 месяца. В таком случае предлагаю писать каждый месяц в отдельную database внутри MongoDB. Потом удалять скопом DB целиком, будет очень быстро. Application layer нужно будет немного изменить, чтобы он делал 3 запроса (последние 3 месяца).
+1
Compass нету под linux. Обидно.
+1
А есть уже где-то DaaS с wiredtiger?
0
INNER JOINскорее это LEFT OUTER JOIN.
+1
Ок, автор поправил, ссылка на доку для минусующих — где сказано что это «left outer join».
0
db.collection.bulkWrite() — Выполняет несколько операций записиСтоит упомянуть, что если произойдет ошибка в середине упорядоченного bulkWrite, то этот «пакет» так и останется на половину записанным, т.е. то что записалось — не откатывается.
+5
Подскажите как сейчас обстоят дела с мапредьюсом помнится он работал в один поток раньше?
+1
Частичные индексы автоматически обновляются, если документ при изменении стал проходить фильтр? Или, в случае примера с рейтингом, добавятся только новые документы с большим рейтингом и уже существующие?
0
Очень хотелось бы поддержки агрегации в c#-драйвере в linq-стиле, как это сделано для обычных запросов.
Сейчас, если надо использовать агрегацию из c#-кода, всё печально: ручное формирование Bson-документов, текстовые имена полей, которые потом неудобно рефакторить...
Сейчас, если надо использовать агрегацию из c#-кода, всё печально: ручное формирование Bson-документов, текстовые имена полей, которые потом неудобно рефакторить...
+1
Дак вроде запилили, еще в драйвере 2.1 https://jira.mongodb.org/browse/CSHARP-935
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релиз mongodb 3.2 немного подробностей