Si su complemento va a tener MUCHOS datos, entonces wp_postmeta
NO es una buena idea como se muestra a continuación:
Tomando WooCommerce como ejemplo, en una tienda con ~ 30,000 productos, habrá un promedio de, por ejemplo, ~ 40 publicaciones meta (atributos y todo) por producto, 5 imágenes de producto por producto, lo que significa que habrá ~ 4 imágenes meta 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 uno x 4 imágenes meta por cada = 600,000 filas en wp_postmeta
Entonces, con solo 30,000 productos, está buscando tener 1,800,000 filas wp_postmeta
.
Si agrega más propiedades a sus productos o imágenes de sus productos, este número se multiplicará.
El problema con eso es doble:
- Las autouniones son muy caras con MySQL
wp_postmeta
la tabla no está indexada a menos que esté utilizando versiones posteriores de mysql (es decir, no hay í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'
Esto selecciona la ciudad de envío de todos los detalles de la orden, viene en unos 3 segundos en un servidor dedicado de nivel de entrada, incluso si hay 5-10 órdenes . Esto se debe a que la consulta se ejecuta desde una wp_postmeta
tabla que tiene ~ 3 millones de filas en la instalación en vivo.
Incluso la página de inicio es bastante lenta, porque el tema extrae varios elementos de wp_postmeta
: controles deslizantes, 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 enumeran productos.
No puede solucionar esto por ningún medio normal. Puede poner Elastic Search en su servidor y usar un plugin de Elastic Search en Wordpress, puede usar redis / memcached, puede usar un buen plugin de caché de página, pero al final el problema fundamental seguirá siendo: recuperar cualquier cantidad de datos de un archivo hinchado wp_postmeta
La tabla será lenta, siempre que se haga. En el servidor donde probé la solución que implementé a continuación, todo esto se instaló y configuró correctamente y se optimizó, y el sitio funcionó de manera aceptable para usuarios no registrados o consultas realizadas comúnmente desde que se iniciaron los complementos de almacenamiento en caché.
Pero en el momento en que un usuario conectado intentó 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 la base de datos para almacenarlos en caché o hacer cualquier otra cosa, las cosas se volvieron lentas.
Entonces intenté algo más:
Codifiqué un pequeño complemento para llevar todos los meta del producto (postmeta para producto de tipo post ) 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. Convertí el formato EAV en un formato relacional horizontal y plano. También tenía el complemento para eliminar postmeta de todos los productos movidos de la wp_postmeta
tabla.
Mientras lo hacía, moví los postmeta de adjuntos y todos los meta tipos de publicaciones a sus propias tablas.
Luego me conecté al get_(post_type)_meta
filtro para anular la recuperación de metadatos para servirlos desde nuevas tablas personalizadas.
Ahora la misma consulta de antes, que tardó ~ 3 segundos en recuperarse, wp_postmeta
toma ~ 0.006 segundos. El sitio ahora se comporta como si fuera una nueva instalación de WP.
....................
Naturalmente, hacer las cosas a la manera de Wordpress es mejor. En realidad es la norma.
Sin embargo , también es obvio que la tabla EAV es muy ineficiente en el escalado. 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 gran cantidad de datos y, Dios no lo quiera, consultar / buscar en esos datos para usar la wp_postmeta
tabla con seguridad. El éxito en el rendimiento será excelente.
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 complemento Easy Digital Downloads, mencionó que usaría tablas personalizadas si recién comenzara a codificar su complemento, si va a crear algo que se utilizará durante mucho tiempo o acumulará muchos 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 recuperarlos. Si haces eso, entonces eres bastante sólido.