As expectativas dos clientes e as correspondentes demandas nas aplicações nunca foram tão altas. Os usuários esperam que os aplicativos sejam rápidos, confiáveis e disponíveis. Além disso, os dados são fundamentais e os usuários desejam poder dividir e dividir os dados agregados conforme necessário para encontrar insights. Os usuários não querem esperar que os engenheiros de dados provisionem novos índices ou construam novas cadeias ETL. Eles querem acesso irrestrito aos dados mais recentes disponíveis. Mas lidar com todas as necessidades do seu aplicativo é uma tarefa difícil para qualquer banco de dados. Para o banco de dados, a otimização para operações frequentes e de baixa latência em registros individuais é diferente da otimização para agregações menos frequentes ou filtragem pesada em muitos registros. Muitas vezes, tentamos lidar com ambos os padrões com o mesmo banco de dados e lidar com o desempenho inconsistente à medida que nosso aplicativo é dimensionado. Achamos que estamos otimizando com esforço ou custo mínimo, quando na verdade estamos fazendo o oposto. A execução de análises em um banco de dados OLTP geralmente exige um provisionamento excessivo de um banco de dados para dar conta de picos de tráfego. Isso acaba custando muito dinheiro e geralmente não proporciona uma experiência agradável ao usuário final. Neste passo a passo, veremos como lidar com as altas demandas de usuários com esses dois padrões de acesso. Estaremos construindo um aplicativo financeiro no qual os usuários registram transações e visualizam transações recentes, ao mesmo tempo que desejam filtragem complexa ou agregações em suas transações anteriores. Uma abordagem híbrida Para atender às necessidades de nossos aplicativos, usaremos com . O DynamoDB lidará com nossos principais padrões de acesso a transações – registrando transações e fornecendo um feed de transações recentes para os usuários navegarem. O Rockset complementará o DynamoDB para lidar com nossos padrões de acesso "deliciosos" e com muitos dados. Permitiremos que nossos usuários filtrem por horário, comerciante, categoria ou outros campos para encontrar as transações relevantes ou para realizar agregações poderosas para visualizar tendências de gastos ao longo do tempo. Amazon DynamoDB Rockset À medida que trabalharmos com esses padrões, veremos como cada um desses sistemas é adequado ao trabalho em questão. O DynamoDB é excelente nas principais operações OLTP – leitura ou gravação de um item individual ou busca de uma série de itens sequenciais com base em filtros conhecidos. Devido à forma como particiona os dados com base na chave primária, o DynamoDB é capaz de fornecer desempenho consistente para esses tipos de consultas em qualquer escala. Por outro lado, o Rockset se destaca na ingestão contínua de grandes quantidades de dados e no emprego de diversas estratégias de indexação nesses dados para fornecer filtragem altamente seletiva, agregações em tempo real ou em tempo de consulta e outros padrões que o DynamoDB não consegue lidar facilmente. À medida que trabalharmos neste exemplo, aprenderemos os conceitos fundamentais subjacentes aos dois sistemas, bem como as etapas práticas para atingir nossos objetivos. Você pode acompanhar o aplicativo usando o . repositório GitHub Implementando recursos principais com DynamoDB Começaremos este passo a passo implementando os principais recursos de nosso aplicativo. Este é um ponto de partida comum para qualquer aplicativo, à medida que você cria as operações "CRUDL" padrão para fornecer a capacidade de manipular registros individuais e listar um conjunto de registros relacionados. Para um aplicativo de comércio eletrônico, esta seria a funcionalidade de fazer um pedido e visualizar pedidos anteriores. Para um aplicativo de mídia social, isso seria criar postagens, adicionar amigos ou visualizar as pessoas que você segue. Essa funcionalidade normalmente é implementada por bancos de dados especializados em fluxos de trabalho que enfatizam muitas operações simultâneas em um pequeno número de linhas. de processamento transacional online (OLTP) Para este exemplo, estamos construindo um aplicativo financeiro empresarial onde um usuário pode fazer e receber pagamentos, bem como visualizar o histórico de suas transações. O exemplo será intencionalmente simplificado para este passo a passo, mas você pode pensar em três padrões principais de acesso para nosso aplicativo: , que armazenará o registro de um pagamento realizado ou recebido pela empresa; Registrar transação , o que permitirá aos usuários ver os pagamentos mais recentes feitos e recebidos por uma empresa; e Visualize as transações por intervalo de datas , o que permitirá que um usuário se aprofunde nas especificidades de uma única transação. Visualize transações individuais Cada um desses padrões de acesso é um padrão de acesso crítico e de alto volume. Registraremos constantemente as transações dos usuários, e o feed de transações será a primeira visualização quando eles abrirem o aplicativo. Além disso, cada um desses padrões de acesso utilizará parâmetros conhecidos e consistentes para buscar o(s) registro(s) relevante(s). Usaremos o DynamoDB para lidar com esses padrões de acesso. DynamoDB é um banco de dados NoSQL fornecido pela AWS. É um banco de dados totalmente gerenciado e tem popularidade crescente tanto em aplicativos de alta escala quanto em aplicativos sem servidor. Um dos recursos mais exclusivos do DynamoDB é como ele fornece desempenho consistente em qualquer escala. Quer sua tabela tenha 1 megabyte ou 1 petabyte, você deverá ver o mesmo tempo de resposta para suas operações. Essa é uma qualidade desejável para casos de uso OLTP essenciais, como os que estamos implementando aqui. Esta é uma grande e valiosa conquista de engenharia, mas é importante compreender que ela foi alcançada por meio de uma seleção seletiva quanto aos tipos de consultas que terão um bom desempenho. O DynamoDB é capaz de fornecer esse desempenho consistente por meio de duas decisões principais de design. Primeiro, cada registro na tabela do DynamoDB deve incluir uma chave primária. Esta chave primária é composta por uma chave de partição e também por uma chave de classificação opcional. A segunda decisão importante de design do DynamoDB é que a API impõe fortemente o uso da chave primária – falaremos mais sobre isso posteriormente. Na imagem abaixo, temos alguns exemplos de dados de transações em nosso aplicativo FinTech. Nossa tabela usa uma chave de partição do nome da organização em nosso aplicativo, além de uma chave de classificação baseada em que fornece as características de exclusividade de um UUID, além de classificação por horário de criação que nos permite fazer consultas baseadas em tempo. ULID Os registros em nossa tabela incluem outros atributos, como nome do comerciante, categoria e valor, que são úteis em nossa aplicação, mas não são tão críticos para a arquitetura subjacente do DynamoDB. A parte importante está na chave primária e, especificamente, na chave de partição. Nos bastidores, o DynamoDB dividirá seus dados em várias partições de armazenamento, cada uma contendo um subconjunto dos dados em sua tabela. O DynamoDB usa o elemento chave de partição da chave primária para atribuir um determinado registro a uma partição de armazenamento específica. À medida que a quantidade de dados em sua tabela ou o tráfego em sua tabela aumenta, o DynamoDB adicionará partições como uma forma de dimensionar horizontalmente seu banco de dados. Conforme mencionado acima, a segunda decisão principal de design do DynamoDB é que a API impõe fortemente o uso da chave primária. Quase todas as ações de API no DynamoDB exigem pelo menos a chave de partição da sua chave primária. Por causa disso, o DynamoDB é capaz de rotear rapidamente qualquer solicitação para a partição de armazenamento adequada, independentemente do número de partições e do tamanho total da tabela. Com essas duas compensações, há necessariamente limitações na forma como você usa o DynamoDB. Você deve planejar e projetar cuidadosamente seus padrões de acesso antecipadamente, pois sua chave primária deve estar envolvida em seus padrões de acesso. Alterar seus padrões de acesso posteriormente pode ser difícil e exigir algumas etapas manuais de migração. Quando seus casos de uso se enquadrarem nas competências principais do DynamoDB, você colherá os benefícios. Você obterá um desempenho consistente e previsível, independentemente da escala, e não verá degradação de longo prazo em seu aplicativo ao longo do tempo. Além disso, você terá uma experiência totalmente gerenciada com baixa carga operacional, permitindo que você se concentre no que é importante para o negócio. As operações principais em nosso exemplo se encaixam perfeitamente neste modelo. Ao recuperar um feed de transações para uma organização, teremos o ID da organização disponível em nosso aplicativo que nos permitirá usar a operação DynamoDB para buscar um conjunto contíguo de registros com a mesma chave de partição. Para recuperar detalhes adicionais sobre uma transação específica, teremos o ID da organização e o ID da transação disponíveis para fazer uma solicitação do DynamoDB para buscar o item desejado. Query GetItem Você pode ver essas operações em ação com o . Siga as instruções para implantar o aplicativo e propagá-lo com dados de amostra. Em seguida, faça solicitações HTTP ao serviço implantado para buscar o feed de transações para usuários individuais. Essas operações serão rápidas e eficientes, independentemente do número de solicitações simultâneas ou do tamanho da tabela do DynamoDB. aplicativo de amostra Complementando DynamoDB com Rockset Até agora, usamos o DynamoDB para lidar com nossos principais padrões de acesso. O DynamoDB é ótimo para esses padrões, pois seu particionamento baseado em chave fornecerá desempenho consistente em qualquer escala. No entanto, o DynamoDB não é bom para lidar com outros padrões de acesso. O DynamoDB não permite consultar com eficiência por atributos diferentes da chave primária. Você pode usar para reindexar seus dados por atributos adicionais, mas ainda pode ser problemático se você tiver muitos atributos diferentes que podem ser usados para indexar seus dados. os índices secundários do DynamoDB Além disso, o DynamoDB não fornece nenhuma funcionalidade de agregação pronta para uso. Você pode calcular suas próprias agregações usando o DynamoDB, mas isso pode ocorrer com flexibilidade reduzida ou com consumo de leitura não otimizado em comparação com uma solução projetada para agregação antecipadamente. Para lidar com esses padrões, . complementaremos o DynamoDB com Rockset Rockset é melhor considerado como um conjunto secundário de índices em seus dados. O Rockset usa apenas esses índices no momento da consulta e não projeta nenhuma carga de volta no DynamoDB durante uma leitura. Em vez de atualizações transacionais individuais de seus clientes de aplicativos, o Rockset foi projetado para ingestão contínua e de streaming de seu armazenamento de dados primário. Possui conectores diretos para vários armazenamentos de dados primários, incluindo DynamoDB, MongoDB, Kafka e muitos bancos de dados relacionais. À medida que o Rockset ingere dados do seu banco de dados primário, ele indexa seus dados em um , que empresta conceitos de: um índice de linha, um índice invertido e um índice colunar. Índices adicionais, como intervalo, tipo e geoespacial, são criados automaticamente com base nos tipos de dados ingeridos. Discutiremos as especificidades desses índices abaixo, mas este Índice Convergente permite padrões de acesso mais flexíveis aos seus dados. Índice Convergente Este é o conceito central por trás do Rockset: é um índice secundário em seus dados usando um pipeline de ingestão totalmente gerenciado e quase em tempo real do seu armazenamento de dados primário. As equipes há muito extraem dados do DynamoDB para inseri-los em outro sistema para lidar com casos de uso adicionais. Antes de entrarmos nos detalhes de como o Rockset ingere dados da sua tabela, vamos discutir brevemente como o Rockset difere de outras opções neste espaço. Existem algumas diferenças fundamentais entre o Rockset e outras abordagens. Em primeiro lugar, o Rockset é totalmente gerenciado. Você não apenas não é obrigado a gerenciar a infraestrutura do banco de dados, mas também não precisa manter o pipeline para extrair, transformar e carregar dados no Rockset. Com muitas outras soluções, você é responsável pela “cola” do código entre seus sistemas. Esses sistemas são críticos, mas sujeitos a falhas, pois você deve se proteger defensivamente contra quaisquer alterações na estrutura de dados. Mudanças a montante podem resultar em dificuldades a jusante para aqueles que mantêm esses sistemas. Em segundo lugar, o Rockset pode lidar com dados em tempo real de forma mutável. Com muitos outros sistemas, você obtém um ou outro. Você pode optar por realizar exportações e carregamentos em massa periódicos de seus dados, mas isso resulta em dados obsoletos entre os carregamentos. Como alternativa, você pode transmitir dados para seu data warehouse apenas com acréscimos, mas não pode realizar atualizações no local em dados alterados. Rockset é capaz de lidar com atualizações em itens existentes com a mesma rapidez e eficiência que insere novos dados e, portanto, pode fornecer uma visão em tempo real de seus dados alterados. Em terceiro lugar, o Rockset gera seus índices automaticamente. Outras soluções 'totalmente gerenciadas' ainda exigem que você configure índices conforme necessário para dar suporte a novas consultas. O mecanismo de consulta do Rockset foi projetado para usar um conjunto de índices para suportar toda e qualquer consulta. À medida que você adiciona mais e mais consultas ao seu sistema, você não precisa adicionar índices adicionais, ocupando cada vez mais espaço e recursos computacionais. Isso também significa que consultas ad hoc também podem aproveitar totalmente os índices, tornando-as rápidas sem esperar que um administrador adicione um índice personalizado para suportá-las. Como o Rockset ingere dados do DynamoDB Agora que sabemos o básico do que é Rockset e como ele nos ajuda, vamos conectar nossa tabela DynamoDB ao Rockset. Ao fazer isso, aprenderemos como funciona o processo de ingestão do Rockset e como ele difere de outras opções. Rockset possui conectores específicos para diversas fontes de dados, e a implementação específica do conector depende das especificações da fonte de dados upstream. Para se conectar ao DynamoDB, o Rockset depende do . DynamoDB Streams é um recurso de captura de dados alterados do DynamoDB em que detalhes de cada operação de gravação em uma tabela do DynamoDB são registrados no stream. Os consumidores do fluxo podem processar essas alterações na mesma ordem em que ocorreram na tabela para atualizar os sistemas downstream. DynamoDB Streams Um fluxo do DynamoDB é ótimo para o Rockset se manter atualizado com uma tabela do DynamoDB quase em tempo real, mas não é a história completa. Um Stream do DynamoDB contém apenas registros de operações de gravação que ocorreram depois que o Stream foi habilitado na tabela. Além disso, um . As operações que ocorreram antes da ativação do stream ou há mais de 24 horas não estarão presentes no stream. fluxo do DynamoDB retém registros por apenas 24 horas Mas o Rockset precisa não apenas dos dados mais recentes, mas de todos os dados do seu banco de dados para responder corretamente às suas consultas. Para lidar com isso, ele faz uma exportação em massa inicial (usando um DynamoDB Scan ou , dependendo do tamanho da sua tabela) para obter o estado inicial da sua tabela. uma exportação para S3 Assim, o processo de conexão do DynamoDB do Rockset consiste em duas partes: Um processo inicial para exportar sua tabela completa para ingestão no Rockset; de inicialização Um processo subsequente e para consumir atualizações do seu DynamoDB Stream e atualizar os dados no Rockset. contínuo Observe que ambos os processos são totalmente gerenciados pela Rockset e transparentes para você como usuário. Você não será responsável por manter esses pipelines e responder a alertas se houver algum erro. Além disso, se você escolher o método de exportação S3 para o processo de ingestão inicial, nenhum dos processos de ingestão do Rockset consumirá unidades de capacidade de leitura da sua tabela principal. Assim, o Rockset não retirará o consumo dos casos de uso da sua aplicação nem afetará a disponibilidade de produção. Aplicativo: Conectando DynamoDB ao Rockset Antes de passar a usar o Rockset em nosso aplicativo, vamos conectar o Rockset à nossa tabela DynamoDB. Primeiro, precisamos criar uma nova integração entre o Rockset e a nossa mesa. Percorreremos as etapas de alto nível abaixo, mas você pode encontrar se necessário. instruções passo a passo mais detalhadas no repositório do aplicativo, No console Rockset, navegue até o para iniciar este processo. novo assistente de integração No assistente de integração, escolha como tipo de integração. Em seguida, clique em para passar para a próxima etapa. Amazon DynamoDB Iniciar O assistente de integração do DynamoDB possui instruções passo a passo para autorizar o Rockset a acessar sua tabela do DynamoDB. Isso requer a criação de uma política do IAM, uma função do IAM e um bucket S3 para a exportação da sua tabela. Você pode seguir essas instruções para criar os recursos manualmente, se preferir. No mundo sem servidor, preferimos criar coisas por meio tanto quanto possível, e isso inclui esses recursos de suporte. de infraestrutura como código, O repositório de exemplo inclui a infraestrutura como código necessária para criar os recursos de integração do Rockset. Para usá-los, primeiro encontre os valores de ID da conta Rockset e ID externo na parte inferior do assistente de integração Rockset. Copie e cole esses valores nas bloco do arquivo serverless.yml. Em seguida, para criar esses recursos. seções relevantes do custom remova o comentário dos recursos nas linhas 71 a 122 do serverless.yml Reimplante seu aplicativo para criar esses novos recursos. Nas saídas da implantação, copie e cole o nome do bucket S3 e o ARN da função IAM nos locais apropriados no console do Rockset. Em seguida, clique no botão Salvar integração para salvar sua integração. Depois de criar sua integração, você precisará criar uma a partir da integração. Navegue até o no console Rockset e siga as etapas para usar sua integração para criar uma coleção. Você também pode encontrar no repositório do aplicativo. coleção Rockset assistente de criação de coleção instruções passo a passo para criar uma coleção Depois de concluir essa conexão, geralmente em um conjunto de instâncias de tamanho adequado, inserções, atualizações ou exclusões de dados no DynamoDB serão refletidas no índice do Rockset e estarão disponíveis para consulta em menos de 2 segundos. Usando Rockset para filtragem complexa Agora que conectamos o Rockset à nossa tabela DynamoDB, vamos ver como o Rockset pode habilitar novos padrões de acesso em nossos dados existentes. Lembre-se de nossa seção de recursos principais que o DynamoDB está fortemente focado em suas chaves primárias. Você deve usar sua chave primária para acessar seus dados com eficiência. Dessa forma, estruturamos nossa tabela para usar o nome da organização e o horário da transação em nossas chaves primárias. Essa estrutura funciona para nossos principais padrões de acesso, mas podemos querer fornecer uma maneira mais flexível para os usuários navegarem em suas transações. Existem vários atributos úteis – categoria, nome do comerciante, quantidade, etc. – que podem ser úteis na filtragem. Poderíamos usar os índices secundários do DynamoDB para permitir a filtragem de mais atributos, mas isso ainda não é uma boa opção aqui. A estrutura de chave primária do DynamoDB não permite facilmente consultas flexíveis que envolvem combinações de muitos atributos opcionais. Você poderia ter um índice secundário para filtrar por nome e data do comerciante, mas precisaria de outro índice secundário se quisesse permitir a filtragem por nome, data e valor do comerciante. Um padrão de acesso que filtra por categoria exigiria um terceiro índice secundário. Em vez de lidar com essa complexidade, vamos nos apoiar no Rockset aqui. Vimos antes que o Rockset usa um Índice Convergente para indexar seus dados de várias maneiras. Uma dessas maneiras é um índice invertido. Com um índice invertido, o Rockset indexa cada atributo diretamente. Observe como esse índice está organizado. Cada nome e valor de atributo é usado como a chave do índice, e o valor é uma lista de IDs de documentos que incluem o nome e o valor do atributo correspondente. As chaves são construídas para que sua ordem de classificação natural possa suportar consultas de intervalo com eficiência. Um índice invertido é ótimo para consultas que possuem condições de filtro seletivo. Imagine que queremos permitir que nossos usuários filtrem suas transações para encontrar aquelas que atendem a determinados critérios. Alguém na organização Vandelay Industries está interessado em saber quantas vezes encomendou Chipotle recentemente. Você pode encontrar isso com uma consulta como segue: SELECT * FROM transactions WHERE organization = 'Vandelay Industries' AND merchant_name = 'Chipotle' Como estamos fazendo filtros seletivos no nome do cliente e do comerciante, podemos usar o índice invertido para encontrar rapidamente os documentos correspondentes. O Rockset procurará os pares de nomes e valores de atributos no índice invertido para encontrar as listas de documentos correspondentes. Depois de ter essas duas listas, ele pode mesclá-las para encontrar o conjunto de registros que corresponda a ambos os conjuntos de condições e retornar os resultados ao cliente. Assim como a indexação baseada em partição do DynamoDB é eficiente para operações que usam a chave de partição, o índice invertido do Rockset oferece pesquisas eficientes em qualquer campo do seu conjunto de dados, até mesmo em atributos de objetos incorporados ou em valores dentro de matrizes incorporadas. Aplicação: Usando a API Rockset em sua aplicação Agora que sabemos como o Rockset pode executar consultas seletivas com eficiência em nosso conjunto de dados, vamos examinar os aspectos práticos da integração de consultas do Rockset em nosso aplicativo. Rockset expõe serviços RESTful protegidos por um token de autorização. SDKs também estão disponíveis para linguagens de programação populares. Isso o torna ideal para integração com aplicativos sem servidor, porque você não precisa definir configurações complicadas de rede privada para acessar seu banco de dados. Para interagir com a API Rockset em nosso aplicativo, precisaremos de uma chave de API Rockset. Você pode criar uma na do console Rockset. Depois de fazer isso, copie seu valor em seu arquivo serverless.yml e reimplante para disponibilizá-lo para seu aplicativo. seção de chaves de API Observação lateral: para simplificar, estamos usando esta chave de API como uma variável de ambiente. Em uma aplicação real, você deve usar algo como ou para armazenar seu segredo e evitar variáveis de ambiente. Parameter Store AWS Secrets Manager Veja nossa para ver como interagimos com a API Rockset. A inicialização da classe leva um objeto cliente Rockset que será usado para fazer chamadas ao Rockset. classe TransactionService No , temos a seguinte consulta para interagir com o Rockset: método filterTransactions da nossa classe de serviço const response = await this._rocksetClient.queries.query({ sql: { query: ` SELECT * FROM Transactions WHERE organization = :organization AND category = :category AND amount BETWEEN :minAmount AND :maxAmount ORDER BY transactionTime DESC LIMIT 20`, parameters: [ { name: "organization", type: "string", value: organization, }, { name: "category", type: "string", value: category, }, { name: "minAmount", type: "float", value: minAmount, }, { name: "maxAmount", type: "float", value: maxAmount, }, ], }, }); Há duas coisas a serem observadas sobre essa interação. Primeiro, estamos usando parâmetros nomeados em nossa consulta ao lidar com entradas de usuários. Esta é uma prática comum com bancos de dados SQL para evitar ataques de injeção de SQL. Em segundo lugar, o código SQL está misturado ao código do nosso aplicativo e pode ser difícil de rastrear ao longo do tempo. Embora isso possa funcionar, existe uma maneira melhor. À medida que aplicamos nosso próximo caso de uso, veremos como usar Rockset Query Lambdas em nossa aplicação. Usando Rockset para agregação Até este ponto, revisamos as estratégias de indexação do DynamoDB e do Rockset ao discutir como o banco de dados pode encontrar um registro individual ou conjunto de registros que corresponda a um predicado de filtro específico. Por exemplo, vimos que o DynamoDB incentiva você a usar uma chave primária para encontrar um registro, enquanto o índice invertido do Rockset pode encontrar registros com eficiência usando condições de filtro altamente seletivas. Nesta seção final, mudaremos um pouco de assunto para focar no layout dos dados, em vez de indexar diretamente. Ao pensar sobre o layout dos dados, contrastaremos duas abordagens: baseada em linhas e baseada em colunas. Bancos de dados baseados em linhas, como o nome indica, organizam seus dados no disco em linhas. A maioria dos bancos de dados relacionais, como PostgreSQL e MySQL, são bancos de dados baseados em linhas. O mesmo acontece com muitos bancos de dados NoSQL, como o DynamoDB, mesmo que seus registros não sejam tecnicamente “linhas” no sentido de banco de dados relacional. Bancos de dados baseados em linhas são ótimos para os padrões de acesso que vimos até agora. Ao buscar uma transação individual por seu ID ou um conjunto de transações de acordo com algumas condições de filtro, geralmente queremos que todos os campos retornem para cada uma das transações. Como todos os campos do registro são armazenados juntos, geralmente é necessária uma única leitura para retornar o registro. (Nota: algumas nuances sobre isso chegarão em breve). A agregação é uma história completamente diferente. Com consultas de agregação, queremos calcular um agregado – uma contagem de todas as transações, uma soma dos totais de transações ou um gasto médio por mês para um conjunto de transações. Voltando ao usuário da organização Vandelay Industries, imagine que ele queira olhar os últimos três meses e descobrir o gasto total por categoria para cada mês. Uma versão simplificada dessa consulta seria a seguinte: SELECT category, EXTRACT(month FROM transactionTime) AS month, sum(amount) AS amount FROM transactions WHERE organization = 'Vandelay Industries' AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month ORDER BY category, month DESC Para esta consulta, pode haver um grande número de registros que precisam ser lidos para calcular o resultado. No entanto, observe que não precisamos de muitos campos para cada um de nossos registros. Precisamos de apenas quatro – categoria, transactionTime, organização e quantidade – para determinar esse resultado. Assim, não apenas precisamos ler muito mais registros para satisfazer esta consulta, mas também nosso layout baseado em linhas lerá vários campos que são desnecessários para nosso resultado. Por outro lado, um layout baseado em colunas armazena dados no disco em colunas. O Índice Convergente do Rockset usa um índice colunar para armazenar dados em um layout baseado em colunas. Em um layout baseado em colunas, os dados são armazenados juntos por colunas. Um registro individual é fragmentado em suas colunas constituintes para indexação. Se minha consulta precisar fazer uma agregação para somar o atributo "quantidade" para um grande número de registros, o Rockset poderá fazer isso simplesmente verificando a parte "quantidade" do índice colunar. Isso reduz enormemente a quantidade de dados lidos e processados em comparação com layouts baseados em linhas. Observe que, por padrão, o índice colunar do Rockset não ordenará os atributos dentro de uma coluna. Como temos casos de uso voltados para o usuário que operarão com dados de um cliente específico, preferiríamos organizar nosso índice colunar por cliente para reduzir a quantidade de dados a serem verificados ao usar o índice colunar. Rockset fornece para ajudar com isso. Com o clustering, podemos indicar que queremos que nosso índice colunar seja clusterizado pelo atributo “organização”. Isso agrupará todos os valores das colunas da organização nos índices colunares. Assim, quando a Vandelay Industries está agregando seus dados, o processador de consultas do Rockset pode pular as partes do índice colunar para outros clientes. clustering de dados em seu índice colunar Como o índice baseado em linhas do Rockset ajuda no processamento Antes de passarmos a usar o índice colunar em nossa aplicação, quero falar sobre outro aspecto do Índice Convergente do Rockset. Anteriormente, mencionei que layouts baseados em linhas foram usados ao recuperar registros completos e indiquei que tanto o DynamoDB quanto nossas consultas de índice invertido do Rockset estavam usando esses layouts. Isso é apenas parcialmente verdade. O índice invertido tem algumas semelhanças com um índice baseado em colunas, pois armazena nomes e valores de colunas juntos para pesquisas eficientes por qualquer atributo. Cada entrada de índice inclui um ponteiro para os IDs dos registros que incluem o nome da coluna e a combinação de valores fornecidos. Depois que o ID ou IDs relevantes forem descobertos no índice invertido, o Rockset poderá recuperar o registro completo usando o índice de linha. Rockset usa codificação de dicionário e outras técnicas avançadas de compactação para minimizar o tamanho do armazenamento de dados. Assim, vimos agora como o Índice Convergente do Rockset se encaixa: O é usado para verificar rapidamente um grande número de valores em uma coluna específica em busca de agregações; índice baseado em coluna O é usado para filtros seletivos em qualquer nome e valor de coluna; índice invertido O é usado para buscar quaisquer atributos adicionais que possam ser referenciados na cláusula de projeção. índice baseado em linha Nos bastidores, o poderoso mecanismo de indexação e consulta do Rockset rastreia estatísticas sobre seus dados e gera planos ideais para executar sua consulta com eficiência. Aplicação: Usando Rockset Query Lambdas em sua aplicação Vamos implementar nossa consulta de agregação Rockset que usa o índice colunar. Para nossa consulta anterior, escrevemos nossa consulta SQL diretamente na API Rockset. Embora esta seja a coisa certa a fazer em algumas interfaces de usuário altamente personalizáveis, há uma opção melhor quando o código SQL é mais estático. Gostaríamos de evitar manter nosso código SQL confuso no meio da lógica do nosso aplicativo. Para ajudar com isso, o Rockset possui um recurso chamado Query Lambdas. Query Lambdas são consultas nomeadas, versionadas e parametrizadas que são registradas no console Rockset. Depois de configurar um Query Lambda no Rockset, você receberá um endpoint totalmente gerenciado e escalonável para o Query Lambda que pode chamar com seus parâmetros para serem executados pelo Rockset. Além disso, você ainda obterá estatísticas de monitoramento para cada Query Lambda, para que possa acompanhar o desempenho do seu Query Lambda conforme você faz alterações. Você pode , mas vamos configurar nosso primeiro Query Lambda para lidar com nossa consulta de agregação. Um . aprender mais sobre Query Lambdas aqui passo a passo completo pode ser encontrado no repositório do aplicativo Navegue até a do console Rockset. Cole a seguinte consulta no editor: seção Query Editor SELECT category, EXTRACT( month FROM transactionTime ) as month, EXTRACT( year FROM transactionTime ) as year, TRUNCATE(sum(amount), 2) AS amount FROM Transactions WHERE organization = :organization AND transactionTime > CURRENT_TIMESTAMP() - INTERVAL 3 MONTH GROUP BY category, month, year ORDER BY category, month, year DESC Esta consulta agrupará as transações dos últimos três meses de uma determinada organização em grupos com base na categoria específica e no mês da transação. Em seguida, somará os valores de uma categoria por mês para encontrar o valor total gasto em cada mês. Observe que ele inclui um parâmetro para o atributo "organização", conforme indicado pela sintaxe ":organização" na consulta. Isso indica que um valor de organização deve ser transmitido para executar a consulta. Salve a consulta como Query Lambda no console Rockset. Em seguida, observe o . Ele chama o Query Lambda pelo nome e passa a propriedade "organização" que foi fornecida por um usuário. código fetchTransactionsByCategoryAndMonth em nossa classe TransactionService Este é um código muito mais simples de manusear em nosso aplicativo. Além disso, o Rockset fornece controle de versão e monitoramento específico de consulta para cada Query Lambda. Isso torna mais fácil manter suas consultas ao longo do tempo e entender como as alterações na sintaxe da consulta afetam o desempenho. Conclusão Nesta postagem, vimos como usar DynamoDB e Rockset juntos para construir uma experiência de aplicação rápida e agradável para nossos usuários. Ao fazer isso, aprendemos os fundamentos conceituais e as etapas práticas para implementar nosso aplicativo. Primeiro, usamos o DynamoDB para lidar com a funcionalidade principal do nosso aplicativo. Isso inclui padrões de acesso, como recuperar um feed de transação para um cliente específico ou visualizar uma transação individual. Devido à estratégia de particionamento baseada em chave primária do DynamoDB, ele é capaz de fornecer desempenho consistente em qualquer escala. Mas o design do DynamoDB também limita sua flexibilidade. Ele não pode lidar com consultas seletivas em campos arbitrários ou agregações em um grande número de registros. Para lidar com esses padrões, usamos Rockset. Rockset fornece um índice secundário totalmente gerenciado para potencializar aplicativos com muitos dados. Vimos como o Rockset mantém um pipeline de ingestão contínua de seu armazenamento de dados primário que indexa seus dados em um Índice Convergente, que combina indexação invertida, colunar e de linha. À medida que percorremos nossos padrões, vimos como cada uma das técnicas de indexação do Rockset funciona em conjunto para lidar com experiências de usuário agradáveis. Por fim, seguimos as etapas práticas para conectar o Rockset à nossa tabela DynamoDB e interagir com o Rockset em nossa aplicação. Também aparece . aqui
