Muitas equipes de desenvolvimento recorrem ao DynamoDB para criar arquiteturas orientadas a eventos e aplicativos de alto desempenho e fáceis de usar em escala. Como banco de dados operacional, o DynamoDB é otimizado para transações em tempo real, mesmo quando implantado em vários locais geográficos. No entanto, ele não oferece um desempenho forte para padrões de acesso de pesquisa e análise. Pesquisa e análise no DynamoDB Embora bancos de dados NoSQL como o DynamoDB geralmente tenham excelentes características de escalabilidade, eles suportam apenas um conjunto limitado de operações focadas no processamento de transações online. Isto torna difícil pesquisar, filtrar, agregar e unir dados sem depender fortemente de estratégias de indexação eficientes. O DynamoDB armazena dados internamente, particionando-os em um grande número de nós com base em um campo de chave de partição especificado pelo usuário presente em cada item. Esta pode ser opcionalmente combinada com uma chave de classificação para representar uma chave primária. A chave primária atua como um índice, tornando as operações de consulta baratas. Uma operação de consulta pode fazer comparações de igualdade (=) na chave de partição e operações comparativas (>, <, =, BETWEEN) na chave de classificação, se especificada. chave de partição especificada pelo usuário A execução de consultas analíticas não cobertas pelo esquema acima requer o uso de uma operação de verificação, que normalmente é executada verificando toda a tabela do DynamoDB em paralelo. Essas varreduras podem ser lentas e caras em termos de rendimento de leitura porque exigem uma leitura completa de toda a tabela. As verificações também tendem a ficar mais lentas quando o tamanho da tabela aumenta, pois há mais dados a serem verificados para produzir resultados. Se quisermos dar suporte a consultas analíticas sem enfrentar custos de varredura proibitivos, podemos aproveitar os índices secundários, que discutiremos a seguir. Indexação no DynamoDB No DynamoDB, os índices secundários são frequentemente usados para melhorar o desempenho do aplicativo, indexando campos que são consultados com frequência. As operações de consulta em índices secundários também podem ser usadas para potencializar recursos específicos por meio de consultas analíticas que possuem requisitos claramente definidos. Os índices secundários consistem na criação de chaves de partição e chaves de classificação opcionais sobre os campos que queremos consultar. Existem dois tipos de índices secundários: Índices secundários locais (LSIs): os LSIs estendem os atributos de hash e chave de intervalo para uma única partição. Índices secundários globais (GSIs): GSIs são índices aplicados a uma tabela inteira em vez de a uma única partição. No entanto, como , o uso excessivo de GSIs no DynamoDB pode custar caro. As análises no DynamoDB, a menos que sejam usadas apenas para pesquisas de pontos muito simples ou varreduras de pequenos intervalos, podem resultar no uso excessivo de índices secundários e em custos elevados. a Nike descobriu Os custos da capacidade provisionada ao usar índices podem aumentar rapidamente porque todas as atualizações na tabela base também devem ser feitas nos GSIs correspondentes. Na verdade, a AWS informa que para evitar limitar as gravações na tabela base e prejudicar o aplicativo. O custo da capacidade de gravação provisionada cresce linearmente com o número de GSIs configurados, tornando proibitivo o custo do uso de muitos GSIs para suportar vários padrões de acesso. a capacidade de gravação provisionada para um índice secundário global deve ser igual ou maior que a capacidade de gravação da tabela base O DynamoDB também não foi projetado para indexar dados em estruturas aninhadas, incluindo arrays e objetos. Antes de indexar os dados, os usuários precisarão desnormalizar os dados, achatando os objetos e matrizes aninhados. Isso poderia aumentar muito o número de gravações e os custos associados. Para uma análise mais detalhada do uso de índices secundários do DynamoDB para análises, consulte nosso blog . Índices secundários para análises no DynamoDB O resultado final é que, para casos de uso analítico, você pode obter vantagens significativas de desempenho e custo sincronizando a tabela do DynamoDB com uma ferramenta ou serviço diferente que atua como um índice secundário externo para executar análises complexas com eficiência. DynamoDB + Elasticsearch Uma abordagem para construir um índice secundário sobre nossos dados é usar DynamoDB com Elasticsearch. Elasticsearch baseado em nuvem, como Elastic Cloud ou Amazon OpenSearch Service, pode ser usado para provisionar e configurar nós de acordo com o tamanho dos índices, replicação e outros requisitos. Um cluster gerenciado requer algumas operações para atualizar, proteger e manter o desempenho, mas menos do que executá-lo inteiramente sozinho em instâncias do EC2. Como a abordagem usando o não é compatível e é bastante difícil de configurar, podemos transmitir gravações do DynamoDB para o Elasticsearch usando DynamoDB Streams e uma função AWS Lambda. Essa abordagem exige que executemos duas etapas separadas: plug-in Logstash para Amazon DynamoDB Primeiro criamos uma função lambda que é invocada no stream do DynamoDB para postar cada atualização conforme ela ocorre no DynamoDB no Elasticsearch. Em seguida, criamos uma função lambda (ou instância do EC2 executando um script se demorar mais que o tempo limite de execução do lambda) para postar todo o conteúdo existente do DynamoDB no Elasticsearch. Devemos escrever e conectar ambas as funções lambda com as permissões corretas para garantir que não perderemos nenhuma gravação em nossas tabelas. Quando eles são configurados junto com o monitoramento necessário, podemos receber documentos do DynamoDB no Elasticsearch e usar o Elasticsearch para executar consultas analíticas nos dados. A vantagem dessa abordagem é que o Elasticsearch suporta indexação de texto completo e diversos tipos de consultas analíticas. O Elasticsearch oferece suporte a clientes em diversas linguagens e ferramentas como o Kibana para visualização que podem ajudar a criar painéis rapidamente. Quando um cluster é configurado corretamente, as latências de consulta podem ser ajustadas para consultas analíticas rápidas sobre dados que fluem para o Elasticsearch. As desvantagens incluem que o custo de configuração e manutenção da solução pode ser alto. Até mesmo o Elasticsearch gerenciado exige lidar com replicação, reestilhaçamento, crescimento de índice e ajuste de desempenho das instâncias subjacentes. O Elasticsearch possui uma arquitetura fortemente acoplada que não separa computação e armazenamento. Isto significa que os recursos são frequentemente sobreprovisionados porque não podem ser dimensionados de forma independente. Além disso, diversas cargas de trabalho, como leituras e gravações, competirão pelos mesmos recursos de computação. O Elasticsearch também não consegue lidar com atualizações com eficiência. A atualização de qualquer campo acionará uma reindexação de todo o documento. Os documentos do Elasticsearch são imutáveis, portanto, qualquer atualização requer que um novo documento seja indexado e a versão antiga seja marcada como excluída. Isso resulta em computação adicional e E/S gasta para reindexar até mesmo os campos inalterados e para gravar documentos inteiros na atualização. Como os lambdas são acionados quando veem uma atualização no stream do DynamoDB, eles podem ter picos de latência devido a . A configuração requer métricas e monitoramento para garantir que esteja processando corretamente os eventos do stream do DynamoDB e seja capaz de gravar no Elasticsearch. inicializações a frio Funcionalmente, em termos de consultas analíticas, , que são úteis para consultas analíticas complexas que envolvem mais de um índice. Os usuários do Elasticsearch geralmente precisam desnormalizar dados, realizar junções no lado da aplicação ou usar objetos aninhados ou relacionamentos pai-filho para contornar essa limitação. o Elasticsearch carece de suporte para joins Vantagens Suporte para pesquisa de texto completo Suporte para vários tipos de consultas analíticas Pode trabalhar com os dados mais recentes no DynamoDB Desvantagens Requer gerenciamento e monitoramento de infraestrutura para ingestão, indexação, replicação e fragmentação Arquitetura fortemente acoplada resulta em provisionamento excessivo de recursos e contenção de computação Atualizações ineficientes Requer sistema separado para garantir a integridade e consistência dos dados entre DynamoDB e Elasticsearch Não há suporte para junções entre índices diferentes Essa abordagem pode funcionar bem ao implementar a pesquisa de texto completo nos dados no DynamoDB e nos painéis usando o Kibana. No entanto, as operações necessárias para ajustar e manter um cluster Elasticsearch em produção, o uso ineficiente de recursos e a falta de recursos de junção podem ser desafiadores. DynamoDB + Rockset é um banco de dados de pesquisa e análise totalmente gerenciado, criado principalmente para oferecer suporte a aplicativos em tempo real com altos requisitos de QPS. Muitas vezes é usado como um índice secundário externo para dados de bancos de dados OLTP. Rockset Rockset possui um conector integrado com DynamoDB que pode ser usado para manter os dados sincronizados entre DynamoDB e Rockset. Podemos especificar a tabela DynamoDB da qual queremos sincronizar o conteúdo e uma coleção Rockset que indexa a tabela. O Rockset indexa o conteúdo da tabela DynamoDB em um snapshot completo e, em seguida, sincroniza as novas alterações conforme elas ocorrem. O conteúdo da coleção Rockset está sempre sincronizado com a fonte do DynamoDB; não mais do que alguns segundos de intervalo em estado estacionário. O Rockset gerencia automaticamente a integridade e a consistência dos dados entre a tabela do DynamoDB e a coleção do Rockset, monitorando o estado do stream e fornecendo visibilidade sobre as alterações de streaming do DynamoDB. Sem uma definição de esquema, uma coleção Rockset pode se adaptar automaticamente quando campos são adicionados/removidos ou quando a própria estrutura/tipo dos dados muda no DynamoDB. Isso é possível graças à e que evitam a necessidade de qualquer ETL adicional. tipagem dinâmica forte aos esquemas inteligentes A coleção Rockset que obtemos do DynamoDB oferece suporte a SQL para consultas e pode ser facilmente usada por desenvolvedores sem a necessidade de aprender uma linguagem específica de domínio. Ele também pode ser usado para atender consultas a aplicativos por meio de uma API REST ou usando bibliotecas cliente em diversas linguagens de programação. O superconjunto de ANSI SQL que o Rockset suporta pode funcionar nativamente em matrizes e objetos JSON profundamente aninhados e aproveitar índices que são construídos automaticamente em todos os campos, para obter latências de milissegundos até mesmo em consultas analíticas complexas. A Rockset foi pioneira , que permite o isolamento de cargas de trabalho em unidades de computação separadas enquanto compartilha os mesmos dados subjacentes em tempo real. Isso oferece aos usuários maior eficiência de recursos ao oferecer suporte a ingestão e consultas simultâneas ou a vários aplicativos no mesmo conjunto de dados. na separação computação-computação Além disso, Rockset cuida da segurança, criptografia de dados e controle de acesso baseado em funções para gerenciar o acesso a eles. Os usuários do Rockset podem evitar a necessidade de ETL aproveitando que podemos configurar no Rockset para modificar os dados à medida que chegam a uma coleção. Os usuários também podem gerenciar opcionalmente o ciclo de vida dos dados configurando políticas de retenção para limpar automaticamente os dados mais antigos. Tanto a ingestão de dados quanto o atendimento de consultas são gerenciados automaticamente, o que nos permite focar na criação e implantação de painéis e aplicativos em tempo real, eliminando a necessidade de gerenciamento e operações de infraestrutura. as transformações de ingestão Especialmente relevante em relação à sincronização com o DynamoDB, o Rockset oferece suporte a atualizações locais em nível de campo, para evitar reindexações dispendiosas. em termos de ingestão, consulta e eficiência para escolher a ferramenta certa para o trabalho. Compare o Rockset e o Elasticsearch Resumo Desenvolvido para oferecer QPS alto e atender aplicativos em tempo real Completamente sem servidor. Não são necessárias operações ou provisionamento de infraestrutura ou banco de dados Separação computação-computação para desempenho previsível e utilização eficiente de recursos Sincronização ao vivo entre o DynamoDB e a coleção Rockset, para que eles nunca tenham mais do que alguns segundos de intervalo Monitoramento para garantir consistência entre DynamoDB e Rockset Índices automáticos criados sobre os dados, permitindo consultas de baixa latência Atualizações locais que evitam reindexações dispendiosas e reduzem a latência dos dados Une-se a dados de outras fontes, como Amazon Kinesis, Apache Kafka, Amazon S3, etc. Podemos usar o Rockset para implementar sem quaisquer preocupações operacionais, de escalonamento ou de manutenção. Isso pode acelerar significativamente o desenvolvimento de aplicativos em tempo real. Se quiser criar seu aplicativo com dados do DynamoDB usando Rockset, você pode começar gratuitamente . análises em tempo real dos dados no DynamoDB aqui
