antonio leandro

enciclopédia

dados e armazenamento

como se guarda e se lê o que não cabe numa máquina: relacional, lsm, colunar, vetorial.

32 verbetes, 10 no caminho mínimo, 29 lidos na íntegra · do que mais pesa para o que menos

muda como você pensa

  1. A Relational Model of Data for Large Shared Data Banksprograma nenhum deveria saber como o dado está guardado: se o usuário só enxerga relações com colunas nomeadas, trocar ordenação, índice ou caminho de acesso deixa de quebrar a aplicação · núcleo
  2. The Log-Structured Merge-Tree (LSM-Tree)o índice fica dez vezes mais barato se você parar de colocar cada entrada nova no lugar definitivo na hora: uma fila em memória desce para o disco por merges sequenciais em blocos grandes · núcleo
  3. Dynamo: Amazon's Highly Available Key-value Storerecusar uma escrita é pior que guardar duas versões conflitantes: o dynamo fica sempre gravável e empurra a reconciliação para a leitura e para a aplicação, que é quem sabe fundir dois carrinhos · núcleo
  4. Dremel: Interactive Analysis of Web-Scale Datasetsconsulta interativa sobre petabytes não precisa virar job em lote: árvore de execução em vários níveis mais layout colunar para registros aninhados responde agregação em trilhão de linhas em segundos · núcleo · pelo resumo
  5. Gorilla: A Fast, Scalable, In-Memory Time Series Databasemonitoramento não precisa de acid nem de histórico: guardar só as últimas 26 horas em memória, comprimidas de 16 para 1,37 bytes por ponto, vale mais que garantir que nenhum ponto se perca · núcleo
  6. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databasesnum banco em nuvem o recurso escasso deixou de ser cpu e disco e virou rede — a saída da aurora foi mandar só o redo log para a camada de storage e deixar ela materializar as páginas · núcleo
  7. Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Serviceprevisibilidade vale mais que eficiência: o dynamodb desacopla o controle de admissão da partição, corta cada otimização que esconde trabalho e aceita gastar mais no caso normal para nunca ter um caso ruim · núcleo
  8. What Goes Around Comes Around... And Around...vinte anos depois, o placar é o mesmo: nenhum modelo de dados derrubou o relacional — o sql absorveu json, array e grafo, e quem começou gritando "nosql" terminou vendendo um dialeto de sql · núcleo

vale o tempo

  1. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Loggingantes de desfazer qualquer coisa, refaça tudo — inclusive o que as transações perdedoras escreveram: repetir a história inteira é o que faz lock de registro, undo lógico e rollback parcial conviverem sem corromper a página
  2. C-Store: A Column-oriented DBMSnum mundo read-mostly vale gastar cpu para poupar disco: guardar coluna a coluna, comprimida, em várias ordens de ordenação — e jogar fora a tabela, ficando só com as projeções · núcleo
  3. What Goes Around Comes Aroundquase toda proposta "nova" de modelo de dados é uma reencarnação de algo dos anos 70, e a mais simples ganha sempre: complexidade só sobrevive quando paga em performance, nunca quando paga só em expressividade
  4. The Bw-Tree: A B-tree for New Hardware Platformstira-se o latch da b-tree trocando ponteiro por indireção: se nenhum nó aponta direto para outro, um único cas instala qualquer mudança — e a página antiga segue intacta no cache dos outros cores
  5. The Snowflake Elastic Data Warehouseseparar storage de compute não é economia de infra: é o que deixa cache ficar frio de propósito, upgrade rodar lado a lado e o usuário desligar todo o cluster sem mover um byte de dado · núcleo
  6. SILK: Preventing Latency Spikes in Log-Structured Merge Key-Value Storesreduzir o custo do trabalho interno de um lsm store não conserta a cauda: a p99 vem da interferência entre flush, compaction e cliente, e o que falta é um escalonador de i/o
  7. Umbra: A Disk-Based System with In-Memory Performanceo buffer manager voltou: com páginas de tamanho variável e uma faixa de memória virtual reservada por size class, um banco em ssd entrega desempenho de banco em memória no working set quente e degrada com elegância fora dele
  8. Evolution of Development Priorities in Key-value Stores Serving Large-scale Applications: The RocksDB Experienceem oito anos de produção o alvo de otimização do rocksdb mudou três vezes — write amplification, depois espaço em disco, depois cpu — e o recurso que parecia escasso em 2012 não era o que limitava as aplicações
  9. Amazon Redshift Re-inventedo data warehouse parou de ser um cluster que alguém tuna e virou um serviço que se dimensiona sozinho — e, no caminho, engordou até virar o ponto de junção de todo dado da nuvem
  10. Vector Database Management Techniques and Systemsbanco vetorial não é uma categoria nova de banco: é o problema de vizinho mais próximo aproximado, com décadas de literatura, embalado atrás de uma api — o que muda de produto para produto é o índice, não o armazenamento
  11. Distributed Transactions at Scale in Amazon DynamoDBdá para pôr transação acid serializável num key-value store sem lock e sem mvcc: ordena por timestamp, manda tudo num único request e deixa get e put avulsos passarem direto pelo storage node

