I database di nuova generazione

Sto imparando i database relazionali tradizionali (con PostgreSQL ) e facendo qualche ricerca ho trovato alcuni nuovi tipi di database. CouchDB , Drizzle e Scalaris per citarne alcuni, quali saranno le prossime tecnologie di database da affrontare?

Direi database di nuova generazione, non SQL di prossima generazione.

SQL è un linguaggio per interrogare e manipolare i database relazionali. SQL è dettato da uno standard internazionale. Mentre lo standard viene revisionato, sembra funzionare sempre all’interno del paradigma del database relazionale.

Ecco alcune nuove tecnologie di archiviazione dei dati che stanno attirando l’attenzione al momento:

  • CouchDB è un database non relazionale. Lo chiamano un database orientato ai documenti.
  • Amazon SimpleDB è anche un database non relazionale accessibile in modo distribuito attraverso un servizio web. Amazon ha anche un negozio a valore-chiave distribuito chiamato Dynamo , che alimenta alcuni dei suoi servizi S3.
  • Dynomite e Kai sono soluzioni open source ispirate ad Amazon Dynamo.
  • BigTable è una soluzione di archiviazione dei dati proprietaria utilizzata da Google e implementata utilizzando la tecnologia di Google File System. Il framework MapReduce di Google utilizza BigTable.
  • Hadoop è una tecnologia open source ispirata a MapReduce di Google, che serve un’esigenza simile, per distribuire il lavoro di archivi di dati su larga scala.
  • Scalaris è un archivio di chiavi / valori transazionali distribuito. Inoltre non relazionale e non usa SQL. È un progetto di ricerca dell’Istituto Zuse di Berlino, in Germania.
  • RDF è uno standard per la memorizzazione di dati semantici, in cui i dati e i metadati sono intercambiabili. Ha il suo linguaggio di query SPARQL, che assomiglia superficialmente a SQL, ma in realtà è completamente diverso.
  • Vertica è un database analitico orientato alle colonne altamente scalabile progettato per l’architettura distribuita (grid). Sostiene di essere relazionale e conforms a SQL. Può essere utilizzato tramite l’Elastic Compute Cloud di Amazon.
  • Greenplum è un DBMS di data warehousing su vasta scala, che implementa sia MapReduce che SQL.
  • XML non è affatto un DBMS, è un formato di interscambio. Ma alcuni prodotti DBMS funzionano con dati in formato XML.
  • ODBMS o Object Database sono per la gestione di dati complessi. Non sembrano esserci prodotti ODBMS dominanti nel mainstream, forse a causa della mancanza di standardizzazione. SQL standard sta gradualmente acquisendo alcune funzioni OO (ad esempio tipi di dati estensibili e tabelle).
  • Drizzle è un database relazionale, ricavando gran parte del suo codice da MySQL. Comprende vari cambiamenti architettonici progettati per gestire i dati in un’architettura di sistema “cloud computing” scalabile. Presumibilmente continuerà a utilizzare SQL standard con alcuni miglioramenti di MySQL.
  • Cassandra è un negozio di valori-chiave altamente scalabile, alla fine coerente, distribuito, strutturato, sviluppato su Facebook da uno degli autori di Amazon Dynamo e che ha contribuito al progetto Apache.
  • Project Voldemort è un sistema di archiviazione a valore chiave non relazionale, distribuito. È usato su LinkedIn.com
  • Anche Berkeley DB merita una menzione. Non è “next-gen” perché risale ai primi anni ’90. È un popolare negozio di valore-chiave che è facile da incorporare in una varietà di applicazioni. La tecnologia è attualmente di proprietà di Oracle Corp.

Vedi anche questo bell’articolo di Richard Jones: ” Anti-RDBMS: un elenco di negozi a valori-chiave distribuiti “. Entra più nel dettaglio descrivendo alcune di queste tecnologie.

I database relazionali hanno punti deboli, per essere sicuri. Le persone sostengono che non gestiscono tutti i requisiti di modellazione dei dati dal giorno in cui è stata introdotta per la prima volta.

Anno dopo anno, i ricercatori escogitano nuovi modi di gestire i dati per soddisfare requisiti speciali: o requisiti per gestire relazioni dati che non si adattano al modello relazionale, oppure requisiti di volume o velocità elevati che richiedono l’elaborazione dei dati su raccolte di server distribuiti, invece di server di database centrali.

