Стоит ли использовать MongoDB?

Question

[Splite]

Здравствуйте! Есть приложение, в реал-тайме пишущее логи в приличных объемах.

Сейчас пишет в файл, для удобной работы с ними в вебе хочу записывать их в бд. Логи разнотипные, определенной структуры не получается (пользователь вошел, ввели команду, сервер отключился и т.п.).

Есть ли смысл использовать MongoDB? Или лучше MySQL по старинке?

Answer 1

[Сергей Протько]

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

Comments

[Splite]

Минимально скажется в чью пользу? Где-то пишут что mysql быстрее, а где-то наоборот

[hadra]

@Splite в - будет, но если что данные восстанавливаются .

[Сергей Протько]

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

Answer 2

[Алексей]

Ситуация такая же была, использовал для хранения MySQL. Работало (в плане записи все шустро). Но был один критичный момент. Т.к. вариантов сообщений было много, и под каждый написать таблицу было не самое лучшее решение + поля переменные. Одним словом структура описана только на верхнем уровне. Укладывать приходилось что-то в поля, что-то в BLOB. Как результат поиск толком не работал. Обработка была тяжелой. Иногда выпадало по таймауту.
После было решено отказаться в пользу MongoDB. С момента перехода скопилось уже несколько миллионов записей. При этом занимает лишь 3.4Гб оперативы, на диске гиг (половина это индексы). Для анализа настроен инкрементальный MapReduce по расписанию. Поиск укладывается в секунду и меньше. MapReduce (5агрегаций) в среднем выполняется за пару секунд.
За время эксплуатации никаких нареканий, одно удовольствие. В дальнейшем можно будет поднять кластер и настроить шардинг.

Так что если структура не фиксированная, либо достаточно сложная + необходимо делать различные агрегации и обработки данных, то рекомендую посмотреть на MongoDB. Как вариант добавить на время (неделю две) параллельную запись и туда и туда для анализа.

Comments

[Splite]

Ну 3 гб. оперативы это как-то слишком серьезно для логов. Или я чего-то не понимаю?

[Алексей]

MongoDB очень прожорлива по оперативе, самих данных там и GB нет, остальное это индексы, и зарезервированная память. Да и у себя не совсем логи храню, а пользовательскую статистику. Записи разного размера, с десяток полей + несколько составных индексов навешено.

Answer 3

[Александр Вульф]

MemCached попробуйте)

Comments

[Splite]

Логи ценные, а так есть риск их потерять

Answer 4

[LucemFerre]

Если логи будут использоваться для формирования статистики, то перевести их в SQL так или иначе придется. Все зависит от объемов данных. Если они большие - придется писать системы ротации. Удобнее, конечно, попробовать сначала писать в чистые таблицы без индексов, и потом уже пачками переносить данные в нормальные, с индексами, для формирования отчетности.
ИМХО, данные вполне себе структурированные. Создать по табличке на каждый тип логирования, или привести к какому то денармализованному виду, который будет нормализовываться при ротации - дело намного проще, чем делать ротацию SQL-NoSql.

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

Comments

[Yuri Shikanov]

@LucemFerre что мешает в mongodb делать поиск?

[Сергей Протько]

@LucemFerre, map/reduce для анализа помощьнее будет, нет?

Answer 5

[Rpsl]

Используйте монгу.

Answer 6

[mr null]

Считаю что логи необязательно накапливать, пишите в MemCached, если памяти сервера будет хватать для обеспечения потока записи. Из MemCached можно сохранять по необходимости. Если данные нужно накапливать и как-то структурировать, то MongoDB.

MySQL совершенно негоден для логирования.

Answer 7

[Назар Мокринский]

У меня печальный опыт использования MongoDB. По причине своей природы данные хранятся в JSON формате, что сказывается на размере, дико быстро заканчивалось место, а ещё аггрегация и map-reduce по нескольким миллионам записей дико тупили, иногда вываливаясь из таймаута, при этом практически переставала работать запись в БД. Короче, все байки про скорость для меня оказались байками, либо я абсолютно не умею её готовить.

