Введение Управление потоковой передачей данных из исходной системы, такой как PostgreSQL, MongoDB или DynamoDB, в нижестоящую систему для поиска и анализа в реальном времени является проблемой для многих команд. Поток данных часто включает в себя сложные инструменты ETL, а также самоуправляемую интеграцию, чтобы гарантировать, что большие объемы записи, включая обновления и удаления, не нагружают ЦП и не влияют на производительность конечного приложения. Для такой системы, как , инженеры должны иметь глубокие знания базовой архитектуры, чтобы . Elasticsearch был разработан для анализа журналов, где данные меняются нечасто, что создает дополнительные проблемы при работе с транзакционными данными. Elasticsearch эффективно принимать потоковые данные Rockset, с другой стороны, представляет собой облачную базу данных, устраняющую множество инструментов и накладных расходов, необходимых для загрузки данных в систему. Поскольку Rockset специально создан для поиска и аналитики в реальном времени, он также был разработан для , что позволяет снизить нагрузку на ЦП, необходимую для обработки вставок, обновлений и удалений. обеспечения возможности изменения на уровне полей В этом блоге мы сравним и противопоставим, как обрабатывают прием данных, а также предоставим практические методы использования этих систем для аналитики в реальном времени. Elasticsearch и Rockset Эластичный поиск Прием данных в Elasticsearch Хотя существует множество способов загрузки данных в Elasticsearch, мы рассмотрим три распространенных метода поиска и аналитики в реальном времени: Принимайте данные из реляционной базы данных в Elasticsearch с помощью плагина ввода Logstash JDBC. Прием данных из Kafka в Elasticsearch с помощью соединителя приемника службы Kafka Elasticsearch. Принимайте данные непосредственно из приложения в Elasticsearch с помощью REST API и клиентских библиотек. Плагин ввода Logstash JDBC можно использовать для выгрузки данных из реляционной базы данных, такой как PostgreSQL или MySQL, в Elasticsearch для поиска и аналитики. Принимайте данные из реляционной базы данных в Elasticsearch с помощью плагина ввода Logstash JDBC. Logstash — это конвейер обработки событий, который принимает и преобразует данные перед отправкой их в Elasticsearch. Logstash предлагает , который периодически опрашивает реляционную базу данных, такую как PostgreSQL или MySQL, на предмет вставок и обновлений. Чтобы использовать эту службу, ваша реляционная база данных должна предоставлять записи с отметками времени, которые Logstash может прочитать, чтобы определить, какие изменения произошли. плагин ввода JDBC Этот подход к приему хорошо работает для вставок и обновлений, но при удалении необходимы дополнительные соображения. Это связано с тем, что Logstash не может определить, что было удалено в вашей базе данных OLTP. Пользователи могут обойти это ограничение, реализовав обратимое удаление, при котором к удаленной записи применяется флаг, который используется для фильтрации данных во время запроса. Или они могут периодически сканировать свою реляционную базу данных, чтобы получить доступ к самым последним записям и переиндексировать данные в Elasticsearch. . Также часто используется платформа потоковой передачи событий, такая как Kafka, для отправки данных из исходных систем в Elasticsearch для поиска и анализа в реальном времени. Принимайте данные из Kafka в Elasticsearch с помощью Kafka Elasticsearch Sink Connector Confluent и Elastic совместно выпустили , доступный компаниям, использующим как управляемые предложения Confluent Kafka, так и Elastic Elasticsearch. Соединитель требует установки и управления дополнительным инструментом Kafka Connect. Kafka Elasticsearch Service Sink Connector Используя соединитель, вы можете сопоставить каждую тему в Kafka с одним типом индекса в Elasticsearch. Если в качестве типа индекса используется динамическая типизация, Elasticsearch поддерживает некоторые изменения схемы, такие как добавление полей, удаление полей и изменение типов. Одна из проблем, которая возникает при использовании Kafka, — это необходимость переиндексации данных в Elasticsearch, когда вы хотите изменить анализатор, токенизатор или индексированные поля. Это связано с тем, что сопоставление нельзя изменить, если оно уже определено. Чтобы выполнить переиндексацию данных, вам потребуется дважды записать исходный индекс и новый индекс, переместить данные из исходного индекса в новый индекс, а затем остановить исходное задание соединителя. Если вы не используете управляемые сервисы от Confluent или Elastic, вы можете использовать для Logstash для отправки данных в Elasticsearch. плагин Kafka с открытым исходным кодом Elasticsearch предлагает возможность использовать включая Java, Javascript, Ruby, Go, Python и другие, для приема данных через REST API непосредственно из вашего приложения. Одна из проблем при использовании клиентской библиотеки заключается в том, что ее необходимо настроить для работы с в случае, когда Elasticsearch не может справиться с нагрузкой приема. Без системы очередей существует вероятность потери данных в Elasticsearch. Принимайте данные непосредственно из приложения в Elasticsearch с помощью REST API и клиентских библиотек. поддерживаемые клиентские библиотеки, очередями и противодавлением Обновления, вставки и удаления в Elasticsearch Elasticsearch имеет , который можно использовать для обработки обновлений и удалений. API обновления уменьшает количество сетевых отключений и вероятность конфликтов версий. API обновления извлекает существующий документ из индекса, обрабатывает изменения, а затем снова индексирует данные. Тем не менее, Elasticsearch не предлагает обновления или удаления на месте. Таким образом, весь документ по-прежнему необходимо переиндексировать, а это ресурсоемкая операция. API обновлений Под капотом данные Elasticsearch хранятся в индексе Lucene, и этот индекс разбивается на более мелкие сегменты. Каждый сегмент является неизменяемым, поэтому документы не могут быть изменены. При обновлении старый документ помечается для удаления, а новый документ объединяется в новый сегмент. Чтобы использовать обновленный документ, необходимо запустить все анализаторы, что также может увеличить загрузку ЦП. Клиенты, работающие с постоянно меняющимися данными, часто видят, что слияния индексов съедают значительную часть их общих счетов за вычисления Elasticsearch. Учитывая количество необходимых ресурсов, Elastic рекомендует ограничить количество обновлений Elasticsearch. Показательный клиент Elasticsearch, , использовал Elasticsearch для поиска по сайту как часть своей платформы электронной коммерции. Bol.com ежедневно делал около 700 тысяч обновлений своих предложений, включая изменения в контенте, ценах и доступности. Изначально им хотелось найти решение, которое синхронизировалось бы с любыми изменениями по мере их возникновения. Но, учитывая влияние обновлений на производительность системы Elasticsearch, они решили допустить 15-20-минутные задержки. Пакетная обработка документов в Elasticsearch обеспечивала стабильную производительность запросов. Bol.com Удаление и проблемы слияния сегментов в Elasticsearch В Elasticsearch могут возникнуть проблемы, связанные с и освобождением места. удалением старых документов Elasticsearch выполняет в фоновом режиме, если в индексе имеется большое количество сегментов или в сегменте много документов, помеченных для удаления. Объединение сегментов — это копирование документов из существующих сегментов во вновь сформированный сегмент, а оставшиеся сегменты удаляются. К сожалению, Lucene не умеет определять размеры сегментов, которые необходимо объединить, что может привести к созданию неравномерных сегментов, которые повлияют на производительность и стабильность. объединение сегментов Это связано с тем, что Elasticsearch предполагает, что все документы имеют и принимает решения об объединении на основе количества удаленных документов. При работе с документами разного размера, как это часто бывает в мультитенантных приложениях, размер некоторых сегментов будет расти быстрее, чем других, что снижает производительность крупнейших клиентов приложения. В таких случаях единственным выходом является переиндексация большого объема данных. одинаковый размер, Проблемы репликации в Elasticsearch Elasticsearch использует для репликации . Первичная реплика обрабатывает входящую операцию записи, а затем пересылает ее своим репликам. Каждая реплика получает эту операцию и повторно индексирует данные локально. Это означает, что каждая реплика независимо друг от друга тратит дорогостоящие вычислительные ресурсы на повторную индексацию одного и того же документа снова и снова. Если имеется n реплик, Elastic потратит n раз больше ресурсов процессора для индексации одного и того же документа. Это может увеличить объем данных, которые необходимо при обновлении или вставке. модель основного резервного копирования переиндексировать Массовые вызовы API и очередей в Elasticsearch Хотя вы можете использовать API обновления в Elasticsearch, обычно рекомендуется группировать частые изменения с помощью . При использовании Bulk API инженерным группам часто приходится создавать очередь и управлять ею, чтобы оптимизировать обновления в системе. Bulk API Очередь не зависит от Elasticsearch, ее необходимо настраивать и управлять ею. Очередь будет объединять вставки, обновления и удаления в системе в течение определенного интервала времени, скажем, 15 минут, чтобы ограничить влияние на Elasticsearch. Система организации очередей также применяет регулирование при высокой скорости вставки, чтобы обеспечить стабильность приложения. Хотя очереди полезны для обновлений, они не подходят для определения большого количества изменений данных, требующих полного переиндексирования данных. Это может произойти в любой момент, если в системе много обновлений. В командах, использующих Elastic в больших масштабах, обычно есть выделенные сотрудники, которые ежедневно управляют и настраивают свои очереди. Переиндексация в Elasticsearch Как упоминалось в предыдущем разделе, когда имеется множество обновлений или вам нужно изменить сопоставления индексов, происходит переиндексация данных. подвержена ошибкам и может привести к выходу из строя кластера. Что еще более страшно, так это то, что переиндексация может произойти в любой момент. Переиндексация Если вы хотите изменить сопоставления, у вас будет больше контроля над временем, в течение которого происходит переиндексация. Elasticsearch имеет API переиндексации для создания нового индекса и чтобы гарантировать отсутствие простоев при создании нового индекса. При использовании API псевдонимов запросы перенаправляются к псевдониму или старому индексу по мере создания нового индекса. Когда новый индекс будет готов, API псевдонимов преобразует данные для чтения из нового индекса. API псевдонимов, С API псевдонимов по-прежнему сложно синхронизировать новый индекс с последними данными. Это связано с тем, что Elasticsearch может записывать данные только в один индекс. Итак, вам нужно будет настроить восходящий конвейер данных для двойной записи в новый и старый индекс. Роксет Прием данных в Rockset Rockset использует встроенные коннекторы для синхронизации ваших данных с исходными системами. Управляемые соединители Rockset настроены для каждого типа источника данных, поэтому данные можно получить и сделать запросами в течение 2 секунд. Это позволяет избежать ручных конвейеров, которые увеличивают задержку или могут принимать данные только микропакетами, скажем, каждые 15 минут. На высоком уровне Rockset предлагает встроенные соединители для баз данных OLTP, потоков данных, озер и хранилищ данных. Вот как они работают: Rockset выполняет первоначальное сканирование ваших таблиц в вашей базе данных OLTP, а затем использует для синхронизации с последними данными, при этом данные становятся доступными для запроса в течение 2 секунд с момента их создания исходная система. Встроенные соединители с базами данных OLTP потоки CDC как или Kinesis, Rockset постоянно принимает любые новые темы, используя интеграцию на основе извлечения, которая не требует настройки в Kafka или Kinesis. Встроенные соединители для потоков данных. Благодаря таким потокам данных, Kafka Rockset постоянно отслеживает обновления и принимает любые новые объекты из озер данных, таких как корзины S3. Обычно мы обнаруживаем, что команды хотят объединить потоки данных в реальном времени с данными из своих озер данных для аналитики в реальном времени. Встроенные соединители с озерами данных и хранилищами Обновления, вставки и удаления в Rockset Rockset имеет распределенную архитектуру, оптимизированную для эффективного индексирования данных параллельно на нескольких машинах. Rockset — это , поэтому она записывает целые документы на одну машину, а не разделяет их на части и отправляет разные поля на разные машины. Благодаря этому можно быстро добавлять новые документы для вставки или находить существующие документы на основе первичного ключа _id для обновлений и удалений. база данных с сегментированием документов Подобно Elasticsearch, Rockset использует индексы для быстрого и эффективного получения данных при их запросе. Однако, в отличие от других баз данных или поисковых систем, Rockset индексирует данные во время приема в , индексе, который сочетает в себе хранилище столбцов, индекс поиска и хранилище строк. Конвергентный индекс хранит все значения полей в виде серии пар ключ-значение. В примере ниже вы можете увидеть документ и то, как он хранится в Rockset. конвергентном индексе Под капотом , высокопроизводительное хранилище значений ключей, которое делает мутации тривиальными. RocksDB поддерживает атомарную запись и удаление по разным ключам. Если поступает обновление поля документа, необходимо обновить ровно 3 ключа, по одному на каждый индекс. Индексы для других полей в документе не затрагиваются, а это означает, что Rockset может эффективно обрабатывать обновления вместо того, чтобы каждый раз тратить циклы на обновление индексов для всего документа. Rockset использует RocksDB name Вложенные документы и массивы также являются первоклассными типами данных в Rockset, то есть к ним применим тот же процесс обновления, что делает Rockset хорошо подходящим для обновлений данных, хранящихся в современных форматах, таких как JSON и Avro. Команда Rockset также создала несколько пользовательских расширений для RocksDB для обработки большого количества операций записи и чтения, что является обычным явлением в рабочих нагрузках аналитики в реальном времени. Одним из таких расширений является , которое обеспечивает четкое разделение вычислений запросов и вычислений индексации в RocksDB Cloud. Это позволяет Rockset избежать вмешательства записи в чтение. Благодаря этим улучшениям Rockset может масштабировать операции записи в соответствии с потребностями клиентов и предоставлять свежие данные для запросов, даже если в фоновом режиме происходят мутации. удаленное сжатие Обновления, вставки и удаления с использованием Rockset API Пользователи Rockset могут использовать поле _id по умолчанию или указать конкретное поле в качестве первичного ключа. Это поле позволяет перезаписать документ или его часть. Разница между Rockset и Elasticsearch заключается в том, что Rockset может обновлять значение отдельного поля, не требуя переиндексации всего документа. Чтобы обновить существующие документы в коллекции с помощью API Rockset, вы можете отправлять запросы к конечной точке Patch Documents. Для каждого существующего документа, который вы хотите обновить, вы просто указываете поле _id и список операций исправления, которые будут применены к документу. API Rockset также предоставляет конечную точку «Добавить документы», чтобы вы могли вставлять данные непосредственно в свои коллекции из кода приложения. Чтобы удалить существующие документы, просто укажите поля _id документов, которые вы хотите удалить, и сделайте запрос к конечной точке «Удалить документы» Rockset API. Обработка реплик в Rockset В отличие от Elasticsearch, только одна реплика в Rockset выполняет индексацию и сжатие с использованием удаленного сжатия RocksDB. Это уменьшает количество ресурсов ЦП, необходимых для индексации, особенно когда для обеспечения надежности используются несколько реплик. Переиндексация в Rockset Во время приема в Rockset вы можете использовать преобразование приема, чтобы указать желаемые преобразования данных, которые будут применяться к необработанным исходным данным. Если позже вы захотите изменить преобразование приема, вам потребуется переиндексировать данные. Тем не менее, Rockset обеспечивает и динамически типизирует значения каждого поля данных. Если размер и форма данных или запросов изменятся, Rockset продолжит работать и не потребует переиндексации данных. бессхемный прием Rockset может масштабироваться до сотен терабайт данных без необходимости переиндексации. Это восходит к стратегии шардинга Rockset. Когда объем вычислений, которые клиент выделяет в своем виртуальном экземпляре, увеличивается, подмножество сегментов перемешивается для достижения лучшего распределения по кластеру, что обеспечивает более распараллеленную, более быструю индексацию и выполнение запросов. В результате в этих сценариях переиндексация не требуется. Заключение Elasticsearch был разработан для анализа журналов, где данные не часто обновляются, вставляются или удаляются. Со временем команды расширили использование Elasticsearch, часто используя Elasticsearch в качестве вторичного хранилища данных и механизма индексирования для анализа в реальном времени постоянно меняющихся транзакционных данных. Это может оказаться дорогостоящим мероприятием, особенно для команд, оптимизирующих прием данных в режиме реального времени, а также повлечь за собой значительные затраты на управление. Rockset, с другой стороны, был разработан для анализа в реальном времени и предоставления новых данных для запроса в течение 2 секунд с момента их создания. Чтобы решить эту проблему, Rockset поддерживает вставку, обновление и удаление на месте, экономя вычислительные ресурсы и ограничивая использование переиндексации документов. Rockset также осознает затраты на управление коннекторами и приемом данных и использует платформенный подход, включая коннекторы реального времени в свои облачные предложения. В целом мы видели, как компании, которые для аналитики в реальном времени, экономят 44% только на счетах за вычисления. Присоединяйтесь к волне инженерных команд, перешедших с Elasticsearch на Rockset за считанные дни. Начните сегодня. переходят с Elasticsearch на Rockset бесплатную пробную версию
