Друид против Elasticsearch
Я новичок в друид. Я уже читал "друид против Elasticsearch", но я до сих пор не знаю, в чем хорош друид.
Ниже моя проблема:
У меня есть кластер Solr с 70 узлами.
У меня есть очень большая таблица в solr, которая имеет 1 миллиард строк, и каждая строка имеет 100 полей.
Пользователь будет использовать разные диапазоны запроса полей полей (по меньшей мере, 20 комбинаций в одном запросе), чтобы подсчитать различное количество идентификаторов клиентов, но алгоритм подсчета отдельных подсчетов очень медленный и использует много памяти, поэтому, если результат запроса более 200 тысяч, узел запроса solr вылетит.
Есть ли у друида лучшая производительность, чем у solr?
2 ответа
Друид сильно отличается от баз данных, специфичных для поиска, таких как ES/Solr. Это база данных, предназначенная для аналитики, где вы можете выполнять свертки, фильтрацию столбцов, вероятностные вычисления и т. Д.
Друид действительно рассчитывает благодаря использованию HyperLogLog, который является вероятностной структурой данных. Так что, если вы не беспокоитесь о 100% точности, вы обязательно можете попробовать Друид, и я заметил резкое улучшение времени отклика в одном из моих проектов. Но, если вы заботитесь о точности, то Druid может оказаться не лучшим решением (даже если это возможно и в Druid, с потерей производительности и дополнительным пространством) - подробнее здесь: https://groups.google.com/forum/
ES обычно нужны необработанные данные, потому что они предназначены для поиска. Это означает, что индекс огромен, но вложенные агрегаты дороги. (Я знаю, что пропустил много деталей здесь).
Друид предназначен для расчета метрики по данным временных рядов. У этого есть четкое различие размеров и метрик. На основе полей измерения поля метрик предварительно агрегируются во время приема. Этот шаг помогает сократить огромное количество данных в зависимости от количества размерных данных. Другими словами, Друид работает лучше всего, когда измерение имеет категориальную ценность.
Ты упомянул range query, Диапазон фильтра по метрикам отлично работает. Но если вы имеете в виду запрос под числовыми измерениями, это то, что друид все еще находится в стадии разработки.
Что касается отдельного подсчета, то и ES, и Druid поддерживают HyperLogLog. В Druid вы должны указать поля во время приема, чтобы применить HyperLogLog во время запроса. Это довольно быстро и эффективно.
Последние версии (6.x AFAIK) Elasticsearch поддерживают ваш вариант использования, и вы получите результат от всех 3 (Druid, ES, Solr), но, чтобы ответить на ваш последний вопрос о производительности, я считаю, что Druid будет наиболее производительным с минимальным требования к ресурсам для вашего варианта использования.
Хотя ES поддерживает аналитику и агрегирование, его основной дизайн основан на требовании бесплатного текстового поиска. Поскольку ES выполняет больше действий, чем ваше требование, указанное выше, он будет использовать ресурсы и может не подходить, если вы не хотите делать больше, чем просто отдельный счет.
Цитата с сайта Druid https://druid.apache.org/docs/latest/comparisons/druid-vs-elasticsearch.html
Druid фокусируется на рабочих процессах OLAP. Druid оптимизирован для обеспечения высокой производительности (быстрое агрегирование и прием данных) при невысокой стоимости и поддерживает широкий спектр аналитических операций.