Come archiviare 3 milioni di record in formato valore chiave?

Dobbiamo archiviare le informazioni di base su 3 milioni di prodotti. Attualmente le informazioni sono un CSV da 180 mb che viene aggiornato trimestralmente.

Ci saranno circa 30.000 query al giorno, ma le query sono solo un archivio di valori chiave molto semplice. Dobbiamo solo cercare l'ID del prodotto e visualizzare il resto delle informazioni (che sarebbero tutte in un record).

Questo è per il web, quindi le prestazioni veloci sono fondamentali.

Dovremmo usare MySQL, anche se in realtà non abbiamo bisogno di un database relazionale? Dovremmo semplicemente generare 3 milioni di file html statici ogni trimestre? Dovremmo archiviare un CSV a una riga per ogni prodotto su qualcosa come Amazon S3 o Rackspace Cloud Files? Qual è il modo migliore per farlo?

Poiché MySQL è così ampiamente supportato e questa è davvero una cosa banale da fare, suggerirei di seguirlo. A meno che il server non abbia almeno qualche GB di memoria, suggerirei di utilizzare MySQL anziché utilizzare un sistema in memoria.

Una volta che inizi a mettere i tuoi dati in un database, che sia MySQL o qualcos'altro, molto probabilmente scoprirai che troverai più usi per esso. In questo momento stai parlando solo di coppie chiave-valore, ma il resto dei dati relativi ai tuoi prodotti deve essere archiviato da qualche parte. Se non si trova in un database, non posso immaginare che l'archiviazione dei dati sia molto efficiente.

Qualunque cosa tu faccia, non creare quei tre milioni di file. Abbiamo già visto una serie di domande risultanti dai problemi che molti file creano.

È possibile utilizzare il tipo di valore-chiave dedicato del database NoSQL ottimizzato per questo tipo di attività. Dai un'occhiata a:

