21 publicaciones etiquetados con "Arquitectura"

La mayor parte de este blog ha profundizado en una cosa a la vez: compare-and-swap, transacciones multiclave, estructuras de datos nativas, streams, watch, el op-log que hay debajo. Cada artículo responde a "cómo funciona esto". Este responde a una pregunta distinta y más práctica: cuando tienes un problema delante, ¿cuál eliges?

Esa pregunta importa porque la elección equivocada rara vez es un fallo estrepitoso. Es un sistema que funciona en la demo y luego pierde una actualización bajo carga, o canaliza a mil escritores a través de una sola clave, o usa una notificación de tipo "dispara y olvida" donde hacía falta un log durable. Las primitivas no te impiden usarlas mal. Así que esto es una guía de campo: el modelo mental que las une, una tabla de decisión, un recorrido por cada rama con su encaje honesto y su límite honesto, y un diagrama de flujo al final.

La mayoría de los almacenes de datos distribuidos te hacen elegir, pronto y de forma permanente, entre dos mundos. Está el almacén "de verdad": un clúster que despliegas, al que apuntas un cliente por la red y con el que hablas a través de un protocolo de cable. Y está el almacén "falso" al que recurres en las pruebas unitarias: un diccionario en memoria, un mock, un stub hecho a mano que implementa lo justo de la interfaz para que la prueba compile. Los dos no comparten nada. Tu prueba ejercita el comportamiento del stub, no el del almacén, y el hueco entre ellos es exactamente donde se esconden los bugs.

Zaris colapsa esa elección. El mismo cliente tipado de .NET que habla con un clúster distribuido sobre TLS también ejecuta el almacén embebido dentro de tu proceso, sin socket, sin mapa de particiones y sin despliegue, y es el mismo motor de almacén, no un sustituto. Seleccionas cuál obtienes con una única cadena de conexión. Este artículo trata de cómo funciona eso, los casos para los que es genuinamente bueno y la línea dura donde el modo embebido se detiene y empieza un clúster.

Hay una pregunta que todo desarrollador acaba por hacerle a un almacén distribuido, normalmente justo después de un informe de error confuso: si escribo un valor y luego lo leo de inmediato, ¿tengo la garantía de ver lo que escribí? Suena como si debiera tener una respuesta de una sola palabra. No la tiene — ni para ningún almacén particionado y replicado, ni para Zaris. La respuesta honesta es "sí, dentro de una partición, porque las lecturas van al mismo propietario único al que fue tu escritura" — y lo interesante es todo lo que se esconde en esa salvedad.

Esta entrada reúne en un solo lugar el modelo de consistencia de Zaris. Hemos escrito sobre las piezas por separado — compare-and-swap optimista, reintentos transparentes ante cambios de propiedad, el op-log reproducible que alimenta a las réplicas, transacciones multiclave. Aquí las enlazamos desde el lado del lector y respondemos a la única pregunta que importa frente a un teclado: cuando leo, ¿qué se me promete en realidad? Incluyendo, sobre todo, dónde se detiene la promesa.

El licenciamiento es la parte de un producto en la que la mayoría de los ingenieros nunca quieren pensar, y se nota. El patrón habitual es una bomba de tiempo: se comprueba una fecha, y cuando pasa, el software te castiga — lanza una excepción al arrancar, corrompe o borra el estado local para evitar que lo "robes", o simplemente revienta y se lleva tu data con él. Ese diseño trata a tus propios operadores como adversarios, y falla justo en el momento en que menos te lo puedes permitir: en producción, después de que el reloj girara silenciosamente.

Zaris adopta la postura opuesta. La comprobación de licencia es el interruptor más crítico para la seguridad de un almacén de datos distribuido, así que está construida como tal: una única función de política pura y determinista, un camino de aplicación elegante y totalmente reversible que nunca destruye un byte, y un reloj por máquina que se reanuda en el instante en que activas una clave. Este post recorre cómo funciona realmente ese ciclo de vida en el código que se envía — porque la ingeniería interesante aquí está en lo que se niega a hacerte.

Dos eventos de aspecto muy diferente en un almacén distribuido resultan ser el mismo problema por debajo. El primero: una réplica se queda atrás de su primario — una pausa de GC, un disco lento, una breve partición de red — y ahora sostiene una copia obsoleta de una partición que debe eventualmente igualar. El segundo: una partición se reasigna a un nodo que nunca la ha tenido, y ese nodo debe adquirir el conjunto de datos entero del propietario actual. Uno es lag de replicación; el otro es migración. Tienen disparadores diferentes, operadores diferentes, historias de fallo diferentes.

Pero la pregunta que cada uno tiene que responder es idéntica: ¿cómo converjo a la verdad actual de esta partición sin congelar las escrituras mientras lo hago? Zaris responde a ambos con un único mecanismo — un log de operaciones ordenado por revisión mantenido por segmento, reproducido desde un punto conocido. Este post trata de ese log: cómo se construye en el camino de escritura, cómo se acota para que no pueda crecer sin límite, cómo se reproduce, y por qué el exacto mismo sustrato lleva tanto a una réplica rezagada como a un propietario completamente nuevo a la convergencia.

