¿Existe un patrón para "mantenimiento de la casa" un DB NoSQL con consistencia eventual?

7

Estoy trabajando con una base de datos NoSQL con consistencia eventual. Mi software no solo inserta objetos Java en JSON sino que también crea índices secundarios para referencias cruzadas y cosas similares. Debido al hecho de que mi software tiene que crear todas las referencias por sí mismo, no existe un mecanismo real para garantizar la coherencia completa en toda la base de datos.
Es por eso que quiero programar algo así como una rutina de limpieza, que puede llamarse durante el tiempo de ejecución para probar las inconsistencias.
Ahora me pregunto si hay patrones de software que sirvan para estos fines específicos:

  • Se debe usar un esquema (no muy seguro de cuál será el formato; probablemente XML o algo parecido) como entrada que describa las relaciones entre las entradas de la base de datos. Este esquema probablemente será la propia documentación.
  • La rutina debe poder identificar claves a las que nunca se accedió durante la verificación de las relaciones mencionadas anteriormente.
  • Debe ser capaz de verificar valores agregados, des / incrementos y JSON.

El primer elemento de la lista es el más importante, por lo que la rutina identifica fallas en el código, así como en la documentación / requisitos. Cualquier sugerencia hacia publicaciones útiles o problemas probables, debería considerar, son muy apreciadas.

    
pregunta Unknown Id 15.09.2015 - 18:05

1 respuesta

1

En primer lugar, la consistencia eventual debería ser bastante segura, y tal proceso de "administración de datos" puede no ser obligatorio. Puede ser de hecho una característica para tener varios estados de los datos en la base de datos. En el proceso de BigData, es bastante habitual: Google, por ejemplo, puede tener varios estados de los mismos datos en sus servidores.

En mi humilde opinión, su pregunta puede tener respuestas en dos niveles, siguiendo la arquitectura DDD.

1. En la capa de infraestructura

Puede escribir algún código específico para el motor NoSQL que está utilizando.

Se optimizaría, por ejemplo. para un proceso rápido usando KVP, quizás con los siguientes patrones:

  • Usar la memoria como caché tanto como sea posible, para evitar solicitudes innecesarias en el NoSQL;
  • Ejecute la operación en un proceso separado , para reducir el impacto en el proceso principal;
  • Permita que este proceso separado use un map / reduce pattern , luego inyecte las modificaciones como lotes;
  • Use algún tipo de patrón de CQRS , y varias bases de datos: una base de datos KVP para sus escrituras directas, luego una lectura secundaria dedicada -sólo bases de datos, que contienen algunos datos "pulidos" (también rellenos con mapa / reducir), listos para ser consumidos por sus Servicios de dominio .

Su idea de identificar claves "muertas" es interesante. Podría implementarse dentro de la capa de infraestructura, como parte del proceso de almacenamiento, por ejemplo. al mantener una lista en la memoria de las entradas escritas, luego eliminarlas y recogerlas utilizando un algoritmo de tipo generacional , marcando claves con un número de generación, listo para eliminar el que no se usa.

2. A nivel de dominio

En DDD intentamos ser desacoplados de la base de datos como sea posible . Como resultado, realizar algún proceso de limpieza de datos en la capa de infraestructura suena algo extraño.

Dicha limpieza de datos puede ser parte del dominio, en un Contexto delimitado dedicado. La capa de infraestructura, cuando aplica el algoritmo de mapa / reducción, puede usar alguna lógica definida en el dominio, usar objetos de dominio, para validar sus datos y solucionar cualquier problema de sincronización.

Por último, pero no menos importante, si sus datos parecen incoherentes, puede oler como un problema de dominio. Sus agregados pueden ser definidos erróneamente. Lo que debería persistir son Aggregates Roots , cuyo alcance ha sido definido por un contexto de ejecución dado. Normalmente, los agregados se mantienen en su base de datos y garantizan la coherencia de los cambios al aislar a sus miembros de los objetos externos (es decir, puede vincularse a un agregado a través de su ID, pero no puede acceder directamente a sus objetos internos). La consistencia eventual del KVP debería ser suficiente para asegurar datos consistentes. Si tiene problemas de coherencia, puede considerar arreglar su dominio, lo que puede tener algunos problemas con el alcance Aggregate Roots .

    
respondido por el Arnaud Bouchez 12.10.2015 - 16:08

Lea otras preguntas en las etiquetas