Комментарии 47
На специализированные базы данных (https://en.wikipedia.org/wiki/Time_series_database) не смотрели?
> Модель данных была специально спроектирована для хранения унифицированных документов в JSON-формате.
Но это же много ресурсов на формирование строк, их передачу и хранение.
> Модель данных была специально спроектирована для хранения унифицированных документов в JSON-формате.
Но это же много ресурсов на формирование строк, их передачу и хранение.
Прекрасно применимая вещь, в проектах начального уровня. Как только коллекция уходит за терабайт, да появляется потребность соблюдать 152ФЗ, простите за язву, но жизнь на монге становиться прекрасной. :)
Проблемы:
1. Как и говорил автор: место, свободное место и уборка базы станет головной болью.
2. Репликация, шардинг, кластеризация… можно будет узнать очень много нового по этим темам. И все равно не заработает.
3. Распределенное хранилище с единой точкой входа… о сколько мученически ночей на настройку:)
… и кстати, монга как saas, даже за много денег, не решает большинства проблем.
Проблемы:
1. Как и говорил автор: место, свободное место и уборка базы станет головной болью.
2. Репликация, шардинг, кластеризация… можно будет узнать очень много нового по этим темам. И все равно не заработает.
3. Распределенное хранилище с единой точкой входа… о сколько мученически ночей на настройку:)
… и кстати, монга как saas, даже за много денег, не решает большинства проблем.
>Репликация,
По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации
По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации
В данном кейсе речь о «выхлопе» журнальных данных в mongo вместо текстовых файлов. В таких случаях, как правило, хранить данные больше чем за пол года смысла нет, поэтому коллекции можно ограничить и до терабайтов дело не дойдет.
У меня терабайт логов набегал примерно за неделю, Mongo при вставке нескольких тысяч записей в секунду становилась неадекватной, удаление старых логов с помощью какой-то встроенной штуки, которая сама может удалять старое, работало как-то через раз. Аггрегация тормозила жутко, когда надо было посчитать уникальные айпи для запроса с параметром, например, x=12. В общем, ушли на ElasticSearch, в котором тоже всякие свои грабли, но в итоге их победили.
Это объяснимо, MongoDB блокировало на уровне DB. Теперь, с приходом 3.0 блок происходит на уровне коллекций. Не ясно какой версией пользовался автор.
Монга имеет чуть более чем сложную систему шардинга и репликации. Топология MongoDB сама по себе предполагает множество шестеренок в механизме, что в конечном счете может усложнить жизнь админу/DevOps. Ничего страшного там нет, но есть системы которые шардинг и репликацию делают гораздо более прозрачно и естественно, например Cassandra или ElasticSearch.
И еще, Автор, почему бы не воспользоваться готовым решением ELK? IMHO, оно будет и быстрее и проще и красивее.
По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации
Монга имеет чуть более чем сложную систему шардинга и репликации. Топология MongoDB сама по себе предполагает множество шестеренок в механизме, что в конечном счете может усложнить жизнь админу/DevOps. Ничего страшного там нет, но есть системы которые шардинг и репликацию делают гораздо более прозрачно и естественно, например Cassandra или ElasticSearch.
И еще, Автор, почему бы не воспользоваться готовым решением ELK? IMHO, оно будет и быстрее и проще и красивее.
Ставка была сделана на средства MongoDB API, JavaScript, MapReduce, позволяющие делать агрегации любой сложности и получать данные о состоянии системы без задержки. Высокопроизводительные noSQL базы как правило обладают плоской схемой и малыми возможностями для агрегации, а другие еще и задержкой в получении данных.
Если говорить о логах (данные жестко привязаны к дате/времени) — Вы будете удивлены как быстро работает ELK, кроме того еще и в реальном времени. Все дело в разделении индексов, когда при поиске по одному дню поиск просто не «лезет» в предыдущие (количество данных может быть любым, главное чтобы влезало на диск). Плюс полноконтекстовой поиск в ES на высоте, в то время как в MongoDB это все же довесок к основному движку. Еще одно достоинство ELK: вашим программистам не нужно писать логи в таблицу, они просто продолжают писать в лог файл.
Горизонтальная масштабируемость ES на высоте, просто добавляете еще одну железку. С Mongo такое не прокатит, будете как минимум заморачиваться с шардингом и количеством реплик / арбитров.
Я не знаю чья это кибана, но она работает 104.131.39.41:5601/
К слову о подсчете элементов
Горизонтальная масштабируемость ES на высоте, просто добавляете еще одну железку. С Mongo такое не прокатит, будете как минимум заморачиваться с шардингом и количеством реплик / арбитров.
Я не знаю чья это кибана, но она работает 104.131.39.41:5601/
К слову о подсчете элементов
абсолютно согласен с kireevco
Для проектов с простой схемой данных, уверен, MongoDB не самое производительное и не самое простое решение. В данном случае схема довольно сложная, это не учитывая, что в статье она сильно упрощена (для наглядности). В проектах с односложными записями попробую указанные выше решения, спасибо за наводку!
Как раз с увеличением сложности (объема) все минусы монги полезут вверх, Она как раз применима на малых проектах, или на малых данных.
Logstash может индексировать JSON как есть, а elasticsearch обладает неимоверными возможностями поиска.
Когда нужно делать реально необходимый map-reduce (например для сложных отчетов) существет интеграция.
Тем не менее я не исключаю возможности необходимости map-reduce в mongo, но вот realtime поиск и map-reduce у меня как-то не вяжется в голове.
Когда нужно делать реально необходимый map-reduce (например для сложных отчетов) существет интеграция.
Тем не менее я не исключаю возможности необходимости map-reduce в mongo, но вот realtime поиск и map-reduce у меня как-то не вяжется в голове.
В ES тоже надо заморачиваться с количеством шардов. Правда, возможность делать выборки по wildmask вместо имени индекса это компенсируют. Можно делать индексы за сутки, за час и т.п.
Эластик хорош всем, кроме того, что не может переварить 8к индексов по 4 гигабайта, состоящие из 4 шард с одной репликой.
Да, проблема эластика в том что на каждый индекс выделяется определенное количество ресурсов.
Даже если индекс пустой, все равно, по умолчанию, происходит резервирование ресурсов.
Не знаю какое архитектурное решение за 8K индексами, но в реальности это решится только горизонтальным наращиванием IO и памяти.
Но я полностью чувствую Вашу боль :)
Даже если индекс пустой, все равно, по умолчанию, происходит резервирование ресурсов.
Не знаю какое архитектурное решение за 8K индексами, но в реальности это решится только горизонтальным наращиванием IO и памяти.
Но я полностью чувствую Вашу боль :)
Да как раз для логов как-то и попытался его использовать. Просто много серверов и логов с них.
На самом деле, если не дышать, то он еще работал. Но вот вставка в моменты переиндексации умирает. Даже если делать ее с большим таймаутом. Окончательно его добила смерть одного из серверов. После этого он так и не смог восстановиться. Хотя серверов было около 50.
Рад, что мою боль разделили ))
На самом деле, если не дышать, то он еще работал. Но вот вставка в моменты переиндексации умирает. Даже если делать ее с большим таймаутом. Окончательно его добила смерть одного из серверов. После этого он так и не смог восстановиться. Хотя серверов было около 50.
Рад, что мою боль разделили ))
ES, в целом, даст то же самое, другим средствами.
Высокопроизводительные noSQL базы как правило обладают плоской схемой и малыми возможностями для агрегации, а другие еще и задержкой в получении данных.
Иначе говоря, вы недостаточно изучили фундамент.
Если совсем коротко, раз уж про ELK который вы очевидно даже не тестировали, то ELK быстрее Mongo в разы. И чем сложнее «запросы» тем отрыв больше.
Но игра «у кого быстрее» это не самое главное. У ELK отличный stack и поддержка для таких time-series use cases на порядок серьезней, практичней и прагматичней.
В данном проекте скорости монги хватает, задержек в получении или обработке данных нет. Подход вполне работоспособен и имеет право на жизнь.
Если я правильно понял, Вы интегратор / консалтинг компания. На мой взгляд нужно знать работающие из коробки решения. ELK как раз один из них, когда заказчик, как бы это покультурней казать, «писает кипятком от восторга».
Согласен. Я про свой огород больше плачу :)
По моему опыту как только разработчики «почуют» возможность логить все что не попадя Вы будете писать в свою DB всяких хлам, от которого размеры вырастут неимоверно сильно. Субъективно — от этого высока вероятность отказа MongoDB, а от этого блокирующей абстрактной операции `logger.writeMongoLog(«Error 503 — unknown error»)`, что может положить все приложение. Это просто довод против записи напрямую в DB.
Расскажите/ткните пожалуйста про 1ТБ + 152ФЗ? Или это две различные проблемы? (тогда все понятно).
У меня все просто, я имею около 1Тб логов в неделю, и большую их часть надо хранить по 153ФЗ. Дополнительно еще по ним хочется строить ту или иную аналитику.
Так что скорее это одна проблема. :)
Так что скорее это одна проблема. :)
Хранить логи по пол года это как не ходить пол года в туалет :)
Но закон есть закон, да )
Но закон есть закон, да )
Все хуже, 3 года :)
Представил — испугался.
Зачем костыли с forEach, если для агрегации есть mapКRduce, который работает и с репликациями, и шардами?
upd: заметил, про mapReduce написали, но поверхностно
upd: заметил, про mapReduce написали, но поверхностно
Для мониторинга системы выполняется около 200 метрик каждую минуту, все делаются путем запросов (чаще агрегаций) из mongo. Данные при этом агрегируются за маленькие промежутки времени, и mapReduce для этого использовать крайне неудобно. Против mapReduce ничего не имею, использую для построения отчетов, когда данные собираются минимум за месяц.
В статье описывал проблемы, с которыми столкнулся, а с mapReduce таковых не было, да и опыта работы не столь много, чтобы поделиться особыми скилами. А вот быстро достать и агрегировать данные за «вчера» приходилось часто, и чтобы привести вывод в удобный вид .forEach() очень выручал, возможно этот опыт кому-то пригодится.
В статье описывал проблемы, с которыми столкнулся, а с mapReduce таковых не было, да и опыта работы не столь много, чтобы поделиться особыми скилами. А вот быстро достать и агрегировать данные за «вчера» приходилось часто, и чтобы привести вывод в удобный вид .forEach() очень выручал, возможно этот опыт кому-то пригодится.
А не смотрели например на Fluentd? Просто кмк не было необходимости писать драйвер и слать приложением данные в монгу напрямую. Под это дело существует fluent. Получить любые логи, преобразовать в JSON и отправить хоть в монгу хоть куда.
Cassandra не рассматривалась? Она, говорят, хороша для такого
Недавно услышал о такой штуке, как HP Vertica, до 1Тб бесплатно, очень хвалили знатоки… так. к слову.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB как средство мониторинга LOG-файлов