Sebbene queste tecnologie avanzate facciano grandi cose per risolvere il problema specifico per cui sono state progettate, i database relazionali sono ancora una buona soluzione generica per la maggior parte delle esigenze aziendali. SQL non sta andando via.


Ho scritto un articolo su php | Architect magazine sull’innovazione dei database non relazionali e sulla modellazione dei dati nei database relazionali e non relazionali. http://www.phparch.com/magazine/2010-2/september/

Mi mancano i database di grafici nelle risposte finora. Un grafico o una rete di oggetti è comune nella programmazione e può essere utile anche nei database. È in grado di gestire le informazioni semi-strutturate e interconnesse in modo efficiente. Tra le aree in cui i database di grafi hanno guadagnato molto interesse ci sono il web semantico e la bioinformatica. È stato menzionato RDF, ed è in effetti un linguaggio che rappresenta un grafico. Ecco alcuni suggerimenti su cosa sta accadendo nell’area del database grafico:

  • Grafici: una migliore astrazione del database
  • Graphd, il back-end di Freebase
  • Motore di database grafico open source Neo4j
  • AllegroGraph RDFstore
  • Strato di astrazione Graphdb per bioinformatica
  • Graphdb dietro il motore di raccomandazione Directed Edge

Faccio parte del progetto Neo4j , che è scritto in Java ma ha anche collegamenti a Python, Ruby e Scala. Alcune persone lo usano con Clojure o Groovy / Grails. C’è anche uno strumento GUI in evoluzione.

Potrebbe non essere il posto migliore per rispondere con questo, ma mi piacerebbe condividere questa tassonomia del mondo noSQL creato da Steve Yen (si prega di trovarlo su http://de.slideshare.net/northscale/nosqloakland-200911021 )

  1. valore-chiave-cache

    • memcached
    • repcached
    • coerenza
    • in fi nispan
    • eXtreme scale
    • cache jboss
    • velocità
    • terracoqa
  2. valore-chiave in negozio

    • keyspace
    • fl sono
    • schema-free
    • RAMCloud
  3. key-value-store alla fine coerente

    • dinamo
    • voldemort
    • Dynomite
    • subrecord
    • MongoDb
    • Dovetaildb
  4. ordinata-valore-chiavi

    • tokyo tiranno
    • lightcloud
    • NMDB
    • LUXIO
    • memcachedb
    • ACTORD
  5. server di strutture dati

    • Redis
  6. tuple-store

    • GigaSpaces
    • coord
    • fiume Apache
  7. database degli oggetti

    • ZopeDB
    • db4o
    • bassofondo
  8. negozio di documenti

    • CouchDB
    • Mongo
    • Jackrabbit
    • Database XML
    • ThruDB
    • CloudKit
    • perservere
    • Riak Basho
    • scalaris
  9. ampio magazzino colonnare

    • Tavolo grande
    • HBase
    • cassandra
    • Hypertable
    • KAI
    • OpenNep

Per dare un’occhiata a ciò che la ricerca accademica sta facendo nell’area dei database next gen, dai un’occhiata a questo: http://www.thethirdmanifesto.com/

Per quanto riguarda il linguaggio SQL come una corretta implementazione del modello relazionale, cito da wikipedia, “SQL, inizialmente spinto come linguaggio standard per i database relazionali, si discosta dal modello relazionale in diversi punti. menzionare il modello relazionale o utilizzare termini o concetti relazionali, tuttavia è ansible creare un database conforms al modello relazionale utilizzando SQL se non si utilizzano determinate funzionalità SQL. ”

http://en.wikipedia.org/wiki/Relational_model (di riferimento nella sezione “SQL e il modello relazionale” il 28 marzo 2010

Non essere pedante, ma vorrei sottolineare che almeno CouchDB non è basato su SQL. E mi auguro che il prossimo gen SQL renderebbe SQL molto meno … fugace e non intuitivo.

Esistono database speciali per XML come MarkLogic e Berkeley XMLDB. Possono indicizzare xml-doc e uno può interrogarli con XQuery. Mi aspetto dei database JSON, forse esistono già. Ha fatto un po ‘googling ma non riuscivo a trovarne uno.

SQL è in circolazione dai primi anni ’70, quindi non credo che andrà via presto.

Forse il ‘nuovo (-ish) sql’ sarà oql (vedi http://en.wikipedia.org/wiki/ODBMS )

Ho sentito parlare anche di NimbusDB di Jim Starkey

Jim Starkey è l’uomo che “crea” Interbase

chi lavora su Vulcan (una fork di Firebird)

e chi era all’inizio di Falcon per MySQL