python - try - sottoscrizione azure




Database di valori-chiave affidabile ed efficiente per Linux? (7)

Ho avuto fortuna con la soluzione Tokyo Cabinet / pytc. È molto veloce (un po 'più veloce dell'usare il modulo shelve usando anydbm nella mia implementazione), sia per la lettura che per la scrittura (anche se anch'io faccio molta più lettura). Il problema per me era la documentazione spartana sui collegamenti Python, ma c'è un codice di esempio sufficiente per capire come fare ciò che devi fare. Inoltre, tokyo cabinet è abbastanza facile da installare (come i collegamenti Python), non richiede un server (come si dice) e sembra essere attivamente supportato (stabile ma non più in fase di sviluppo attivo). È possibile aprire i file in modalità di sola lettura, consentendo l'accesso simultaneo o la modalità di lettura / scrittura, impedendo ad altri processi di accedere al database.

Stavo osservando varie opzioni durante l'estate, e il consiglio che ho ricevuto è stato questo: provare le diverse opzioni e vedere cosa funziona meglio per te. Sarebbe bello se ci fosse semplicemente un'opzione "migliore", ma tutti sono alla ricerca di caratteristiche leggermente diverse e sono disposti a fare diversi compromessi. Tu sai meglio.

(Detto questo, sarebbe utile per gli altri se condividessi ciò che ha finito per funzionare al meglio per te, e perché hai scelto quella soluzione rispetto ad altri!)

Ho bisogno di un database di valori-chiave veloce, affidabile ed efficiente in memoria per Linux. Le mie chiavi sono circa 128 byte e la dimensione massima del valore può essere 128K o 256K. Il sottosistema del database non deve utilizzare più di circa 1 MB di RAM. La dimensione totale del database è 20G (!), Ma si accede solo a una piccola porzione casuale dei dati alla volta. Se necessario, posso spostare alcuni dati BLOB dal database (in file normali), quindi le dimensioni scendono a 2 GB al massimo. Il database deve sopravvivere a un arresto del sistema senza alcuna perdita nei dati non modificati di recente. Avrò circa 100 volte più letture rispetto alle scritture. È un vantaggio se può utilizzare un dispositivo a blocchi (senza un filesystem) come memoria. Non ho bisogno di funzionalità client-server, solo una libreria. Ho bisogno di collegamenti Python (ma posso implementarli se non sono disponibili).

Quali soluzioni dovrei prendere in considerazione e quale raccomandi?

Candidati che so di quali potrebbero funzionare:

  • Tokyo Cabinet (i collegamenti Python sono pytc , si veda anche il codice di esempio pytc , supporta gli hash e gli alberi B +, i file di registro delle transazioni e altro ancora, la dimensione dell'array bucket viene fissata al momento della creazione del database, il writer deve chiudere il file per dare ad altri un possibilità: molte piccole scritture con la riapertura del file per ognuna di esse sono molto lente, il server Tyrant può aiutare con un sacco di piccole scritture: confronto veloce tra Tokyo Cabinet, Tokyo Tyrant e Berkeley DB )
  • VSDB (sicuro anche su NFS, senza blocco, per quanto riguarda le barriere ?; gli aggiornamenti sono molto lenti, ma non così lenti come in cdb, ultima versione nel 2003)
  • BerkeleyDB (fornisce il ripristino di emergenza, fornisce transazioni, il modulo Python bsddb fornisce i binding)
  • TDB di Samba (con transazioni e collegamenti Python, alcuni utenti hanno subito problemi di corruzione , a volte mmap() s l'intero file, l'operazione di repack raddoppia le dimensioni del file, produce misteriosi guasti se il database è maggiore di 2G (anche su sistemi a 64 bit) , anche l'implementazione cluster ( CTDB ) è disponibile, il file diventa troppo grande dopo molte modifiche, il file diventa troppo lento dopo molti conflitti hash, nessun modo incorporato per ricostruire il file, aggiornamenti paralleli molto rapidi bloccando singoli bucket hash)
  • aodbm (append-only sopravvive a un crash del sistema, con collegamenti Python)
  • hamsterdb (con attacchi Python)
  • C-tree (soluzione commerciale matura e versatile ad alte prestazioni, ha una versione gratuita con funzionalità ridotte)
  • il vecchio TDB (dal 2001)
  • bitcask (log-strutturato, scritto in Erlang)
  • varie altre implementazioni DBM (come GDBM, NDBM, QDBM, Perl's SDBM o Ruby's, probabilmente non hanno un crash recovery corretto)

Non userò questi:

  • MemcacheDB (client-server, usa BereleleyDB come back-end)
  • cdb (ha bisogno di rigenerare l'intero database ad ogni scrittura)
  • http://www.wildsparx.com/apbcdb/ (idem)
  • Redis (mantiene l'intero database in memoria)
  • SQLite (diventa molto lento senza passare periodicamente l'aspirapolvere, vedere il completamento automatico nella barra degli indirizzi in Firefox 3.0, anche se le versioni 3.1 e successive di sqlite consentono l' auto_vacuum , attenzione: le piccole transazioni di scrittura possono essere molto lente; sta facendo molte transazioni, altri processi muoiono di fame e non possono mai ottenere il blocco)
  • MongoDB (troppo pesante, tratta i valori come oggetti con struttura interna)
  • Firebird (RDBMS basato su SQL, troppo pesante)

Cordiali saluti, un recente articolo sui database di valori chiave nella rivista Linux.

FYI, una vecchia lista di software

Cordiali saluti, un confronto di velocità di MemcacheDB, Redis e Tokyo Cabinet Tyrant

Domande correlate su StackOverflow:


Ho usato bsddb.hashlib () con Python, ha funzionato abbastanza bene.



Potresti gradire il cdb djb , che ha le proprietà che hai citato.


Un altro suggerimento è TDB (una parte del progetto Samba). L'ho usato attraverso il modulo tdb , tuttavia non posso dire di aver testato la sua affidabilità in caso di crash; i progetti in cui l'ho usato non avevano tali requisiti e non riesco a trovare la documentazione pertinente.


cdb può gestire qualsiasi database fino a 4 GB, rendendolo troppo piccolo per la materia da 20GB a portata di mano.


che ne dici di un SQLite?





key-value