para aprofundar

  1. On-the-fly Sharing for Streamed Aggregationvárias agregações contínuas sobre o mesmo stream não precisam de um plano compartilhado montado de antemão: dá para dividir o trabalho entre elas em tempo de execução · pelo resumo
  2. Cassandra: A Decentralized Structured Storage Systemjunte o anel do dynamo com o modelo de colunas do bigtable, tire a leitura que o vector clock exige antes de cada escrita, e sobra um banco que absorve bilhões de escritas por dia sem master
  3. Storing and Querying Tree-Structured Records in Dremelnem toda consulta sql sobre dado aninhado pode ser executada podando a árvore, e a relação de dominância diz exatamente quais podem — é ela que autoriza o dremel a nunca materializar o produto cartesiano
  4. In-Memory Performance for Big Datao buffer pool não precisa ser o preço da durabilidade: trocando identificador de página por ponteiro direto nas referências internas do sistema, ele some do caminho quando o dado já está na memória · pelo resumo
  5. Amazon Redshift and the Case for Simpler Data Warehouseso concorrente do redshift nunca foi o teradata: era o dado que ninguém analisa. mpp colunar já era commodity, e o gargalo estava no modelo de compra — em ser fácil de comprar, ajustar e operar
  6. TiDB: A Raft-based HTAP Databaseuma estrela de nêutrons não precisa ser esférica nem quando está parada: a crosta cristalina aguenta um quadrupolo de alguns por cento, e ele mexe na fase da onda gravitacional antes de a maré aparecer
  7. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analyticsdá para deixar tudo em parquet no object store e ainda ter transação, versão e índice: o warehouse não precisa ser dono do formato de armazenamento para entregar performance de warehouse
  8. Manu: A Cloud Native Vector Database Management Systembanco vetorial não precisa de transação: abrindo mão de join e de consistência forte, dá para montar o sistema inteiro como publish/subscribe sobre o log e escalar busca, indexação e escrita separadamente
  9. Intelligent Scaling in Amazon Redshifto warehouse na nuvem escala no eixo errado: rais trata o tamanho do cluster como decisão contínua, provisionando computação para a query pesada e redimensionando o warehouse conforme o workload muda
  10. Amazon MemoryDB: A Fast and Durable Memory-First Cloud Databasedurabilidade não precisa morar no mesmo processo que a velocidade: tirando o log de transações para fora do redis, dá para ter leitura em microssegundos e 11 noves de durabilidade no mesmo banco
  11. Predicate Caching: Query-Driven Secondary Indexing for Cloud Data Warehousescache não precisa guardar o resultado: guardar as faixas de tuplas que passaram no predicado dá um índice secundário que nasce da própria carga de trabalho e não precisa ser recomputado a cada escrita
  12. Stage: Query Execution Time Prediction in Amazon Redshiftprever quanto uma query vai demorar não é um modelo, são três: cache exato, modelo local por instância que sabe quando não sabe, e modelo global transferível entre todas as instâncias do redshift

de nicho

  1. The Story of AWS Glueo gargalo do etl na nuvem nunca foi o motor: era o cluster que demora a subir, o schema que ninguém conhece e o shuffle que estoura o disco — glue deixou spark de pé e reescreveu tudo em volta