Cinco armazenamento de dados diferentes, cada um respondendo a uma pergunta que os outros respondem mal: SQL distribuído para dados de negócios transacionais, coluna larga para telemetria de gravação alta, um armazenamento na memória para estado efêmero, armazenamento de objetos para arquivos e um banco de dados vetorial para pesquisa semântica.
| Medida | Valor | Fonte | Medido |
|---|---|---|---|
| Lojas de dados distintas na produção | 5 (YugabyteDB, ScyllaDB, Redis/Valkey, MinIO, Qdrant) | kubectl get statefulsets,deployments --all-namespaces | |
| Topologia SQL distribuída | yb-master and yb-tserver as separate stateful sets | kubectl get statefulsets -n kamo | |
| Arquivos de migração SQL sob controle de versão | 90 | find . -name '*.sql' across all service repositories | |
| Migrações do mecanismo de banco de dados de produção concluídas | 1 (CockroachDB to YugabyteDB, live data) | service configuration history; port 26257 retired in favour of 5433 |
Que edifício nos ensinou
A resposta padrão para onde os dados vão é o último projeto usado, e é assim que uma empresa acaba executando agregações analíticas contra o banco de dados que recebe os pedidos dos clientes, ou mantendo trinta gigabytes de arquivos carregados em linhas de tabelas. Escolhemos cada loja de acordo com a carga de trabalho e migramos quando erramos — a plataforma anteriormente era executada em um mecanismo SQL distribuído diferente e foi removida, o que é uma coisa realmente difícil de fazer com dados de produção e vale mais como experiência do que qualquer discussão sobre arquitetura.
O SQL distribuído não é um substituto para um banco de dados de nó único, e as maneiras pelas quais ele difere são as maneiras que mais afetam. Uma transação vê um snapshot para toda a sua vida, mesmo no modo de leitura-commit, então a segunda leitura de uma linha dentro de uma transação não observa uma gravação de outra transação confirmada no meio — o código que estava correto em um único nó está silenciosamente errado aqui.
O armazenamento de objetos carrega todos os arquivos enviados, com deduplicação por conteúdo, e isso tem sua própria lição: um upload com falha pode deixar uma linha que uma nova tentativa posterior de deduplicação pode usar, produzindo um arquivo que o sistema acredita que existe e não pode servir. Nós descobrimos isso em produção, agora é algo que verificamos em qualquer sistema que construímos que deduplica qualquer coisa.
Construído com
- YugabyteDB
- ScyllaDB
- Redis
- Valkey
- MinIO
- Qdrant
- PostgreSQL wire protocol
- Hibernate
O que isso nos qualifica para
Diga-nos o que você está tentando fazer
Uma breve conversa geralmente é suficiente para dizer se somos as pessoas certas, se não formos, diremos isso e indicaremos um lugar melhor.