it-swarm.it

NoSQL vs Other SQL Drupal Setups

Quali sono i vantaggi di eseguire NoSQL (ex MongoDB) su MySQL, PostGRE SQL o MSSQL in Drupal? I vantaggi ottenuti dal semplice utilizzo dell'archiviazione o è necessario modificare alcuni Drupal?

14
Kevin

MongoDB può essere utilizzato per archiviare la maggior parte o tutte le entità in un archivio rapido e orientato ai documenti. Questo tipo di archiviazione è molto più scalabile rispetto allo storage standard basato su SQL che abbiamo in Drupal core (che si basa su uno schema "una tabella per campo").

Nello stato attuale di Drupal 7, avresti:

  • La tabella di base dell'entità archiviata su SQL (ad es. La tabella degli utenti, la tabella dei nodi, ecc.)
  • Tutti i campi memorizzati in SQL
  • Le proprietà delle entità dalle loro tabelle di base duplicate in MongoDB

Ciò consente una rapida interrogazione sulle entità su MongoDB e la possibilità di aggiungere indici complessi che nessun database SQL di OpenSource supporta (inclusi gli indici tra le tabelle). Allo stesso tempo, non si perde interoperabilità perché la tabella di base dell'entità è ancora memorizzata in SQL e può quindi essere unita da moduli che sono ancora solo SQL (come Flag).

Questo tipo di query veloce è disponibile grazie al meccanismo EntityFieldQuery, un modo per creare query su entità, proprietà e campi in modo astratto. L'implementazione predefinita nel core traduce queste query in SQL, ma il modulo MongoDB ha un'implementazione completa che può soddisfare direttamente quelle query da MongoDB.

Grazie al backend EntityFieldQuery per Views , puoi facilmente sfruttare questo potere, usando gli strumenti a cui sei abituato. L'unico aspetto negativo è che le relazioni non sono supportate (ma in pratica raramente ne hai bisogno comunque - e questo può essere aggirato spingendo dati aggiuntivi nell'oggetto entità e aggiungendoli esponendoli come proprietà aggiuntive dell'entità).

In breve, non appena le prestazioni della query rappresentano un problema nel progetto, che si verifica non appena si dispone di un set di dati significativo (diciamo a partire da poche decine di migliaia di entità su un determinato tipo di entità), MongoDB è un guadagno netto per pochissimi inconvenienti. Altamente raccomandato.

13
Damien Tournoud

MongoDB e simili sono progettati per archiviare dati strutturati (gerarchici) in modo relativamente flessibile.

Ad esempio in Drupal 7, quando si usa field_sql_storage, ogni campo ottiene le sue tabelle. Quando si collegano 10 campi a un tipo di contenuto, si ottengono 10 tabelle nel database. Quando carichi quel nodo, field_sql_storage eseguirà una query per campo e per nodo (o più nodi, quando si utilizza node_load_multiple).

Quando si utilizza mongodb_field_storage , è possibile memorizzare tutti i campi di un nodo in un singolo documento e ottenere con una singola query.

Puoi anche archiviare altre cose come watchdog, sessioni, cache, blocchi in MongoDB .

È comunque necessario MySQL, MongoDB non lo sostituisce (solo per parti specifiche).

Un altro vantaggio è che con MongoDB è più semplice ridimensionare, è possibile aggiungere molti server a un cluster condividendo i dati tra di loro.

7
Berdir

I pro vengono con contro.

Drupal nel suo insieme non può essere passato a MongoDb, quindi dovrai supportare due database e assicurarti che funzionino bene insieme.

Molti moduli non saranno in grado di funzionare con mongodb, quindi perderai l'interoperabilità.

A meno che tu non abbia un'esigenza urgente (come una parte del tuo sistema non sta affrontando il numero di richieste/o quantità di dati) non cambierei. E anche quando inizi ad avvicinarti ai limiti, guarda a lanciare l'hardware al problema o a sintonizzarti prima di passare.

Pensavo di aver risposto prima, c'è un quasi duplicato su SO

5
Jeremy French