NoSQL frente a otras configuraciones de Drupal SQL

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

7 database

— Kevin
fuente

Esta es una pregunta a la que Károly Négyesi daría una respuesta "autorizada". Seguramente conoce la ventaja de usar MongoDB con Drupal.

— kiamlaluno

Lee mi mente ... muy interesado en otras opciones si hay beneficios sustanciales, y por supuesto los pros vienen con contras.

— Kevin

Respuestas:

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 estándar basado en SQL que tenemos en el núcleo de Drupal (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 core traduce esas consultas a SQL, pero el módulo MongoDB tiene una implementación con todas las funciones que puede satisfacer esas consultas de MongoDB directamente.

Gracias al backend EntityFieldQuery para Vistas , 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.

— Damien Tournoud
fuente

Damien Tournoud: Si experimenta problemas de rendimiento con solo unas pocas decenas de miles de entradas, entonces probablemente haya un problema subyacente (configuración de DBMS, consultas mal escritas, puede ser cualquier cosa). Si el esquema SQL subyacente es lo suficientemente bueno, no debería tener que preocuparse antes de un millón de entradas en una sola tabla (pero los campos pueden crecer rápidamente si considera las revisiones y los campos de valores múltiples probablemente).

— Pierre

Mi punto exacto: nuestro esquema está normalizado y, como consecuencia, tiene un rendimiento de consulta muy pobre. Para mejorar el rendimiento de la consulta, debe desnormalizar el esquema. La principal ventaja de usar MongoDB en nuestro caso es que es una especie de "motor de desnormalización automática".

— Damien Tournoud

Y, por supuesto, MongoDB es genial aquí porque es una base de datos orientada a documentos. Almacenar documentos complejos como entidades en el almacenamiento SQL es simplemente estúpido. Es nuestra implementación predeterminada, pero no significa que

— debas

@Pierre: Damien habló sobre unas pocas decenas de miles de entidades , que pueden ser algo completamente diferente a las filas de la tabla. Por ejemplo, puede tener 10 o más campos en esa entidad, luego tiene 10 tablas adicionales que deben consultarse con una consulta separada cada vez que se carga dicha entidad. Y MongoDB puede reemplazar estas tablas adicionales, no la tabla base de la entidad.

— Berdir

Ningún módulo debe esperar que los campos estén en MySQL. La única forma de consultar campos en Drupal 7 es EntityFieldQuery. Abra un error en el módulo si está consultando las tablas de campo directamente. No conozco ninguno de esos módulos en este momento.

— Damien Tournoud

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

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

Cuando usa mongodb_field_storage , puede almacenar todos los campos de un nodo en un solo documento y obtener 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 con MongoDB es más fácil escalar, puede agregar muchos servidores a un clúster y compartir los datos entre ellos.

— Berdir
fuente

Hola berdir ¿Sabes que si dejo MongoDB en un proyecto existente para probar el rendimiento, habilitaría y deshabilitaría el módulo sin consecuencias? Quiero probar mongo, pero ¿y si no funciona o algo así? ¿Es seguro intentarlo? (Sé que no puede garantizarlo, pero me pregunto qué sucede en la mayoría de los casos)

— Beto Aveiga

Bueno, para empezar, no puede simplemente dejarlo caer. Cada campo ha configurado qué backend de almacenamiento que usa tendrá que cambiar / volver a crear sus campos, volver a crear sus vistas (ya que necesitan usar el backend efq_views ), quizás sus propias consultas si escribió consultas directas en las tablas de datos de campo. Podría ser más fácil recrear la misma estructura en una nueva instalación para una comparación inicial.

— Berdir

Gracias Berdir! Probé MongoDB hace unos días, pero no hubo un aumento notable en el rendimiento, pero tampoco estaba al tanto de las cosas / cambios que me estás diciendo en este momento. Pensé que "MongoDB debería marcar la diferencia en sitios más grandes". Intentaré MongoDB nuevamente.

— Beto Aveiga

Los pros vienen con contras.

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

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 casi un duplicado en SO

— Jeremy French
fuente