Dovrei provare a scrivere un semplice archivio di valori-chiave da solo? [chiuso]

Ricorda che, una volta accumulati abbastanza dati, il tuo semplice approccio interno sarà molto lento quando si tratterà del recupero, a meno che non implementi una sorta di sistema di indicizzazione. Quindi, se questo è un potenziale problema, mi permetto di usare un dbms.

Oltre a utilizzare un server NoSQL, è anche possibile utilizzare un database SQL per memorizzare coppie di chiavi. Non c'è nulla di intrinseco in quel tipo di dati che lo impedisce. Quindi, se hai già MySQL in esecuzione, questa potrebbe essere l'opzione più semplice.

Sì. Se non riesci a trovare una soluzione che risolva esattamente il tuo problema, allora prenderei in considerazione la possibilità di scrivere la mia. Come altri hanno già detto: considera la scalabilità. Se prevedi che sarà necessario ridimensionarlo molto presto, forse potrebbe valere la pena di investire in qualcosa che è stato progettato per gestirlo.

Un'altra cosa che vorrei menzionare, è che lo renderei il più amichevole possibile. Cioè, avrei una chiave / valore di base / valore (astratto) di classe / interfaccia ed estendere la tua implementazione chiave / valore in cima a questo. Questo è puramente perché più tardi lungo la linea, lo troverai molto più facile per (dire) il backup della tua chiave / valore con memcached se lo fai in questo modo, o addirittura lo scambia interamente - perché l'interfaccia sarà la stessa. Se disponi di funzioni globali per get e set , allora sembrerebbe equivalente, ma hai ancora il problema di quanto velocemente puoi eseguire il hotswap dell'implementazione senza tempi di inattività.

Vorrei fare una rapida rassegna di ciò che è là fuori, se trovi che uno degli attuali NoSQL ha fatto il lavoro, quindi userei uno di essi. Non perché non potresti scrivere qualcosa da te abbastanza velocemente ma perché ti permette di scaricare il carico di supporto. Se tutto ciò di cui hai bisogno è uno storage a valore chiave, uno dei figli di Dynamo (Cassandra, Riak, ...), o redis è probabilmente lo strumento giusto per il lavoro.

Il problema sembra abbastanza basilare da essere eseguito da solo senza troppi problemi. Certo, è necessario testare, ma è ragionevole rispetto all'autentica.

Quando la ruota è facile, non reinventare la ruota:

• Se conosci già una soluzione adatta alle tue esigenze. Con "conosci" , intendo che hai già provato il prodotto, sapere che è facile da installare, conoscere i possibili avvertimenti, ecc.

• O se ti aspetti di aggiungere più funzionalità in futuro, utilizzare un prodotto su scala aziendale che offra più funzioni di quelle di cui hai bisogno in questo momento può essere una soluzione migliore. Redis , a proposito, viene in mente come una soluzione eccellente per l'archiviazione dei valori-chiave.

Se non conosci alcuna soluzione esistente e sei sicuro di non dover aggiungere funzionalità in seguito, sarebbe probabilmente più veloce creare il tuo archivio di valori-chiave piuttosto che trovarne uno esistente che funzionerà nel tuo contesto, sulla tua piattaforma, ecc.

Penso che tu sia bicihedding qui. Qualunque cosa tu stia facendo, con ogni probabilità questa domanda è modo accanto al punto.

1. Come hai detto tu stesso, lo storage avrà un'API basata su HTTP. Definiscilo prima.
2. Utilizza l'implementazione più semplice che potresti (ad es. sopra redis ). Se ciò richiede più di un'ora, stai sbagliando.
3. Scrivi l'applicazione effettiva che consuma i dati tramite detta API.
4. Aggiungi dati di esempio ragionevolmente realistici.
5. Misura le prestazioni sotto carico. Se la prestazione è soddisfacente, hai finito.
6. Utilizza le informazioni che hai raccolto per migliorare l'implementazione dell'API.
7. Vai a 5.

Come per "Non è XYZ overkill?": Probabilmente no.

A meno che tu non abbia prove concrete a dimostrare che significativamente influisce sulle prestazioni, perché preoccuparsi? Ha più funzioni di quelle che ti servono? Non hai bisogno di usarli. Certamente, stai usando un linguaggio di programmazione con più funzioni di quelle che hai effettivamente usato.

Questo non è "eccessivo". Sta "mantenendo un'opzione";)

Infine, riguardo alla tua dichiarazione su come fare questo lavoro in poche ore. Ci sono due opzioni in realtà:

• O è ragionevole presumere che lo spazio di archiviazione possa diventare un collo di bottiglia, nel qual caso è molto meglio usare una soluzione ben mantenuta, ottimizzata, scalabile e affidabile , perché ti porterà settimane per fornirne una e non si può dire quanto perdita di dati o corruzione di dati causerà nel frattempo.
• Oppure, se lo spazio di archiviazione non è un collo di bottiglia, perché non usare semplicemente qualcosa che porti a termine il lavoro? Dov'è il valore di avere il pieno controllo che stai cercando?

Se non puoi misurare i vantaggi del licenziamento di tutte le soluzioni di terze parti prontamente disponibili a favore di quelle fatte in casa, probabilmente stai soffrendo di Not Invented Here .

Sui sistemi Linux e Posix ti consiglio di utilizzare l'API dbm o la GNU gdbm libreria ( implementare un superset di dbm )

Questa API di archiviazione valore-chiave è piuttosto comune ed esiste dal secolo precedente. È in POSIX (utilizzando <ndbm.h> ). Le implementazioni sono abbastanza buone e in grado di gestire sia dati piccoli che enormi.

In generale, dovresti sapere che i database NoSQL hanno alcune caratteristiche da considerare:

1-Non utilizza SQL come linguaggio di query

Questo aggiungerà un livello di complessità nella soluzione se stai già utilizzando un database SQL nella stessa soluzione.

2-Potrebbe non fornire garanzie ACID complete

Potrebbe non essere opportuno nelle applicazioni critiche.

3-Ha un'architettura distribuita, fault-tolerant

Questo è molto bello, ma ne hai davvero bisogno?

4-Additional Additional Model

Se stai già utilizzando un altro RDBMS, dovrai costruire / utilizzare un altro meccanismo di sicurezza.

Secondo me, e come @MainMa, già menzionato, per le applicazioni di database comuni, l'attività dovrebbe essere banale se hai già un database RDBMS nella tua soluzione. Fai il lavoro da solo, è quasi banale. Tuttavia, se la soluzione non ha già un database, potrebbe essere utile perché alcuni fornitori offrono hosting (e praticamente l'installazione) del database per te. Ciò ti fa risparmiare risorse e, eventualmente, denaro.