Utilizzando un database relazionale per Schemaless dati - Best Practices

Question

Dopo aver letto un articolo scioccante scritto da Bret Taylor (co-creatore di FriendFeed, attuale CTO di Facebook), How FriendFeed uses MySQL to store schema-less data, ho cominciato a chiedermi se ci sono le best practice per l'utilizzo di un RDBMS come Oracle, MySQL o PostgreSQL per la memorizzazione e l'interrogazione di dati di schemi?

Poche persone amano ammettere di utilizzare un database relazionale quando NoSQL è il nuovo hotness, il che rende difficile trovare buoni articoli sull'argomento. Come posso implementare un database di schemi (o "orientato ai documenti") come strato su un database relazionale?

Answer 1

Quello è il classico articolo in questo argomento: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html (Utilizzando MySQL come NoSQL - Una storia per superamento 750.000 QPS su un server commodity)

Answer 2

Memorizzazione schemaless dati in SQL fondamentalmente significa attuare un negozio di valori-chiave che accade usare SQL come back-end. Dal momento che non si utilizzano funzionalità relazionali e lo schema è abbastanza banale non si troveranno molte informazioni sulla progettazione di database SQL in questo modo. Tuttavia, dovresti essere in grado di trovare molte più informazioni generali sulla progettazione di applicazioni per l'archiviazione dei valori-chiave che verranno applicate.

Answer 3

Non troverete molto su questo argomento perché molte persone costruiscono soluzioni a scopo singolo. Le loro soluzioni sono progettate per soddisfare molto bene una necessità. I database NoSQL richiedono molto tempo per costruire questi archivi di dati monouso, ma si paga per non avere la flessibilità e alcuni dei controlli e delle funzionalità di sicurezza incorporati di un RDBMS.

Answer 4

Ho studiato questo problema in modo approfondito. È piuttosto banale modellare i dati degli schemi in un RDBMS usando una tabella "proprietà" (essenzialmente usando coppie chiave/valore). La parte difficile è indicizzare e interrogare le tue cose. (Essenzialmente tutta la complessità affrontata da Friendfeed è incentrata su questo problema.)

Se si indice la tabella delle proprietà si finisce con un indice su tutte le proprietà. Questo non è auspicabile in quanto aggiunge troppi sovraccarichi poiché si desidera eseguire query solo su determinate proprietà. Inoltre, vorrete sicuramente accedere alle vostre cose tramite indici composti. È incredibilmente complesso modellare gli indici composti. Le uniche soluzioni che ho trovato richiedono che tu costruisca i tuoi indici usando lo schema solo per quello scopo: molto ingombrante. Più lo guardavo, meno sembrava pratico.

Una buona soluzione a questo problema si basa sull'utilizzo di indici parziali (noti anche come indici filtrati).

Answer 5

Gli ingegneri di Quora utilizzano MySQL as the data store instead of NoSQLs such as Cassandra, MongoDB, CouchDB etc. Sono partition data at the application level, il che significa che partizionano i dati solo se necessario, tengono i dati su una macchina se possibile e utilizzano un hash della chiave primaria per partizionare set di dati più grandi su più database. Il partizionamento dei dati a livello di applicazione funziona in modo tale che i dati che soddisfano una serie di criteri siano "trasferiti" a un database mentre i dati che non soddisfano tali criteri (o forse un diverso insieme di criteri) possono essere inviati a un altro database