PrestaShop y las bases de datos ¿amigos o enemigos?
Introducción
A lo largo de la vida de una tienda online, los cambios son totalmente inevitables.
Módulos, plantillas, diseños, secciones, categorías, productos… todo está sujeto a cambios.
En ocasiones tenemos que sustituir un módulo por otro por muchas y muy diversas razones, como por ejemplo cambiar de proveedor de transporte o de procesador de pagos.
Los diseños van y vienen. El tener que adaptarnos a las nuevas tecnologías y exigencias de éstas, hace que sea imprescindible ir alterándolos con el tiempo.
Sin embargo, hay un elemento que no deja jamás de crecer: la base de datos.
A medida que nuestra tienda recibe nuevos pedidos, se registran clientes, creamos y modificamos transportistas, creamos y modificamos productos, etc nuestra base de datos crece y crece sin parar.
Si crees que los transportistas se eliminan, pregúntate porqué su ID se incrementa cada vez que lo editas, o mejor aún: échale un vistazo a la tabla ps_carrier de tu base de datos y fliparás un poquito, especialmente si tienes una tienda online con un tiempo en el mercado.
A medida que nuestro negocio online prospera, la base de datos va acumulando más y más información, especialmente cuando usamos los módulos de estadísticas de PrestaShop o determinados módulos existentes en el mercado.
Alguno de ellos, como el de Google Analytics 4 de Línea Gráfica, es capaz de acumular más de 1Gb de información en la tabla de estadísticas de tu base de datos en poco tiempo (menos de un año)
Si no realizamos un mantenimiento eficiente de nuestra base de datos, tablas genéricas de PrestaShop como ps_search_index o ps_guests puede acumular una grandísima cantidad de información, especialmente si tu tienda recibe mucho tráfico.
Módulos: el eterno debate
PrestaShop es un sistema que podríamos definir como bastante bien programado.
A nivel de código, cuenta con un desarrollo de calidad medio-alto, está bien documentado y como ya sabemos, dispone de una enorme comunidad, tanto a nivel profesional (GitHub) como a título particular (foro) que ayuda y participa activamente y que resuelven muchísimas dudas y problemas (bugs).
A nivel técnico, PrestaShop tiene un rendimiento excelente.
Especialmente en su versión 8, con la llegada de la compatibilidad con php 8.1 y el cambio a una versión de Symfony (el framework sobre el que está desarrollado su core) la performance ha mejorado hasta niveles como no habíamos visto.
Sin embargo, por mucho que nos guste a las agencias exprimir las funcionalidades genéricas de PrestaShop, en la mayoría de ocasiones se hace imprescindible “tirar de módulos” para implementar nuevas características que, de ser desarrolladas a medida, serían tremendamente costosas… ¿o no?
Creo que estarás de acuerdo conmigo en que el uso de módulos en una tienda online que cuenta con una inversión “normal” es imprescindible. Me refiero por “normal” a tiendas online entre 2000€ y 5000€ de inversión inicial.
Es cierto que aspectos como los filtros de productos, checkout rápido en una página, registro de profesionales (b2b), login con redes sociales, etc son necesarios y que PrestaShop carece de estas funcionalidades en su versión inicial o como mucho, las que incorpora son del todo ineficientes.
A priori, nada nos haría sospechar de módulos comprados en el marketplace de PrestaShop Addons, procedentes de desarrolladores nacionales e internacionales que cuentan en su haber con insignias y distinciones en sus fichas de vendedor tales como “Certified Agency” o “Certified Partner” no fuesen lo suficientemente estables, lo suficientemente buenos.
Y lo cierto es que la inmensa mayoría lo son, sin embargo, el “cliffhanger” anterior lo dejé ahí para darte que pensar, porque sí que es cierto que problemas, los hay y en el 90% de las ocasiones (si no más) están derivados del uso directo de módulos.
Preámbulo
En este post, que no sé si terminará siendo un post o un mini e-book, voy a tratar de explicar qué es lo que pasa cuando usamos módulo tras módulo en una tienda PrestaShop, aunque esto es extensible a un gran número de CMS del mercado como WordPress, Drupal, Magento, Joomla y muchos otros.
Así que, querido lector, ponte cómodo, pilla palomitas y despega conmigo.
Vamos a adentrarnos, como dice uno de los grandísimos de la escena del PrestaShop hispano, en este “oscuro y tenebroso camino” que en esta ocasión representan las bases de datos mal gestionadas para todos: para ti, como propietario o futuro propietario de una tienda online, para nosotros, las agencias y para los sysadmin, o más conocidos como Administradores de sistemas, que son realmente los que hacen que las páginas web funcionen día a día, sin interrupciones, sin lentitud y sin problemas.
La madre del cordero (las bases de datos)
Como imagino que ya sabrás a estas alturas de la película, la base de datos es el lugar donde nuestra tienda online almacena los datos.
Oye Jordi ¿y qué tipo de datos almacena la base de datos de mi tienda online? – te preguntarás.
Pues déjame que te diga que no solo los relativos a los productos, categorías, clientes o pedidos de tu tienda, sino también los relativos a la configuración general.
Aspectos como los idiomas, países o provincias, ajustes del sistema, correos electrónicos, filtros de producto y muchos más son almacenados en la base de datos.
Así que puedes imaginar la cantidad de consultas que es necesario realizar a nuestra base de datos para mostrar algo tan nimio como una ficha de producto.
Las bases de datos se dividen en tablas.
Me gustaría que pensases en las tablas como en hojas de excel, donde cada columna representa un tipo de campo diferente.
Imagina que tienes una hoja de Excel para llevar el control de los números telefónicos de tus clientes.
Tendríamos probablemente una columna para el nombre, otra para los apellidos y otra para el número de teléfono.
Si esto quisiéramos llevarlo a un entorno de base de datos, tendríamos igualmente una tabla, que sería nuestra hoja de excel del ejemplo anterior y tres columnas, que aquí, en las bases de datos se llaman campos.
Sucede que en una tabla de Excel es muy complicado, si no cuentas con los conocimientos adecuados, hacer que por ejemplo el campo destinado para el teléfono (la tercera columna) admita solamente números y que además, tengan esa forma característica que nosotros tendemos a reconocer en un número telefónico, algo así como:
(91) 555 55 55 para los números fijos
666 66 66 66 para los móviles
Hacer esto en bases de datos es muy muy sencillo, pues podemos asignar a cada campo un tipo diferente.
Así pues, podemos establecer que el campo destinado a almacenar el número de teléfono pueda contener únicamente números y el signo + (para poder poner un teléfono en notación internacional). Además, podemos establecer que el signo + solo pueda ir al principio.
Podemos decir que ese campo debe tener una longitud mínima y máxima
Y de este modo evitaremos introducir mal un número de teléfono, algo que en Excel es muy complicado de realizar.
Se puede hacer pero cuesta mucho más.
Como curiosidad te contaré que lo que permite que luego los números de teléfono se visualicen de una forma determinada se llama máscara y no depende exclusivamente de la base de datos, es un ajuste externo a esta.
Hasta aquí hemos aprendido que las bases de datos están compuestas de tablas y registros, llamados campos. Además, cada campo es de un tipo determinado para evitar almacenar en él información que no debería de existir, como por ejemplo poner un número de teléfono en lugar del nombre.
Esto en una hoja de excel de control de números de teléfono es probable que no fuese necesario, sin embargo si tienes varios millones de teléfonos almacenados puede que sea una buena práctica a fin de evitar que un día necesites llamar a un número concreto y te encuentres con la sorpresa de que el número está incorrectamente escrito y por tanto no puedes contactar con esa persona
Sería un desastre ¿verdad?
Pues bien, ahora entiendes el concepto de validación de datos
Sé que en este momento de tu lectura te estarás preguntando muchas cosas pero déjame decirte que es absolutamente imprescindible que conozcas un mínimo acerca de cómo funcionan las bases de datos si tu objetivo es comprender la importancia de los problemas que vas a enfrentar en un futuro con tu tienda online.
Es más: es imprescindible que conozcas un mínimo sobre las bases de datos si quieres tener criterio a la hora de tomar determinadas decisiones a las que te verás obligado y comprender ciertos comportamientos que tu tienda adoptará tarde o temprano, así que acepta un consejo y sigue leyendo.
Las relaciones
Como puedes ver si entras en el administrador de base de datos de tu hosting y echas un vistazo general a la base de datos de tu tienda online PrestaShop, no hay unas pocas tablas, al contrario: encontrarás de media más de 250 tablas.
Por tanto, puedes hacerte una idea de las dimensiones de una base de datos de PrestaShop aún a pesar de que todavía no tengas una gran cantidad de información.
Sin embargo existe otro concepto importante que afecta a las bases de datos.
Verás, las bases de datos como las de Presta se llaman bases de datos relacionales debido a que existe una relación entre campos de distintas tablas.
Una de las metas que he trazado en la redacción de este post es intentar que estos conceptos sean fáciles de comprender, así que explicaré a continuación esto de las relaciones.
Déjame ponerte un ejemplo muy sencillo:
En tu cabeza tienes una pequeña base de datos de recetas.
A muy tarugo que seas con la cocina, sabrás que existe una relación entre el azúcar o la sacarina y el café o las infusiones.
Nadie querría poner sal en el café ¿verdad?
De este modo, en tu base de datos mental de recetas, has establecido una relación entre la tabla de ingredientes y la tabla de preparaciones.
Así puedes determinar que el azúcar es lo que va con el café pero no así la sal.
Podríamos decir que los ingredientes (todos) están conectados con la preparación
Cuando piensas en una receta concreta, como el café con leche, sabes que tienes que buscar unos ingredientes concretos porque hay una relación establecida entre ambos elementos que corresponden a tablas diferentes.
Por si acaso no eres bueno con la cocina te pondré otro ejemplo derivado de nuestra lista de contactos telefónicos.
Imagina que tienes un listado de teléfonos en una tabla. Solo eso: teléfonos
Luego tienes otra tabla con nombres, que son los contactos: las personas a las que llamas directamente
Y además, existe una tercera tabla que es la de empresas. Esas personas trabajan en empresas que son realmente tus clientes.
La relación entre tablas es lo que, en bases de datos, nos permite asociar un número de teléfono a una o más personas y a una empresa determinada.
Y digo a una o más personas porque cuando tienes una base de datos de este estilo sabrás que es totalmente normal tener varios teléfonos para una misma empresa dado que en ella pueden trabajar diferentes personas (contactos) con los que mantienes conversaciones.
De la misma manera que si existiese, por ejemplo, otra tabla con emails de contacto, también necesitarás establecer una relación entre los teléfonos, los contactos, las empresas y los emails.
Relaciones hay de varios tipos y no, no me refiero a las relaciones personales, que ahí no entro, sino que hablo de las relaciones entre los datos las tablas.
Decimos por ejemplo que hay una relación uno a uno cuando cada campo de la tabla de teléfonos se relaciona exclusivamente con cada uno de los campos de la lista de nombres.
También existen relaciones de uno a varios cuando por ejemplo tenemos que relacionar un número de teléfono con varios nombres, es decir, con varios contactos que trabajan en la misma empresa.
Hay más combinaciones, pero creo que queda claro el concepto de relación entre datos.
Las relaciones entre tablas de una base de datos se planifica en el diseño inicial y puede llegar a incluir miles de relaciones entre campos.
A través de PhpMyAdmin, la herramienta gratuita incluida en prácticamente todos los hostings del mundo es posible ver las relaciones entre campos.
Te animo a que le eches un vistazo a las de tu base de datos, ¡vas a fliparlo!
Además, déjame decirte que a cada entrada de la base de datos lo llamamos registro
Los índices
No sé si alguna vez has tenido en tu ordenador una hoja de excel con muchísimas columnas y con miles y miles de filas.
Y no sé si quizá has intentado buscar un dato concreto en una de ellas, pero si lo has hecho, te habrás dado cuenta que el ordenador tarda unos segundos en encontrar el dato que quieres buscar.
Si tuviésemos una tabla de una base de datos con muchos campos y con miles y miles de registros y necesitásemos buscar un valor concreto, esa búsqueda tardaría unos cuántos segundos, pues aunque tu web, casi seguro que está en un servidor potente, lo que tú contratas es un hosting, es decir: una pequeña porción de ese servidor y por tanto no cuentas con todos los recursos solo para tu base de datos.
Imagina que tienes 50.000 productos en tu base de datos: cada vez que cargues una de esas fichas, el sistema tendrá que buscar entre todos ellos hasta encontrar el que quieres mostrar y eso, si fuese así, haría que tardases varios segundos en poder cargar la página.
Y no tengo que decirte lo que significa “varios segundos” cuando hablamos de velocidades de carga en una tienda online ¿verdad?
Pues bien, los índices actúan como indicadores en cada campo, pero como hemos hecho antes, vamos a poner un ejemplo que te ayude a comprenderlos mejor.
Imagina que estás en clase. Has vuelto a tu infancia y el profe de Historia te pone tareas para el “finde”: tienes que hacer un resumen del capítulo que habla sobre el Imperio Romano.
Llegas a casa, sacas el libro de historia de la mochila, lo abres y tienes que empezar a leerlo entero, por encima, pasando página tras página hasta encontrar el capítulo.
Ineficiente ¿verdad?
En condiciones generales ¿qué haríamos?
Buscaríamos en el índice en qué página se encuentra ese capítulo ¿correcto?
Es más: muy probablemente lo que el profe nos haya dicho sea algo del estilo “tenéis que hacer un resumen del capítulo 8: el Imperio Romano”.
Así que lo que realmente vas a hacer es abrir el libro, ir al índice, que está al principio y buscar en qué página se encuentra el capítulo 8.
Pues eso, querido lector, es un índice en bases de datos.
Consiste en agregar una información a cada registro a modo de índice que nos permite, entre otras cosas, encontrar la información de una forma rápida y eficiente sin necesidad de recorrer todos los registros de la tabla.
Volviendo al ejemplo de nuestra base de datos de teléfonos, que a estas alturas te recuerdo que ya tiene teléfonos, contactos, empresas y correos electrónicos, colocaríamos un índice en cada teléfono para que a la hora buscar uno de ellos no tuviésemos que recorrer toda la tabla entera leyendo números y números.
Si sabemos que Jacinto tiene el teléfono con el identificador (ID) 750, solo tengo que ir al ID 750 para encontrar su número y llamarlo.
¿Te suena un poco lo de “ID”?
Bien bien ¡se acercan cosas interesantes!
Consultas
Las consultas han aparecido ya en este texto, las has visto e interactuado con ellas pero probablemente no te hayas dado cuenta.
Cada vez que necesitas solicitar un dato a tu tienda, tienes que hacer una consulta para cargar esos datos desde tu tienda online.
Esto es lógico porque si tienes 20.000 productos y vas a cargar una página en tu web que muestra solo 20, necesitarás un método para encontrar esos 20 productos de entre 20.000 que forman el total ¿correcto?
Pues para eso (y mucho más) están las consultas.
Otro de los conceptos erróneos a los que se tiende en base de datos cuando no tenemos conocimiento de ellas es a pensar que las consultas solo existen para extraer información, sin embargo no hay nada más lejos de la realidad.
Las consultas pueden llegar a ser exageradamente complicadas.
Como anécdota te contaré que hace muchos años trabajé en el que era en su momento el casino más grande de Europa, en Madrid. Concretamente en el departamento de sistemas.
Allí compartí sala con una ingeniera de bases de datos cuyo trabajo consistía exclusivamente en diseñar consultas a la base de datos del casino que respondiese a la demanda de los usuarios.
¡Imagínate cómo de importantes pueden llegar a ser!
Aunque existen multitud de tipos de consultas y además pueden anidarse, es decir: se puede poner una consulta dentro de otra, ahora mismo no voy a liarte con eso.
Prefiero explicarte los tipos más importantes de consultas y pronto (te lo prometo) entenderás porqué es necesario que las conozcas, aunque sea muy por encima.
Además, descubrirás un terrible secreto: las consultas también sirven para guardar datos en una base de datos, no solo para leerlos. ¿No me crees? ¡sigue leyendo!
SELECT
Es el tipo de consulta más corriente, es el patito feo de las consultas, la común, la que pasa desapercibida… pero de las más malignas (ya te contaré más adelante). Aunque reconozco que no es la peor.
Al lío: lo que hace esta consulta es leer datos (extraerlos) de una o más tablas.
Ejemplo: De la tabla de teléfonos, indícame el de Pablo, que es el ID 760
INSERT
Esta es guay, no da mucha guerra. Es la hermana guapa de SELECT.
Sirve para entrar datos (introducirlos) en una o más tablas.
Ejemplo: Graba el teléfono 666 55 55 55 y asócialo al nombre “Juan Luis”
Ejemplo PrestaShop: Da de alta el producto “Reloj Tag-Heur dorado”
UPDATE
Update es gemela de Insert pero con menos poderes.
Sirve para modificar un dato existente en la base de datos.
Ejemplo: Cambia el número 666 55 55 55 por 666 55 44 44
Ejemplo PrestaShop: Cambia el precio al producto con ID 88 de 90€ a 100€
DELETE
Delete es maligna. Aunque tiene un poder tambíen limitado, su uso está restringido (es coña) dado que pueda causar estragos en una base de datos.
Ejemplo: Borra el teléfono 666 66 66 66
Ejemplo PrestaShop: Elimina el cliente con ID 234
WHERE
Empezamos a complicar las cosas. Where es un condicional. Como condicional dependerá de lo que le pidamos. Es como el hijo tonto de las consultas y tengo que decirte que no he visto más errores en diseño de bases de datos como errores con consultas WHERE: una barbaridad.
Para comprender mejor cómo funciona, te pongo un ejemplo con nuestra base de datos imaginaria
Ejemplo: Dame todos los teléfonos de los usuarios cuyo nombre sea igual a “Juan”
De esta forma la consulta nos devolvería todos los teléfonos de los usuarios llamados JUAN independientemente de sus apellidos.
Si tenemos a 20 “Juanes” en la base de datos nos devolverá 20 resultados
Ejemplo PrestaShop: Dame todos los productos de la categoría “camisetas”
JOIN
Join es el diablo. Dicen que para su creación, el mismísimo Darth Vader se alió con los Stith y se reunieron en la Estrella de la Muerte durante varios días tratando de encontrar una herramienta que darle a la Resistencia y que fuese capaz de aniquilarla por dentro.
Hay pocas cosas conocidas en el universo con más poder que una consulta Join que no utiliza índices… pero esto lo dejo para más adelante (ups! que te destripo el final)
Bromas aparte (que lo último no lo es), he aquí un ejemplo:
Si tenemos la tabla de números de teléfono, la de nombres y la de empresas, una consulta JOIN podría ser “Dame todos los nombres y teléfonos que coincidan con la empresa “Acme S.L.”
Y no, de esta no te pongo ejemplo de PrestaShop porque aún necesitamos avanzar un poco más en lo que sucede, pero pronto lo entenderás joven padawan.
Hay muchos más tipos de consultas y como te he comentado, las consultas pueden anidarse una dentro de la otra en la misma consulta.
Así por ejemplo, sería perfectamente posible usar una consulta SELECT que dentro contuviese una o más consultas JOIN.
Ahora ya tienes una mínima instrucción en bases de datos.
No es que vayas a poder hacer gran cosa con ellas, pero te garantizo que con esto comprenderás mucho mejor cómo funcionan y cómo afectan a una tienda online, así como la importancia que tienen y lo poco valoradas que están.
Las consultas en PrestaShop Vs las consultas en los módulos de PrestaShop
Un problema muy recurrente que pasa por nuestras manos más a menudo de lo que nos gustaría en la agencia es el relacionado con webs lentas y más concretamente: con webs lentas debido a módulos.
Te voy a contar una anécdota para ponerte en situación.
Hace unos años tuvimos un problema de rendimiento grave en una tienda de una gran cliente nuestro.
Cuando el número de usuarios concurrentes llegaba a 50 más o menos, la tienda se volvía ingobernable.
El tiempo de respuesta de carga aumentaba considerablemente y con ello la lentitud, tanto en el backoffice como en el propio front.
A medida que nuevos usuarios se conectaban a la tienda, se iba volviendo más y más lenta, hasta el punto que el servidor colapsaba.
Es una tienda de ropa, más concretamente de moda jóven.
En época de rebajas podíamos llegar a tener 500 usuarios concurrentes conectados al mismo tiempo en la tienda, así que imagínate.
Una de las primeras acciones que llevamos a cabo fue la de aumentar los recursos de hardware cambiando el servidor.
Recuerdo que por aquel entonces, llegamos a colocar esta web en una máquina dedicada de OVH, un servidor con 32 núcleos (64 hilos de procesamiento) Intel Xeon (última versión de aquel entonces) con 128Gb de RAM y discos Nvme (50 veces más rápidos que un SSD).
Nara era suficiente, logramos estabilizar a 60-75 usuarios concurrentes, pero por encima de este nivel el servidor seguía colapsando.
Finalmente, desesperados, tuvimos que recurrir a un servicio externo de análisis, un experto en bases de datos que auditó la web y descubrió el problema ¡y vaya si lo descubrió!
Resulta que hacía unas semanas, habíamos instalado un módulo de opiniones de clientes.
Es el típico módulo que tras una venta, envía un correo automático a un cliente y le pide que valore su compra a cambio de un cupón de descuento.
Cuando el cliente accede a valorar su compra, la opinión se coloca en la ficha del producto y es visible para el resto de usuarios de la web.
Añade estrellitas que tanto le gustan a Google (rich text snippets) y toda la parafernalia.
Bueno, pues te contaré que este módulo hacía que cada vez que se cargase una ficha de producto, se ejecutase una consulta a la base de datos, la cual, por un problema de diseño, no se cerraba jamás (no llegaba a completarse), sin embargo, en el front (en la tienda) no daba ningún problema aparente.
Esto significa que cada ficha de cliente vista por cada usuario de la web generaba una consulta a la base de datos que se quedaba permanentemente abierta.
Hagamos unas cuentas rápidas:
Digamos que, por ejemplo, un usuario vista de promedio 20 fichas de producto
Teníamos 500 usuario visitando 20 fichas = 1000 consultas no finalizadas (en ejecución) contra la base de datos.
Esto tumbaría hasta los servidores de la NASA.
Por ese motivo, aún con un servidor dedicado por entero para esta web, por encima de las 50-75 visitas concurrentes colapsaba el sistema.
Comprendiendo la magnitud del problema
Cuando instalamos una tienda PrestaShop, tal cual viene de origen, podemos afirmar que casi la totalidad de las consultas que contiene su código están debidamente optimizadas, no hay nada de lo que preocuparnos (por ahora).
Pero claro, como decíamos antes, llega un momento en que necesitamos sí o también utilizar módulos y aquí, es donde nos podemos encontrar con las sorpresas, tal y como has podido leer más arriba en el caso que te he relatado.
Ahora que ya tienes toda la información relevante llega el momento de realizar una serie de preguntas esenciales cuyas respuestas te ayudarán a comprender mejor el contexto del uso de módulos en PrestaShop, su riesgo, ventajas, inconvenientes, posibles problemas, motivos y mucho más.
¿Porqué algunos módulos de PrestaShop no tienen consultas totalmente optimizadas?
Personalmente me gusta agrupar los módulos en dos grandes grupos
- Módulos que operan sobre los datos propios de la base de datos: Estos módulos, generalmente, no introducen nuevos datos en la base de datos, sino que operan con los existentes. Tampoco crean nuevas tablas o registros en tu tienda online. Por lo general, estos módulos suelen presentar menos problemas debido a que no necesitan generar nuestras estructuras de datos.
- Módulos que necesitan generar nuevas tablas o registros: Por el contrario, estos módulos son los que aglutinan la mayor parte de los problemas en las consultas a la base de datos. Además, he de reconocer que una gran mayoría de módulos necesitan crear nuevo contenido en la base de datos para su correcto funcionamiento.
Teniendo esto en cuenta, hemos de pensar que hay varios motivos que pueden producir que, en su etapa de diseño y programación, un módulo tenga un problema importante en las consultas que ejecuta en la base de datos y aquí están los más destacados
- Fallos de diseño/programación: Es el motivo más habitual de todos y lamentablemente lo hemos encontrado tanto en módulos realizados por empresas de gran reputación como en módulos de desarrolladores menos conocidos.
- Imposibilidad de optimizar más una consulta concreta: Hay situaciones (más de las que podríamos pensar) en las que es imposible optimizar más una consulta. Estas situaciones están directamente relacionadas con la magnitud de las tablas que se consultan. Si tu tienda online tiene ya unos años de vida y tienes tablas en la base de datos con decenas o cientos de miles de registros, a veces no es posible optimizar más una consulta de lo que ya está en su planificación inicial.
- Índices inexistentes o no creados: Cuando hemos de realizar una consulta agresiva, es decir, una consulta que consumirá gran cantidad de recursos debido a la magnitud de los datos a consultar, lo más idóneo como ya hemos aprendido, es utilizar índices. Los índices nos ayudarán a optimizar la consulta ya que serán capaces de conducirnos a los datos exactos que queremos consultar de entre todos los existentes en la tabla. Lo que sucede en este punto, es que hay tablas que no tienen índices o que el módulo no ha integrado un índice nuevo en la tabla que no lo tiene.
¿Qué sucede cuando usamos consultas sin índices?
Esta pregunta es de las más importantes que hemos de hacernos, pues constituye uno de los principales motivos de problemas de rendimiento en las bases de datos de PrestaShop.
La respuesta corta es que dependerá de dos factores: Tipo de consulta y magnitud de la tabla o tablas a consultar (cantidad de datos).
Sin embargo hay una constante que siempre podemos tener en cuenta: Una consulta sin índices siempre será más lenta que una consulta con índices.
Dentro de esto, como decía en el párrafo anterior, una consulta select sin índices a una tabla tardará más que una consulta select a la misma tabla pero realizada con índices.
¿No sería entonces una buena práctica usar siempre índices en las consultas?
Dado que los índices están en las tablas, las consultas solo pueden usarlos si la tabla los contiene.
No todas las tablas de la base de datos de PrestaShop contienen índices, por lo tanto no siempre podemos utilizarlos.
¿Podemos crear índices siempre que lo necesitemos?
Sí, podemos crear índices en una tabla si ésta no los tiene y además, una tabla puede contener más de un índice.
Hay varios tipos de índice, aunque no vamos a profundizar en ello.
Un programador que diseña un módulo que va a actuar sobre una tabla que no tiene índices, puede definirlos en el script de instalación de dicho módulo, sin embargo esto no siempre se hace.
¿Porqué los desarrolladores casi nunca generan índices sobre las tablas?
Esta es otra de las grandes preguntas que hemos de formularnos para comprender la dinámica del problema y no tiene una contestación corta, pues para ello debemos primero entender cómo funcionan los índices.
Si bien, como decíamos antes, es técnicamente posible generar índices en una tabla que no los tiene o bien agregar otros índices diferentes, hemos de pensar en cómo impactan los índices en una base de datos.
Cuando generamos índices mejoramos unos aspectos y empeoramos otros
A continuación, te muestro una tabla comparativa para que entiendas mejor qué se gana y qué se pierde creando y generando índices en las tablas de una base de datos.
| Beneficios | Empeoramientos |
|---|---|
| Mejora del Rendimiento en Consultas de Lectura: Este es el beneficio más notable de los índices. Al permitir al sistema de gestión de bases de datos (SGBD) localizar rápidamente los datos sin tener que recorrer toda la tabla, los índices reducen el tiempo necesario para realizar consultas de lectura. Esto es especialmente útil en tablas grandes. | Costo en Operaciones de Escritura: Cada vez que se inserta, actualiza o elimina una fila en una tabla, todos los índices en esa tabla deben actualizarse. Esto puede aumentar el tiempo que toman estas operaciones, especialmente en tablas con muchos índices o con un alto volumen de operaciones de escritura. |
| Eficiencia en la Ordenación de Datos: Los índices, especialmente los índices ordenados como B-trees, pueden hacer que la ordenación de los datos según ciertas columnas sea mucho más rápida, ya que los datos ya están parcial o totalmente ordenados. | Uso de Espacio Adicional: Los índices consumen espacio adicional en el disco. En bases de datos muy grandes, el espacio ocupado por los índices puede ser considerable. |
| Optimización de las Operaciones de Join: Los índices pueden mejorar significativamente el rendimiento de las operaciones de JOIN al permitir que el SGBD encuentre rápidamente las filas coincidentes en las tablas relacionadas. | Mantenimiento de Índices: Los índices pueden fragmentarse con el tiempo, especialmente en bases de datos con alta actividad de inserción, actualización o eliminación. La fragmentación puede degradar el rendimiento de las consultas, lo que requiere mantenimiento regular, como la reconstrucción de índices. |
| Soporte para la Unicidad: Los índices únicos garantizan que no hay dos filas en una tabla que tengan el mismo valor en ciertas columnas, lo cual es crucial para mantener la integridad de los datos, especialmente para las claves primarias. |
Como puedes apreciar, los índices no son la solución a todos los problemas de rendimiento que puede tener una base de datos PrestaShop, es más: un uso inadecuado de índices puede llevar a más problemas todavía, incluido a un peor rendimiento.
Los índices no son la solución a todos los problemas de rendimiento, aunque sí puede suponer la diferencia entre una web lenta y una web rápida. Es importante conocer y tener en cuenta el impacto de éstos en el rendimiento de la base de datos.
Entonces ¿qué se debe hacer si detecto que tengo un problema de esta índole en mi base de datos?
Bueno, para empezar he de decir que a menos que seas desarrollador, sysadmin o una persona con formación específica en este terreno no vas a saber con exactitud si tienes o no un problema de consultas en tu base de datos, por lo que la primera recomendación es que consultes con un especialista en bases de datos.
Este profesional podrá indicarte si realmente tienes o no un problema de rendimiento y si es así, entonces podréis preparar un plan de actuación.
Piensa que por el mero hecho de tener una web lenta no implica necesariamente que tengas un problema de rendimiento en la base de datos, pues el foco puede estar en algún otro lugar.
Una vez detectado y diagnosticado un problema de rendimiento en la base de datos, deberíamos de realizar una auditoría de la misma.
Este tipo de auditorías pasan por monitorizar los procesos que el código de tu tienda lanza contra la base de datos (consultas) y las monitoriza todas ellas para luego volcarlas a un log, un archivo de texto donde se registra toda la actividad.
El análisis de este archivo es esencial para determinar dónde se encuentra el problema.
Muchas veces el problema se localiza en un pequeño grupo de consultas, es lo que solemos detectar por ejemplo, cuando tenemos un módulo ineficiente (como el ejemplo que te ponía antes)
Las "consultas de la muerte"
Ahora ya tienes una idea más general sobre la problemática de los módulos en PrestaShop, lo que pueden ocasionar y sobre todo los motivos por los que sucede.
Sin embargo, llevo todo el texto dejando un asunto pendiente que quiero aclarar.
En base a nuestra experiencia, sabemos que hay un tipo determinado de consultas que son terribles para el rendimiento de las bases de datos.
Es una clase concreta de consultas que hemos visto con mucha frecuencia y que a menudo se ejecutan sin índices.
Estoy hablando de las consultas JOIN sin índices
Las consultas JOIN están muy presentes en PrestaShop debido a la naturaleza relacional de sus datos y la necesidad de acceder a información compleja de manera eficiente. PrestaShop almacena datos en una base de datos relacional, donde la información está distribuida en múltiples tablas relacionadas entre sí.
Algunos de los motivos más importantes por los que estas consultas están tan presentes en el código tanto del core como de los módulos de tu tienda online son:
1. Estructura de Datos Relacional
PrestaShop utiliza una base de datos relacional para almacenar información sobre productos, clientes, pedidos, configuraciones de tienda, etc. Estos datos están organizados en tablas separadas que están interrelacionadas mediante claves foráneas. Para reconstruir la información completa a partir de estas tablas separadas, se requieren consultas JOIN.
2. Optimización del Rendimiento de Consultas
Las consultas JOIN permiten recuperar datos de múltiples tablas en una sola consulta, lo que puede ser mucho más eficiente que realizar múltiples consultas separadas y luego combinar los datos a nivel de aplicación. Esto reduce la carga en la base de datos y mejora el rendimiento de la aplicación.
3. Complejidad de los Datos del Comercio Electrónico
La gestión de un e-commerce implica gestionar complejas relaciones entre productos, variantes de productos (combinaciones), inventario, precios, usuarios, direcciones de envío, pedidos, pagos, y más. Las consultas JOIN facilitan la extracción de informes complejos y la visualización de datos relacionados, como detalles del pedido con información del cliente, productos pedidos, precios, y estados de envío, en una sola operación.
4. Personalización y Extensibilidad
PrestaShop ofrece amplias opciones de personalización y extensibilidad a través de módulos y temas. Los desarrolladores de módulos a menudo necesitan acceder a datos de varias tablas para implementar funcionalidades personalizadas, lo que requiere el uso de consultas JOIN. Por ejemplo, un módulo de recomendación de productos puede necesitar unir tablas de productos, historial de pedidos y valoraciones de clientes para determinar qué productos recomendar a un cliente específico.
5. Soporte para Multitienda
PrestaShop tiene capacidades multitienda que te permiten gestionar varias tiendas desde un solo back-office. Las consultas JOIN son esenciales para filtrar y presentar datos específicos de la tienda al acceder a configuraciones, productos, y pedidos, asegurando que la información mostrada sea relevante para la tienda actual.
6. Internacionalización
La gestión de múltiples idiomas y monedas es otra área donde las consultas JOIN son cruciales. PrestaShop almacena traducciones de productos, categorías, y otros elementos en tablas separadas. Las consultas JOIN permiten recuperar la información del producto junto con sus traducciones adecuadas en una sola consulta, simplificando la presentación de datos en el idioma preferido del usuario.
Como puedes ver, las consultas JOIN son fundamentales en PrestaShop debido a la necesidad de gestionar eficientemente las complejas relaciones entre los datos almacenados en una base de datos relacional, optimizando el rendimiento y permitiendo la personalización y extensibilidad en un entorno de comercio electrónico dinámico.
El problema se presenta cuando tenemos un gran número de consultas JOIN ejecutándose sin índices, pues esto significa que cada consulta deberá recorrer todas las tablas implicadas en ella.
Cuando tenemos una tienda online con tablas muy grandes (productos, clientes, categorías, etc), estas consultas consumen muchísima cantidad de recursos, en consecuencia, comprometen la estabilidad del servidor y provocan lentitud y tiempos de carga excesivos.
Recomendaciones
Tras todo este tocho, es posible que te estés preguntando qué puedes hacer para evitar estos problemas. O quizá tu tienda online ya se esté viendo afectada por esto y necesitas resolverlo.
A continuación te doy una serie de consejos que puedes poner en práctica en tu tienda online para evitar o intentar dar con la causa de este problema
- Haz una copia de tu tienda (staging). Esto es siempre muy recomendable cuando nos enfrentamos a una identificación de un problema grave. Un entorno de pruebas o staging es un duplicado de tu web donde puedes trastear tranquilamente sin riesgo a cargarte nada.
- Desactiva los módulos uno a uno y comprueba los resultados cada vez que lo hagas: esta es una de las mejores prácticas que puedes llevar a cabo para identificar un módulo problemático.
- Prueba siempre los módulos nuevos en el duplicado de tu tienda, nunca en producción. Asegúrate que el módulo no interfiere negativamente con el resto de funcionalidades.
- Monitoriza la actividad de tu base de datos. Es imprescindible que sepas qué es lo que sucede en tu base de datos. Uno de los puntos más importantes, es tener un registro de slow queries (consultas lentas) que te ayuden a identificar dónde se están produciendo los cuellos de botella.
Conclusiones
Espero que con este artículo hayas aprendido un poco más cómo se comportan las bases de datos de PrestaShop y cómo interactúan con el código.
Es muy importante tener en cuenta esta información, sobre todo de cara a un correcto mantenimiento de tu tienda online.
Si tienes algún problema de rendimiento en tu tienda online y necesitas ayuda no dudes en ponerte en contacto con nosotros.