¿Qué es un buen equilibrio entre reutilizar campos versus crear nuevos en el contexto de escalabilidad de campos?

34

He leído la siguiente frase en un sitio web:

En lugar de agregar nuevos campos a un tipo de contenido, agregar campos existentes es una mejor opción para reducir la complejidad del sistema y mejorar la escalabilidad.

Y surgen algunas dudas.

En el sistema que estamos desarrollando, tenemos la posibilidad de reutilizar un campo en 3 o 4 tipos de contenido, pero en lugar de mejorar la escalabilidad como dice la frase citada, me temo que disminuirá, porque la tabla del campo se convertiría más rápidamente en un cuello de botella. (Al menos ese es mi razonamiento en este caso, ya que todos los valores de ese campo juntos, serían un par de millones por año y eso haría que la tabla sea demasiado grande). ¿Estás de acuerdo?

¿Cuántas filas sería un máximo sensato para apuntar cuando se está haciendo arquitectura? De esa forma, podríamos decidir cuándo reutilizar los campos y cuándo crear nuevos (aunque la posibilidad de reutilizar está allí).

entities performance

— rafamd
fuente

66

Me encantaría ver las respuestas respaldadas con métricas reales.

— mpdonadio

Creo que hemos reunido comentarios muy constructivos e informativos sobre esta pregunta. Sin embargo, esperaré uno o dos días antes de marcar como respondido, ya que algo dentro de mí insiste en que mantener separados uno o dos campos más pesados (a pesar de que podrían reutilizarse) podría ser una buena idea :) ... especialmente saber esos Los fileds podrían crecer fácilmente en 5, 10 o 20 millones de artículos por año.

— rafamd

24

La cantidad de datos en un campo generalmente no es un problema. Si le preocupa eso, busque complementos de almacenamiento de campo alternativos o escriba el suyo. Por ejemplo , MongoDB , que puede manejar casi cualquier cosa que le pongas. Por ejemplo, se usa en http://examiner.com .

Un verdadero problema sin embargo es el número de campos que tiene. Debido a que actualmente en Drupal 7, la configuración de campo completa de todos los campos, sin importar si están cargados o no, se obtiene del caché en cada solicitud.

He visto sitios con más de 250 campos, donde cargar y deserializar la configuración del campo requiere más de 13 MB de memoria.

Editar: el caché de información de campo se ha mejorado (consulte http://drupal.org/node/1040790 para más detalles) con Drupal 7.22, solo los campos de los paquetes que se muestran en una página determinada se cargan desde el caché y se cargan entradas de caché separadas. Eso solo funciona si no hay llamadas API incorrectas que soliciten instancias en varios paquetes.

— Berdir
fuente

Hola Berdir, gracias por tu respuesta. No sabía sobre esa sobrecarga para el número de campos. Entonces, deberíamos intentar reutilizar tanto como sea posible, pero aún así, ¿no deberíamos tratar de dividir a aquellos que sabemos que son los más pesados? No sé mucho sobre mongo y cosas por el estilo, pero ¿es realmente que no les importa el tamaño de un grupo al que tienen que consultar? Gracias !

— rafamd

En realidad no lo se. Depende, supongo. Hacer una prueba como MPD sugirió podría no ser una mala idea. Incluso podría compararlo de muy bajo nivel directamente en Mysql. Cree dos tablas con el mismo diseño e índices que las tablas de datos de campo, escriba 10m (asegúrese de usar valores diferentes para la entidad_id) filas en una y 5m en la segunda. Luego compare el rendimiento de escritura y el rendimiento de lectura (basado en el entity_id, también conocido como índice). Sospecho que el rendimiento de lectura será casi igual gracias al índice, pero el rendimiento de escritura podría marcar la diferencia.

— Berdir

Dicho esto, tener un puñado de campos más o menos realmente no hará una diferencia, por lo que si te sientes más cómodo de esa manera, eso no debería ser un problema.

— Berdir

Las escrituras son la parte difícil, de ahí mi recomendación sobre hacer una prueba. Lo que puede ser contradictorio es el hecho de que MySQL elimina las entradas en caché basadas en la tabla y no en la fila (la última vez que lo verifiqué). No estoy seguro de cuál sería un mayor impacto, la sobrecarga de memoria de múltiples campos y tablas o errores de caché de las escrituras en la misma tabla. Sin embargo, seguramente depende del tráfico / uso. Los sistemas con múltiples cachés (caché Drupal, código de operación APC, usuario APC, caché de consultas MySQL, memcached, barniz, etc.) hacen que las decisiones basadas en el intestino sean muy difíciles sin perfiles.

— mpdonadio

este ya no es el caso: drupal.org/node/1040790

— jackbravo

13

Estoy totalmente de acuerdo con berdir. Aquí están mis experiencias con un proyecto con millones de filas y 30-40 campos en algunos tipos de nodos.

El número de filas en una tabla de campo no es un gran problema para el rendimiento de lectura, ya que todos los campos se obtienen por clave primaria.
El número de campos por tipo de nodo puede convertirse rápidamente en grandes problemas de rendimiento al escribir nuevos nodos. Tener más de 30 campos para un tipo de nodo da como resultado más de 60 instrucciones INSERT cuando crea un nuevo nodo. Esto lleva unos segundos en completarse. Si sus usuarios crean muchos datos, esto afectará su rendimiento. Las inserciones masivas de 1000 nodos tardarán casi una hora. Si tiene que actualizar 100.000 nodos, este es un gran problema.
Si cree que el problema del número de campos lo afectará, debería pensar seriamente en escribir su propio almacenamiento de campo o simplemente no usar campos. (Todavía puede hacer que su nodo funcione con vistas con un esfuerzo adicional).
Una palabra sobre MongoDB. Es un proyecto muy interesante y espero que se convierta en el olimpo de los grandes DB. Lamentablemente, en comparación con la madurez de MySql o PgSql, es un bebé. Prepárese para lidiar con un producto muy joven.

— BetaRide
fuente

Hola @BetaRide, gracias por tu comprensión. Aproximadamente 2), ya estamos tratando de minimizar el número de campos por tipo de contenido y eso no es exactamente lo que estamos discutiendo aquí. El verdadero problema es: ¿debería reutilizar ciegamente los campos siempre que sea posible o debería intentar (al menos) mantener separados uno o dos más pesados? Sí, mongo debería ser nuestra última alternativa por ahora :)