Hay un número que todo ingeniero de rendimiento de .NET acaba memorizando: 85.000 bytes. Cualquier asignación individual en o por encima de aproximadamente ese tamaño no va al heap normal de objetos pequeños — va al Large Object Heap (LOH). El LOH es un animal diferente. Solo se recolecta durante una recolección de basura de gen-2 (completa), y por defecto no se compacta. Esa combinación está bien para un búfer grande que asignas una vez y conservas. No está bien para un almacén en memoria de baja latencia que escribe y sobrescribe repetidamente valores grandes.

Imagina la carga de trabajo: blobs serializados grandes, documentos JSON grandes, imágenes, payloads de protocolo — almacenados, actualizados, reemplazados, una y otra vez. Cada una de esas escrituras grandes deposita un objeto nuevo en el LOH. Como el LOH no se compacta, los huecos liberados no se fusionan de vuelta en espacio contiguo; se fragmentan. Y como recuperar algo de él implica una recolección completa de gen-2, las pausas se alargan y aterrizan con más frecuencia justo a medida que crece el working set. Para un almacén cuyo argumento entero es baja latencia, esa es la clase equivocada de sorpresa.

Zaris incluye una función opcional para esquivar el LOH por completo para estos valores. Está desactivada por defecto, y este post trata de lo que hace, cómo funciona, y — igual de importante — cuándo deberías y cuándo no deberías activarla.

La capacidad nunca es la adecuada por mucho tiempo. El tráfico crece, llega un lanzamiento, termina una temporada — y el almacén que dimensionaste el trimestre pasado está o bien al límite o bien medio ocioso. La pregunta que decide si eso es una tarea o una crisis es simple: ¿puedes cambiar el tamaño de un almacén en marcha sin tumbarlo?

Para Zaris la respuesta es sí, con una asimetría importante que vale la pena reconocer de entrada. Escalar hacia afuera — añadir servidores — es la dirección fácil, segura y sin pérdidas, y ocurre en vivo mientras el almacén sigue sirviendo. Escalar hacia adentro — quitar servidores — también está soportado, pero es una operación deliberada y monitorizada porque la data del servidor que se va tiene que ir a algún sitio primero.

Este post recorre ambas direcciones: hacer crecer un almacén con Add-ZrServer, reducirlo con Remove-ZrServer, por qué la reducción necesita un drain, y dónde encaja la consola web.

La forma más rápida de asegurarte de que TLS se omita es forzar un único modelo de confianza sobre todos. Un desarrollador que ejecuta un almacén en una laptop no quiere levantar una CA. Un banco con una raíz offline en un HSM no quiere que tu herramienta acuñe certificados en absoluto. Entrega un almacén que solo conozca uno de esos casos, y la mitad de tus usuarios desactivarán la seguridad para poder trabajar.

Por eso Zaris no elige por ti. Su confianza TLS es enchufable a lo largo de cuatro modos de autoridad certificadora, desde el autofirmado sin configuración hasta certificados que aprovisionas enteramente fuera de banda. Eliges el modo que coincide con la PKI que ya ejecutas, y Zaris encaja en ella en lugar de pedirte que la reconstruyas a su alrededor. TLS no es una talla única, y tratarlo así es exactamente por qué la seguridad se pospone.

Zaris es un almacén clave/valor distribuido construido de forma nativa para .NET. Sus clientes de primera clase hablan un protocolo binario eficiente y, si tu stack es .NET, esa es la ruta que quieres: APIs asíncronas reales, tipos de .NET, primitivas de coordinación, reemplazos directos de IDistributedCache y HybridCache.

Pero la mayoría de los sistemas no son solo .NET. Hay un servicio en Python haciendo trabajo de datos, un sidecar en Go, un ejecutor de trabajos en Ruby, una pasarela en Node. Reescribir todos ellos sobre un cliente nuevo para probar un almacén nuevo es inviable. Así que, en la 2.0.0, cada nodo de Zaris también puede exponer un listener del protocolo de Redis (RESP2): apunta un cliente de Redis existente a él y usa Zaris como almacén clave/valor de reemplazo directo, en cualquier lenguaje, sin cambiar una sola línea de código del cliente.

Este artículo trata de cómo funciona realmente ese front-end: el modelo de enrutamiento, el modelo de datos, los modelos de conmutación por error y exactamente qué comandos entran y salen.

Hoy lanzamos Zaris 0.9.0 y, con él, Zaris alcanza la disponibilidad general. Está listo para producción, es multiplataforma y ahora cuenta con soporte comercial.

Si aún no te has topado con él: Zaris es un almacén clave/valor distribuido y en memoria para .NET. Es rápido, replicado, y puedes operarlo desde un navegador, PowerShell o directamente desde tu aplicación. Esta versión es la culminación de ese trabajo: el punto en el que un "proyecto prometedor" se convierte en "algo que puedes poner en producción".