друид против Elasticsearch

Я новичок в друиде. Я уже читал «Друид VS Elasticsearch», но до сих пор не знаю, в чем друид хорош.

Ниже моя проблема:

  1. У меня есть кластер solr с 70 узлами.

  2. У меня очень большая таблица в solr, в которой 1 миллиард строк, и каждая строка имеет 100 полей.

  3. Пользователь будет использовать запрос диапазона полей различных комбинаций (20 комбинаций по крайней мере в одном запросе) для подсчета отдельного числа идентификаторов клиента, но алгоритм подсчета отдельных запросов solr очень медленный и использует много памяти, поэтому, если результат запроса будет больше 200 тысяч, узел запроса solr выйдет из строя.

Друид имеет лучшую производительность, чем solr в отдельном подсчете?


distinct-values druid
person zhouxiang    schedule 24.08.2016    source источник
comment
Solr 5.2 может использовать HyperLogLog для подсчета количества элементов: lucidworks. ru / blog / 2015/05/26 /   -  person Toke Eskildsen    schedule 28.10.2016
comment
Elasticsearch основан на Lucene, поэтому здесь вы сравниваете 3 разных фреймворка. Вы можете соответственно обновить заголовок или описание.   -  person avp    schedule 10.07.2019

Ответы (3)


arrow_upward
8
arrow_downward

Druid сильно отличается от баз данных, ориентированных на поиск, таких как ES / Solr. Это база данных, предназначенная для аналитики, где вы можете делать сводные данные, фильтрацию столбцов, вероятностные вычисления и т. Д.

Druid действительно считает отличным благодаря использованию HyperLogLog, который представляет собой вероятностную структуру данных. Так что, если вы не беспокоитесь о 100% точности, вы определенно можете попробовать Druid, и я заметил резкое улучшение времени отклика в одном из моих проектов. Но если вы заботитесь о точности, то Druid может быть не лучшим решением (хотя этого вполне можно добиться и в Druid, с высокими показателями производительности и дополнительным пространством) - подробнее здесь: https://groups.google.com/forum/#!topic/druid-development/AMSOVGx5PhQ

person Ramkumar Venkataraman    schedule 29.08.2016
comment
К вашему сведению: ES поддерживает агрегирование cardinality, основанное на алгоритме HyperLogLog ++. - person Kenji Noguchi; 12.10.2016
comment
о, классно! не знал об этом. У вас есть какие-либо показатели того, насколько уменьшится размер индекса, если вы используете агрегирование cardinality? - person Ramkumar Venkataraman; 12.10.2016
comment
cardinality - агрегирование времени запроса. Я не думаю, что это помогает с точки зрения размера индекса. - person Kenji Noguchi; 14.10.2016
comment
Ах, понял! Druid поддерживает агрегирование времени индекса и времени запроса на основе HLL. Агрегатор времени индекса значительно уменьшает размер хранилища для измерений высокой мощности. - person Ramkumar Venkataraman; 14.10.2016
comment
Druid также поддерживает расширение DataSketches, см. druid.apache.org/ документы / последняя / разработка / расширения-ядро /; примерное количество отдельных элементов Theta Sketch работает хорошо, Nielsen Marketing Cloud добился успеха с ним slideshare.net/ItaiYaffe/ - person Davos; 03.10.2019

arrow_upward
8
arrow_downward

ES обычно нужны необработанные данные, потому что они предназначены для поиска. Это означает, что индекс огромен, но вложенные агрегаты обходятся дорого. (Я знаю, что пропустил здесь много деталей).

Druid предназначен для расчета метрик по данным таймсерий. Он имеет четкое различие по параметрам и показателям. На основе полей измерения поля показателей предварительно агрегируются во время приема. Этот шаг помогает уменьшить огромное количество данных в зависимости от количества размерных данных. Другими словами, Друид лучше всего работает, когда измерение имеет категориальное значение.

Вы упомянули range query. Фильтр диапазонов по метрикам отлично работает. Но если вы имеете в виду запрос по числовым измерениям, над этим Druid все еще работает.

Что касается отдельного количества, и ES, и Druid поддерживают HyperLogLog. В Druid вы должны указать поля во время загрузки, чтобы применить HyperLogLog во время запроса. Это довольно быстро и эффективно.

person Kenji Noguchi    schedule 12.10.2016

arrow_upward
1
arrow_downward

Последние версии (6.x AFAIK) Elasticsearch поддерживают ваш вариант использования, и вы получите результат от всех трех (Druid, ES, Solr), но, чтобы ответить на ваш последний вопрос о производительности, я считаю, что Druid будет наиболее производительным с минимальными затратами. требования к ресурсам для вашего варианта использования.

Хотя ES поддерживает аналитику и агрегирование, его основной дизайн основан на требовании бесплатного текстового поиска. Поскольку ES выполняет больше вещей, чем ваше требование, упомянутое выше, он будет использовать ресурсы и может не подходить, если вы не хотите делать больше, чем просто отдельный счет.

Цитата с веб-сайта Druid https://druid.apache.org/docs/latest/comparisons/druid-vs-elasticsearch.html

Druid фокусируется на рабочих процессах OLAP. Druid оптимизирован для обеспечения высокой производительности (быстрое агрегирование и прием данных) при невысокой стоимости и поддерживает широкий спектр аналитических операций.

person avp    schedule 10.07.2019