Datos de sensores, cotizaciones de un valor bursátil, marcador de un partido de fútbol, …; en ocasiones, nos encontramos con la necesidad de almacenar datos volátiles, que no perduran o que cambian en el tiempo.
¿Qué son? Son un tipo de datos, o de contenido en general, que comparten varias de estas características especiales:
- No perduran en el tiempo
- Actualización constante
- Caducan
- Válidos para todos los usuarios
- No tienen relación con el usuario o la navegación
- Grandes volúmenes de información
Básicamente la estrategia consiste en almacenar en los tres soportes de almacenamiento estándar que tenemos disponibles: memoria, base de datos o disco; aunque a veces combinamos varios de ellos para optimizar el uso. Por lógica, el acceso más rápido es a la memoria, pero es limitada y volátil.
PHP y WordPress nos han enseñado a trabajar con este tipo de datos con diferentes métodos, completamente válidos en cualquier caso pero que tienen rendimientos y limitaciones en función del uso que queramos darle.
Vamos a repasar 5 opciones de desarrollo que tenemos y daremos unas pinceladas sobre cada uno.
Índice de contenidos
1. En WordPress utilizando la tabla wp_options
El acceso más fácil que nos proporciona WordPress y que nos permite guardar datos simples en el modelo de datos del propio WordPress.
Con el tiempo, y la instalación y uso de plugins y de nuestro propio código, convierte a wp_options en una tabla gigantesca y poco optimizada, que afectará al rendimiento de nuestro sitio ya que es muy utilizada por el propio WordPress.
- Pro: fácil acceso y programación.
- Contra: manejo de la tabla wp_options para gran cantidad de datos y de actualizaciones
Nota: Existen diferentes plugins para realizar estas acciones de limpieza sobre la tabla wp_options.
2. También en WordPress, mediante el Transients API
Una mejora del anterior punto, que nos permite poner caducidad a los datos, aunque también almacena los datos en wp_options.
- Pro: permite caducar los contenidos (aunque no es 100% real, ya que se necesitan tareas para realizar el borrado, por ejemplo mediante el cron).
- Contra: manejo de la tabla wp_options. Aplíquense las anteriores optimizaciones.
3. En base de datos
Estaría siempre la opción de manejar nuestro propia tabla e incluso creando nuestro propio modelo de datos separado al de WordPress.
- Pro: permite manejar datos o estructuras más complejas.
- Contra: desarrollo más laborioso y difícil de mantener al ser propietario.
Todas estas opciones de desarrollo, se basan en almacenar contenido en la base de datos como repositorio de la información, buscando un almacenamiento más rápido y eficiente, pensamos en la memoria, incluso cuando hablamos de optimizaciones en tiempo por debajo del milisegundo.
4.Sesiones y Cookies de usuario
Nos facilita almacenar contenido relacionado con las acciones del usuario y la navegación que está realizando (acciones de usuario en nuestro site).
- Pro: rapidez, sencillez y eficiencia.
- Contra: sólo podemos almacenar datos para ese usuario y no permite la expiración de los mismos (excepto por la finalización de la sesión).
5.Memcached
Se trata de un sistema de almacenamiento basado en memoria y que corre como un servicio en nuestras máquinas, ideal para grandes volúmenes y tráfico.
En grandes instalaciones, varios servidores a la vez, podemos optar por tener diferentes servicios Memcached en ejecución, uno por servidor, o un sólo servicio centralizado donde acceden todos los servidores web.
- Pro: rapidez, escalabilidad y eficiencia.
- Contra: es volátil, ya que depende del servicio.
Nota: Otro sistema de almacenamiento basado en memoria es Redis, que añade la opción de la persistencia en disco.
No me olvido de otras técnicas como las funciones WP_Cache de WordPress o el APC y el OPcode Cache de PHP, menos usadas, pero a veces de similar eficiencia.
A modo de resumen o de guía práctica diremos que:
- Siempre que podamos, debemos utilizar el almacenamiento en memoria antes que el almacenamiento en base de datos o disco.
- Determinar el contexto de los datos (por servidor, por aplicación, por usuario), el volumen de los mismos (memoria PHP, memoria de la máquina, espacio en BD o espacio en disco) nos determinan el soporte y técnica a utilizar.
- Si necesitamos que los datos sean compartidos para cualquier usuario, utilizaremos memoria compartida. por ejemplo Memcached como soporte.
- Y por último, si la persistencia se va a prolongar durante un periodo largo o el dato se transforma de volátil a persistente o es muy costoso obtenerlo, la opción de base de datos será la más eficiente optimizando el acceso o no con Plugins como W3 Total Cache.
El entorno ideal casi siempre será una mezcla de todas estas opciones de arquitectura de datos. Siempre hablamos de entornos con mucho tráfico, es decir, muchas operaciones de entrada/salida.
Si todavía se te quedan cortas estas opciones, será momento de hablar de Big Data y WordPress otro día.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado. ¡Ah! ¿te funciona? pues entonces no he dicho nada :)
Pues la verdad es que a ver si te animas a comentar lo del big data y WordPress, porque la verdad esto del big Data debe ser algo alucinante porque lo oigo por todas partes y quiero enterarme un poco. Te animo a que cuanto antes nos hables de esas maravillas.
Cierto, parece el tema de moda en los últimos años.
Todo el mundo habla de ello pero no percibimos nada «tangible».