Deep dive de Amazon DynamoDB
•Transferir como PPTX, PDF•
1 gostou•784 visualizações
"O Amazon DynamoDB é um serviço de banco de dados NoSQL, totalmente gerenciado, para aplicativos que precisam de latência consistente de um dígito de milissegundos em qualquer escala. Nesta sessão iremos explorar as capacidades e benefícios do DynamoDB em detalhes e iremos discutir como obter o máximo do seu banco de dados DynamoDB. Examinaremos as melhores práticas de design de schema com o DynamoDB em vários casos de uso, incluindo jogos, AdTech, IoT e outros. Também exploraremos o design de índices eficientes, scanning e queries, e detalharemos as funcionalidades lançadas recentemente, incluindo o suporte a documentos JSON, Streams, Time-to-Live (TTL) e muito mais." https://aws.amazon.com/pt/dynamodb/
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Deep dive de Amazon DynamoDB
Semelhante a Deep dive de Amazon DynamoDB (20)
Mais de Amazon Web Services LATAM
Mais de Amazon Web Services LATAM (20)
Deep dive de Amazon DynamoDB
- 1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Daniela Binatti | CTO | Pismo Regis Gimenis | Sr. Consultant | AWS Professional Services Deep Dive em Amazon DynamoDB
- 2. Agenda Componentes do DynamoDB Modelagem de dados Cenários e recomendações Estudo de caso:
- 3. Amazon DynamoDB Serviço gerenciado de banco de dados NoSQL Alta escalabilidade Alta disponibilidade Desempenho rápido e consistente Flexível, compatível com estruturas de dados de documentos e chave-valor API simples e poderosa
- 5. Tabelas do DynamoDB Tabelas Itens Atributos Chave de Partição Chave de Ordenação Mandatória Padrão de acesso chave-valor Define a distribuição dos dados Opcional Relacionamentos 1:N Habilita consultas ricas Todos os itens ==, <, >, >=, <= “begins with” “between” resultados ordenados contagens primeiros/últimos valores respostas paginadas
- 7. Tipos de dados String (S) Number (N) Binary (B) String Set (SS) Number Set (NS) Binary Set (BS) Boolean (BOOL) Null (NULL) List (L) Map (M) Utilizados para armazenar documentos JSON
- 8. 00 55 A954 AA FF Tabelas com chave de partição Chave de partição identifica unicamente um item Chave de partição é utilizada para construir um índice hash não-ordenado 00 FF Id = 1 Nome = Jim Hash (1) = 7B Id = 2 Nome = Andy Depto = Eng Hash (2) = 48 Id = 3 Nome = Kim Depto = Ops Hash (3) = CD Key Space
- 9. Réplicas de partições Id = 2 Nome = Andy Depto = Eng Id = 3 Nome = Kim Depto = Ops Id = 1 Nome = Jim Id = 2 Nome = Andy Depto = Eng Id = 3 Nome = Kim Depto = Ops Id = 1 Nome = Jim Id = 2 Nome = Andy Depto = Eng Id = 3 Nome = Kim Depto = Ops Id = 1 Nome = Jim Réplica1 Réplica 2 Réplica 3 Partição1 Partição 2 Partição N
- 10. Tabelas com chaves de partição e ordenação Chave de partição e chave de ordenação identificam unicamente um item Dados armazenados ordenados pela chave de ordenação para mesma chave de partição 00:0 FF:∞ Hash (2) = 48 Cliente#= 2 Pedido# = 10 Item = Caneta Cliente# = 2 Pedido# = 11 Item = Calçado Cliente# = 1 Pedido# = 10 Item = Brinquedo Cliente# = 1 Pedido# = 11 Item = Tênis Hash (1) = 7B Cliente# = 3 Pedido# = 10 Item = Livro Cliente# = 3 Pedido# = 11 Item = Papel Hash (3) = CD 55 A9:∞54:∞ AA Partição 1 Partição 2 Partição 3
- 11. Índices
- 12. Índice secundário global (GSI) Chave de partição alternativa GSIs A5 (part.) A4 (ord.) A1 (chave) A3 (projetado) Tabela Incluir atributo A3 A4 (part.) A5 (ord.) A1 (chave) A2 (projetado) A3 (projetado) ALL A2 (part.) A1 (chave) KEYS_ONLY RCUs e WCUs são provisionados separadamente para GSI A1 (partição) A2 A3 A4 A5
- 13. Atualização de GSI Tabela Primary table Primary table Primary table Primary table Índice Secundário Global Aplicação cliente 3. Atualização assíncrona Se o GSI não tiver capacidade de escrita suficiente, a escrita na tabela pode ser afetada
- 14. Índice secundário local (LSI) Permite definir uma chave de ordenação alternativa Índice é localizado na mesma partição da tabela A1 (partição) A3 (ord.) A2 (chave) A1 (partição) A2 (ord.) A3 A4 A5 LSIs A1 (partição) A4 (ord.) A2 (chave) A3 (projetado) KEYS_ONLY Incluir atributo A3 A1 (partição) A5 (ord.) A2 (chave) A3 (projetado) A4 (projetado) ALL Para cada valor de chave de partição, o tamanho total não pode exceder 10GB Tabela
- 15. Escalabilidade
- 16. Escalabilidade Tabelas não possuem limite de número de itens Tamanho máximo dos itens é de 400KB Escalabilidade é alcançada através de uso de partições Tamanho aproximado de 10GB Máximo de 3000 unidades de capacidade de leitura Máximo de 1000 unidades de capacidade de escrita
- 17. Capacidade Capacidade é provisionada por tabelas e GSIs • Unidade de capacidade de escrita (WCU) medida em 1KB / s • Unidade de capacidade de leitura (RCU) medida em 4KB / s • Medida de RCU considera a leitura consistente • Leituras com consistência eventual custa ½ de leituras consistentes Capacidade de leitura e escrita são definidas isoladamente WCURCU
- 18. Cálculo do número de partições # 𝑝𝑎𝑟𝑡𝑖çõ𝑒𝑠 = 𝑇𝑎𝑚𝑎𝑛ℎ𝑜 𝑑𝑎 𝑡𝑎𝑏𝑒𝑙𝑎 𝑒𝑚 𝐺𝐵 10 𝐺𝐵(𝑝𝑜𝑟 𝑡𝑎𝑚𝑎𝑛ℎ𝑜) # 𝑝𝑎𝑟𝑡𝑖çõ𝑒𝑠 (𝑝𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒) = 𝑅𝐶𝑈 3000 𝑅𝐶𝑈 + 𝑊𝐶𝑈 1000 𝑊𝐶𝑈 (𝑝𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒)(𝑝𝑜𝑟 𝑡𝑎𝑚𝑎𝑛ℎ𝑜)(𝑡𝑜𝑡𝑎𝑙) Este modelo poderá mudar no futuro...
- 19. Exemplo # 𝑑𝑒 𝑝𝑎𝑟𝑡𝑖çõ𝑒𝑠 = 8 𝐺𝐵 10 𝐺𝐵 = 0,8 = 1 (𝑝𝑜𝑟 𝑡𝑎𝑚𝑎𝑛ℎ𝑜) # 𝑑𝑒 𝑝𝑎𝑟𝑡𝑖çõ𝑒𝑠 (𝑝𝑜𝑟 𝑐𝑎𝑝𝑎𝑐𝑖𝑑𝑎𝑑𝑒) = 5000 𝑅𝐶𝑈 3000 𝑅𝐶𝑈 + 500 𝑊𝐶𝑈 1000 𝑊𝐶𝑈 = 2,17 = 3 Tamanho= 8 GB, RCUs = 5000, WCUs = 500 (𝑡𝑜𝑡𝑎𝑙) RCUs / partição = 5000/3 = 1666,67 WCUs / partição = 500/3 = 166,67 Dados / partição = 10/3 = 3,33 GB RCUs e WCUs são distribuídas uniformemente entre partições
- 20. Capacidade extra (burst capacity) 0 400 800 1200 1600 UnidadesdeCapacidade(UC) Tempo Provisionado Consumido Unidades não utilizadas Consumo de unidades salvas Burst: 300 segundos (1200 × 300 = 360k UC) Unidades de capacidade não utilizadas nos últimos 300s são acumuladas e podem ser utilizadas em picos de requisições
- 21. Capacidade extra consumida 0 400 800 1200 1600 UnidadesdeCapacidade(UC) Tempo Provisionado Consumido Requisitado Requisições não atendidas Burst: 300 segundos (1200 × 300 = 360k UC)
- 22. Evitando Hot Partitions Chaves: alta cardinalidade Distribuição no Espaço: acessos devem ser uniformemente distribuídos entre partições Distribuição no Tempo : requisições distribuídas uniformemente no tempo
- 24. Acesso Uniforme
- 26. Relacionamentos 1:1 Exemplo: dado um usuário, busque atributos Utilize uma tabela ou GSI com chave de partição Utilize a API GetItem Tabela: Usuários Chave Partição Atributos UserId = bob Email = bob@gmail.com, JoinDate = 2011-11-15 UserId = fred Email = fred@yahoo.com, JoinDate = 2011-12-01
- 27. Relacionamentos 1:N Exemplo: Dado um equipamento, encontrar todos os eventos entre o período X e Y Utilize uma tabela com chave de partição e ordenação Utilize a API Query Tabela: Medidas-Equipamento Chave Part. Chave Ord. Atributos DeviceId = 1 Tempo= 5513A97C Temperatura= 30, pressão= 90 DeviceId = 1 Tempo= 5513A9DB Temperatura= 30, pressão= 90
- 28. Relacionamentos N:M Exemplo: Dado um usuário, encontrar todos os seus jogos. Dado um jogo, encontrar todos os seus usuários. Utilize uma tabela e um GSI com chaves de partição e ordenação alternadas Utilize a API Query Tabela: Usuário-Jogo Chave Part. Chave Ord. UserId = bob JogoID = Game1 UserId = fred JogoID = Game2 UserId = bob JogoID = Game3 GSI: Jogo-Usuário Chave Part. Chave Ord. JogoID = Game1 UserId = bob JogoID = Game2 UserId = fred JogoID = Game3 UserId = bob
- 30. Log de Eventos Armazenamento de dados temporais
- 31. Tabelas de séries temporais Tabela_Eventos_2017_Abril Event_id Timestamp Atributo1 …. Atributo N Tabela_Eventos_2017_Março Event_id Timestamp Atributo1 …. Atributo N Tabela_Eventos_2017_Fevereiro Event_id Timestamp Atributo1 …. Atributo N Tabela_Eventos_2017_Janeiro Event_id Timestamp Atributo1 …. Atributo N RCUs = 1000 WCUs = 100 RCUs = 10000 WCUs = 10000 RCUs = 100 WCUs = 1 RCUs = 10 WCUs = 1 Tabela atual Tabelas antigas DadosquentesDadosfrios Não misture dados quentes e frios; arquive dados frios no Amazon S3 (Chave Part) (Chave Ord)
- 32. DynamoDB Time to Live (TTL) RCUs = 10000 WCUs = 10000 RCUs = 100 WCUs = 1 DadosquentesDadosfrios Utilize a funcionalidade DynamoDB TTL e Streams para arquivar Tabela_Eventos_2017_April Event_id Timestamp myTTL 1489188093 …. Atributo N Arquivamento_Eventos Event_id Timestamp Atributo1 …. Atributo N (Chave Part) (Chave Ord)
- 33. Isolar dados quentes de dados frios Pré-criar tabelas diárias, semanais ou mensais Provisionar capacidade para tabela atual Escrita na tabela atual Mova os dados frios para uma tabela separada Reduza a capacidade para tabelas de dados frios
- 34. Catálogo de Produtos Leitura de itens populares
- 35. Partição 1 200 RCUs Partição K 200 RCUs Partição M 200 RCUs Partição 50 200 RCU Partição com gargalo Produto ABC Produto XYZ Usuários Tabela CatalogoProduto 10.000 𝑅𝐶𝑈 50 𝑝𝑎𝑟𝑡𝑖çõ𝑒𝑠 ≈ 𝟐𝟎𝟎 𝑅𝐶𝑈 𝑝𝑜𝑟 𝑝𝑎𝑟𝑡𝑖çã𝑜 SELECT Id, Descrição, ... FROM CatalogoProduto WHERE Id=”Produto ABC"
- 36. Requisiçòes/segundo Chave Primária Distribuição de Requisições por Chave de Partição # requisições DynamoDB
- 37. DynamoDB Utilizar cache SELECT Id, Descrição, ... FROM CatalogoProduto WHERE Id=”Produto ABC" Partição 1 200 RCUs Partição K 200 RCUs Partição M 200 RCUs Partição 50 200 RCU Produto ABC Produto XYZ Tabela CatalogoProduto Usuários
- 38. DynamoDB Accelerator (DAX) DynamoDB DynamoDB Accelerator(DAX) Your Applications Caching made simple New!
- 39. Requisiçòes/segundo Chave Primária Distribuição de Requisições por Chave de Partição # requisições DynamoDB Cache Hits
- 40. Mensagens Itens com atributos grandes
- 41. Dest Data Remet Mensagem David 2016-10-02 Bob … … 48 mais mensagens para David … David 2016-10-03 Alice … Alice 2016-09-28 Bob … Alice 2016-10-01 Carol … Atributos grandes e pequenos David Tabela Mensagens 50 itens × 256 KB cada Corpo da mensagem Anexos SELECT * FROM Mensagens WHERE Dest='David' LIMIT 50 ORDER BY Data DESC Inbox
- 42. Custo da consulta caixa de entrada Itens retornados Tamanho médio Taxa conversão Leituras de consistência eventual
- 43. Destin Data Remet Assunto MsgId David 2016-10-02 Bob Hi!… afed David 2016-10-03 Alice RE: The… 3kf8 Alice 2016-09-28 Bob FW: Ok… 9d2b Alice 2016-10-01 Carol Hi!... ct7r Separar atributos grandes GSI : Inbox MsgId Corpo 9d2b … 3kf8 … ct7r … afed … David 1. Query GSI : 2 RCU 2. BatchGetItem : 1600 RCU (50 itens de 256 KB) (50 itens de 128 bytes) Tabela: Msg
- 44. Distribuir itens grandes Reduzir tamanho de item 1:N Configurar projeções dos GSIs Utilizar GSIs para modelar M:N entre remetente e destinatário
- 45. Jogos online Consultas com filtros e ordenações
- 46. JogoID Data Host Oponente Status d9bl3 2016-10-02 David Alice DONE 72f49 2016-09-30 Alice Bob PENDING o2pnb 2016-10-08 Bob Carol IN_PROGRESS b932s 2016-10-03 Carol Bob PENDING ef9ca 2016-10-03 David Bob IN_PROGRESS Tabela : Jogos Tabela Jogos
- 47. Consulta jogos pendentes de Bob Índices permitem consulta com partição e ordenação E como fazer se tiver 2 filtros e uma ordenação? SELECT * FROM Game WHERE Oponente ='Bob‘ AND Status=‘PENDING' ORDER BY Data DESC (partição) (ordenação) (???)
- 48. Índice Secundário Oponente Data JogID Status Host Alice 2016-10-02 d9bl3 DONE David Carol 2016-10-08 o2pnb IN_PROGRESS Bob Bob 2016-09-30 72f49 PENDING Alice Bob 2016-10-03 b932s PENDING Carol Bob 2016-10-03 ef9ca IN_PROGRESS David Abordagem 1: Criar índice secundário Bob
- 49. Índice secundário Abordagem 1: Criar índice secundário Bob Oponente Data JogoID Status Host Alice 2016-10-02 d9bl3 DONE David Carol 2016-10-08 o2pnb IN_PROGRESS Bob Bob 2016-09-30 72f49 PENDING Alice Bob 2016-10-03 b932s PENDING Carol Bob 2016-10-03 ef9ca IN_PROGRESS David SELECT * FROM Jogo WHERE Oponente='Bob' ORDER BY Data DESC FILTER ON Status='PENDING'
- 50. Abordagem 2: Criar chave composta StatusData DONE_2016-10-02 IN_PROGRESS_2016-10-08 IN_PROGRESS_2016-10-03 PENDING_2016-09-30 PENDING_2016-10-03 Status DONE IN_PROGRESS IN_PROGRESS PENDING PENDING Data 2016-10-02 2016-10-08 2016-10-03 2016-10-03 2016-09-30
- 51. Índice secundário Oponente StatusData JogoID Host Alice DONE_2016-10-02 d9bl3 David Carol IN_PROGRESS_2016-10-08 o2pnb Bob Bob IN_PROGRESS_2016-10-03 ef9ca David Bob PENDING_2016-09-30 72f49 Alice Bob PENDING_2016-10-03 b932s Carol Abordagem 2: Chave composta
- 52. Oponente StatusData JogoID Host Alice DONE_2016-10-02 d9bl3 David Carol IN_PROGRESS_2016-10-08 o2pnb Bob Bob IN_PROGRESS_2016-10-03 ef9ca David Bob PENDING_2016-09-30 72f49 Alice Bob PENDING_2016-10-03 b932s Carol Índice Secundário Bob SELECT * FROM Jogo WHERE Oponente ='Bob' AND StatusData BEGINS_WITH 'PENDING' Abordagem 2: Chave composta
- 53. Consulta de todos os campeões Id (Part.) Usuário Jogo Resul Data Campeao 1 Bob G1 1300 2015-12-23 2 Bob G1 1450 2015-12-23 3 Jay G1 1600 2015-12-24 4 Mary G1 2000 2015-10-24 Y 5 Ryan G2 123 2015-03-10 6 Jones G2 345 2015-03-20 Y Tabela: Resultados-Jogos Campeao (Part.) Id Usuário Result Y 4 Mary 2000 Y 6 Jones 345 GSI: Premios Índice esparso
- 54. Substituir filtros por índices Concatenar atributos para formar chaves de índices secundários úteis para otimizar consultas Utilizar índices esparsos quando adequado
- 55. Votação Alta taxa de escrita
- 56. Aplicação de votação Tabela de Agregações Usuários Tabela de Votos Aplicação
- 57. Partição 1 1000 WCUs Partição K 1000 WCUs Partição M 1000 WCUs Partição N 1000 WCUs Tabela Votos Candidato A Candidato B Gargalo Usuários Provisionado: 20.000 WCUs
- 59. Write sharding Candidato A_2 Candidato B_1 Candidato B_2 Candidato B_3 Candidato B_5 Candidato B_4 Candidato B_7 Candidato B_6 Candidato A_1 Candidato A_3 Candidato A_4 Candidato A_7 Candidato B_8 UpdateItem: “CandidatoA_” + rand(0, 10) ADD 1 para Votos Candidato A_6 Candidato A_8 Candidato A_5 Usuário Tabela Votos
- 60. Tabela Votos Shard aggregation Candidato A_2 Candidato B_1 Candidato B_2 Candidato B_3 Candidato B_5 Candidato B_4 Candidato B_7 Candidato B_6 Candidato A_1 Candidato A_3 Candidato A_4 Candidato A_5 Candidato A_6 Candidato A_8 Candidato A_7 Candidato B_8 Periodic Process Candidato A Total: 2.5M 1. Sum 2. Store Usuário
- 61. DynamoDB Streams
- 62. Transmissão de atualizações da tabela Assíncrono Exatamente uma vez Ordenado por item Altamente durável Escalável com a tabela Tempo de vida de 24 horas Latência < 1s DynamoDB Streams
- 63. View Type Valores Old Image Nome = John, Destino = Marte New Image Nome = John, Destino = Plutão New and Old Image Nome = John, Destino = Marte Nome = John, Destino = Plutão Keys Only Nome = John Tipos de Views Atual: Nome = John, Destino = Marte UpdateItem: Nome = John, Destino = Plutão
- 64. Stream Partição 1 Partição 2 Partição 3 Partição 4 Tabela Shard 1 Shard 2 Shard 3 Shard 4 KCL Worker KCL Worker KCL Worker KCL Worker Amazon Kinesis Client Library Application DynamoDB Aplicação Cliente Updates DynamoDB Streams e Kinesis Client Library
- 65. DynamoDB Streams e AWS Lambda
- 66. Nova arquitetura da aplicação de votação Tabela Agregação Amazon Redshift Amazon EMR Your Amazon Kinesis– Enabled App Usuários Tabela VotosVotação Votos DynamoDB Stream
- 67. Nova arquitetura da aplicação de votação Tabela Agregação Amazon Redshift Amazon EMR Your Amazon Kinesis– Enabled App Usuários Tabela VotosVotação Votos DynamoDB Stream Votação em qualquer escala
- 68. Nova arquitetura da aplicação de votação Tabela Agregação Amazon Redshift Amazon EMR Your Amazon Kinesis– Enabled App Usuários Tabela VotosVotação Votos DynamoDB Stream Agregação em tempo- real, escalável e tolerante a falhas
- 69. Nova arquitetura da aplicação de votação Tabela Agregação Amazon Redshift Amazon EMR Your Amazon Kinesis– Enabled App Usuários Tabela VotosVotação Votos DynamoDB Stream Análise de dados, demografia
- 72. Estudo de Caso
- 73. “AWS permitiu que construíssemos uma solução completa de processamento de meios de pagamentos em tempo recorde” A Pismo é a primeira plataforma PaaS de processamento de meios de pagamentos. Reimaginamos tudo que há de antiquado nesse mercado para criar uma plataforma robusta, segura e extremamente flexível. Um dos nossos principais diferenciais é o enriquecimento de dados na captura de transações financeiras, como por exemplo o armazenamento dos itens que compõe a transação “AWS DynamoDB possibilitou a implementação de uma solução de enriquecimento de dados para altos volumes transacionais” - Daniela Binatti, CTO
- 74. O Desafio Encontrar uma forma de armazenamento não estruturada para todas as transações recebidas • escalável e rápida • totalmente gerenciada • compatível com a arquitetura reativa da Pismo
- 75. Implementação Auth_ID Account_ID 1 1400 2 2367 3 5468 Items (List) Items Partition Key Sort Key Primary Key AuthItems Auth_ID Account_ID 65.00 200620171 1400 2 2367 130.00 3 5468 123.70 Columns Rows Primary Key Index Amount Date AWS DynamoDBAWS RDS Authorizations 20062017 20062017 Desc Price Desc 1 30.00 ID Item 1 Desc 2 35.00Item 2
- 76. TRANSACTIONS API DynamoDB TRANSACTIONS API RDS Master DB instance RDS Standby DB instance Lambda Solução
- 77. Obrigado!
- 78. Ainda não tem o App oficial do AWS Summit São Paulo? http://amzn.to/2rOcsVy Não deixe de avaliar as sessões no app!
Notas do Editor
- consistent, single-digit millisecond latency at any scale Fast, Consistent Performance [automatic partitioning, SSD technology] Highly Scalable [store as much data, limits are there for safety] Fully Managed [choose key schema, tablename, provisioned capacity] Event Driven Programming [Streams, Lambda/KCL] Fine-grained Access Control [item-level, IAM credentials] Flexible [doc, kv]
- Hash Key only
- Hash Key & Sort Key
- Online Indexing
- Think of this as a parallel table asynchronously populated by DynamoDB Eventually consistent 1 Table update = 0, 1 or 2 GSI updates
- There is a limit in place to avoid run-away apps. But you can request a limit increase. http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html For every distinct hash key value, the total sizes of all table and index items cannot exceed 10 GB This request would have caused the ReadCapacityUnits limit to be exceeded for the account in us-west-2. Current ReadCapacityUnits reserved by the account: 237. Limit: 2000. Requested: 5000. Refer to the Amazon DynamoDB Developer Guide for current limits and how to request higher limits. (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: LimitExceededException; Request ID: 0U3G4FLA19BQMELKS4G7RSTH83VV4KQNSO5AEMVJF66Q9ASUAAJG)
- Picture from: http://www.amazon.com/Black-Aluminum-Control-Amplifier-Wheel/dp/B005HU1ZHA Scan and Query Cumulative size of processed items – ceiling (Ʃ(item sizes)/4KB) Batch GetItem ceiling [(Ʃ(item1 size)/4KB) + …ceiling (Ʃ(itemN size)/4KB)] Consumed throughput is measured per operation Provisioned throughput is divided between all partitions
- RCUs and WCUs are uniformly spread across partitions on table creation
- Uneven access across key space
- Key/values access patters (Map, Dictionary…)
- Touch on elasticity
- Add a single table chart, describe bottlenecks
- Warn: You still consume IO even if the item doesn’t exist
- Often some items in your table are accessed more frequently than others. For example, this graph illustrates how many requests per second were made for each item in your table. For collections like a product catalog, some items are substantially more popular than others. The same probably goes for tweets sent from a celebrity, and that sort of thing. Displaying those “hot items” on everyone’s twitter feed is problematic since they cause an uneven request distribution. (ask audience) Can anyone think of some things that we can do to “cool off” those hot items?
- One thing we can do is cache those reads in the application. Since a tweet doesn’t change once you post it, you can cache it in memory or in something like Amazon ElastiCache. This is a technique used in high throughput applications with a traditional database as well.
- 50 messages to read from Large items not necessarily expensive on their own, but the cost adds up Query comes from same partition
- Put the metadata into a GSI. 128 bytes versus 256KB
- Last section was 5:25
- This is your base table
- filter will drop items, but you still pay for reads
- BEGINS_WITH
- Previous section is 5:05
- Touch on elasticity
- { "Records":[ { "EventName":"INSERT", "EventVersion":"1.0", "EventSource":"aws:dynamodb", "Dynamodb":{ "NewImage":{ "Message":{ "S":"New item!" }, "Id":{ "N":"101" } }, "SizeBytes":26, "StreamViewType":"NEW_AND_OLD_IMAGES", "SequenceNumber":"111", "Keys":{ "Id":{ "N":"101" } } }, "EventID":"1", "eventSourceARN":"arn:aws:dynamodb:us-east-1:acct-id:table/ExampleTableWithStream/stream/stream-id/", "AwsRegion":"us-east-1" }, { "EventName":"MODIFY", "EventVersion":"1.0", "EventSource":"aws:dynamodb", "Dynamodb":{ "NewImage":{ "Message":{ "S":"This item has changed" }, "Id":{ "N":"101" } }, "SizeBytes":59, "StreamViewType":"NEW_AND_OLD_IMAGES", "SequenceNumber":"222", "OldImage":{ "Message":{ "S":"New item!" }, "Id":{ "N":"101" } }, "Keys":{ "Id":{ "N":"101" } } }, "EventID":"2", "eventSourceARN":"arn:aws:dynamodb:us-east-1:acct-id:table/ExampleTableWithStream/stream/stream-id/", "AwsRegion":"us-east-1" }, { "EventName":"REMOVE", "EventVersion":"1.0", "EventSource":"aws:dynamodb", "Dynamodb":{ "SizeBytes":38, "StreamViewType":"NEW_AND_OLD_IMAGES", "SequenceNumber":"333", "OldImage":{ "Message":{ "S":"This item has changed" }, "Id":{ "N":"101" } }, "Keys":{ "Id":{ "N":"101" } } }, "EventID":"3", "eventSourceARN":"arn:aws:dynamodb:eu-west-1:acct-id:table/ExampleTableWithStream/stream/stream-id/", "AwsRegion":"eu-west-1" } ] }
- Kinesis Firehose: Elasticsearch, S3, Redshift FIXME
- O Titans Group é lider em serviços de telefonia e provedores de internet, com operação em 40 operadores em 17 países… um principais produtos chamado “X” é um aplicativo de sincronização de arquivos para mobile e desktop
- Titans Group precisava garantir que a solução de storage do produto atendesse os requisitos mais exigentes do ponto de vista de durabilidade, disponibilidade e confidencialidade das informações dos usuários. Também era preciso garantir a escalabilidade tanto do ponto de vista técnico quanto do ponto de vista de custo.
- NoSQL you have to ask – how will the application access the data? And store your data in such a way to retrieve the data with just a Select, and No joins. Designed by keeping in mind Access patterns. Via duplication of data (storage) and using Hierarchical structures, you can now optimize for compute, and therefore it is very fast. == Non-relational (NoSQL) databases typically do not enforce a schema. A “partition key” is generally used to retrieve values, column sets, or semi-structured JSON, XML, or other documents containing related item attributes.