it-swarm-es.com

NoSQL vs Otro SQL Drupal Configuraciones

¿Cuáles son las ventajas de ejecutar NoSQL (ex MongoDB) sobre MySQL, PostGRE SQL o MSSQL en Drupal? ¿Se obtienen las ventajas de simplemente usar el almacenamiento o debe cambiar alguna configuración Drupal)?

14
Kevin

MongoDB se puede utilizar para almacenar la mayoría o todas sus entidades en un almacenamiento rápido y orientado a documentos. Este tipo de almacenamiento se escala mucho mejor que el almacenamiento basado en SQL estándar que tenemos en Drupal core (que se basa en un esquema de "una tabla por campo").

En el estado actual de Drupal 7, tendría:

  • La tabla base de la entidad almacenada en SQL (es decir, la tabla de usuarios, la tabla de nodos, etc.)
  • Todos los campos almacenados en SQL
  • Las propiedades de las entidades de sus tablas base duplicadas en MongoDB

Esto permite consultas rápidas sobre las entidades en MongoDB y la capacidad de agregar índices complejos que no son compatibles con la base de datos SQL de Opensource (incluidos los índices en las tablas). Al mismo tiempo, no pierde la interoperabilidad porque la tabla base de la entidad todavía está almacenada en SQL y, por lo tanto, puede unirse mediante módulos que todavía son solo SQL (como Flag).

Este tipo de consulta rápida está disponible gracias al mecanismo EntityFieldQuery, una forma de generar consultas sobre entidades, sus propiedades y sus campos de manera abstracta. La implementación predeterminada en el núcleo traduce esas consultas a SQL, pero el módulo MongoDB tiene una implementación completa que puede satisfacer esas consultas de MongoDB directamente.

Gracias al EntityFieldQuery backend for Views , puede aprovechar fácilmente este poder, utilizando las herramientas a las que está acostumbrado. El único inconveniente es que las relaciones no son compatibles (pero en la práctica rara vez las necesita de todos modos, y esto puede solucionarse insertando datos adicionales en el objeto de entidad y agregando exponerlos como propiedades adicionales de la entidad).

En pocas palabras, tan pronto como el rendimiento de la consulta sea un problema en su proyecto, lo que sucede tan pronto como tenga un conjunto de datos significativo (digamos, comenzando en unas pocas decenas de miles de entidades en un tipo de entidad dado), MongoDB es una ganancia neta por muy muy pocos inconvenientes. Muy recomendable.

13
Damien Tournoud

MongoDB y similares están diseñados para almacenar datos estructurados (jerárquicos) de una manera relativamente flexible.

Por ejemplo en Drupal 7, cuando usas field_sql_storage, cada campo tiene sus propias tablas. Cuando adjuntas 10 campos a un tipo de contenido, terminas con 10 tablas en tu base de datos. Cuando carga ese nodo, field_sql_storage ejecutará una consulta por campo y por nodo (o múltiples nodos, cuando use node_load_multiple).

Cuando usa mongodb_field_storage , puede almacenar todos los campos de un nodo en un solo documento y obtener con una sola consulta.

También puede almacenar otras cosas como watchdog, sesiones, caché, bloques en MongoDB .

Sin embargo, todavía necesita MySQL, MongoDB no lo reemplaza (solo para partes específicas).

Otra ventaja es que es más fácil con MongoDB escalar, puede agregar muchos servidores a un clúster para compartir los datos entre ellos.

7
Berdir

Los pros vienen con contras.

Drupal en su conjunto no se puede cambiar a MongoDb, por lo que tendrá que admitir dos bases de datos y asegurarse de que funcionen bien juntos.

Muchos módulos no podrán funcionar con mongodb, por lo que perderá la interoperabilidad.

A menos que tenga una necesidad apremiante (como parte de su sistema no está haciendo frente a la cantidad de solicitud/cantidad de datos), no cambiaría. E incluso cuando comience a acercarse a los límites, observe lanzar hardware al problema o ajustar antes de cambiar.

Pensé que había respondido esto antes, hay un casi duplicado en SO

5
Jeremy French