Esiste un modello per "housekeeping" di un DB NoSQL con consistenza finale?

7

Sto lavorando con un DB NoSQL con coerenza finale. Il mio software non sta solo inserendo oggetti Java in JSON, ma anche creando indici secondari per riferimenti incrociati e cose simili. Dato che il mio software deve creare tutti i riferimenti su di esso, non esiste un vero meccanismo per garantire la coerenza completa nell'intero DB.
Ecco perché voglio programmare qualcosa come una routine housekeeping, che può essere chiamata durante il runtime per verificare le incoerenze.
Ora mi chiedo se ci sono alcuni modelli di software consigliati che servono a questi scopi specifici:

  • Uno schema (non del tutto sicuro di quale sarà il formato, probabilmente XML o sth simile) dovrebbe essere usato come input che descrive le relazioni tra le voci del DB. Questo schema sarà probabilmente la documentazione stessa.
  • La routine dovrebbe essere in grado di identificare le chiavi a cui non si è mai avuto accesso durante il controllo delle relazioni di cui sopra.
  • Deve essere in grado di controllare i valori aggregati, il de / / incremento e JSON.

Il primo elemento nell'elenco è il più importante, in modo che la routine identifichi i difetti nel codice e nella documentazione / requisiti. Ogni accenno alla letteratura utile o ai probabili problemi, dovrei considerare, sono molto apprezzati.

    
posta Unknown Id 15.09.2015 - 18:05
fonte

1 risposta

1

Innanzitutto, la coerenza finale dovrebbe essere abbastanza sicura e tale processo di "gestione dei dati" potrebbe non essere obbligatorio. Potrebbe essere una caratteristica avere diversi stati dei dati nel database. Nel processo di BigData, è piuttosto normale - Google per esempio potrebbe avere diversi stati degli stessi dati nei suoi server.

IMHO la tua domanda potrebbe avere risposte a due livelli, seguendo l'architettura DDD.

1. A livello di infrastruttura

Potresti scrivere del codice specifico per il motore NoSQL che stai utilizzando.

Sarebbe ottimizzato per es. per processi veloci usando KVP, magari con i seguenti schemi:

  • Utilizzare memoria come cache il più possibile, per evitare richieste non necessarie sul NoSQL;
  • Esegui l'operazione in un processo separato , per ridurre l'impatto sul processo principale;
  • Consenti a questo processo separato di utilizzare una mappa / riduci pattern , quindi di iniettare le modifiche come batch;
  • Utilizza un qualche tipo di schema CQRS e diversi database: un database KVP per le tue scritture dirette, quindi una lettura secondaria dedicata - solo database, contenenti alcuni dati "lucidati" (anche compilati con map / reduce), pronti per essere utilizzati dai Servizi di dominio .

La tua idea di identificare le chiavi "morte" è interessante. Potrebbe essere implementato all'interno del livello infrastruttura, come parte del processo di archiviazione, ad es. mantenendo una lista in memoria di voci appena scritte, quindi eliminando quindi garbage-collect con un algoritmo di tipo generazionale , che contrassegna le chiavi con un numero di generazione, pronto per rimuovere quello non utilizzato.

2. A livello di dominio

In DDD cerchiamo di essere disgiunti dal database il più possibile . Di conseguenza, eseguire alcuni processi di pulizia dei dati a livello di infrastruttura suona un po 'strano.

Tale pulizia dei dati può essere parte del dominio, in un contesto limitato . Il livello infrastruttura, quando si applica l'algoritmo mappa / riduzione, può utilizzare alcune logiche definite nel dominio, utilizzando oggetti dominio, per convalidare i dati e correggere qualsiasi problema di sincronizzazione.

Ultimo ma non meno importante, se i tuoi dati sembrano incoerenti, potrebbe avere l'odore di un problema di dominio. I tuoi aggregati potrebbero essere definiti in modo errato. Quello che dovresti persistere sono Aggregates Roots , il cui ambito è stato definito da un dato contesto di esecuzione. In genere, gli aggregati vengono mantenuti nel database e garantiscono la coerenza delle modifiche isolando i membri da oggetti esterni (ad esempio, è possibile collegarsi a un aggregato tramite il relativo ID, ma non è possibile accedere direttamente ai relativi oggetti interni). L'eventuale consistenza del KVP dovrebbe essere sufficiente a garantire dati coerenti. Se riscontri problemi di coerenza, potresti decidere di correggere il tuo dominio, che potrebbe avere qualche problema sull'ambito Aggregate Roots .

    
risposta data 12.10.2015 - 16:08
fonte

Leggi altre domande sui tag