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