В реальных бизнес-сценариях многие пользователи сталкиваются с технической проблемой выбора ClickHouse и Elasticsearch. Пользователи недостаточно знают о ядрах ClickHouse и Elasticsearch, поэтому они выбирают то, что им нужно, только тестируя производительность. В этой статье описываются преимущества и недостатки ClickHouse и Elasticsearch на основе анализа архитектур их ядер.
ClickHouse - это аналитическая база данных на основе колоночно-накопительных вычислений, разработанная российской компанией Яндекс. В течение последних лет она была очень популярна в области OLAP и широко использовалась крупными предприятиями.
Elasticsearch - это движок, предназначенный для распределенного анализа поиска в режиме близком к реальному времени, а его базовое хранилище полностью основано на Lucene. Автономные поисковые возможности Lucene расширены Elasticsearch для обеспечения возможностей анализа распределенного поиска. Elasticsearch, а также его компоненты с открытым исходным кодом Logstash и Kibana, обеспечивают сквозные функции анализа журналов и поиска. Вместе они также называются ELK.
Распределенная архитектура
ClickHouse и Elasticsearch - это продукты данных, которые могут быть развернуты на нескольких машинах распределенным образом. Дизайн распределенной архитектуры оказывает значительное влияние на простоту использования и масштабируемость продуктов. Основные проблемы, которые необходимо решить для распределенной архитектуры, включают обнаружение узлов, синхронизацию метаданных и синхронизацию данных реплик.
Elasticsearch
Elasticsearch - это признанный продукт с открытым исходным кодом, поэтому его технологии являются относительно зрелыми. Встроенная функция обнаружения узлов и протокол синхронизации Meta обеспечивают простоту использования. Протокол синхронизации Meta в Elasticsearch должен решить проблемы, аналогичные протоколу Raft с открытым исходным кодом. Поскольку на момент создания Elasticsearch протокола Raft не существовало, Elasticsearch должен был разработать свой эксклюзивный протокол. После нескольких лет разработки протокол синхронизации Meta в Elasticsearch стал достаточно зрелым. На основе этого протокола Elasticsearch предоставляет функции многоролевого различения и автоматического вывода схемы. Стоит отметить, что Elasticsearch не использует протокол синхронизации Meta для многократной синхронизации данных. Вместо этого Elasticsearch использует традиционный механизм синхронизации "основной - резервный", когда основной узел синхронизирует данные с резервными узлами. Этот метод является более простым и эффективным.
ClickHouse
Возможности распределенной архитектуры ClickHouse относительно просты, поскольку ClickHouse была разработана всего несколько лет назад. Его распределенная архитектура все еще находится на стадии итераций, и возможности простоты использования постоянно улучшаются. ClickHouse использует внешний кластер ZooKeeper для выпуска распределенных задач DDL (изменения метаданных узла) и задач синхронизации основного/резервного узлов. Задачи синхронизации данных между несколькими репликами также выполняются кластером ZooKeeper. Однако передача данных между несколькими репликами в конечном итоге представляет собой репликацию данных "точка-точка" по протоколу HTTP. Все реплики доступны для записи, а синхронизация данных является полностью многонаправленной. Что касается обнаружения узлов, ClickHouse в настоящее время не имеет такой возможности.
Пользователям приходится вручную настраивать адрес узла кластера, чтобы реализовать обнаружение узла. Распределенная архитектура "строительных лесов" ClickHouse обеспечивает сильные возможности гибкого развертывания и вмешательства O&M, но простота использования оставляет желать лучшего. С точки зрения эластичности распределенного развертывания и масштаба кластера, между ClickHouse и Elasticsearch нет никакой разницы. Архитектура ClickHouse является плоской и не имеет внешнего или внутреннего узла. Можно развертывать кластеры любого размера. Кроме того, ClickHouse имеет тонкий контроль над функциями мультирепликации, позволяя пользователям настраивать реплики таблиц. Один физический кластер может быть разделен на несколько логических кластеров, и пользователи могут задавать необходимое количество шардов и реплик для каждого логического узла.
Архитектура хранилища
Elasticsearch
Пропускная способность записи является основной метрикой в сценариях работы с большими данными. Продукты больших данных требуют быстрой записи и достаточного пространства для хранения. Ниже приведен дизайн процедуры записи в режиме реального времени в Elasticsearch:
В каждом шарде Elasticsearch процесс записи делится на две части.
- Сначала данные записываются в Lucene, а затем в TransLog. После того как запрос на запись достигает шарда, сначала записывается индекс памяти Lucene, пока данные еще находятся в памяти.
- Затем записывается TransLog. После записи TransLog данные TransLog сбрасываются на диск. Затем запрос возвращается пользователю. Есть несколько ключевых моментов:
- Данные сначала записываются в Lucene, чтобы предотвратить появление "недействительных" данных в запросах на запись от пользователей.
- Индекс Lucene не доступен для поиска после записи. Его необходимо "промыть" и преобразовать в полный сегмент, а затем снова открыть. Интервал обновления может быть установлен пользователем. Индексы Lucene нельзя просматривать в реальном времени после записи, поэтому Elasticsearch - это система, работающая практически в реальном времени.
- Через регулярные промежутки времени (например, через 30 минут) Lucene выгружает на диск новые сегменты, созданные в памяти. После этого процесса индексные файлы становятся постоянными. Старые данные TransLog очищаются только тогда, когда они больше не будут использоваться.
ClickHouse
Запись данных в ClickHouse является более простой, прямой и экстремальной по сравнению с Elasticsearch. Как упоминалось выше, Elasticsearch - это система, работающая практически в реальном времени, поэтому только что записанные данные в механизм хранения в памяти должны регулярно выгружаться для поиска. ClickHouse отказывается от механизма хранения данных в памяти и записывает все данные непосредственно на диск для сохранения. В то же время традиционный этап записи журналов повторных записей исключается. В сценариях, требующих чрезвычайно высокой пропускной способности записи, Elasticsearch и ClickHouse приходится жертвовать видимостью записи данных в реальном времени для повышения пропускной способности. Однако ClickHouse реализует высокую пропускную способность записи за счет реализации отложенной пакетной записи данных на стороне клиента. Что касается синхронизации нескольких реплик, Elasticsearch требует синхронизации в реальном времени. Запросы на запись обрабатываются в нескольких репликах, прежде чем они будут возвращены. ClickHouse полагается на ZooKeeper для асинхронной синхронизации дисковых файлов. На практике пропускная способность узла ClickHouse при записи намного выше, чем узла Elasticsearch той же спецификации.
Сегмент против Части данных
Конструкции хранилищ Elasticsearch и ClickHouse выглядят похоже, но их возможности совершенно разные. Дисковые файлы Elasticsearch состоят из отдельных сегментов, а сегмент - это наименьшая единица индекса Lucene. Сегменты объединяются асинхронно в фоновом режиме, что решает две проблемы:
- Это делает вторичные индексы более упорядоченными.
- Это изменяет данные первичного ключа.
Вторичный индекс - это глобально упорядоченный индекс, поскольку один индекс для всех данных лучше для ускорения запросов, чем несколько индексов. Elasticsearch поддерживает операции удаления и обновления первичного ключа, которые опираются на функцию удаления индексов Lucene. Операция обновления преобразуется в операции удаления и записи. Если в сегментах индекса Lucene имеется несколько записей об удалении, системе необходимо объединить сегменты, чтобы удалить эти записи. При объединении нескольких сегментов сохраненные данные в индексе Lucene объединяются в режиме append-only. В этой ситуации "переупорядочивание" вторичных индексов после слияния не требуется.
По сравнению с сегментами в Elasticsearch, наименьшей единицей в хранилище ClickHouse является DataPart. Данные, записываемые пакетно за один раз, записываются в DataPart. Данные, хранящиеся в DataPart, полностью упорядочены оператором ORDER BY, определенным в таблице. Это упорядоченное хранилище представляет собой кластеризованный индекс по умолчанию, который можно использовать для ускорения сканирования данных. ClickHouse также асинхронно объединяет части Data Parts, что также решает две проблемы:
- Он хранит данные более упорядоченным образом.
- Он модифицирует данные первичного ключа.
Части данных объединяются в режиме слияния-сортировки, и объединенные Части данных все еще находятся в полностью упорядоченном состоянии. В зависимости от настройки полностью упорядоченного хранения DataPart, ClickHouse обновляет данные первичного ключа совершенно по-разному. При изменении первичного ключа Elasticsearch использует метод с такой процедурой:
Проверка исходной записи > генерация новой записи > удаление исходной записи > запись данных в новую запись.
Этот метод ограничивает эффективность обновления первичного ключа, и существует значительная разница между эффективностью записи данных после обновления первичного ключа и записи только в append. Обновление первичного ключа в ClickHouse полностью асинхронно, поэтому последние версии нескольких записей с одинаковым первичным ключом создаются во время асинхронного слияния. Такой асинхронный пакетный режим более эффективен для обновления первичного ключа.
Подводя итог, ниже перечислены различия в возможностях хранения файлов между сегментом и DataPart:
- Segment - это формат хранения индексов Lucene. Производительность индексов Lucene для хранения инвертированных файлов велика, и он поддерживает хранение исходных данных в различных форматах, таких как хранение строк и хранение столбцов. По умолчанию Elasticsearch хранит исходные данные в двух копиях, одна в режиме хранения строк, а другая - в режиме хранения столбцов. Elasticsearch будет выбирать хранимые объекты для сканирования по шаблонам запросов.
- DataPart в родном ClickHouse не имеет вторичных индексных файлов, и данные хранятся полностью в режиме хранения столбцов. Коэффициент сжатия и пропускная способность сканирования при хранении по столбцам в ClickHouse являются наилучшими. Elasticsearch относительно слабее в хранении данных и несет гораздо больше затрат.
Обсуждение вопроса о бессхемности
Elasticsearch
Когда речь заходит об особенностях Elasticsearch, упоминается слово "бессхемный". Elasticsearch может автоматически определить json-схему записанных данных и затем настроить метаструктуру таблицы хранения. Эта функция избавляет пользователей от необходимости создавать таблицы и добавлять столбцы. Однако, более подходящим названием является auto schema inference, поскольку эта функция использует возможности распределенной синхронизации Мета-структуры Elasticsearch. Хранилище Elasticsearch требует схемы и сильно привязано к схеме, поскольку ядром хранилища Elasticsearch являются вторичные индексы. Индекс не может быть создан для поля без типа. Настоящая бессхемность требует, чтобы типы полей можно было гибко и эффективно изменять, при этом производительность запросов существенно не снижается. В настоящее время, если пользователь хочет изменить тип поля в индексе Elasticsearch, доступен только один метод: переиндексировать все данные.
ClickHouse
В отличие от этого, хранилище ClickHouse не привязано к схеме, поскольку аналитические возможности ClickHouse сосредоточены на сканировании хранилища. Типы данных могут быть динамически преобразованы во время сканирования данных, а типы полей также могут быть медленно и асинхронно скорректированы при объединении DataParts. Издержки изменения типов полей во время запроса заключаются в увеличении накладных расходов оператора cast. Однако пользователи не ощутят резкого снижения производительности. По мнению автора, отсутствие схемы - это не сильная сторона Elasticsearch, а его слабость. Что касается автоматического поиска схемы, то он очень удобен для небольших пользователей. Однако он никогда не сможет создать схему с наилучшей производительностью для пользователей. В сценариях с большим объемом данных все равно необходимо создавать схему на основе конкретных требований запроса. В конце концов, удобство сопровождается затратами.
Архитектура запросов
Вычислительный механизм
Elasticsearch
Вычислительный механизм Elasticsearch - это поисковая система общего назначения. Сложность запросов, с которыми может справиться поисковая система, ограничена. Все поисковые запросы в поисковой системе могут быть возвращены с результатом через несколько определенных этапов, а вычислительный механизм - нет. Хотя Elasticsearch имеет SQL-плагины, логика реализации этих плагинов заключается в преобразовании простых SQL-запросов в определенные режимы поиска. Для анализа данных, который не поддерживается поисковой системой, Elasticsearch-SQL ничего не может сделать. Кроме того, текущие возможности перевода Elasticsearch SQL не являются совершенными и интеллектуальными. Для достижения наилучшей производительности поиска пользователям все еще необходимо использовать собственные API-интерфейсы запросов Elasticsearch. API запросов Elasticsearch непривычны для пользователей, привыкших использовать SQL, поскольку код для сложных запросов сложно написать.
Поисковая система Elasticsearch поддерживает три различных режима поиска: query_and_fetch, query_then_fetch и dfs_query_then_fetch. Первый режим очень прост. Каждый распределенный узел выполняет поиск самостоятельно, а затем возвращает результаты клиенту. Во втором режиме каждый распределенный узел хранилища ищет идентификаторы и соответствующие оценки записей TopN. Затем идентификаторы и оценки отправляются на узел с запросом для получения окончательного результата TopN. Затем узел хранилища запрашивается для получения подробных данных. Дизайн двухраундового запроса направлен на минимизацию объема подробных данных, что представляет собой количество сканирований диска. Для последнего режима сначала подсчитывается глобальная частота терминов (TF) и частота документов (DF), а затем выполняется query_then_fetch, чтобы сбалансировать критерии оценки каждого узла хранения. Поисковый механизм Elasticsearch не обладает способностью потоковой обработки, присущей вычислительному механизму базы данных. Он обрабатывает запросы полностью поочередно. Когда объем данных, которые необходимо вернуть, велик, запрос легко проваливается или вызывает сборку мусора (GC). Как правило, верхний предел возможностей поисковой системы в Elasticsearch - это двухфазный запрос. Таким образом, Elasticsearch не может обрабатывать некоторые запросы, например, запросы, связанные с несколькими таблицами.
ClickHouse
Вычислительный механизм ClickHouse является векторным. Он использует функции векторизации и операторы агрегатора на основе шаблонов C++ для достижения превосходной производительности обработки агрегированных запросов. В сочетании с отличными возможностями параллельного сканирования хранилища ресурсы могут быть полностью использованы. Вычислительный механизм ClickHouse перекрывает возможности поискового механизма Elasticsearch в части поддержки аналитических запросов. Вычислительный механизм с полными возможностями SQL позволяет пользователям более гибко анализировать данные.
Сканирование данных
ClickHouse - это вычислительный механизм, основанный на хранении колонок, и в качестве ядра он использует упорядоченное хранение. В процессе запроса и сканирования данных информация, такая как упорядоченность хранилища, статистика блоков хранения столбцов и ключи разделов, определяет блоки хранения столбцов, подлежащие сканированию. Затем сканирование данных выполняется параллельно. Вычисление выражений и агрегированное вычисление обрабатываются в обычном вычислительном механизме. От вычислительного механизма к сканированию данных данные передаются в блоках хранения столбцов, что имеет высокую степень векторизации. Как описано в предыдущем разделе, Elasticsearch в основном сканирует данные на этапах запроса и выборки. На этапе запроса Elasticsearch сканирует индексные файлы Lucene для получения запрашиваемых DocIds и сканирует файлы колонок-хранилищ для агрегированных вычислений. На этапе выборки выполняются точечные запросы к файлам хранения строк в индексах Lucene для чтения подробных данных. В обеих фазах могут происходить как вычисления выражений, так и агрегатные вычисления, и вычисления завершаются по строкам. В целом, ни сканирование данных, ни вычислительные возможности Elasticsearch не являются векторными и основаны на результатах вторичных индексов. Если количество целевых строк, возвращаемых вторичными индексами, особенно велико (для аналитических запросов с большим объемом данных), то можно отчетливо увидеть слабость поисковой системы Elasticsearch в обработке данных.
Дискуссия о высоком параллелизме
Многие пользователи считают, что ClickHouse силен в обработке запросов, но слаб в параллелизме, потому что параллелизм в ClickHouse просто потрясающий и является его основным преимуществом. Пропускная способность диска может быть полностью занята для обработки только одного запроса, а параллелизм запросов не зависит от шардов, которые можно настроить по своему усмотрению. Пропускная способность обработки одновременных запросов является ключевой метрикой для измерения эффективности системы данных. В архитектуре ClickHouse нет естественных дефектов параллелизма. Для ClickHouse объем данных, подлежащих сканированию, и вычислительная сложность запроса определяют вычислительные операции ClickHouse. Предел параллелизма ClickHouse определяется аппаратными возможностями. Возможности параллелизма ClickHouse достаточно хороши, поэтому ошибочно полагать, что его возможности параллелизма не очень хороши. ClickHouse стремится к тому, чтобы задержка одного запроса по умолчанию была как можно меньше. В некоторых сценариях пользователи могут улучшить параллелизм, установив соответствующие системные параметры, такие как max_threads. Почему Elasticsearch имеет хороший параллелизм в некоторых сценариях?
- С точки зрения дизайна кэша, кэш Elasticsearch включает в себя кэш запросов, кэш данных и индексный кэш. Кэш ускоряется на всех этапах, от результатов запроса до результатов сканирования индекса, потому что Elasticsearch считает, что сценарий содержит "горячие" данные, которые могут запрашиваться часто. Однако ClickHouse содержит только UnCompressedBlockCache для ввода-вывода и PageCache для системы. Почему? ClickHouse фокусируется на сценариях анализа запросов, где данные и запросы изменчивы, а другие кэши, такие как кэш для результатов запросов, труднодоступны. Поэтому ClickHouse всегда фокусируется на дисковых данных с отличными возможностями кэширования ввода-вывода.
- Что касается гранулярности сканирования данных, Elasticsearch может создавать вторичные индексы по всем столбцам. Вторичные индексы обычно загружаются в память заранее, поэтому стоимость получения результатов индексного запроса низка даже при изменчивых условиях запроса. После получения результата Elaticsearch может считывать данные по строкам для вычислений. ClickHouse не поддерживает вторичные индексы. Он может только сканировать большой объем данных для фильтрации результатов при изменчивых условиях запроса.
Однако, даже если Elasticsearch поддерживает вторичные индексы, хорош ли его параллелизм? Возможно, нет. Если для вторичного индекса возвращается большой набор результатов, то также будет выполнено большое количество сканирований ввода-вывода. Это означает, что параллельность не будет высокой, если только кэш данных Elasticsearch не достаточно велик, чтобы загрузить все исходные данные в память.
В итоге, Elasticsearch сильнее в параллельности только в сценариях чистого поиска (только небольшое количество записей отфильтровывается предложением WHERE) и в среде с достаточным объемом памяти. В сценариях анализа с большим количеством записей, отфильтрованных предложением WHERE, ClickHouse сильнее благодаря отличному режиму хранения колонок и векторным вычислениям. Эти две системы фокусируются на разных аспектах. Кроме того, возможность одновременной обработки в ClickHouse основана на пропускной способности диска, в то время как в Elasticsearch она основана на кэше памяти. ClickHouse больше подходит для недорогих сценариев анализа с большим объемом данных, поскольку он может полностью использовать пропускную способность диска.
Резюме
Elasticsearch отлично подходит для сценариев поиска, в которых только несколько записей отфильтровываются предложением WHERE. В рабочей среде с достаточными ресурсами памяти Elasticsearch обладает отличными возможностями одновременного выполнения запросов. Однако в сценариях анализа больших данных, где большое количество записей отфильтровывается по условию WHERE, ClickHouse будет иметь лучшую производительность параллельных запросов благодаря отличному режиму хранения столбцов и векторным вычислениям. Кроме того, ClickHouse поддерживает больше типов запросов. Возможности одновременной обработки ClickHouse основаны на пропускной способности диска, а Elasticsearch - на кэше памяти. Поэтому их стоимость различна.
ClickHouse подходит для недорогих сценариев анализа с большими объемами данных, поскольку он может полностью использовать пропускную способность диска. С точки зрения стоимости импорта и хранения данных ClickHouse имеет преимущество.