NoSQL vs autres SQL Drupal Setups
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?)
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 Drupal core (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 répondre directement à ces requêtes 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 bref, 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é.
MongoDB et similaires sont conçus pour stocker des données structurées (hiérarchiques) d'une manière relativement flexible.
Par exemple dans Drupal 7, lors de l'utilisation de 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_storage exécutera une requête par champ et par nœud (ou plusieurs nœuds, lors de l'utilisation de 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 avec MongoDB d'évoluer, vous pouvez ajouter de nombreux serveurs à un cluster partager les données entre eux.
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é.
Sauf si vous avez 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 en double sur SO