Come scegliere un archivio dati per la prossima nuova cosa brillante

Nota: questo è un post sul blog tecnico scritto dall'ingegnere principale Silvia Botros ed è apparso per la prima volta sul blog Sysadvent il 25 dicembre 2017.

I database possono essere difficili. Sai cos'è più difficile? Scegliendone uno in primo luogo. Questo è difficile sia che tu sia in una nuova azienda che sta ancora trovando il suo prodotto/mercato adatto o in un'azienda che ha trovato il suo pubblico e sta semplicemente espandendo l'offerta di prodotti.

Quando si costruisce una cosa nuova, una delle primissime parti di quel processo di progettazione è quali archivi di dati dovremmo usare e dovrebbero essere un singolo o un plurale? Dovremmo usare negozi relazionali o dobbiamo scegliere un negozio di valore chiave? E le opzioni di tempo? Dovremmo anche aggiungere un po' di replay del registro distribuito?

Così. Molti. Opzioni…

In questo articolo cercherò di descrivere un processo che, si spera, guiderà tale decisione e, ove applicabile, spiegherà in che modo le dimensioni e la maturità della tua organizzazione possono influire su questa decisione.

Requisiti di base

I dati sono la linfa vitale di qualsiasi prodotto. Anche se stiamo pianificando nella progettazione di utilizzare una tecnologia più all'avanguardia per memorizzare lo stato dell'applicazione (perché MySQL o Postgres non sono più "cool"), qualunque cosa scegliamo è ancora un archivio di dati e quindi richiede l'applicazione di rigore quando facendo la nostra selezione.

La cosa importante da ricordare è che niente è gratis. Tutti gli archivi dati vengono forniti con compromessi e se non sei esplicito su quali compromessi stai assumendo come rischio aziendale, ti assumerai un rischio sconosciuto che si manifesterà nel momento peggiore possibile.

È improbabile che il tuo product manager sappia o abbia bisogno di preoccuparsi di ciò che usi per il tuo archivio dati, ma guiderà le esigenze che riducono l'elenco delle opzioni. A volte anche questo ha bisogno di una spintarella da parte del team di sviluppo, però. Ecco un elenco di cose che devi chiedere al team di prodotto per aiutarti a guidare le tue opzioni:

• Tasso di crescita: come si prevede che i dati stessi o l'accesso ad essi cambieranno nel tempo?
• In che modo il team di fatturazione utilizzerà questi nuovi dati?
• In che modo il team ETL utilizzerà questi dati?
• Quali requisiti di precisione/coerenza sono previsti per questa nuova funzionalità?
• Quale intervallo di tempo per tale coerenza è accettabile? La correzione post-elaborazione è accettabile?

Trova il contesto che non è detto

La scelta del datastore non è una scelta riservata al DBA o al team Ops o anche solo al tecnico che scrive il codice.

Le organizzazioni mature con un mercato indirizzabile noto devono prendere una decisione dagli stakeholder di tutta l'organizzazione.

Se i requisiti del team di prodotto soddisfano una dozzina di archivi dati, come si determinano i requisiti non esplicitamente richiamati?

È necessario far emergere i requisiti non detti il ​​prima possibile perché è la strada verso il fallimento delle aspettative su tutta la linea.

Molte cose implicite possono farti fallire in questa trappola delle "troppe scelte". Ciò include ma non è limitato a:

• Elenchi di funzionalità incompleti
• Requisiti di prestazione che non sono elencati in modo esplicito
• Esigenze di coerenza che si presuppongono
• Tasso di crescita non specificato
• Requisiti di fatturazione o di query ETL che non sono ancora disponibili/conosciuti

Questi sono tutti modi possibili che possono far girare un team di ingegneri troppo a lungo a controllare un lungo elenco di scelte di archiviazione dati semplicemente perché i criteri espliciti con cui stanno lavorando sono troppo permissivi o incompleti.

Per più prodotti "greenfield", come ho detto prima, il tuo obiettivo è la flessibilità. Quindi un datastore più generico e di qualità nota ti aiuterà ad avvicinarti a un deliverable, con la consapevolezza che in futuro potrebbe essere necessario passare a un datastore più adatto alla tua nuova scala.

Fai la tua lista

È tempo di filtrare le potenziali soluzioni in base all'elenco dei requisiti. L'elenco risultante non deve essere più di una manciata di possibili archivi di dati. Se l'elenco di potenziali database che puoi utilizzare è più di questo, i tuoi requisiti sono troppo permissivi e devi tornare indietro e trovare maggiori informazioni.

Per le aziende più giovani e meno mature, i requisiti dell'archivio dati sono l'area delle più sconosciute. Probabilmente stai costruendo una cosa nuova che nessuno offre ancora e quindi cose come la dimensione totale del mercato indirizzabile e il tasso di crescita possono essere relativamente sconosciuti e difficili da quantificare.

In questo caso, ciò di cui hai bisogno è non vincolarti troppo presto nella vita della tua nuova azienda utilizzando un datastore pony one trick. Sì, a un certo punto i tuoi dati cresceranno in modi nuovi e inaspettati, ma ciò di cui hai bisogno in questo momento è flessibilità mentre cerchi di trovare la tua nicchia di mercato e scopri come sarà la crescita dei tuoi dati e quali specifiche funzionalità di scalabilità diventeranno cruciali per la tua crescita

