Domanda

Qual è il database più veloce e più stabile non-SQL per memorizzare i dati di grandi dimensioni e di elaborare migliaia le richieste durante il giorno (è per il servizio di scambio di traffico)? Ho trovato KDB + e Berkeley DB. Sono buoni? Ci sono altre opzioni?

Maggiori dettagli ...

Ogni giorno i processi server> 100K visite. Per ogni visita ho bisogno di leggere statistiche corrispondenti da DB, scrittura di registro a DB e le statistiche di aggiornamento in DB, alias 3 operazioni con DB per visita. Il traffico è in continuo aumento. Così il motore DB dovrebbe essere veloce. Da un lato DB sarà gestito dal demone scritto su C, Erlang o qualsiasi altro linguaggio di basso livello. Da un altro lato DB sarà gestito da script PHP.

È stato utile?

Soluzione

Berkely DB è provato e testato ed indurito ed è al centro di molti sistemi di volume di transazioni mega-alti. Un esempio è quello delle infrastrutture gestore di telefonia mobile che utilizzano enormi negozi LDAP (OpenWave, per esempio) per elaborare più di 2 miliardi di transazioni al giorno. Questi sistemi anche comunemente hanno qualcosa come Oracle nel mix anche per il punto nel tempo di recupero, ma usano Berkeley DB come cache replicate.

Inoltre, BDB non è limitato a coppie di valori chiave nel semplice senso dei valori scalari. È possibile memorizzare tutto quello che vuoi nel valore, comprese le strutture arbitrarie / record.

Altri suggerimenti

Il file di sistema stesso è più veloce e più stabile di qualsiasi altra cosa. Memorizza Big Data senza soluzione di continuità e in modo efficiente. L'API è molto semplice.

È possibile memorizzare e recuperare dal file system molto, molto efficiente.

Dal momento che la tua domanda è un po 'sottile sui "requisiti" è difficile da dire molto di più.

Che dire di Redis?

http://code.google.com/p/redis/

Non ho provare ancora ha letto su di esso e sembra essere un abbastanza veloce e stabile per la memorizzazione dei dati. Esso fornisce anche una soluzione anti-single-point-fallimento decente, per quanto ho capito.

Cosa c'è di sbagliato con SqlLite ? Dal momento che non stabiliva esplicitamente non-SQL, Berkeley DB si basano su coppie chiave / valore che potrebbe non essere sufficiente per le vostre esigenze, se si desidera espandere il set di dati, ancora di più, come si dovrebbe fare che set di dati si riferiscono l'uno all'altro utilizzando il tasto / coppie di valori ....

D'altra parte, KDB +, guardando il FAQ sul loro sito web è un relazionale database che può gestire SQL tramite il loro linguaggio di programmazione D ... essere a conoscenza, se la necessità di migrare appare, ci potrebbero essere potenziali intoppi, come ad esempio i dialetti incompatibili o una query che utilizza specifiche vendor, da qui la possibilità di ottenere bloccato in tale banca dati e di non essere in grado di migrare a tutti ... qualcosa da tenere a mente per più tardi ...

È necessario essere attenti a ciò che si decide qui e guarda da una prospettiva a lungo termine, i futuri aggiornamenti, la migrazione a un altro database, quanto facile sarebbe di up-scala, etc

Una voce evidente in questa categoria è Intersystems Caché. (Beh, ovvio per me ...) Siate consapevoli, però, non è poco. (Ma non credo che KDB + è o.)

MongoDB è il database NoSQL più veloce e migliore. Dai un'occhiata alla questo benchmark prestazioni .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top