Implementazioni con successo VoltDB

Question

Ho lavorato a un progetto per oltre sei mesi, costruendo software sanitario da zero. Quando mi sono unito, MySQL era stato scelto come archivio dati principale.

A pochi mesi e molti mal di testa in seguito, abbiamo iniziato a studiare archivi di dati alternativi in ​​grado di offrire la flessibilità necessaria per registrare i nostri dati sanitari critici e in continua evoluzione.

Abbiamo esaminato molte soluzioni NoSQL; MongoDB attira la maggior parte della nostra attenzione. Essere in grado di archiviare dati strutturati e incorporati sarebbe un enorme vantaggio. Tuttavia, siamo stati spaventati da segnalazioni di problemi di perdita/affidabilità dei dati.

Mi sono imbattuto in alcuni archivi di dati "NewSQL" e sono interessato a VoltDB in particolare.

Sono curioso di sapere se qualcuno ha qualche esperienza con Volt o l'ha visto implementato in un progetto.

Edit:

L'integrità dei dati e la coerenza sono più importanti. Potrebbe essere molto dannoso per le informazioni dei pazienti essere perso, possono ricevere un trattamento improprio, ecc.

Il volume dei dati può variare; probabilmente sosterremo prima le piccole pratiche. Qualcosa come 700 utenti totale. Ma anche quando passiamo agli ospedali, non guardiamo ai social media come il traffico.

Per quanto riguarda la domanda, si evolveranno strutture dati. Oltre a dover modificare la struttura esistente per acquisire input nuovi o modificati, dobbiamo conservare la struttura dei dati esistenti come una sorta di snapshot. Siamo stati in grado di fare questo stile EAV solo con MySQL.

Grazie per il vostro feedback.

Answer 1

Siamo andati a vivere l'anno scorso con un'applicazione che utilizza VoltDB. Archiviamo circa 1,5 miliardi di record ed elaboriamo 50-90 milioni di transazioni al giorno con un cluster di server kfactor = 1 4 (memoria/server da 256 GB). Data la performance di VoltDB, potremmo facilmente passare 1 miliardo di transazioni al giorno.

Fino ad oggi, non abbiamo avuto problemi relativi al software VoltDB. La nostra esperienza è che è veramente conforme all'ACID. Con l'aggiunta della funzione Command Logging, credo che sia possibile configurare i parametri di registrazione per impedire la perdita di qualsiasi transazione.

Altre caratteristiche importanti includono la sua scalabilità (e la relativa semplicità di aggiungere capacità).

Un'importante considerazione nella scelta di VoltDB è la comprensione dello schema di partizionamento di VoltDB. Raggiungere le altissime velocità di transazione possibili con VoltDB dipende dal parallelismo raggiunto attraverso il partizionamento dei dati. Il partizionamento è trasparente per l'applicazione, ma i dati dell'applicazione devono prestarsi ad essere partizionati per ottenere le massime prestazioni. Se i tuoi dati non si prestano al partizionamento, credo che l'impatto principale sarebbe la riduzione della velocità di trasmissione (cioè i tassi di transazione) - non un ostacolo allo show.

Infine, una nota relativa alle stored procedure. VoltDB consente di sostituire le stored procedure senza arrestare il database. Inoltre, ogni chiamata di una stored procedure costituisce una singola transazione. Abbiamo sfruttato le stored procedure in modo tale da poter modificare/aggiornare la nostra logica applicativa senza arrestare il database.

Answer 2

La domanda, così com'è, è molto soggettiva, ma ulteriori informazioni possono aiutarci a indicarti la giusta direzione.

Quali sono esattamente le vostre esigenze? Questo sistema ha esigenze transazionali in cui l'integrità e la coerenza dei dati sono della massima importanza, come quelle nelle applicazioni commerciali e finanziarie? Qual è il volume dei dati e quanti utenti concorrenti? Quali sono i requisiti di prestazione?

Inoltre, hai citato ever-changing healthcare data, questo significa che le strutture dati sono in continua evoluzione e in continua evoluzione? In tal caso, potresti voler stare lontano dai database relazionali data la natura degli schemi rigidi e, invece, considerare i negozi di documenti come Mongo dove le strutture di dati di schemi forniscono più flessibilità.

BTW,

non si ottiene paura di storie di affidabilità su Mongo; puoi trovare storie dell'orrore per praticamente qualsiasi prodotto, sia open source che commerciale; spesso queste recensioni negative hanno meno a che fare con il prodotto e più a che fare con la scarsa implementazione del cliente.

VoltDB, l'ultimo controllo, richiede che tutte le logiche di persistenza siano codificate come stored procedure. Le ovvie carenze con questo approccio sono meno visibilità e modularità del codice e maggiori esigenze di manutenzione. A parte questo, Voltdb è molto veloce poiché la maggior parte del sovraccarico trovato nei database relazionali tradizionali, come il blocco, ecc., Viene eliminato dal motore del database principale.

Answer 3

la questione è un po 'vecchio, ma do un feedback perché abbiamo usato MongoDB da tempo, e stiamo cercando di VoltDB ma per ragioni totalmente diverse:

• Per quanto riguarda MongoDB : stiamo usando mongoDB in produzione da 4 anni e non abbiamo mai perso un singolo byte di dati. Il "mongodb non è affidabile" sembra essere un mito, almeno per me. Stiamo gestendo milioni di nuove voci in mongoDB ogni giorno senza problemi

• Stiamo cercando VoltDB per un caso d'uso diverso: fornendo analisi in tempo reale su un volume enorme. MongoDB non è male nel fornire analisi, ma quando si superano i milioni di voci da analizzare, inizia ad essere un po 'lento. VoltDB è molto più bravo in questo, ma non consiglierei di usarlo per memorizzare dati, soprattutto dati ad alto valore ... Usiamo un altro database per memorizzare i dati.