NoSQL vs altre configurazioni Drupal SQL

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 una parte della configurazione di Drupal?

7 database

— Kevin
fonte

Questa è una domanda alla quale Károly Négyesi darebbe una risposta "autorevole". Conosce sicuramente il vantaggio di usare MongoDB con Drupal.

— kiamlaluno

Leggi la mia mente .. molto interessato ad altre opzioni se ci sono benefici sostanziali, e ovviamente i pro arrivano con i contro.

— Kevin,

Risposte:

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 nel core di Drupal (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 back-end EntityFieldQuery per Views , puoi facilmente sfruttare questo potere, utilizzando 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.

— Damien Tournoud
fonte

Damien Tournoud: se riscontri problemi di prestazioni con solo alcune decine di migliaia di voci, probabilmente c'è un problema alla base (configurazione DBMS, query scritte male, può essere qualsiasi cosa). Se lo schema SQL di base è abbastanza buono, non dovresti preoccuparti prima di un milione di voci su una singola tabella (ma i campi possono crescere rapidamente se consideri probabilmente revisioni e campi multivalore).

— Pierre,

Il mio punto esatto: il nostro schema è normalizzato e, di conseguenza, ha prestazioni di query molto scarse. Per migliorare le prestazioni della query, è necessario denormalizzare lo schema. Il vantaggio principale dell'utilizzo di MongoDB nel nostro caso è che si tratta di una sorta di "motore di denormalizzazione automatica".

— Damien Tournoud,

E, naturalmente, MongoDB è fantastico qui perché è un database orientato ai documenti. La memorizzazione di documenti complessi come entità nell'archivio SQL è semplicemente stupida. È la nostra implementazione predefinita, ma non significa che dovresti usarla :)

— Damien Tournoud,

@Pierre: Damien ha parlato di alcune decine di migliaia di entità , che possono essere completamente diverse dalle file di tabella. Ad esempio, potresti avere 10 o più campi su quell'entità, quindi hai 10 tabelle aggiuntive che devono essere interrogate con una query separata ogni volta che tale entità viene caricata. E MongoDB può sostituire queste tabelle aggiuntive, non la tabella base entità.

— Berdir,

Nessun modulo dovrebbe aspettarsi che i campi siano in MySQL. L'unico modo per eseguire query sui campi su Drupal 7 è EntityFieldQuery. Aprire un bug nel modulo se si esegue direttamente la query delle tabelle dei campi. Non conosco nessuno di quei moduli in questo momento.

— Damien Tournoud,

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

Ad esempio Drupal 7, quando si utilizza field_sql_storage, ogni campo ottiene le proprie tabelle. Quando si collegano 10 campi a un tipo di contenuto, si ottengono 10 tabelle nel database. Quando si carica quel nodo, field_sql_storageverrà eseguita 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 .

Tuttavia, hai ancora bisogno di MySQL, MongoDB non lo sostituisce (solo per parti specifiche).

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

— Berdir
fonte

Ciao Berdir! Sai se rilasciare MongoDB in un progetto esistente per testare le prestazioni abiliterei e disabiliterei il modulo senza conseguenze? Voglio provare mongo, ma cosa succede se non funziona o qualcosa del genere? È sicuro provare? (So che non puoi garantirlo, ma mi chiedo cosa succede nella maggior parte dei casi)

— Beto Aveiga,

Bene, per cominciare, non puoi semplicemente rilasciarlo. Ogni campo ha configurato il back-end di archiviazione che usa dovrai cambiare / ricreare i tuoi campi, ricreare le tue viste (poiché devono usare il backend efq_views ), forse le tue query se hai scritto query dirette rispetto alle tabelle dei dati dei campi. Potrebbe essere più semplice ricreare la stessa struttura in una nuova installazione per un confronto iniziale.

— Berdir,

Grazie Berdir! Ho provato MongoDB qualche giorno fa ma non c'è stato un notevole miglioramento delle prestazioni, ma non ero a conoscenza delle cose / cambiamenti che mi stai dicendo in questo momento. Ho pensato "MongoDB dovrebbe fare la differenza nei siti più grandi". Proverò di nuovo MongoDB.

— Beto Aveiga,

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 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

— Jeremy francese
fonte