Puoi indicare strumenti di archiviazione dei dati alternativi e fornire buone ragioni per usarli al posto di vecchi database relazionali? A mio avviso, la maggior parte delle applicazioni usa raramente tutta la potenza di SQL: sarebbe interessante vedere come creare un'applicazione senza SQL.
Risposte:
File di testo normale in un filesystem
File XML o JSON su disco
Foglio di calcolo / file CSV
Subversion (o sistema di controllo della versione basato su disco simile)
Berkeley DB (Fondamentalmente, una tabella hash basata su disco)
Datastore di Google App Engine
Collezioni di lingue native (archiviate in memoria o serializzate su disco)
Motore di archiviazione personalizzato (scritto a mano)
Non posso dire di conoscere qualcosa di più su di loro, ma come si potrebbe anche guardare in sistemi di database oggetto .
La risposta di Matt Sheppard è ottima (mod up), ma terrò conto di questi fattori quando penso a un fuso:
Un vantaggio particolare dei file CSV su RDBMS è che possono essere facili da condensare e spostarsi praticamente su qualsiasi altra macchina. Effettuiamo trasferimenti di dati di grandi dimensioni e tutto è abbastanza semplice, utilizziamo solo un grande file CSV e facile da eseguire script utilizzando strumenti come rsync. Per ridurre la ripetizione su file CSV di grandi dimensioni, è possibile utilizzare qualcosa come YAML . Non sono sicuro che memorizzerei qualcosa come JSON o XML, a meno che tu non abbia requisiti di relazione significativi.
Per quanto riguarda le alternative non menzionate, non scartare Hadoop , che è un'implementazione open source di MapReduce. Questo dovrebbe funzionare bene se hai una tonnellata di dati vagamente strutturati che devono essere analizzati e vuoi essere in uno scenario in cui puoi semplicemente aggiungere altre 10 macchine per gestire l'elaborazione dei dati.
Ad esempio, ho iniziato a provare ad analizzare prestazioni che erano essenzialmente tutti i numeri di temporizzazione di diverse funzioni registrate su circa 20 macchine. Dopo aver provato a inserire tutto in un RDBMS, mi sono reso conto che non ho davvero bisogno di interrogare nuovamente i dati dopo averli aggregati. E per me è utile solo nel suo formato aggregato. Quindi, tengo i file di registro in giro, compressi e quindi lascio i dati aggregati in un DB.
Nota che sono più abituato a pensare con dimensioni "grandi".
Prova Prevayler: http://www.prevayler.org/wiki/ Prevayler è un'alternativa a RDBMS. Nel sito hanno maggiori informazioni.
Se non è necessario ACID , probabilmente non è necessario l'overhead di un RDBMS. Quindi, determinare se ne hai bisogno prima. La maggior parte delle risposte non RDBMS fornite qui non fornisce ACID.
Motore di archiviazione personalizzato (scritto a mano) / Prestazioni potenzialmente molto elevate nei casi di utilizzo richiesti
Se disponi di enormi set di dati, anziché crearne uno tuo, potresti utilizzare HDF, il formato di dati gerarchico.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format :
HDF supporta diversi modelli di dati, tra cui array multidimensionali, immagini raster e tabelle.
È anche gerarchico come un file system, ma i dati sono memorizzati in un file binario magico.
HDF5 è una suite che rende possibile la gestione di raccolte dati estremamente grandi e complesse.
Pensa ai petabyte di dati di telerilevamento della NASA / JPL.
Buongiorno,
Un caso a cui riesco a pensare è quando i dati che stai modellando non possono essere facilmente rappresentati in un database relazionale.
Una volta tale esempio è il database utilizzato dagli operatori di telefonia mobile per monitorare e controllare le stazioni base per le reti di telefonia mobile.
In quasi tutti questi casi, viene utilizzato un DB OO , un prodotto commerciale o un sistema a rotazione automatica che consente l'erarchia di oggetti.
Ho lavorato su un'applicazione di monitoraggio 3G per una grande azienda che rimarrà senza nome, ma il cui logo è una macchia di vino rosso (-: e hanno usato un tale OO DB per tenere traccia di tutti i vari attributi per le singole celle all'interno del Rete.
L'interrogazione di tali DB viene eseguita utilizzando tecniche proprietarie che, di solito, sono completamente prive di SQL.
HTH.
Saluti,
rapinare
I database di oggetti non sono database relazionali. Possono essere davvero utili se si desidera semplicemente inserire alcuni oggetti in un database. Supportano inoltre il controllo delle versioni e la modifica delle classi per gli oggetti già esistenti nel database. db4o è il primo che viene in mente.
C'era uno strumento RAD chiamato JADE scritto alcuni anni fa che ha un OODBMS integrato. Anche le precedenti incarnazioni del motore DB supportavano Digitalk Smalltalk. Se si desidera campionare la creazione di applicazioni utilizzando un paradigma non RDBMS, questo potrebbe essere un inizio.
Altri prodotti OODBMS includono Objectivity , GemStone (è necessario ottenere VisualWorks Smalltalk per eseguire la versione Smalltalk ma esiste anche una versione java). Ci sono stati anche alcuni progetti di ricerca open source in questo spazio: EXODUS e il suo discendente SHORE vengono in mente.
Purtroppo, il concetto sembrava morire, probabilmente a causa della mancanza di uno standard chiaramente visibile e di una capacità di query ad hoc relativamente scarsa rispetto ai sistemi RDMBS basati su SQL.
Un OODBMS è più adatto per le applicazioni con strutture di dati di base che sono meglio rappresentate come un grafico di nodi interconnessi. Dicevo che l'applicazione OODBMS per antonomasia era un Dungeon multiutente (MUD) in cui le stanze contenevano gli avatar dei giocatori e altri oggetti.
Puoi fare molto, semplicemente usando i file memorizzati nel file system. Gli RDBMS stanno migliorando nella gestione dei BLOB, ma questo può essere un modo naturale per gestire i dati di immagine e simili, in particolare se le query sono semplici (elencando e selezionando singoli elementi).
Altre cose che non si adattano molto bene in un RDBMS sono le strutture di dati gerarchiche e suppongo che i dati geospaziali e i modelli 3D non siano così facili da lavorare con entrambi.
Servizi come Amazon S3 forniscono modelli di archiviazione più semplici (chiave-> valore) che non supportano SQL. La scalabilità è la chiave lì.
Anche i file Excel possono essere utili, in particolare se gli utenti devono essere in grado di manipolare i dati in un ambiente familiare e creare un'applicazione completa per farlo non è fattibile.
Esistono molti modi per archiviare i dati - anche "database relazionale" copre una gamma di alternative da una semplice libreria di codice che manipola un file locale (o file) come se fosse un database relazionale su un singolo utente, attraverso sistemi basati su file che possono gestire più utenti per una generosa selezione di seri sistemi basati su "server".
Usiamo molto i file XML: ottieni dati ben strutturati, strumenti utili per interrogare la stessa capacità di apportare modifiche, se del caso, qualcosa che è leggibile dall'uomo e non devi quindi preoccuparti del funzionamento del motore db (o del funzionamento del motore db). Questo funziona bene per cose che sono essenzialmente di sola lettura (nel nostro caso il più delle volte generate da un db altrove) e anche per sistemi a utente singolo in cui è possibile caricare e salvare i dati secondo necessità - ma si stanno creando opportunità per problemi se si desidera la modifica multiutente - almeno di un singolo file.
Per noi questo è tutto: o useremo qualcosa che farà SQL (MS offre un set di strumenti che vanno da un .DLL per fare cose da singolo utente fino al server aziendale e parlano tutti lo stesso SQL (con limitazioni all'estremità inferiore)) o useremo XML come formato perché (per noi) la verbosità è raramente un problema.
Al momento non è necessario manipolare i dati binari nelle nostre app in modo che non sorgano domande.
Murph
Si potrebbe voler considerare l'uso di un server LDAP al posto di un database SQL tradizionale se i dati dell'applicazione sono fortemente orientati al valore / chiave e di natura gerarchica.
I file BTree sono spesso molto più veloci dei database relazionali. SQLite contiene al suo interno una libreria BTree che è di dominio pubblico (come in "pubblico dominio", senza usare il termine in senso lato).
Francamente, se volessi un sistema multiutente, avrei bisogno di molte convinzioni per non usare un database relazionale di server decente.
Database full-text, che possono essere interrogati con operatori di prossimità come "entro 10 parole da", ecc.
I database relazionali sono uno strumento di business ideale per molti scopi: abbastanza facili da capire e progettare, abbastanza veloci, adeguati anche quando non sono progettati e ottimizzati da un genio che potrebbe "sfruttare tutta la potenza", ecc.
Ma alcuni scopi aziendali richiedono l'indicizzazione full-text, che i motori relazionali non forniscono o considerano come ripensamento. In particolare, i campi legali e medici hanno ampie strisce di testo non strutturato da archiviare e guadare.
Inoltre: * Scenari incorporati: dove di solito è necessario utilizzare qualcosa di più piccolo di un RDBMS completo. Db4o è un ODB che può essere facilmente utilizzato in tal caso. * Sviluppo rapido o proof-of-concept - in cui si desidera concentrarsi sul business e non preoccuparsi del livello di persistenza
Il teorema di CAP lo spiega in modo succinto. SQL fornisce principalmente "Solida coerenza: tutti i client vedono la stessa vista, anche in presenza di aggiornamenti".
KISS: Keep It Small and Simple
Vorrei offrire RDBMS :) Se non vuoi avere problemi con la configurazione / amministrazione vai su SQLite. RDBMS integrato con supporto SQL completo. Ti consente persino di archiviare qualsiasi tipo di dati in qualsiasi colonna.
Vantaggio principale rispetto ad esempio al file di registro: se ne hai uno enorme, come hai intenzione di cercarlo? Con il motore SQL è sufficiente creare indice e velocizzare notevolmente le operazioni.
Informazioni sulla ricerca full-text: SQLite dispone anche di moduli per la ricerca full-text.
Goditi semplicemente una bella interfaccia standard per i tuoi dati :)
Un buon motivo per non utilizzare un database relazionale sarebbe quando si dispone di un enorme set di dati e si desidera eseguire un'elaborazione massicciamente parallela e distribuita sui dati. L'indice Web di Google sarebbe un perfetto esempio di un caso del genere.
Hadoop ha anche un'implementazione del file system di Google chiamato Hadoop Distributed File System .
Consiglio vivamente Lua come alternativa al tipo di archiviazione dei dati di tipo SQLite.
Perché:
Questa è l'opzione "raccolta della lingua madre" della risposta accettata. Se stai usando C / C ++ come livello di applicazione, è perfettamente ragionevole inserire il motore Lua (100kB di binario) solo per leggere config / dati o scriverli.