Брать ли mongodb для нового проекта?

Question

[Александр Дементеев]

Всем привет. Мы разрабатываем сервис - типа сбор и последующий анализ статистических данных. Выбираем базу и есть сомнения.

Думаю про mongo:
Есть коллекция с проектами. С определенной периодичностью по каждому проекту собираются данные и вносятся в другую коллекцию: одна запись за каждый день. Внутри такой записи вложен набор всяких разных характеристик. Вот с этими характеристиками и работает конечный пользователь.

Получается логика работы с mongo: чтобы выбрать данные для последующей обработки и вывода пользователю (графики, анализ) нужно сделать так:
1. Выбрать проект по ID - по-идее должно происходить очень быстро, чтобы проверить права доступа к проекту, какие-то настройки, плюс там хранятся категории данные к которым будут выбраны на шаге 2.
2. Выбрать записи данных по проекту за определенный период, сгруппировав их по категориям (ну т.е. пройтись по всем категориям и выбрать для каждой данные за период) - тут вроде бы тоже нормально должно быть.
3. Дальше обработка данных происходит внутри скрипта и довольно шустро.
На почти пустой базе весь этот цикл занимает 22-35 мс

Если делать то же самое на MySQL смысл остается таким же, но приходится использовать join'ы и большее количество запросов, что увеличивает время работы до 57-76 мс.

Сбор статистики в первый год прогнозируется такой: около 1 000 000 операций вставок и обновлений в сутки, т.е. ~12 запросов в секунду. Чтений - больше.

Вот и думаю. С одной стороны скорость, конечно, подкупает да и mongo все же "повзрослел" и многие косяки первых версий сейчас вроде бы как ушли. Хотя дело не только в скорости, но и в логичности. Например, не планируются какие-то страшные выборки на стороне базы - в основном, вся логика забита в скрипты. Опять же понравилось работать с документом, а не с данными. С другой стороны в mongo есть очень много отрицательных или просто не вполне понятных моментов - потери данных, блокировки на всю базу. С традиционным MySQL чувствуешь себя уверенно.

В общем, хочется узнать мнение людей, которые уже испытали на себе работу с mongo в серьезных проектах. Насколько сложно потом будет расширяться, насколько вероятна потеря данных (кстати говоря, так и не понял при каких обстоятельствах они могут потеряться), какие вообще еще есть подводные камни? Взяли бы вы его второй раз в работу для тех же целей, или стали бы работать старым-добрым способом?

Спасибо, что дочитали.

Answer 1

[justthefish]

Возьмите лучше Postgres.
Он умеет JSON-поля из коробки (9.2) и запросы по JSON-полям (9.3).

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

И не будет, в отличие от Монги, ограничения в один поток на запись. Это в Монге так и не починили и похоже никогда не починят. (Очень обидно было наткнуться на это при росте проекта, когда база данных просто не успевала прожевать записи и зависала). Не будет загадочной добавки в 100 миллисекунд к любому запросу от mongos при шардировании.
Кроме того, в MongoDB неудобная агрегация - фактически приходится руками писать план выполнения запроса, с классическим SQL же всё более или менее просто и понятно.

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

Comments

[lega]

@Jedi_PHP
> Возьмите лучше Postgres. Он умеет JSON-поля из коробки (9.2)
Лучше назвать это костылем, т.к. там даже нет нативных базовых операций на обновление, например обновить значение поля в json.

> Да, он чуть медленнее MySQL, но они оба быстрее Монги - залейте внутрь хотя бы 10М рандомных записей и убедитесь сами.
Дайте ссылку на тестирование.
Я как раз неделю назад тестировал (insert/update), psql оказался медленнее.

Answer 2

[lega]

> потери данных
Какая может быть потеря данных когда есть реплика?

> блокировки на всю базу.
Конечно это звучит не очень хорошо, но на зарубежных форумах пишут, что в первую очередь система упирается в io, на фоне чего локи выглядят не существенно (т.е. долгие локи как раз возникают из-за io)

Вчера делал примитивное тестирование локов у себя на ноутбуке: из питона делал insert документов, вышло 12k документов в сек, mongostat показывал 20% lock при этом запросы на чтение выполнялись без задержек. На сервере показатели должны быть лучше.

Comments

[Александр Дементеев]

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

[lega]

Тогда можете попробовать PostgreSQL, там есть json и hstore.

Answer 3

[Дэн Иванов]

Если я правильно понял, то по факту это time-series data, но структуру данных представляет собой своего рода дерево, и нотацию можно представить в виде
Domain.Group.Entity.Properties, и вам нужно иметь возможность группировать по каждому из узлов.
Может тогда посмотреть на специализированные решения вроде influxdb.org ?

Comments

[Александр Дементеев]

Ух ты, спасибо. Штука вроде бы интересная, но наверное тут она не совсем подойдет. Да и в разработке, т.е. страшновато её пока использовать в "боевом" режиме.

[Дэн Иванов]

А если данные это только метрики, то чем не подходит тот же самый graphite ?

Answer 4

[zarincheg]

MongoDB вполне можно использовать. Я для схожей задачи в текущем проекте её взял и пока не жалуюсь. Тоже сбор и обработка статистики различной. Из удобного - некоторые выборки/аггрегации вынес в серверный js, который в самой монго, ну типа хранимых процедур. Соотв. в коде приложения вызовы стали проще. Пока что крутится в тестовом режиме, но форсмажоров и потерь пока небыло. Но стоит помнить про правильную репликацию. Блокировки на базу как-то особо пока не мешают, но и 10gen обещаются скоро сделать их на уровне коллекций.

Answer 5

[grossws]

На тему негарантированной записи -- docs.mongodb.org/manual/core/write-concern