Se sei un'azienda più grande con un numero crescente di clienti paganti, il tuo compito qui è ridurre l'elenco delle opzioni preferibilmente in archivi di dati che già possiedi e gestisci. Quando hai già molti clienti paganti, il rischio di aggiungere nuovi archivi di dati con cui il tuo team non ha familiarità diventa maggiore e, a seconda del contesto dei dati, semplicemente inaccettabile.

Un'altra cosa da tenere a mente è quali strumenti esistono già per gli archivi dati e cosa significherebbe adottarne uno nuovo per quanto riguarda il lavoro iniziale che il tuo team deve fare. Gestione della configurazione, script di backup, script di ripristino dei dati, nuovi controlli di monitoraggio, nuovi dashboard da creare e familiarizzare. L'elenco dei costi operativi di un nuovo archivio dati, indipendentemente dal rischio, non è banale.

Scegli il tuo veleno

Quindi ecco un segreto mal tenuto a cui i DBA si aggrappano. I database sono tutti terribili in qualcosa. C'è anche un intero teorema su questo. Non solo i database in senso tradizionale, ma qualsiasi tecnologia che memorizza lo stato sarà orribile in un modo unico per il modo in cui la usi.

Questo è solo un fatto della vita che è meglio interiorizzare ora. No, non sto dicendo che dovresti evitare di utilizzare nessuna di queste tecnologie, sto dicendo di mantenere sane le tue aspettative e sapere che TU e solo tu e il tuo team alla fine siete in grado di mantenere le promesse che fate.

Cosa significa questo in termini non astratti? Una volta che hai una solida idea di quali archivi di dati faranno parte di ciò che stai costruendo, dovresti iniziare conoscendo i punti deboli di questi archivi di dati. Questi punti deboli includono, ma non sono limitati a:

• Questo datastore funziona bene con le query di scansione?
• Questo datastore si basa su un protocollo di gossip per la replica dei dati? in tal caso, come gestisce le partizioni di rete? Quanti dati sono coinvolti in quel gossip?
• Questo datastore ha un singolo punto di errore?
• Quanto sono maturi i conducenti della community per parlargli o hai bisogno di fare il tuo?
• Questa lista può essere enorme

Pensare ai punti deboli delle potenziali soluzioni ancora presenti nell'elenco dovrebbe eliminare più opzioni dall'elenco. Questa è ora la realtà che soddisfa le alte promesse della tecnologia.

Foglio di calcolo e cuocere!

Una volta che il tuo elenco di scelte è ridotto a una piccola manciata, è tempo di metterle tutte in un foglio di calcolo e iniziare a scavare un po' più a fondo. Hai bisogno di una colonna pro e una colonna contro e, a questo punto, dovrai dedicare un po' di tempo alla documentazione di ogni database per scoprire i dettagli essenziali su come eseguire determinate attività.

Se si tratta di dati che prevedi di avere un tasso di crescita elevato, devi sapere quale di queste opzioni è più facile da scalare. Se questa è una funzionalità che esegue molte ricerche fuzzy, è necessario sapere quale datastore può gestire meglio le scansioni o eseguire ricerche su un gran numero di righe e con quale design. L'obiettivo in questa fase è ridurre l'elenco a 2 o 3 opzioni idealmente tramite la sola documentazione, perché se questa nuova funzionalità è abbastanza critica per il successo dell'azienda, dovrai confrontare tutte e tre.

Perché benchmark dici? Perché non ci sono 2 aziende che utilizzano lo stesso datastore allo stesso modo. Perché a volte la documentazione implica avvertimenti che vengono esposti solo nelle storie di guerra di altre persone.

Perché nessuno possiede la stabilità, l'affidabilità e la prevedibilità di questo datastore tranne te.

Progetta il tuo benchmark in anticipo. Idealmente, si configura un'istanza completa dei datastore nell'elenco con le specifiche del livello di produzione e si producono dati di test non troppo piccoli per rendere inutili i test di carico. Assicurati non solo di eseguire il benchmark per il "carico normale", ma anche di testare alcuni scenari di errore.

La speranza è che attraverso il benchmark, tu possa scoprire eventuali avvertimenti abbastanza severi da farti rivisitare l'elenco delle opzioni ora invece che in seguito quando tutto il codice è stato scritto e sei ora nella fase dell'esercitazione antincendio con molto tempo e impegno impegnato nella scelta che hai fatto.

Documenta la tua scelta

Qualunque cosa tu faccia, devi documentare e trasmettere internamente il metodo con cui hai raggiunto la tua scelta e le alternative che sono state studiate nel percorso verso quella decisione. Presumendo che ci sia un progetto architettonico generale di come verrà creata questa nuova funzionalità e tutti i suoi componenti, assicurati di creare una sezione dedicata al datastore che alimenta questa nuova funzionalità con collegamenti a tutti i benchmark fatti per raggiungere la decisione a cui è giunto il team .

Questo non è solo a vantaggio dei futuri nuovi assunti, ma anche a vantaggio del tuo team ora. Un documento su cui le persone possono leggere e sviluppare opinioni in modo asincrono fornisce un modo per mantenere il processo decisionale trasparente, far crescere un senso di migliori intenzioni tra i membri del team e può portare critiche da prospettive che non avevi previsto.

Asporto

Questi passaggi non solo porteranno a decisioni basate sui dati durante l'espansione dell'offerta aziendale, ma porteranno anche a un'infrastruttura solida e a un approccio più disciplinato a quando e dove utilizzerai un campo di tecnologie in continua crescita per fornire valore ai tuoi pagamenti i clienti.