Cinco almacenes de datos diferentes, cada uno de los cuales responde a una pregunta que los demás responden mal: SQL distribuido para datos de negocios transaccionales, columna ancha para telemetría de alta escritura, un almacén en memoria para estados efímeros, almacenamiento de objetos para archivos y una base de datos vectorial para búsqueda semántica.
| Medida | Valor | Fuente | Medido |
|---|---|---|---|
| Almacenes de datos distintos en producción | 5 (YugabyteDB, ScyllaDB, Redis/Valkey, MinIO, Qdrant) | kubectl get statefulsets,deployments --all-namespaces | |
| Topología SQL distribuida | yb-master and yb-tserver as separate stateful sets | kubectl get statefulsets -n kamo | |
| Archivos de migración SQL bajo control de versiones | 90 | find . -name '*.sql' across all service repositories | |
| Se completaron las migraciones del motor de base de datos de producción | 1 (CockroachDB to YugabyteDB, live data) | service configuration history; port 26257 retired in favour of 5433 |
Qué edificio nos enseñó
La respuesta predeterminada a dónde van los datos es cualquiera que sea el último proyecto utilizado, así es como una empresa termina ejecutando agregaciones analíticas contra la base de datos que recibe los pedidos de sus clientes, o manteniendo treinta gigabytes de archivos cargados en filas de tablas. Elegimos cada tienda en función de la carga de trabajo, y migramos cuando nos equivocamos: la plataforma se ejecutaba anteriormente en un motor SQL distribuido diferente y se movió de él, lo cual es algo realmente difícil de hacer con datos de producción y vale más como experiencia que cualquier cantidad de discusión sobre arquitectura.
El SQL distribuido no es un sustituto de una base de datos de un solo nodo, y las formas en que difiere son las que muerden. Una transacción ve una instantánea durante toda su vida incluso en modo de lectura-commit, por lo que la segunda lectura de una fila dentro de una transacción no observa una escritura de otra transacción confirmada en el medio; el código que era correcto en un solo nodo está silenciosamente equivocado aquí. Los conflictos de lectura y escritura aparecen como errores reintentables en transacciones que nunca escribieron nada. Estos no son casos de borde exóticos; son martes, y es por eso que somos cuidadosos con lo que prometemos en el trabajo con datos.
El almacenamiento de objetos lleva cada archivo subido, con deduplicación por contenido, y eso tiene su propia lección: una subida fallida puede dejar una fila que un intento posterior de deduplicación puede usar, produciendo un archivo que el sistema cree que existe y no puede servir. Lo encontramos en producción, ahora es algo que comprobamos en cualquier sistema que creamos que deduplique cualquier cosa.
Construido con
- YugabyteDB
- ScyllaDB
- Redis
- Valkey
- MinIO
- Qdrant
- PostgreSQL wire protocol
- Hibernate
Para lo que esto nos califica
Cuéntanos lo que estás tratando de hacer
Una breve conversación suele ser suficiente para saber si somos las personas adecuadas, si no lo somos, lo diremos y le indicaremos un lugar mejor.