• Redis : Redis è un archivio di valori-chiave avanzato open source. Viene spesso definito server della struttura dei dati poiché le chiavi possono contenere stringhe, hash, elenchi, set e set ordinati.
• MemcacheDB - MemcacheDB è un sistema di archiviazione di valori-chiave distribuito progettato per persistente.
• altri (uno di questi elenchi è disponibile qui: http://nosql-database.org/ )

Naturalmente puoi usare MySQL o qualsiasi altro database relazionale, ma le soluzioni appositamente progettate per il tipo di dati di valore-chiave dovrebbero essere migliori (altrimenti qual è il punto di progettarli al primo posto, tranne forse il fatto che sarà molto più piccolo (in termini di RAM e HDD) soluzione).

E ora qualcosa di completamente diverso:

Dato:

• 180 MB / 3 milioni di prodotti = 62 byte / prodotto in media.
• 30.000 query al giorno = 0,34 query al secondo
• Aggiornamento trimestrale = dati essenzialmente statici

Soluzione fuori dagli schemi:

Scaricare ogni prodotto come record di risorse TXT e memorizzarlo nel DNS, ad esempio:

$origin products.example.com.

product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"

Benefici:

• estremamente affidabile e affidabile (ne dipendi già ogni giorno)
• può essere costruito praticamente su qualsiasi piattaforma
• praticamente ogni lingua ha il supporto per le query DNS in un modo o nell'altro
• i server open source e commerciali supportano diversi tipi di database back-end
• può essere banalmente replicato (basta specificare più server dei nomi)
• gestisce gli aggiornamenti atomici, anche se replicati su una dozzina di server
• può essere crittografato per garantire l'integrità dei dati
• è in grado di gestire ordini di magnitudo con query al secondo più elevate (10.000 query al secondo sono facilmente gestibili con l'hardware delle materie prime)

Ragioni per cui questa potrebbe essere una cattiva idea:

• devi cercare i dati (DNS è puramente ricerca chiave / valore)
• devi nascondere i dati (DNS non ha riservatezza)

MySQL con MyISAM e alcuni buoni indici sembrano perfetti per questo. Ci sono molte altre opzioni ovviamente, ma MySQL è ampiamente supportato (se non universalmente) su qualsiasi host web commerciale. A seconda della velocità richiesta, vale la pena guardare memcached , ma senza conoscere le dimensioni di ciascuna coppia chiave / valore, memorizzarne 3 milioni in memoria potrebbe essere un'idea ancora peggiore di un file CSV da 180 Mb (oh aspetta, è un file CSV da 180 Mb, quindi sappiamo quanto sono grandi. Devono essere coppie piuttosto piccole, quindi memcached potrebbe essere ancora migliore).

Tu non vuoi 3 milioni di file HTML statici, si farà male il vostro file system male. Un CSV a una riga, anche su S3, avrà lo stesso problema. Nessuno vuole 3 milioni di file in una cartella.

È possibile utilizzare il database Berkeley che fa esattamente questo genere di cose, anche se non è stato alla moda fin dall'alba di Perl5. Berkeley supporta solo coppie di valori-chiave e tu leghi l'intero db a un hash e accedi ad esso come tale.

L'uso di Berkeley è ben dettagliato in molti dei vecchi riferimenti Perl seduti sul tuo scaffale o prova Perldoc per il modulo CPAN BerkeleyDB . In genere evito di usare Berkeley DB (anche se il mio datore di lavoro ha un codice molto antico in cui gioca in modo prominente e alcuni dei DB sono grandi come i tuoi), perché non è divertente quando i tuoi dati diventano più complessi.

Hai segnalato la tua domanda come amazon S3.

Vorrei attirare la vostra attenzione su uno dei loro altri prodotti correlati chiamato Amazon SimpleDB.
Sembra che il modello di dati SimpleDB si adatterebbe bene con il tuo tipo di applicazione.

Questa non è una spina per questo, ma vale la pena dare un'occhiata soprattutto se stai pensando di utilizzare i servizi cloud di Amazon.

Il modello di dati SDB assomiglia a un foglio di calcolo.

Vedi qui per maggiori informazioni: http://aws.amazon.com/simpledb/ E il modello dati: http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/

Anche se 180 mb di dati possono essere facilmente gestiti da qualsiasi database relazionale, consiglio vivamente MongoDB ( http://www.mongodb.org/) sopra MySQL, Redis, MemcacheDB e altri archivi di valori-chiave o database relazionali più semplici. Il motivo è che per questo tipo di problema, MongoDB è il sistema più rapido ed espressivo da utilizzare, che consente aggiornamenti dinamici super rapidi senza restrizioni di schema, quindi i tuoi documenti possono avere formati diversi se ti piace. Sono stato a una presentazione di guardian.co.uk l'altro giorno e hanno preso una decisione politica di vietare tutti i database relazionali e usare MongoDB esclusivamente per servire le loro notizie. Puoi avere un'idea di quanto sia veloce il loro sito Web e che è online dal 1995 (il più antico quotidiano online del Regno Unito). In passato hanno anche attraversato ogni sorta di strozzature a causa di database relazionali. Per 180mb, MongoDB servirà tutto da memoria, quindi è probabile che siano i tempi di caricamento sotto ms.

Ci saranno circa 30.000 query al giorno, ma le query sono solo un archivio di valori chiave molto semplice. Dobbiamo solo cercare l'ID del prodotto e visualizzare il resto delle informazioni (che sarebbero tutte in un record).

Hai detto che le tue query sono solo semplici ricerche chiave, con la ricerca binaria hai bisogno di 21 iterazioni nel caso peggiore, con le chiavi con hash le tue query sono ancora più veloci. Tre milioni di record sono piccoli se si evitano join (o altre operazioni cartesiane di tipo di prodotto) e ricerche lineari.

Oserei dire che qualsiasi cosa andrebbe bene. Il tuo carico è di 30000 query / giorno significa che (supponendo che il carico sia costante durante il giorno) hai una singola query ogni 20 secondi; Non è male.

Ti consiglierei di implementare nella tecnologia che hai più familiarità con prima e quindi misurare se questo è davvero il collo di bottiglia del sistema.

Il modo migliore per farlo dipende in realtà dalla qualità e dalla natura dei dati e delle query. Per cominciare, 180 MB di dati in una singola tabella per i prodotti non sono un problema, a prescindere dal modo in cui li guardi. E 30.000 query al giorno sono ancora meno un problema. Con un database correttamente configurato, qualsiasi vecchio desktop può gestire questo carico.

Altri hanno già sottolineato le tue due principali opzioni, MySQL o un database noSQL.

Se hai un certo numero di attributi esistenti per ogni singolo prodotto (come produttore, prezzo, numero di magazzino, ecc., L'opzione migliore è quella di avere colonne per questi attributi e convertire le coppie chiave / valore in un formato di tabella piatta, con un ID prodotto come chiave primaria per quella tabella. Funzionerà molto bene anche se alcune colonne sono utilizzate solo da metà delle righe, poiché per la maggior parte dei prodotti sarà necessario eseguire solo 1 query per recuperare tutti i loro attributi. questi sono dati sui prodotti, immagino che sia abbastanza probabile che questa sia la struttura dei tuoi dati.

Se gli attributi variano ampiamente in presenza e tipo di dati, allora potresti essere meglio usando un database noSQL, che gestisce questo scenario in modo più efficiente rispetto ai tradizionali database SQL.

Per quanto riguarda le prestazioni: in precedenza ho lavorato per un'azienda di e-commerce, dove per lungo tempo al sito Web sono stati forniti dati da un server MySQL. Questo server aveva 2 GB di RAM, il database in totale era di ca. 5 GB di dimensioni e sotto carico il server ha gestito diverse migliaia di query al secondo. Sì, abbiamo fatto molta ottimizzazione delle query, ma questo è sicuramente fattibile.