Многие команды разработчиков обращаются к DynamoDB для создания управляемых событиями архитектур и удобных и производительных приложений в любом масштабе. Будучи рабочей базой данных, DynamoDB оптимизирована для транзакций в реальном времени, даже если она развернута в нескольких географических точках. Однако он не обеспечивает высокой производительности для шаблонов доступа к поиску и аналитике. Поиск и аналитика на DynamoDB Хотя базы данных NoSQL, такие как DynamoDB, обычно обладают отличными характеристиками масштабирования, они поддерживают лишь ограниченный набор операций, ориентированных на онлайн-обработку транзакций. Это затрудняет поиск, фильтрацию, агрегирование и объединение данных без использования эффективных стратегий индексирования. DynamoDB хранит данные скрытно, распределяя их по большому количеству узлов на основе заданного пользователем поля ключа раздела, присутствующего в каждом элементе. Этот можно дополнительно объединить с ключом сортировки для представления первичного ключа. Первичный ключ действует как индекс, что делает операции запроса недорогими. Операция запроса может выполнять сравнения на равенство (=) для ключа секции и операции сравнения (>, <, =, BETWEEN) для ключа сортировки, если он указан. определяемый пользователем ключ раздела Выполнение аналитических запросов, не предусмотренных приведенной выше схемой, требует использования операции сканирования, которая обычно выполняется путем параллельного сканирования всей таблицы DynamoDB. Такое сканирование может быть медленным и дорогостоящим с точки зрения пропускной способности чтения, поскольку требует полного чтения всей таблицы. Сканирование также имеет тенденцию замедляться при увеличении размера таблицы, поскольку для получения результатов необходимо сканировать больше данных. Если мы хотим поддерживать аналитические запросы, не сталкиваясь с непомерно высокими затратами на сканирование, мы можем использовать вторичные индексы, о которых мы поговорим далее. Индексирование в DynamoDB В DynamoDB вторичные индексы часто используются для повышения производительности приложения за счет индексации часто запрашиваемых полей. Операции запросов к вторичным индексам также можно использовать для реализации определенных функций с помощью аналитических запросов с четко определенными требованиями. Вторичные индексы состоят из создания ключей разделов и дополнительных ключей сортировки по полям, которые мы хотим запросить. Существует два типа вторичных индексов: Локальные вторичные индексы (LSI): LSI расширяют атрибуты ключа хэша и диапазона для одного раздела. Глобальные вторичные индексы (GSI): GSI — это индексы, которые применяются ко всей таблице, а не к одному разделу. Однако, как , чрезмерное использование GSI в DynamoDB может оказаться дорогостоящим. Аналитика в DynamoDB, если только она не используется только для очень простого точечного поиска или сканирования небольших диапазонов, может привести к чрезмерному использованию вторичных индексов и высоким затратам. обнаружила компания Nike Затраты на выделенную емкость при использовании индексов могут быстро возрасти, поскольку все обновления базовой таблицы также должны выполняться в соответствующих GSI. Фактически, AWS рекомендует, чтобы чтобы избежать регулирования операций записи в базовую таблицу и повреждения приложения. Стоимость выделенной емкости записи растет линейно с увеличением количества настроенных GSI, что делает использование большого количества GSI для поддержки множества шаблонов доступа нецелесообразным. предоставленная емкость записи для глобального вторичного индекса была равна или превышала емкость записи базовой таблицы, DynamoDB также не очень хорошо спроектирована для индексации данных во вложенных структурах, включая массивы и объекты. Перед индексированием данных пользователям необходимо будет денормализовать данные, выравнивая вложенные объекты и массивы. Это может значительно увеличить количество операций записи и связанные с этим затраты. Более подробное описание использования вторичных индексов DynamoDB для аналитики можно найти в нашем блоге . «Вторичные индексы для аналитики на DynamoDB» Суть в том, что в аналитических сценариях использования вы можете получить значительные преимущества в производительности и затратах, синхронизировав таблицу DynamoDB с другим инструментом или службой, которая действует как внешний вторичный индекс для эффективного выполнения сложной аналитики. ДинамоБД + Elasticsearch Один из подходов к созданию вторичного индекса наших данных — использовать DynamoDB с Elasticsearch. Облачный Elasticsearch, такой как Elastic Cloud или Amazon OpenSearch Service, можно использовать для предоставления и настройки узлов в соответствии с размером индексов, репликацией и другими требованиями. Управляемый кластер требует некоторых операций для обновления, обеспечения безопасности и поддержания производительности, но в меньшей степени, чем его полностью самостоятельный запуск на экземплярах EC2. Поскольку подход с использованием не поддерживается и его довольно сложно настроить, вместо этого мы можем передавать потоковые записи из DynamoDB в Elasticsearch, используя DynamoDB Streams и функцию AWS Lambda. Этот подход требует от нас выполнения двух отдельных шагов: плагина Logstash для Amazon DynamoDB Сначала мы создаем лямбда-функцию, которая вызывается в потоке DynamoDB для публикации каждого обновления по мере его появления в DynamoDB в Elasticsearch. Затем мы создаем лямбда-функцию (или экземпляр EC2, запускающий скрипт, если это займет больше времени, чем тайм-аут выполнения лямбда-выражения), чтобы опубликовать все существующее содержимое DynamoDB в Elasticsearch. Мы должны написать и подключить обе эти лямбда-функции с правильными разрешениями, чтобы гарантировать, что мы не пропустим ни одной записи в наши таблицы. Когда они настроены вместе с необходимым мониторингом, мы можем получать документы в Elasticsearch из DynamoDB и использовать Elasticsearch для выполнения аналитических запросов к данным. Преимущество такого подхода в том, что Elasticsearch поддерживает полнотекстовое индексирование и несколько типов аналитических запросов. Elasticsearch поддерживает клиентов на разных языках и такие инструменты, как Kibana, для визуализации, которые помогают быстро создавать информационные панели. Если кластер настроен правильно, задержки запросов можно настроить для быстрых аналитических запросов к данным, поступающим в Elasticsearch. К недостаткам можно отнести то, что стоимость установки и обслуживания решения может быть высокой. Даже управляемый Elasticsearch требует репликации, разделения, роста индекса и настройки производительности базовых экземпляров. Elasticsearch имеет тесно связанную архитектуру, которая не разделяет вычисления и хранилище. Это означает, что ресурсы часто выделяются избыточно, поскольку их невозможно масштабировать независимо. Кроме того, несколько рабочих нагрузок, таких как чтение и запись, будут конкурировать за одни и те же вычислительные ресурсы. Elasticsearch также не может эффективно обрабатывать обновления. Обновление любого поля приведет к переиндексации всего документа. Документы Elasticsearch неизменяемы, поэтому для любого обновления требуется индексация нового документа, а старая версия помечается как удаленная. Это приводит к дополнительным затратам вычислительных ресурсов и операций ввода-вывода на переиндексацию даже неизмененных полей и запись целых документов после обновления. Поскольку лямбда-выражения срабатывают при обнаружении обновления в потоке DynamoDB, у них могут наблюдаться резкие скачки задержки из-за . Для установки требуются метрики и мониторинг, чтобы гарантировать правильную обработку событий из потока DynamoDB и возможность записи в Elasticsearch. холодного запуска Функционально, с точки зрения аналитических запросов, , которые полезны для сложных аналитических запросов, включающих более одного индекса. Пользователям Elasticsearch часто приходится денормализовать данные, выполнять соединения на стороне приложения или использовать вложенные объекты или отношения родитель-потомок, чтобы обойти это ограничение. в Elasticsearch отсутствует поддержка соединений Преимущества Поддержка полнотекстового поиска Поддержка нескольких типов аналитических запросов Может работать с последними данными в DynamoDB. Недостатки Требуется управление и мониторинг инфраструктуры для приема, индексирования, репликации и сегментирования. Тесно связанная архитектура приводит к избыточному выделению ресурсов и конкуренции за вычислительные ресурсы. Неэффективные обновления Требуется отдельная система для обеспечения целостности и согласованности данных между DynamoDB и Elasticsearch. Нет поддержки объединений между разными индексами. Этот подход может хорошо работать при реализации полнотекстового поиска по данным в DynamoDB и информационных панелях с использованием Kibana. Однако операции, необходимые для настройки и поддержки кластера Elasticsearch в рабочей среде, неэффективное использование ресурсов и отсутствие возможностей объединения могут оказаться сложными. ДинамоБД + Роксет — это полностью управляемая база данных поиска и аналитики, созданная в первую очередь для поддержки приложений реального времени с высокими требованиями к количеству кадров в секунду. Он часто используется в качестве внешнего вторичного индекса для данных из баз данных OLTP. Rockset Rockset имеет встроенный соединитель с DynamoDB, который можно использовать для синхронизации данных между DynamoDB и Rockset. Мы можем указать таблицу DynamoDB, содержимое которой мы хотим синхронизировать, и коллекцию Rockset, которая индексирует эту таблицу. Rockset индексирует содержимое таблицы DynamoDB в полном снимке, а затем синхронизирует новые изменения по мере их возникновения. Содержимое коллекции Rockset всегда синхронизируется с исходным кодом DynamoDB; с интервалом не более нескольких секунд в устойчивом состоянии. Rockset автоматически управляет целостностью и согласованностью данных между таблицей DynamoDB и коллекцией Rockset, отслеживая состояние потока и обеспечивая видимость изменений потоковой передачи из DynamoDB. Без определения схемы коллекция Rockset может автоматически адаптироваться при добавлении/удалении полей или при изменении структуры/типа самих данных в DynamoDB. Это стало возможным благодаря и , которые устраняют необходимость в дополнительных ETL. строгой динамической типизации умным схемам Коллекция Rockset, которую мы получили от DynamoDB, поддерживает SQL для запросов и может быть легко использована разработчиками без необходимости изучения языка, специфичного для предметной области. Его также можно использовать для обслуживания запросов к приложениям через REST API или с использованием клиентских библиотек на нескольких языках программирования. Расширенный набор ANSI SQL, который поддерживает Rockset, может работать с глубоко вложенными массивами и объектами JSON, а также использовать индексы, которые автоматически создаются по всем полям, чтобы получить миллисекундные задержки даже при сложных аналитических запросах. Rockset впервые внедрила , которое позволяет изолировать рабочие нагрузки в отдельных вычислительных блоках, одновременно используя одни и те же базовые данные в реальном времени. Это обеспечивает пользователям более высокую эффективность использования ресурсов при поддержке одновременного приема и выполнения запросов или при работе нескольких приложений с одним и тем же набором данных. разделение вычислений Кроме того, Rockset заботится о безопасности, шифровании данных и ролевом контроле доступа к ним. Пользователи Rockset могут избежать необходимости в ETL, используя которые мы можем настроить в Rockset для изменения данных по мере их поступления в коллекцию. Пользователи также могут дополнительно управлять жизненным циклом данных, настраивая политики хранения для автоматической очистки старых данных. Как прием данных, так и обработка запросов управляются автоматически, что позволяет нам сосредоточиться на создании и развертывании действующих информационных панелей и приложений, устраняя при этом необходимость в управлении инфраструктурой и операциях. преобразования приема, Rockset поддерживает обновления на уровне полей, что особенно важно при синхронизации с DynamoDB, что позволяет избежать дорогостоящего переиндексирования. с точки зрения приема, запросов и эффективности, чтобы выбрать правильный инструмент для работы. Сравните Rockset и Elasticsearch Краткое содержание Создан для обеспечения высокого количества запросов в секунду и обслуживания приложений реального времени. Полностью бессерверный. Никаких операций или предоставления инфраструктуры или базы данных не требуется. Разделение вычислений для предсказуемой производительности и эффективного использования ресурсов. Синхронизация в реальном времени между DynamoDB и коллекцией Rockset, чтобы расстояние между ними никогда не превышало нескольких секунд. Мониторинг для обеспечения согласованности между DynamoDB и Rockset. Автоматические индексы, построенные на основе данных, позволяющие выполнять запросы с малой задержкой. Обновления на месте, позволяющие избежать дорогостоящего переиндексирования и снизить задержку данных. Объединяется с данными из других источников, таких как Amazon Kinesis, Apache Kafka, Amazon S3 и т. д. Мы можем использовать Rockset для реализации без каких-либо проблем с эксплуатацией, масштабированием или обслуживанием. Это может значительно ускорить разработку приложений реального времени. Если вы хотите создать свое приложение на основе данных DynamoDB с помощью Rockset, вы можете начать работу бесплатно . аналитики данных в DynamoDB в реальном времени здесь