— rafamd

5

Si está realmente preocupado por lo que sucederá, entonces creo que una simulación está en orden.

Obtenga una cuenta en Rackspace Cloud, Amazon, Linode o en cualquier otro lugar donde pueda activar fácilmente un VPS. Haz dos instancias idénticas. Instale Drupal en cada uno. Cree algunos tipos de contenido ficticio y configure los campos de una manera en un sistema y de otra manera en el otro. Use el módulo de desarrollo para crear una gran cantidad de contenido. Ajuste la configuración de rendimiento para asegurarse de que Drupal esté almacenando en caché según sea necesario. Ejecute mysqltuner y ajuste MySQL en cada una de las recomendaciones. Verifique la configuración de PHP y APC para que no esté presionando el intercambio y que no esté agitando el caché de APC.

Una vez que obtenga una buena configuración de referencia para cada uno, comience a simular el tráfico (tanto visitantes normales como actualizaciones de administrador) con wget y drush, y luego haga un perfil.

Las simulaciones nunca son perfectas, pero pueden ayudarlo a avanzar en la dirección correcta.

— mpdonadio
fuente

2

Un problema con la escalabilidad en los campos en el uso de índices en cada campo de tabla individual en cada campo en la tabla creada. El índice agrupado de la clave primaria es un compuesto de la mayoría de los campos, luego creó índices separados en cada campo individual. Los índices crean una tonelada de escrituras generales para la base de datos, y en la mayoría de los casos nunca se usan.

— jozwikjp
fuente

2

Otro consejo: tener muchos campos también causará problemas con muchos módulos diferentes. La GUI de token, por ejemplo, hará que su navegador se demore por minutos si intenta editar alias de URL, por ejemplo. Este comportamiento se puede ver en todas las páginas donde se cargará y mostrará el token (incluido el desarrollo - dpm () etc.)

No hay beneficio de rendimiento al dividir estos datos en varias tablas cuando se usa InnoDB (MyISAM es diferente debido al bloqueo de la tabla). Entonces, si sabe que tendrá muchos tipos de contenido similares con campos similares (cuyas configuraciones también serán las mismas, tal vez solo difieran en el etiquetado) ¡reutilice sus campos!

También podría facilitar la creación de plantillas debido a atributos de nodo similares.

— Andre Baumeier
fuente

1

Solo compartiendo mi historia, estamos usando Drupal Commerce y tenemos alrededor de 40 campos en nuestras variaciones de productos (Sku) y luego otros 460 (sí, locos) en nuestra Exhibición de productos. Teníamos algunas vistas de comparación de productos que examinarían todos estos campos. Sin el almacenamiento en caché, ¡algunas cargas de página pueden demorar hasta un minuto!

