NoSQL vs autres configurations SQL Drupal

Quels sont les avantages d'exécuter NoSQL (ex MongoDB) sur MySQL, PostGRE SQL ou MSSQL dans Drupal? Les avantages tirés de la simple utilisation du stockage ou la configuration de Drupal doit-elle être modifiée?

7 database

— Kevin
source

C'est une question à laquelle Károly Négyesi donnerait une réponse "faisant autorité". Il connaît sûrement l'avantage d'utiliser MongoDB avec Drupal.

— kiamlaluno

Lisez mon esprit .. très intéressé par d'autres options s'il y a des avantages substantiels, et bien sûr les avantages sont contre.

— Kevin

Réponses:

MongoDB peut être utilisé pour stocker la plupart ou la totalité de vos entités dans un stockage rapide orienté document. Ce type de stockage évolue bien mieux que le stockage basé sur SQL standard que nous avons dans le noyau Drupal (qui est basé sur un schéma "une table par champ").

Dans l'état actuel de Drupal 7, vous auriez:

La table de base de l'entité stockée sur SQL (c'est-à-dire la table des utilisateurs, la table des nœuds, etc.)
Tous les champs stockés dans SQL
Les propriétés des entités de leurs tables de base dupliquées dans MongoDB

Cela permet des requêtes rapides sur les entités sur MongoDB et la possibilité d'ajouter des index complexes qu'aucune base de données SQL Open Source ne prend en charge (y compris les index entre les tables). Dans le même temps, vous ne perdez pas l'interopérabilité car la table de base de l'entité est toujours stockée en SQL et peut donc être jointe par des modules qui sont toujours en SQL uniquement (comme Flag).

Ce type de requête rapide est disponible grâce au mécanisme EntityFieldQuery, un moyen de construire des requêtes sur des entités, leurs propriétés et leurs champs de manière abstraite. L'implémentation par défaut dans le noyau traduit ces requêtes en SQL, mais le module MongoDB a une implémentation complète qui peut satisfaire ces requêtes directement de MongoDB.

Grâce au backend EntityFieldQuery pour les vues , vous pouvez facilement tirer parti de cette puissance en utilisant les outils auxquels vous êtes habitué. Le seul inconvénient est que les relations ne sont pas prises en charge (mais en pratique, vous en avez rarement besoin de toute façon - et cela peut être contourné en insérant des données supplémentaires dans l'objet entité et en les exposant en tant que propriétés supplémentaires de l'entité).

En un mot, dès que les performances des requêtes sont un problème sur votre projet, ce qui se produit dès que vous avez un ensemble de données significatif (disons à partir de quelques dixièmes de milliers d'entités sur un type d'entité donné), MongoDB est un gain net pour très très peu d'inconvénients. Hautement recommandé.

— Damien Tournoud
source

Damien Tournoud: Si vous rencontrez des problèmes de performances avec seulement quelques dixièmes de milliers d'entrées, alors il y a probablement un problème sous-jacent (configuration SGBD, requêtes mal écrites, ça peut être n'importe quoi). Si le schéma SQL sous-jacent est suffisamment bon, vous ne devriez pas avoir à vous soucier d'un million d'entrées sur une seule table (mais les champs peuvent augmenter rapidement si vous envisagez les révisions et les champs à valeurs multiples probablement).

— Pierre

Mon point exactement: notre schéma est normalisé et, par conséquent, a de très mauvaises performances d'interrogation. Pour améliorer les performances des requêtes, vous devez dénormaliser le schéma. Le principal avantage de l'utilisation de MongoDB dans notre cas est qu'il s'agit d'une sorte de "moteur de dénormalisation automatique".

— Damien Tournoud

Et bien sûr, MongoDB est génial ici car c'est une base de données orientée document. Stocker des documents complexes comme des entités dans le stockage SQL est tout simplement stupide. C'est notre implémentation par défaut, mais cela ne signifie pas que vous devriez l'utiliser :)

— Damien Tournoud

@Pierre: Damien a parlé de quelques dixièmes de milliers d' entités , ce qui peut être complètement différent des lignes de table. Par exemple, vous pouvez avoir 10 champs ou plus sur cette entité, puis vous avez 10 tables supplémentaires qui doivent être interrogées avec une requête distincte chaque fois qu'une telle entité est chargée. Et MongoDB peut remplacer ces tables supplémentaires, pas la table de base d'entité.

— Berdir

Aucun module ne devrait s'attendre à ce que les champs soient dans MySQL. La seule façon d'interroger des champs sur Drupal 7 est EntityFieldQuery. Ouvrez un bogue dans le module s'il interroge directement les tables de champ. Je ne connais aucun de ces modules pour le moment.

— Damien Tournoud

MongoDB et similaires sont conçus pour stocker des données structurées (hiérarchiques) d'une manière relativement flexible.

Par exemple Drupal 7, lors de l'utilisation field_sql_storage, chaque champ obtient ses propres tables. Lorsque vous associez 10 champs à un type de contenu, vous vous retrouvez avec 10 tables dans votre base de données. Lorsque vous chargez ce nœud, field_sql_storageexécutera une requête par champ et par nœud (ou plusieurs nœuds, lors de l'utilisation node_load_multiple).

Lorsque vous utilisez mongodb_field_storage , vous pouvez stocker tous les champs d'un nœud dans un seul document et obtenir avec une seule requête.

Vous pouvez également stocker d'autres choses comme chien de garde, sessions, cache, blocs dans MongoDB .

Cependant, vous avez toujours besoin de MySQL, MongoDB ne le remplace pas (uniquement pour des parties spécifiques).

Un autre avantage est qu’il est plus facile MongoDB d' évoluer , vous pouvez ajouter de nombreux serveurs à un cluster partager les données entre eux.

— Berdir
source

Salut Berdir! Savez-vous que si je laisse tomber MongoDB dans un projet existant pour tester les performances, est-ce que j'activerai et désactiverai le module sans conséquences? Je veux essayer mongo, mais si ça ne marche pas ou quelque chose? Est-il sûr d'essayer? (Je sais que vous ne pouvez pas le garantir mais je me demande ce qui se passe dans la plupart des cas)

— Beto Aveiga

Eh bien, pour commencer, vous ne pouvez pas simplement le déposer. Chaque champ a configuré le backend de stockage qu'il utilise, vous devrez modifier / recréer vos champs, recréer vos vues (car ils doivent utiliser le backend efq_views ), peut-être vos propres requêtes si vous avez écrit des requêtes directes sur les tables de données de champ. Il pourrait être plus facile de recréer la même structure dans une nouvelle installation pour une comparaison initiale.

— Berdir

Merci Berdir! J'ai essayé MongoDB il y a quelques jours mais il n'y a pas eu de gain notable de performances, mais je n'étais pas non plus au courant des choses / changements que vous me dites en ce moment. Je pensais que "MongoDB devrait faire la différence dans les grands sites". Je vais réessayer MongoDB.

— Beto Aveiga

Les avantages sont contre.

Drupal dans son ensemble ne peut pas être basculé vers MongoDb, vous devrez donc prendre en charge deux bases de données et vous assurer qu'elles fonctionnent bien ensemble.

De nombreux modules ne pourront pas fonctionner avec mongodb, vous perdrez ainsi l'interopérabilité.

À moins que vous ayez un besoin pressant (comme si une partie de votre système ne gère pas le nombre de demandes / ou la quantité de données), je ne changerais pas. Et même lorsque vous commencez à approcher des limites, regardez le matériel à résoudre ou le réglage avant de basculer.

Je pensais avoir déjà répondu à cette question, il y a presque un doublon sur SO

— Jeremy French
source