Buoni motivi per NON utilizzare un database relazionale?
https://stackoverflow.com/questions/37823
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Potete per favore indicare strumenti alternativi di archiviazione dei dati e fornire buone ragioni per usarli al posto dei cari vecchi database relazionali?A mio parere, la maggior parte delle applicazioni utilizza raramente tutta la potenza di SQL: sarebbe interessante vedere come creare un'applicazione priva di SQL.
Soluzione
File di testo semplice in un file system
- Molto semplice da creare e modificare
- Facile da manipolare per gli utenti con strumenti semplici (ad es.editor di testo, grep ecc.)
- Archiviazione efficiente di documenti binari
File XML o JSON su disco
- Come sopra, ma con un po' più di capacità di convalidare la struttura.
Foglio di calcolo/file CSV
- Modello molto semplice da comprendere per gli utenti aziendali
Subversion (o sistema di controllo della versione basato su disco simile)
- Ottimo supporto per il controllo delle versioni dei dati
Berkeley DB (Fondamentalmente, una tabella hash basata su disco)
- Molto semplice concettualmente (solo chiave/valore non digitato)
- Abbastanza veloce
- Nessun sovraccarico amministrativo
- Supporta le transazioni, credo
- Molto simile a Berkeley DB, credo, ma ospitato
Archivio dati di App Engine di Google
- Ospitato e altamente scalabile
- Archiviazione di valori-chiave per documento (ad es.modello dati flessibile)
- Focus sul documento
- Archiviazione semplice di dati semistrutturati/basati su documenti
Raccolte in lingua nativa (archiviate in memoria o serializzate su disco)
- Integrazione linguistica molto stretta
Motore di archiviazione personalizzato (scritto a mano).
- Prestazioni potenzialmente molto elevate nei casi d'uso richiesti
Non posso affermare di sapere molto su di loro, ma potrebbe anche interessarti approfondire sistemi di database di oggetti.
Altri suggerimenti
La risposta di Matt Sheppard è ottima (modifica), ma terrei conto di questi fattori quando penso a un mandrino:
- Struttura :ovviamente si rompe in pezzi o stai facendo dei compromessi?
- Utilizzo:come verranno analizzati/recuperati/grokkizzati i dati?
- Tutta la vita :per quanto tempo i dati sono utili?
- Misurare :quanti dati ci sono?
Un vantaggio particolare dei file CSV rispetto agli RDBMS è che possono essere facili da condensare e spostare praticamente su qualsiasi altra macchina.Effettuiamo trasferimenti di dati di grandi dimensioni e tutto è abbastanza semplice: utilizziamo solo un grande file CSV ed è facile creare script utilizzando strumenti come rsync.Per ridurre la ripetizione su file CSV di grandi dimensioni, potresti usare qualcosa di simile 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 fare sconti 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 trovarti 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 le prestazioni che erano essenzialmente tutti i numeri temporali 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 una volta aggregati.E per me è utile solo nel suo formato aggregato.Quindi, tengo i file di registro in giro, compressi e poi lascio i dati aggregati in un DB.
Nota Sono più abituato a pensare con taglie "grandi".
Il filesystem è piuttosto utile per archiviare dati binari, cosa che non funziona mai molto bene nei database relazionali.
Prova Prevayler:http://www.prevayler.org/wiki/Prevayler è un'alternativa all'RDBMS.Nel sito troverete maggiori informazioni.
Se non ti serve ACIDO, probabilmente non hai bisogno del sovraccarico di un RDBMS.Quindi, determina prima se ne hai bisogno.La maggior parte delle risposte non RDBMS fornite qui lo fanno non fornire ACID.
Motore di archiviazione personalizzato (scritto a mano)/Prestazioni potenzialmente molto elevate nei casi d'uso richiesti
Se disponi di enormi set di dati, invece di crearne uno tuo, potresti utilizzare HDF, il formato dati gerarchico.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format:
HDF supporta diversi modelli di dati, inclusi array multidimensionali, immagini raster e tabelle.
È anche gerarchico come un file system, ma i dati sono archiviati in un unico 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 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.
Un esempio è il database utilizzato dagli operatori di telefonia mobile per monitorare e controllare le stazioni base per le reti di telefonia mobile.
Ho quasi tutti questi casi, an OODB viene utilizzato un prodotto commerciale o un sistema auto-laminato che consente gerarchie 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 utilizzato un tale DB OO per tenere traccia di tutti i vari attributi per le singole celle all'interno della rete.
L'interrogazione di tali DB viene effettuata utilizzando tecniche proprietarie che sono, solitamente, completamente esenti da SQL.
HTH.
saluti,
rapinare
I database di oggetti non sono database relazionali.Possono essere davvero utili se vuoi semplicemente inserire alcuni oggetti in un database.Supportano inoltre il controllo delle versioni e la modifica delle classi per oggetti già esistenti nel database. db4o è il primo che mi viene in mente.
In alcuni casi (ad esempio dati sui mercati finanziari e controllo dei processi) potrebbe essere necessario utilizzare un database in tempo reale anziché un RDBMS.Vedere collegamento wiki
C'era uno strumento RAD chiamato GIADA scritto alcuni anni fa che ha un OODBMS integrato.Le precedenti incarnazioni del motore DB supportavano anche Digitalk Smalltalk.Se desideri provare la creazione di applicazioni utilizzando un paradigma non RDBMS, questo potrebbe essere un inizio.
Altri prodotti OODBMS includono Obiettività, Pietra preziosa (Dovrai ottenere VisualWorks Smalltalk per eseguire la versione Smalltalk ma esiste anche una versione Java).C'erano anche alcuni progetti di ricerca open source in questo spazio: mi vengono in mente EXODUS e il suo discendente SHORE.
Purtroppo, il concetto sembrava essere morto, probabilmente a causa della mancanza di uno standard chiaramente visibile e di capacità di query ad hoc relativamente scarse rispetto ai sistemi RDMBS basati su SQL.
Un OODBMS è più adatto per applicazioni con strutture dati principali che sono meglio rappresentate come un grafico di nodi interconnessi.Dicevo che la quintessenza dell'applicazione OODBMS era un Multi-User Dungeon (MUD) in cui le stanze avrebbero contenuto gli avatar dei giocatori e altri oggetti.
Puoi fare molto semplicemente utilizzando i file archiviati nel file system.Gli RDBMS stanno migliorando nella gestione dei BLOB, ma questo può essere un modo naturale per gestire dati di immagine e simili, in particolare se le query sono semplici (enumerazione e selezione di singoli elementi).
Altre cose che non si adattano molto bene a un RDBMS sono le strutture di dati gerarchiche e immagino che neanche i dati geospaziali e i modelli 3D siano così facili da lavorare.
Servizi come Amazon S3 fornire 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 numerosi modi per archiviare i dati: anche il "databse 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 base utente singolo, fino a dai sistemi basati su file in grado di gestire più utenti a una generosa selezione di seri sistemi basati su "server".
Usiamo molto file XML: ottieni dati ben strutturati, strumenti utili per eseguire query sugli stessi, la possibilità di apportare modifiche se appropriato, qualcosa che sia leggibile dall'uomo e non devi quindi preoccuparti del funzionamento del motore DB (o del funzionamento del motore DB).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 puoi semplicemente caricare i dati e salvarli come richiesto, ma stai creando opportunità per problemi se desideri la modifica multiutente, almeno di un singolo file.
Per noi è tutto: o useremo qualcosa che esegua SQL (MS offre una serie di strumenti che vengono eseguiti da un file .DLL per eseguire operazioni per singolo utente fino al server aziendale e parlano tutti lo stesso SQL (con limitazioni nella parte inferiore)) oppure utilizzeremo XML come formato perché (per noi) la verbosità raramente è un problema.
Al momento non dobbiamo manipolare i dati binari nelle nostre app, quindi questa domanda non si pone.
Murph
Si potrebbe prendere in considerazione l'uso di un server LDAP al posto di un database SQL tradizionale se i dati dell'applicazione sono fortemente orientati a chiave/valore 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 pubblico dominio (come nel vero e proprio "dominio pubblico", senza usare il termine in modo approssimativo).
Francamente, però, se volessi un sistema multiutente avrei bisogno di molta persuasione a non utilizzare un database relazionale 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 aziendale ideale per molti scopi: abbastanza facili da comprendere 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 del testo completo, che i motori relazionali non forniscono o considerano in un secondo momento.In particolare, i settori legale e medico hanno ampie porzioni di testo non strutturato da archiviare e sfogliare.
Anche:* Scenari incorporati: in cui di solito è necessario utilizzare qualcosa di più piccolo di un RDBMS completo. Db4o è un ODB che può essere facilmente utilizzato in questi casi.* Sviluppo rapido o proof-of-concept: in cui desideri concentrarti sul business e non preoccuparti del livello di persistenza
Teorema del CAP lo spiega in modo sintetico.SQL fornisce principalmente "Coerenza forte:tutti i client vedono la stessa vista, anche in presenza di aggiornamenti".
BACIO:Mantienilo piccolo e semplice
Offrirei RDBM: :) Se non si non si verifichi problemi con l'impostazione/amministrazione, vai per SQLite.RDBMS integrato con supporto SQL completo.Ti consente anche di memorizzare qualsiasi tipo di dati in qualsiasi colonna.
Vantaggio principale rispetto ad esempio al file di registro:Se ne hai uno enorme, come lo cercherai?Con il motore SQL puoi semplicemente creare un indice e velocizzare notevolmente le operazioni.
Informazioni sulla ricerca del testo completo:SQLite dispone anche di moduli per la ricerca full-text.
Goditi semplicemente la 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 di File system di Google chiamato il File system distribuito Hadoop.
Consiglio vivamente Lua come alternativa all'archiviazione dei dati di tipo SQLite.
Perché:
- Il linguaggio è stato progettato inizialmente come linguaggio di descrizione dei dati
- La sintassi è leggibile dall'uomo (XML is non)
- È possibile compilare blocchi Lua in formato binario, per prestazioni aggiuntive
Questa è l'opzione "raccolta della lingua madre" della risposta accettata.Se stai utilizzando C/C++ come livello di applicazione, è perfettamente ragionevole inserire il motore Lua (100kB di binario) solo per il gusto di leggere configurazioni/dati o scriverli.
