Мда. Так скорее всего и выйдет. А вообще, какие реальные чипы сейчас могут похвастаться доступностью для разработчика и простотой выпуска небольшой партии? ESP8266, MSP, STM, AVR?
У меня был кластер logstash/ES из 3х серверов, 96G памяти на каждом. Данных около 4TB всего.
Работало хорошо, индексировало данные с ~200 серверов. Приходилось вручную отсекать левые даты, тогда многие индексы просто не создавались. Шаблон создания индексов: один на каждый день.
Да, проблема эластика в том что на каждый индекс выделяется определенное количество ресурсов.
Даже если индекс пустой, все равно, по умолчанию, происходит резервирование ресурсов.
Не знаю какое архитектурное решение за 8K индексами, но в реальности это решится только горизонтальным наращиванием IO и памяти.
Если я правильно понял, Вы интегратор / консалтинг компания. На мой взгляд нужно знать работающие из коробки решения. ELK как раз один из них, когда заказчик, как бы это покультурней казать, «писает кипятком от восторга».
Logstash может индексировать JSON как есть, а elasticsearch обладает неимоверными возможностями поиска.
Когда нужно делать реально необходимый map-reduce (например для сложных отчетов) существет интеграция.
Тем не менее я не исключаю возможности необходимости map-reduce в mongo, но вот realtime поиск и map-reduce у меня как-то не вяжется в голове.
По моему опыту как только разработчики «почуют» возможность логить все что не попадя Вы будете писать в свою DB всяких хлам, от которого размеры вырастут неимоверно сильно. Субъективно — от этого высока вероятность отказа MongoDB, а от этого блокирующей абстрактной операции `logger.writeMongoLog(«Error 503 — unknown error»)`, что может положить все приложение. Это просто довод против записи напрямую в DB.
+1 ИМХО от меня. Истинное удовольствие. Туда же идет Cassandra, Couchbase(именно по репликации).
Mongo именно достаточно, но приятнее, в качестве админа, работать с вышеупомянутыми).
В моем случае речь идет о кластерах с > 2 шард/реплик.
Если говорить о логах (данные жестко привязаны к дате/времени) — Вы будете удивлены как быстро работает ELK, кроме того еще и в реальном времени. Все дело в разделении индексов, когда при поиске по одному дню поиск просто не «лезет» в предыдущие (количество данных может быть любым, главное чтобы влезало на диск). Плюс полноконтекстовой поиск в ES на высоте, в то время как в MongoDB это все же довесок к основному движку. Еще одно достоинство ELK: вашим программистам не нужно писать логи в таблицу, они просто продолжают писать в лог файл.
Горизонтальная масштабируемость ES на высоте, просто добавляете еще одну железку. С Mongo такое не прокатит, будете как минимум заморачиваться с шардингом и количеством реплик / арбитров.
Я не знаю чья это кибана, но она работает 104.131.39.41:5601/
Это объяснимо, MongoDB блокировало на уровне DB. Теперь, с приходом 3.0 блок происходит на уровне коллекций. Не ясно какой версией пользовался автор.
По моему репликация на монге как раз прекрасно. Есть правда свои ньюансы, но они изложены и в офф документации и в материалах курсов сертификации
Монга имеет чуть более чем сложную систему шардинга и репликации. Топология MongoDB сама по себе предполагает множество шестеренок в механизме, что в конечном счете может усложнить жизнь админу/DevOps. Ничего страшного там нет, но есть системы которые шардинг и репликацию делают гораздо более прозрачно и естественно, например Cassandra или ElasticSearch.
И еще, Автор, почему бы не воспользоваться готовым решением ELK? IMHO, оно будет и быстрее и проще и красивее.
Контракты сотовой связи как они есть в США сегодня маловероятно будут способствовать покупке дополнительных линий чисто для часов. Надеюсь операторы сделают какой нибудь специальный тариф для wearable устройств.
Именно. Давно использую. Гляньте github.com/kireevco/wimaging — помогает перепаковывать wim файлы и использовать Foreman для развертывания винды. Мои патчи в свежих версиях Foreman должны работать напрямую с wimboot.
А это точно не переполненный SSD тормозит? Какой процент свободного пространства?
Обновился до IntelliJ 15 — пока не видел этого жуткого глюка.
А вот за это спасибо огромное!
Работало хорошо, индексировало данные с ~200 серверов. Приходилось вручную отсекать левые даты, тогда многие индексы просто не создавались. Шаблон создания индексов: один на каждый день.
Даже если индекс пустой, все равно, по умолчанию, происходит резервирование ресурсов.
Не знаю какое архитектурное решение за 8K индексами, но в реальности это решится только горизонтальным наращиванием IO и памяти.
Но я полностью чувствую Вашу боль :)
Когда нужно делать реально необходимый map-reduce (например для сложных отчетов) существет интеграция.
Тем не менее я не исключаю возможности необходимости map-reduce в mongo, но вот realtime поиск и map-reduce у меня как-то не вяжется в голове.
Mongo именно достаточно, но приятнее, в качестве админа, работать с вышеупомянутыми).
В моем случае речь идет о кластерах с > 2 шард/реплик.
Горизонтальная масштабируемость ES на высоте, просто добавляете еще одну железку. С Mongo такое не прокатит, будете как минимум заморачиваться с шардингом и количеством реплик / арбитров.
Я не знаю чья это кибана, но она работает 104.131.39.41:5601/
К слову о подсчете элементов
Монга имеет чуть более чем сложную систему шардинга и репликации. Топология MongoDB сама по себе предполагает множество шестеренок в механизме, что в конечном счете может усложнить жизнь админу/DevOps. Ничего страшного там нет, но есть системы которые шардинг и репликацию делают гораздо более прозрачно и естественно, например Cassandra или ElasticSearch.
И еще, Автор, почему бы не воспользоваться готовым решением ELK? IMHO, оно будет и быстрее и проще и красивее.