Pull to refresh

Comments 47

На специализированные базы данных (https://en.wikipedia.org/wiki/Time_series_database) не смотрели?

> Модель данных была специально спроектирована для хранения унифицированных документов в JSON-формате.
Но это же много ресурсов на формирование строк, их передачу и хранение.
Прекрасно применимая вещь, в проектах начального уровня. Как только коллекция уходит за терабайт, да появляется потребность соблюдать 152ФЗ, простите за язву, но жизнь на монге становиться прекрасной. :)

Проблемы:
1. Как и говорил автор: место, свободное место и уборка базы станет головной болью.
2. Репликация, шардинг, кластеризация… можно будет узнать очень много нового по этим темам. И все равно не заработает.
3. Распределенное хранилище с единой точкой входа… о сколько мученически ночей на настройку:)

… и кстати, монга как saas, даже за много денег, не решает большинства проблем.
>Репликация,
По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации
репликация прекрасна в HDFS или ES. А у монги она просто достаточна :) Это сугубо мое ИМХО.
+1 ИМХО от меня. Истинное удовольствие. Туда же идет Cassandra, Couchbase(именно по репликации).
Mongo именно достаточно, но приятнее, в качестве админа, работать с вышеупомянутыми).
В моем случае речь идет о кластерах с > 2 шард/реплик.
Поддерживаю. +1
У меня от 3 реплик, с шардами все сложно :)
В данном кейсе речь о «выхлопе» журнальных данных в mongo вместо текстовых файлов. В таких случаях, как правило, хранить данные больше чем за пол года смысла нет, поэтому коллекции можно ограничить и до терабайтов дело не дойдет.
У меня терабайт логов набегал примерно за неделю, Mongo при вставке нескольких тысяч записей в секунду становилась неадекватной, удаление старых логов с помощью какой-то встроенной штуки, которая сама может удалять старое, работало как-то через раз. Аггрегация тормозила жутко, когда надо было посчитать уникальные айпи для запроса с параметром, например, x=12. В общем, ушли на ElasticSearch, в котором тоже всякие свои грабли, но в итоге их победили.
Это объяснимо, MongoDB блокировало на уровне DB. Теперь, с приходом 3.0 блок происходит на уровне коллекций. Не ясно какой версией пользовался автор.

По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации

Монга имеет чуть более чем сложную систему шардинга и репликации. Топология MongoDB сама по себе предполагает множество шестеренок в механизме, что в конечном счете может усложнить жизнь админу/DevOps. Ничего страшного там нет, но есть системы которые шардинг и репликацию делают гораздо более прозрачно и естественно, например Cassandra или ElasticSearch.

И еще, Автор, почему бы не воспользоваться готовым решением ELK? IMHO, оно будет и быстрее и проще и красивее.
Ставка была сделана на средства MongoDB API, JavaScript, MapReduce, позволяющие делать агрегации любой сложности и получать данные о состоянии системы без задержки. Высокопроизводительные noSQL базы как правило обладают плоской схемой и малыми возможностями для агрегации, а другие еще и задержкой в получении данных.
Если говорить о логах (данные жестко привязаны к дате/времени) — Вы будете удивлены как быстро работает ELK, кроме того еще и в реальном времени. Все дело в разделении индексов, когда при поиске по одному дню поиск просто не «лезет» в предыдущие (количество данных может быть любым, главное чтобы влезало на диск). Плюс полноконтекстовой поиск в ES на высоте, в то время как в MongoDB это все же довесок к основному движку. Еще одно достоинство ELK: вашим программистам не нужно писать логи в таблицу, они просто продолжают писать в лог файл.

Горизонтальная масштабируемость ES на высоте, просто добавляете еще одну железку. С Mongo такое не прокатит, будете как минимум заморачиваться с шардингом и количеством реплик / арбитров.

Я не знаю чья это кибана, но она работает 104.131.39.41:5601/

К слову о подсчете элементов
image
Для проектов с простой схемой данных, уверен, MongoDB не самое производительное и не самое простое решение. В данном случае схема довольно сложная, это не учитывая, что в статье она сильно упрощена (для наглядности). В проектах с односложными записями попробую указанные выше решения, спасибо за наводку!
Как раз с увеличением сложности (объема) все минусы монги полезут вверх, Она как раз применима на малых проектах, или на малых данных.
Logstash может индексировать JSON как есть, а elasticsearch обладает неимоверными возможностями поиска.
Когда нужно делать реально необходимый map-reduce (например для сложных отчетов) существет интеграция.
Тем не менее я не исключаю возможности необходимости map-reduce в mongo, но вот realtime поиск и map-reduce у меня как-то не вяжется в голове.
В ES тоже надо заморачиваться с количеством шардов. Правда, возможность делать выборки по wildmask вместо имени индекса это компенсируют. Можно делать индексы за сутки, за час и т.п.
Эластик хорош всем, кроме того, что не может переварить 8к индексов по 4 гигабайта, состоящие из 4 шард с одной репликой.
Да, проблема эластика в том что на каждый индекс выделяется определенное количество ресурсов.
Даже если индекс пустой, все равно, по умолчанию, происходит резервирование ресурсов.
Не знаю какое архитектурное решение за 8K индексами, но в реальности это решится только горизонтальным наращиванием IO и памяти.

