Sull'uso di Terracotta come soluzione di persistenza

Question

Sarebbe una buona idea usare Terracotta come soluzione di persistenza (sostituendo un database)? Mi chiedo in particolare problemi di integrità dei dati e supporto per i sistemi transazionali.

Answer 1

La terracotta è transazionale (blocchi sincronizzati formare transazioni di oggetti modificati) ma non è e non vuole essere conforme a JTA. C'è una discussione abbastanza lunga sulle transazioni e alcune idee sbagliate comuni su Terracotta qui .

Ho scritto un post sul blog sulla durata dei dati e come ciò dovrebbe inquadrare il tuo pensiero sull'identificazione delle opportunità per l'uso della terracotta. In breve, il punto debole di Terracotta è il caso d'uso in cui sono necessari persistenza e disponibilità (l'app potrebbe bloccarsi ma è comunque necessario disporre dei dati) ma in cui i dati non sono necessariamente critici a lungo termine.

Un esempio canonico sono dati importanti nel contesto di una sessione utente in un'app Web, come le informazioni del carrello. Vuoi mantenere tali dati persistenti in modo che se l'app web si arresta in modo anomalo, mantieni il carrello. Ma il carrello stesso può o non può mai essere acquistato. Quindi, lo memorizzi in Terracotta fino a quando non viene acquistato, quindi salvalo nel database come "sistema di registrazione" dati.

Storicamente, i dati memorizzati in un database erano sempre "sistema di registrazione" dati che sono stati fondamentali per il successo a lungo termine della tua azienda: clienti, ordini, ecc. Con l'attuale "apolide" architetture (che in realtà non sono apolidi), trasferiamo tutti i dati a medio termine nel database. Ciò significa che stiamo punendo inutilmente il nostro database (con ulteriore lavoro e spazio di archiviazione) e i nostri sviluppatori (che devono gestire la mancata corrispondenza dell'impedenza relazionale all'oggetto, anche se si utilizza ORM). Un approccio migliore è lasciarlo negli oggetti e raggrupparlo con la terracotta. Numerosi utenti recenti di Terracotta hanno utilizzato questa tecnica per ridurre in modo significativo il loro footprint del database (risparmiando milioni di dollari) e contemporaneamente aumentando la loro capacità di ridimensionamento.

Esiste la questione del punto di integrazione con il database e di come effettuare la consegna in modo affidabile. Abbiamo visto questo come un caso d'uso nell'applicazione web Examinator recentemente pubblicata (un'applicazione web di riferimento Spring / Terracotta / Tomcat / MySql) . Quando gli esami sono in corso, lo stato (risposte a domande, ordini di scelta casuali, domande contrassegnate per la revisione) viene memorizzato in Terracotta. Ma al termine degli esami, il punteggio risultante viene calcolato e memorizzato a lungo termine nel database.

Per farlo in modo sicuro, usiamo una strategia chiave di ibernazione che genera prima l'id della riga del database nell'oggetto in Terracotta, quindi salva i dati nel db, quindi rimuove da Terracotta. Questo scenario presenta una potenziale condizione di competizione se l'app si arresta in modo anomalo dopo il salvataggio nel database ma prima della rimozione da Terracotta. In tal caso, l'applicazione potrebbe provare a salvare nuovamente i dati nel db, creando eventualmente due righe. Ma grazie all'ID pre-generato, possiamo dire se la riga è stata precedentemente scritta con successo o meno ed evitare quel problema.

In sintesi, non credo che Terracotta sostituirà presto il tuo db. È troppo nuovo dal punto di vista operativo anche per essere considerato tale nella maggior parte dei negozi. Il modello di utilizzo è molto diverso. Non sono presenti query o funzionalità SQL nell'heap (la capacità di query è definita dal modello a oggetti). Penso che possa e stia iniziando a sostituire l'utilizzo dei dati a medio termine, dove è un'alternativa molto più economica e più semplice. Tuttavia, alcune persone stanno iniziando a sperimentarlo per l'archiviazione a lungo termine.

Answer 2

Terracotta è solo Java. Se è OK per te essere bloccato in questa tecnologia, senza la possibilità di scrivere solo alcuni script (senza JVM) in altre lingue, allora segui.

L'articolo Kill Your Database with Terracotta è stato davvero bello.