Hola Habr!
Esta pequeña nota nació durante la discusión del artículo
"Monolitos distribuidos ..." , y dado que el tema requiere más reflexión, decidí publicarlo en mi blog. El autor del artículo en realidad describe una base de datos distribuida, lo que demuestra que el registro de eventos es la única estructura de almacenamiento correcta. Los argumentos son aproximadamente los siguientes:
- Dado que el evento siempre se localiza en el espacio / tiempo, puede almacenar todos los datos en sí mismo (a veces en forma de enlaces a eventos anteriores), lo que hace que el evento sea serializable, aumenta la localidad, reduce la conectividad, etc.
- Una vez que ocurre un evento, ya no cambia (cualquier refinamiento está documentado por otros eventos), lo que reduce el tráfico de replicación.
- El formato de almacenamiento de eventos puede estar más o menos unificado y desligado de un área temática específica.
- Los registros de eventos se pueden dividir / fusionar con relativa facilidad, puede almacenar diferentes tipos de eventos en diferentes nodos, es decir, en esencia, estamos hablando de una base de datos distribuida.
- Los eventos están ordenados por tiempo, y esta secuencia también refleja una relación causal (no se puede hacer referencia al evento actual más adelante).
- Al registrar un evento, no es necesario actualizar transaccionalmente otros datos (de hecho, es obligatorio, pero en un número limitado de casos, por ejemplo, el saldo del suscriptor en el sistema de facturación debe ser instantáneamente relevante, es necesario actualizar los contadores de enlaces, etc.).
- Los informes se pueden generar directamente desde el registro de eventos, sin la necesidad de convertir los datos en un formulario normalizado.
Con respecto al último punto, numerosas pruebas de rendimiento (incluso en mi blog) muestran que en el hardware moderno, procesar mil millones de eventos (hechos) con un algoritmo de un solo paso con memoria a corto plazo lleva minutos, lo cual es bastante aceptable para la presentación de informes. Y dado que el procesamiento de eventos de varios tipos que no están conectados por enlaces es fácil de paralelizar, el tiempo de informe se puede reducir a decenas de segundos, sin tener que sobrecargar la normalización de datos / indexación / recopilación de estadísticas / depuración y sugerencias de sugerencias, como es el caso en los RDBMS regulares. Por lo tanto, crear informes basados en dichos datos no me asusta. Sin embargo, considere el problema de manera más amplia.
Una aplicación comercial típica se puede representar como una cadena de transformación de datos:
"Entrada => modelo => salida". Cualquier esquema de almacenamiento es un compromiso entre tres extremos:
- Almacenamos los datos en el formato de salida. Así es como funcionan una variedad de escaparates y OLAP, donde el tiempo de respuesta es importante. Se conocen los inconvenientes: demanda de memoria excesiva y baja tasa de actualización (generalmente por lotes).
- Almacenamos datos en el formato del modelo de dominio, simplificando así los algoritmos de cálculo. Hay muchos inconvenientes: se requiere una doble transformación de datos (de entrada a modelo y de modelo a salida), los costos de transacción aumentan, es difícil proporcionar almacenamiento distribuido, cambiar el esquema es costoso, etc. Sin embargo, esta es la opción más popular.
- Almacenamos los datos en el formato de entrada (de hecho, lo que ofrece el autor del artículo es un registro de eventos). En este caso, los costos de transacción son mínimos, los datos se dividen y fusionan fácilmente, un esquema de almacenamiento simple, claro y estable. Beneficio! Es cierto que tienes que aprender a programar de nuevo.
En relación con mi área de interés (sistemas de información corporativos), un evento es un documento primario y el libro de referencia puede considerarse como un evento anterior. Ya describí la estructura de la tabla de un ERP occidental típico en el artículo
"NoERP o una nueva apariencia ..." , donde propuse abolir la normalización excesiva de datos (con la excepción de los registros de saldos instantáneos) y reescribir la mayoría de los cálculos / informes en ciclos de un solo paso, en los cuales los primarios se procesarán directamente documentos No repetiré los argumentos, todo está indicado en el artículo, pero el esquema que propuse coincidió prácticamente con la tesis del autor del primer artículo, a saber, que el registro de eventos son los datos. Es agradable cuando alguien más piensa en esta dirección.
Está claro que este enfoque parece ser un paso atrás en comparación con los DBMS inteligentes modernos, pero en el mundo highloid a veces hay que abandonar las herramientas populares / abstractas / universales, a favor de una programación imperativa brutal y efectiva, que, además, no requiere licencias costosas para los nodos / kernels / users.
Me gustaría decir por separado sobre el método de organizar las relaciones dentro del registro de eventos: debe ser bidireccional, es decir, cada evento debe almacenar un contador de referencia para sí mismo. Esto es necesario para la implementación de algoritmos de un solo paso: pasamos de eventos antiguos a nuevos, al mismo tiempo almacenamos en caché cada evento con un número distinto de cero de enlaces entrantes en la memoria, y lo eliminamos de la memoria caché solo después de procesar todos los referentes. La presencia del contador de referencia reduce de manera desagradable el rendimiento de las transacciones; por ejemplo, si el directorio de la contraparte se usa en cada documento, el contador de referencia en la contraparte debe actualizarse cada vez que se agrega un documento, a veces en otro nodo. Sin embargo, este lugar puede optimizarse universalmente, evitando transacciones distribuidas en todos los demás casos.
En realidad, a nivel de idea, esto es todo por ahora, todavía espero un proyecto específico (por ejemplo, sobre la base de recibos de efectivo o facturas) y, si se presenta esta oportunidad, informaré sobre los resultados.