Но я полностью чувствую Вашу боль :)
Да как раз для логов как-то и попытался его использовать. Просто много серверов и логов с них.
На самом деле, если не дышать, то он еще работал. Но вот вставка в моменты переиндексации умирает. Даже если делать ее с большим таймаутом. Окончательно его добила смерть одного из серверов. После этого он так и не смог восстановиться. Хотя серверов было около 50.
Рад, что мою боль разделили ))
У меня был кластер logstash/ES из 3х серверов, 96G памяти на каждом. Данных около 4TB всего.
Работало хорошо, индексировало данные с ~200 серверов. Приходилось вручную отсекать левые даты, тогда многие индексы просто не создавались. Шаблон создания индексов: один на каждый день.
ES, в целом, даст то же самое, другим средствами.
в целом да.
в худшем случае мостик в хадуп делается легко. А хадуп можно апать в облаке под задачу )
Высокопроизводительные noSQL базы как правило обладают плоской схемой и малыми возможностями для агрегации, а другие еще и задержкой в получении данных.

Иначе говоря, вы недостаточно изучили фундамент.

Если совсем коротко, раз уж про ELK который вы очевидно даже не тестировали, то ELK быстрее Mongo в разы. И чем сложнее «запросы» тем отрыв больше.
Но игра «у кого быстрее» это не самое главное. У ELK отличный stack и поддержка для таких time-series use cases на порядок серьезней, практичней и прагматичней.
В данном проекте скорости монги хватает, задержек в получении или обработке данных нет. Подход вполне работоспособен и имеет право на жизнь.
Если я правильно понял, Вы интегратор / консалтинг компания. На мой взгляд нужно знать работающие из коробки решения. ELK как раз один из них, когда заказчик, как бы это покультурней казать, «писает кипятком от восторга».
Решение хранить логи в mongo было принято архитектором приложения, причины на то были. Мне же, как админу, скорее пришлось с этим как-то жить. Собственно трудности и пути решения описал, это скорее гайд по граблям для тех, кто только начинает знакомство с mongo.
Сочувствую. :)

Вспоминая свои грабли, особенно на масштабировании.
Согласен. Я про свой огород больше плачу :)
По моему опыту как только разработчики «почуют» возможность логить все что не попадя Вы будете писать в свою DB всяких хлам, от которого размеры вырастут неимоверно сильно. Субъективно — от этого высока вероятность отказа MongoDB, а от этого блокирующей абстрактной операции `logger.writeMongoLog(«Error 503 — unknown error»)`, что может положить все приложение. Это просто довод против записи напрямую в DB.
Ооооооо… запись напрямую в DB. Мессир в кайфе :)
Расскажите/ткните пожалуйста про 1ТБ + 152ФЗ? Или это две различные проблемы? (тогда все понятно).
У меня все просто, я имею около 1Тб логов в неделю, и большую их часть надо хранить по 153ФЗ. Дополнительно еще по ним хочется строить ту или иную аналитику.

Так что скорее это одна проблема. :)
Хранить логи по пол года это как не ходить пол года в туалет :)
Но закон есть закон, да )
ага, и порядка 100k/min метрик, частично надо хранить до конца жизни :) Так что ES наша палочка-выручалочка.
Спокойно, у нас 100к событий в секунду ) Сейчас масштабируем до 1М/с.
Правда столько держать «в себе» нет надобности. Контакт ваш записал, можем обмениваться опытом.
Взаимно :) Пока особо обмениваться нечего, мое решение в бете, а вот перед пилотом, можно с удовольствием. :)
Как вариант, тема часто трогается на русском канале в hangops (в slack)
Зачем костыли с forEach, если для агрегации есть mapКRduce, который работает и с репликациями, и шардами?
upd: заметил, про mapReduce написали, но поверхностно
Для мониторинга системы выполняется около 200 метрик каждую минуту, все делаются путем запросов (чаще агрегаций) из mongo. Данные при этом агрегируются за маленькие промежутки времени, и mapReduce для этого использовать крайне неудобно. Против mapReduce ничего не имею, использую для построения отчетов, когда данные собираются минимум за месяц.
В статье описывал проблемы, с которыми столкнулся, а с mapReduce таковых не было, да и опыта работы не столь много, чтобы поделиться особыми скилами. А вот быстро достать и агрегировать данные за «вчера» приходилось часто, и чтобы привести вывод в удобный вид .forEach() очень выручал, возможно этот опыт кому-то пригодится.
А не смотрели например на Fluentd? Просто кмк не было необходимости писать драйвер и слать приложением данные в монгу напрямую. Под это дело существует fluent. Получить любые логи, преобразовать в JSON и отправить хоть в монгу хоть куда.
В данном случае я занимался поддержкой уже имеющегося решения, со всеми своими плюсами и минусами, которые изложил. В сторону Fluentd обязательно посмотрю.
Cassandra не рассматривалась? Она, говорят, хороша для такого
Я, кстати не слышал о реализации логов на cassandra. Для временных рядов целых два варианта знаю.
Недавно услышал о такой штуке, как HP Vertica, до 1Тб бесплатно, очень хвалили знатоки… так. к слову.
Only those users with full accounts are able to leave comments. Log in, please.