Sin embargo, funcionó. Si usó el almacenamiento en caché y el barniz, el tiempo de espera del usuario no fue tan malo.

El principal problema con el que nos encontramos con tantos campos es con Display Suite, ya que sería muy lento (a veces no respondería) si intentáramos reorganizar o mover un campo.

Afortunadamente, decidimos refactorizar nuestros productos un poco para que podamos obtener nuestro número máximo de campos en el rango 200-250 para nuestros productos más complejos (estamos en instrumentación científica, por lo que se necesitan mediciones y especificaciones complejas) .

— Waterskier19
fuente

0

Es una pregunta interesante. He pensado en esto antes, a veces reutilizar un campo puede ser conveniente para no tener un montón de campos similares 'por ahí', pero parece una tontería tener un cierto tipo de contenido que tiene que seleccionar de una gran carga de datos que saber no está destinado a ser devuelto en el resultado.

Necesitaría un poco más de información sobre el proyecto para asesorar sobre las mejores prácticas para escalar. ¿Cuál es el tráfico esperado, cuántos de esos usuarios deben iniciar sesión, etc.? Por ejemplo, si todo el tráfico, excepto el de sus usuarios administradores, no está autenticado y se almacena en caché de forma anónima

— joevallender
fuente

Hola @drupaljoe, gracias por tu respuesta. El tráfico esperado es difícil de estimar, porque es un sitio completamente nuevo. Se está desarrollando con mucho cuidado y esperamos algún tipo de éxito, así que digamos que logramos tener unos doscientos usuarios concurrentes (la mayoría de ellos autenticados). Eso es exactamente lo que estaba pensando, cuestionar esa gran tabla debe ser una molestia, por lo que tal vez deberíamos diseñar para reutilizar esos campos que no crecerán demasiado y separar los que van a contener más datos. ¿Qué se podría considerar demasiado? 1 millón ? 100 millones ? 300 millones ? ...

— rafamd

Creo que los comentarios de los otros dos sobre cómo no debería importar demasiado porque las selecciones están en la clave principal son buenos puntos. Supongo que diría que sigas con esto por ahora, pero asegúrate de haber leído un poco sobre tus opciones para el futuro, mongo para campos, etc. No siempre puedes adivinar todo sobre el futuro de tu sitio

— joevallender

0

Hasta ahora siempre he reutilizado campos, pero ahora estoy considerando usar campos únicos por tipo de nodo para un nuevo proyecto. De hecho, quiero mantener todo bien separado (campos, vistas, reglas, contextos, etc.) para cada paquete de entidades. Entonces planteó la cuestión de la escalabilidad que me llevó hasta aquí. La edición de Berdir me consuela (la caché de información de campo se ha mejorado (consulte http://drupal.org/node/1040790 para más detalles) con Drupal 7.22, solo se cargan los campos de paquetes que se muestran en una página determinada el caché y son entradas de caché separadas. Eso solo funciona si no hay llamadas API incorrectas que soliciten instancias en múltiples paquetes).

Solo quiero señalar que hay un módulo muy interesante que he estado usando durante meses en sitios múltiples y complejos: https://www.drupal.org/project/render_cache . Es una de esas gemas ocultas en mi opinión.

Como dice en la página del proyecto, la parte de comentarios en realidad se está utilizando en el propio DO.

Entonces, con todo eso en mente, ¿convertiría el consenso a favor de campos separados? Sin embargo, la advertencia que se menciona sobre DS todavía es un fastidio. Es súper molesto la forma en que ahorra a través de ajax en lugar de, por ejemplo, la forma en que la interfaz de administración del bloque central maneja el reordenamiento. Sin embargo, creo que es un problema de DS ...

— Oscar
fuente

-3

Según mi sugerencia, es una buena idea usar los mismos campos en un tipo de contenido separado. Porque mejorará el rendimiento de su sitio. En Drupal 7, cuando está utilizando la operación de selección en ese momento, el uso de los mismos campos en el tipo de contenido es realmente útil para su sitio Drupal7.

— purab
fuente

1

En Drupal 7, comenzaron a usar Doctrine ORM ... no, no lo hicieron. Drupal 8 ni siquiera usa Doctrine

— Clive

"Doctrine siempre devuelve el objeto de todos los datos asignados", también es una declaración falsa. Los objetos se pueden anotar para indicar a la doctrina que el comportamiento predeterminado no es adecuado. No es que eso sea terriblemente relevante, dado que, como dice Clive, Drupal no usa Doctrine.

— Letharion