С MySQL всё проще и надежнее. Можете взять MariaDB - получите дополнительные оптимизации, и ничего не потеряете.

Comments

[Splite]

А вот про размер уже серьезный аргумент против MongoDB. Для меня это может быть критично. А насколько сильно отличается размер от mysql?

[Сергей Протько]

@nazarpc мне кажется вы не умеете готовить монгу. У меня mongodb использовалась в качестве базы для агрегации статистики и результатов парсинга. Лимита на размер документа - 16мб для целей хранения логов более чем достаточно. По поводу размера самого BSON - да, единственный минус отсутствия схемы данных - в размер документа входят и сами поля, хотя опять же в 16 мб я не знаю что можно не впихнуть.

По поводу выборок - индексы + mapreduce - мне хватало, если у вас все начинало тупить, то либо у вас очень специфичные запросы, либо у вас были очень сложные запросы без индексов.

[Сергей Протько]

BJSON*

[Назар Мокринский]

@Fesor У меня собирались данные в виде id-дата-значение-ещё_несколько_целочисленных_полей, индексы стояли, но обработка нескольких миллионов записей происходила 15-30 секунд (к тому же это только на одном ядре, несколько ядер одного сервера для map-reduce mongodb использовать не умеет).

[Назар Мокринский]

@Splite Ключи в JSON были из одного символа, данные занимали в разы больше места, так как сами данные занимали примерно столько, сколько и JSON обертка над ними + огромные индексы. Так как планировались сотни миллионов, и даже миллиарды вот таких простеньких записей (прошлый комментарий) — MongoDB просто критически не подошла.

[sim3x]

@Fesor схему можно включить в монге

[Сергей Протько]

@nazarpc, ну я думаю вы понимаете что такие универсальные решения никогда не будут из коробки подходить для работы с такими объемами информации... Скажем для обработки записей уже проще взять Hadoop, в качестве же базы и mysql спасовала бы и любая другая бесплатная.

[Steely]

А я то думал только у меня такой печальный опыт с монго, тоже большая база, >20 миллионов записей, не смог заставить нормально и адекватно выбирать записи, то отвалится по таймауту, то еще что-то.

[Евгений]

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

[lega]

Монгу можно использовать по разному, у меня сейчас в проекте прибывает более 250M записей в месяц (на продакшене планируется >1000М записей в День), все хранится и анализируется замечательно. Для этой задачи монга используется как партицированное хранилище со сжатием.

Answer 8

[Yuri Shikanov]

Как альтернативный вариант можете рассмотреть logstash.net

Comments

[Сергей Протько]

Любопытно. Спасибо.

Answer 9

[comAT0Zz]

Не за MySQL в данном вопросе, но в нём есть подходящий движок - Archive.

Интересно, что понимается под удобной работой. С логами в файле тоже удобно работать можно.

Comments

[Splite]

Ну допустим есть файл с логами, около 1 гб. Как удобно с ним работать? Мне ведь нужно его распарсить, подготовить для веба. А каждый раз это делать очень накладно

Answer 10

[portfelio]

Про Logstash и Hadoop уже говорили. Всё зависит от объема логов. Возможно лучшим решением будет MongoDB+ElasticSearch (тут уже будет logstash), а может быть и Hadoop.

Answer 11

[Mandor]

Если у вас в проекте уже есть MySQL и нет Mongo, то лучше продолжать использовать MySQL.

Кстати существуют сторонние сервисы для менеджмента логов, может быть это выгоднее, чем поднимать инстансы монги?

Answer 12

[ZOXEXIVO]

Попробуйте Redis

Comments

[Сергей Просвирнин]

Redis, конечно, хорошо, но зачем хранить логи в памяти?

[ZOXEXIVO]

Сергей Просвирнин: да, согласен, мимо глаз область применения прошла. Можно попробовать Azure Table Storage. Поддерживает неструктурированные данные и неограниченный объем. API очень простое. Но опять, же непонятно, будут ли эти логи анализироваться, обрабатываться или они нужны только на случай непредвиденных ситуаций