Si su complemento va a tener MUCHOS datos, entonces usar wp_postmeta NO es una buena idea como se muestra a continuación:
Tomando Woocommerce como ejemplo,
En una tienda con ~ 30,000 productos, digamos que habrá un promedio de ~ 40 post meta (atributos y todo) por producto, 5 imágenes de producto por producto, lo que significa que habrá ~ 4 meta de imagen para cada imagen:
30,000 productos x 40 meta cada uno = 1,200,000 filas en wp_postmeta
+
30,000 productos x 5 imágenes cada x 4 meta de imagen para cada = 600,000 filas en wp_postmeta
Por lo tanto, con solo 30,000 productos, está considerando tener 1,800,000 filas en wp_postmeta.
Si agrega más propiedades a sus productos o a las imágenes de sus productos, este número se multiplicará.
El problema con eso es doble:
- Las propias combinaciones son muy caras con MySQL
- La tabla wp_postmeta no está indexada a menos que esté utilizando versiones posteriores de mysql (es decir, no hay un índice FULLTEXT para meta_value)
Para dar un ejemplo de un caso real:
SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'
La consulta de
, que selecciona la ciudad de envío de todos los detalles del pedido, llega a unos 3 segundos en un servidor dedicado de nivel de entrada, incluso si hay 5-10 pedidos . Esto se debe a que la consulta se ejecuta desde una tabla wp_postmeta que tiene ~ 3 millones de filas en la instalación en vivo.
Incluso la página de inicio es bastante lenta, ya que el tema extrae varios elementos de wp_postmeta: deslizadores, algunas inserciones de revisión, algunos otros meta. En general, la lista de productos es muy lenta, las búsquedas son igualmente lentas cuando se listan productos.
No puedes arreglar esto por ningún medio normal. Puede poner Elastic Search en su servidor y usar un complemento de Elastic Search en Wordpress, puede usar redis / memcached, puede usar un buen complemento de caché de página, pero al final quedará un problema fundamental: obtener cualquier cantidad de datos de una gran cantidad de datos. La tabla wp_postmeta será lenta, siempre que se haga. En el servidor donde probé la solución que implementé a continuación, todos estos se instalaron y configuraron correctamente y se optimizaron, y el sitio funcionó de manera aceptable para usuarios no registrados o consultas comunes desde que se activaron los complementos de almacenamiento en caché.
Pero en el momento en que un usuario que inició sesión intentaba hacer algo que no se hacía comúnmente o los crons, los complementos de almacenamiento en caché o cualquier otra utilidad querían obtener datos reales de db para almacenarlos en caché o hacer cualquier otra cosa, todo fue muy lento.
Así que intenté algo más:
Codifiqué un pequeño complemento para llevar todo el meta del producto (postmeta para producto de tipo de publicación) a una tabla personalizada generada por código. Este complemento tomó todos los metadatos para cada publicación y creó una tabla agregando cada meta como columnas e insertando los valores en cada fila. Entonces, convertí el formato EAV en un formato relacional horizontal y plano. También tuve el complemento para eliminar postmeta de todos los productos movidos de la tabla wp_postmeta.
Mientras estoy en eso, también moví el archivo adjunto postmeta y todos los metadatos del otro tipo de publicación a sus propias tablas.
Luego me conecté con get_ (post_type) _meta filter para anular la recuperación de metadatos para servirlos desde nuevas tablas personalizadas.
Ahora, la misma consulta de la anterior, que demoró ~ 3 segundos en recuperarse de wp_postmeta, tarda ~ 0.006 segundos. El sitio ahora se comporta como si fuera una instalación WP nueva.
....................
Naturalmente, hacer las cosas a la manera de WordPress es mejor. En realidad es la norma.
Sin embargo , también es obvio saber que la tabla EAV es muy ineficiente en la escala. Es infinitamente flexible y le permite almacenar cualquier información, pero el precio que paga por eso es el rendimiento. Es una compensación fundamental.
En ese contexto, es difícil decirle a alguien que tiene la intención de tener una tonelada de datos y, por supuesto, Dios no puede hacer preguntas / búsquedas en esos datos para usar la tabla wp_postmeta con seguridad. El éxito de rendimiento será grande.
El uso de sus tablas personalizadas permitirá que sus datos se acumulen y sigan siendo lo suficientemente rápidos.
Al igual que Pippin Williams, el creador del plugin Easy Digital Downloads, mencionó que usaría tablas personalizadas si estuviera comenzando a codificar su plugin, si va a crear algo que se usará durante mucho tiempo o se amontonará. de datos, es más eficiente usar sus tablas personalizadas si las diseña bien.
Debe asegurarse de que cualquier otro desarrollador de complementos / complementos tenga medios para conectarse a su complemento para manipular sus datos antes y después de la recuperación de los datos. Si haces eso, entonces eres bastante sólido.