Eliminar millones de entidades en Drupal: Caso PodcastVery

 Bienvenido o bienvenida aquí otra semana más en Drupalízate, donde yo, Robert Menetray, te voy contando problemas que tengo en proyectos Drupal. Este, espero que sea el último episodio ya de Podcastvery, ¿vale? Se me está alargando mucho el tema de este proyecto en concreto. Hoy toca hablar de eliminación masiva de nodos o de entidades en Drupal, qué problemas he tenido, cómo lo he solucionado y también comentar las soluciones alternativas que me dieron algunas personas de la audiencia, ¿vale? Y bueno, para no liarme más, que siempre me voy por las ramas, por esto, vamos un poco al grano hoy. Lo primero de todo, hacer un pequeño resumen de, para quien no se escuchó en episodios anteriores, en Podcastvery, el proyecto que voy a comentar, es un Drupal 9 que llega a tener 47 millones de nodos, o sea 47 millones es una burrada de nodos en base de datos, lo cual implicaba tener varios gigas, y cuando digo varios gigas me refiero a 200 y pico gigas en base de datos, ¿vale? O sea, son muchos gigas en un MayaDB, en un MySQL. Vale, dicho esto, ya comenté en episodios pasados de que moví esos datos, mejor dicho, copié esos datos a Elasticsearch para poder después eliminarlos del Drupal, o sea, eliminar el tipo de contenido episodio de podcast y mover esos datos a Elasticsearch. Hice un pequeño script muy simple que básicamente me cogía en batch, o sea, en grupo, varios nodos, cogía ese contenido del nodo y me lo ponía en un índice custom de Elasticsearch, y justo después eliminaba el nodo. El problema es que vi que por rendimiento lo que tardaba más, con diferencia, era la eliminación del nodo, lo que hacía que la migración de datos fuera lentísima porque intentaba eliminar cada uno de los nodos. Así que como corría un poco de prisa por el tema de arreglar servidores y reducir el coste de servidores, comentó el código que elimina y lo que hago de momento es migrar a saco todo el contenido. Y cuando yo lo tenga migrado, ya me he buscado la vida para eliminar los contenidos que tengo en Drupal, o sea, reducir la base de datos. Para que os hagáis la idea, había en tablas la descripción de los episodios que me suena que eran 13 o 14 gigas, una de las tablas, y claro, teníamos la tabla de revisiones, que básicamente era un duplicado de esta de 13 gigas, con lo cual entre una cosa y la otra teníamos pues veintipico o casi 30 gigas en un solo campo de Drupal. Después había otros campos que pesaban otros gigas, pero quedaban mucho menores. Esto lo he comentado en episodios pasados, pero para que os hagáis la idea de el marrón que tenía de eliminación de contenidos. Total, desactive el código que eliminaba los nodos y migré los contenidos. Y lo tuve todo en la Sixerch, arreglé problemas de que no tuve en cuenta en su día que había hecho código custom que tenía que usar en la parte de la Sixerch y no la de lo que estaba en MayaDB, pero bueno, arreglé esto y ya me tenía que arremangar, no sé si es la palabra correcta en castellano, o sea, poner manos a la obra para arreglar este percal de contenidos, de eliminar nodos. A ver, primero todo, para eliminar nodos, digamos que si se hace un node delete, vale, eliminar el nodo de ese código, lo que hace Drupal internamente, de forma mal explicada y muy rápida, pero es, vale, ¿qué campos tiene el nodo?, ¿qué tablas son de cada campo?, y ¿cuáles son sus revisiones? Y si elimino el nodo, he de eliminar, pues, todos sus campos, o sea, todos los valores de sus campos en todas las tablas que correspondan, con lo cual si tenemos varios campos, ponle cinco campos, con sus tablas de revisiones tenemos diez tablas con valores a eliminar, y aparte tenemos las tablas centrales, que por ejemplo la tabla node o la tabla del patauto, que también se ha de verificar que si hay contenidos de ese nodo, también ha de eliminar esos valores, con lo cual a final una eliminación de un nodo hace muchas consultas a base de datos, vale, lo estoy explicando mal y rápido, pero para que se entienda, o sea, al final es un trabajo costoso, que consume CPU y RAM, y es otro de la parte de MySQL. Así que, bueno, ¿cómo se puede intentar minimizar este consumo? Como en mi caso, en Podcastvery, lo que quería era eliminar el tipo de contenido, porque moví todos los datos a las XH, pues, tengo que eliminar el nodo, o sea, no es una cosa que a futuros tenga que reutilizar ese tipo de contenido, no, no, me quiero eliminar el tipo de contenido y sus campos, o sea, no quiero que estén ni las tablas en base de datos. Pues, una opción viable en mi caso es, vale, pues, elimino los campos del tipo de contenido, exporto la configuración, esto lo hago en local, o sea, eliminar campos y tal, lo hago en local, exporto la configuración, la subo a producción e importo la configuración. Como estoy importando la configuración, Drupal internamente dirá, ah, vale, que tengo que eliminar estos campos, ¿qué tablas son? Ah, esta y esta, pues las elimino. Pues no, no es tan simple, porque antes de intentar eliminar, lo que hace Drupal es un, ah, tiene valores, pues las tengo que vaciar antes, y una vez vaciadas, ya las voy a eliminar. El problema es que en MySQL vaciar una tabla de varios gigas tiene un coste, digamos, alto de consumo, versus la de eliminar una tabla. Digamos que fue tan alto el consumo de que cuando hacía el comando de importar configuración, o sea, el dhcim, básicamente me reventaba y no me importó, o sea, no hacía nada, o sea, no me permitía eliminar los campos, no me permitía importar la configuración que eliminaba los campos, se quedaba a medias, porque digo, había tablas que pesaban varios gigas. Así que buscando una solución alternativa a esta solución alternativa, llegué a que una cosa que no sabía yo es que MySQL, o MyADB, que viene a ser lo mismo, cuesta muy poco crear una tabla, ponerle un nombre, y después hacer un cambio de nombres, intercambiar los nombres. Con lo cual es factible crear una tabla con idéntico, idénticas columnas, idénticas propiedades, que la tabla original, en este caso de un campo, de por ejemplo el file de description, ¿vale? Si creamos esa tabla con un nombre distinto, y cuando está todo creado, lo que hacemos es intercambiar los nombres con la tabla que Drupal tiene dentro, la tabla que Drupal considera que tiene el nombre correcto, pasará a ser una tabla nueva que he creado yo, que está vacía, que no tiene datos, y la tabla vieja tendrá un nombre que Drupal no reconoce, con lo cual directamente la puedo eliminar a mano, esa tabla, con lo cual puedo eliminar directamente a mano una tabla que pesaba varios gigas y en Drupal dejar una tabla vacía que con el siguiente dhcim, para importar la configuración, la va a importar rápidamente, porque ah, está vacía la tabla, la puedo eliminar, y tal cual haces el comando de importar configuración, te elimina la tabla. A tener en cuenta que no es solo la tabla del campo, sino la tabla de la revisión del campo, ¿vale? Al final por cada campo tenía dos tablas. Hace esta triquiñuela de crear una tabla nueva, renombrarla, mover la vieja, y esto. Con esto, bueno, básicamente pude eliminar muchos gigas. Como digo, pues de un solo campo tenía 13 más 13 o algo así, de otro tenía 5 más 5, el otro tenía, no sé, 3 más 3, había uno de 8 creo, todo esto eran gigas, al final hayan varios gigas que tenía solo en datos en campos. Con esto reducí mucho a base de datos, pero aún me quedaba lo que era eliminar el tipo de contenido, y de forma similar, si elimino el tipo de contenido, se intentan eliminar los nodos del tipo de contenido. Así que antes de intentar importar la configuración que me eliminase los tipos, los nodos, lo que tenía que hacer yo era eliminar de alguna forma los nodos en Drupal, antes de importar la configuración que me eliminase el tipo de contenido. ¿Qué soluciones hay para eliminar el tipo de contenido? Porque, vale, no tengo los campos, básicamente es un nodo pelado que solo tiene el NID, el título, si está publicado o no, y si tiene URL, o sea el patauto. Al final son muy pocas tablas comparado con las que vi antes, pero digamos que igualmente tiene un coste de CPU y de RAM y sigue tardando, menos que antes, pero sigue tardando bastante a eliminar 46 millones, porque recordemos que no está eliminando mil nodos, está eliminando muchos millones de nodos. Vale, pues digamos que hay dos soluciones básicamente, una es módulos contribuidos, vale, de la comunidad y la otra es Pusco de Ocusto. Empezamos con los módulos contribuidos. Que yo conozca básicamente hay dos, vale, que puedan servir para esta funcionalidad de eliminar nodos. Hay dos que yo he usado en tiempo pasado y que son los que conozco yo. Uno es el Devil Generate. El Devil Generate es un sub módulo del Devil que te permite generar contenido y medias, pero si estoy eliminando, no generando, ya, pero te permite generar nodos de un tipo de contenido en específico, o sea hay un flac que le especificas, pues creo que me generes un nodo del tipo artículo o 10 nodos del tipo artículo y hay un flac, una opción que le puedes marcar, de antes de generarme estos nodos, elimíname los nodos del mismo tipo de contenido, o sea, déjame el... esto va muy bien para hacer pruebas en test, en local o en desarrollo. Has añadido, por ejemplo, un campo imagen al tipo de contenido artículo y quieres que los artículos que se están generando para hacer pruebas de que la web funciona bien internamente, pues tengan esa imagen rellenada. Pues básicamente le pones que te genere 10 artículos nuevos y que elimine los antiguos. La opción que puedes usar para eliminar y que no te genere ninguno es decirle de generarme 0 nodos de este tipo de contenido y elimíname los existentes previamente, con lo cual va a intentar eliminarlo todo, en mi caso los episodios de podcast. El problema con esto es que digamos que es lento, que no lo puedes ejecutar de forma asíncrona, o sea, solo puedes ejecutarlo una vez y va, pues, digamos uno a uno eliminando los nodos y que como se te vaya la mano y pongas mal el tipo de contenido, pues te puede eliminar o generar otros tipos de contenido. En mi caso tengo un tipo de contenido que se llama podcast y un tipo de contenido que se llama episodio de podcast, o sea, si no lo has concluido, estás eliminando contenido que no deseas. Y como digo, por rendimiento, cuando eliminas unos cientos o unos miles es factible, cuando eliminas unos millones pues no, porque si no puedes ejecutarlo de forma asíncrona, digamos que es muy lento. Y un caso similar es con el módulo de Leteol. De Leteol, este es un módulo contribuido específicamente solo para eliminar entidades entre las cuales se incluyen los nodos. Yo juraría que esto lo... use este módulo en algún otro proyecto, pero a día de hoy, cuando lo intenté usar para podcast ready, me reventaba al intentar eliminar, o sea, a ponerle la opción de solo este tipo de contenido, porque si no especificas nada te va a eliminar todos los nodos, que es una cosa a tener en cuenta, o sea, cuidado con lo que le marcas, porque si lo marcas mal te va a eliminar lo que no quieres que elimine. Pero esto, que yo le puse el flag de elimíname solo este tipo de contenido, y la... no sé por qué, el código que tiene intentamente no tiene texto o algo, pero le petaba una consulta a Mayasql, buscando en Drupal.org si había un ISE de, bueno, esto, hay una cosa que está mal, aplica este patch y ya funciona, y sí, aplica ese patch y funciona, pero la versión estable, debía ser estable, estas cosas no debían petar. Pero bueno, puse el patch y ahí sí que funciona. Sí que creo que va algo mejor que Devil Generate, pero igualmente, caso similar, no se puede ejecutar de forma asíncrona, con lo cual solo puedes ejecutarlo una vez, y también uno que se tiene en cuenta es que Delete All hace una query primera para obtener cuántos ítems ha de eliminar en total, o sea, digamos hace un count, dime el total de ítems a eliminar. Si tienes pocos ítems, el cálculo es rápido, si tienes una tabla con millones, pues el cálculo tarda unos cuantos segundos. A lo que voy es de que también era el lentillo, vale, si al final tienes un Drupal que tienes que eliminar, pues esto, no sé, unos mil, o así, o menos de mil, o unos pocos miles, es factible usar estos dos módulos, o sea, es instalar el módulo y poca cosa más, ejecutar el comando desde trash, porque esto no lo he comentado, pero estos dos módulos te generan un comando de trash que puedes ejecutar desde línea de comandos. Pero claro, en mi caso se quedaba corto, o sea, tardaría muchos días, creo que hasta semanas, a eliminar todo. La segunda opción es concurrio custom. En mi caso, que no me cuesta nada, es hacer un comando de rash custom, que lo que me hace es, de forma muy similar a lo que hace un delete all, pues tengo un comando que me elimina solo el tipo de contenido que lo especifico, y tengo unos parámetros que le especifico de un offset y un limit. En este caso, el límite, no me acuerdo qué puse, si eran 100 o 1000 items por cada ejecución, y después un offset para que, depende de cómo ejecute el comando, empiece pues en el item 0 hasta, si el límite es 1000, pues del 0 al 1000. Si el offset es 2000, pues del 2000 hasta el 3000, porque es un límite de 1000, se suma. Lo que me permite esto es ejecutarlo en tareas de cron, y que el cron esté, por ejemplo, cada minuto ejecutando el mismo comando varias veces, pero con un offset distinto, con lo cual puedo estar en paralelo eliminando nodos a saco. Lo que me permite, si tengo, por ejemplo, no me acuerdo lo que puse, pero si tenía 10 veces el comando ejecutándose cada minuto, pues digamos que era unas 10 veces más rápido que el de lteol, que sí, que me consume bastante más ram, más que ram y cpu, pero era mucho más rápido en ejecución porque básicamente lo estaba ejecutando en paralelo. Así que es una opción, entre comillas, un poco cutre, porque lo estoy usando con tareas cron, pero es la opción más rápida que encontré yo para eliminar millones de nodos. Y nada más, básicamente que sepáis que eliminar mucho contenido en Drupal es un quebradero de cabeza. Depende si tienes, esto ya lo comenté en episodios pasados, pero si tienes millones de nodos, puede ser que tengas una base de datos gigante, cosa que a mí me chirrea mucho, sobre las tablas de las revisiones, pero bueno. Y poca cosa más, me falta comentar las soluciones alternativas de la audiencia, o sea gente que como tú me estás escuchando, pues bueno, que vieron que tenía problemas y me dijeron, pues si esto yo lo haría de esta forma, o por qué no lo haces de esta otra forma. Básicamente había tres personas, bueno en verdad creo que eran cuatro, que me dieron feedback. Tres eran de la audiencia y uno no era de la audiencia. Digamos que una de ellas me dijo, lo primero fue escala horizontalmente los servidores, o sea duplica o triplica o haz lo que tú quieras pero sepáralo en servidores. O sea la base de datos, si el problema que tienes es en disco, pues básicamente ten un servidor solo para base de datos y si el problema que tienes es en la CPU de las tallas cron, pues ten un servidor solo para las tallas cron. Justamente le dije no, que estoy en ello, o sea justamente me lo comentó cuando yo estaba haciendo, ya lo estaba duplicando y triplicando servidores. Opté por no separar las tallas cron en un servidor independiente, lo puedo hacer, pero ahora mismo por temas de CPU y de costes creo que no me conviene, pero como digo, como esto lo comenté creo que en el pasado justamente, como ya lo tengo ahora todo con tres servidores, no me cuesta nada poner un cuarto, y separar las tallas cron en un servidor aparte. Pero como digo, ahora mismo en mi caso no tiene mucho sentido porque no me hace falta. No lo descarto en un futuro, pero bueno, es bueno saberlo. Sobre todo que sepáis los que escuchéis esto de que podéis tener las tallas cron ejecutándose en un servidor aparte. O sea básicamente es tener el código del Drupal en otro servidor, como la base de datos también está en un servidor independiente, se puede conectar a dos Drupals, uno del Frontend y uno del cron, y que las tallas cron se ejecuten independientemente del Frontend. Sobre todo estos viables si las tallas cron que tú ejecutes no han de hacer nada con el sistema de ficheros de Drupal. O sea, las tallas cron que tú vas a poner no van a eliminar las cachas de Drupal, no van a importar imágenes, no van a hacer no sé qué con PDFs, si no hacen nada con sistema de ficheros, solo van a escribir o eliminar en base de datos, es completamente factible hacer esto. Si, si que tienen que eliminar datos en ficheros, deberías tener el sistema de ficheros en otro servidor y que tanto Frontend como las tallas cron se conecten, o sea que Drupal se conecte a un sistema de ficheros de terceros. Pero esto ya se va un poco de marre y como no es mi caso porque no tengo las imágenes ahora mismo, pues no tengo que hacer nada con un sistema de ficheros, pues perfecto. O sea que como digo me sería muy simple mover esto, o sea mover el cron a un servidor independiente. Vale, otra persona me dijo si el problema que tiene es con los datos de los episodios, pues simple, cárgate los episodios, o sea no hagas nada con episodios en tu web, no los muestres, no los uses para nada. A ver, depende del proyecto, esto puede ser factible, si al final es inviable mostrar ciertos datos en la web por temas de rendimiento o lo que sea, pues si es factible pues no los muestres, o sea piensa en algo para no usar estos datos. En mi caso, aunque se aprecia la aportación, esta opción no me sirve. Básicamente porque yo quiero mostrar datos de los episodios en cada página de los podcasts y también quiero que esos datos de los episodios, o sea textos y descripciones, se usen en las búsquedas de texto de cada uno de los podcasts. O sea, si alguien busca un nombre de una persona que le salgan podcasts donde la han entrevistado, por ejemplo, porque el nombre de la entrevistado está en la descripción del episodio, por ejemplo. O que si buscas episodios que hablen de SEO, pues te salgan podcasts donde han hablado de SEO, aunque en su título o en su descripción no esté la palabra SEO, porque hablan de marketing online y no de SEO, por decir algo, pero tienen episodios dedicados a esta temática. O sea, al final, tener textos de episodios en mi proyecto creo que es relevante tenerlos. Y una opción similar de otra persona es no tengas los datos de los episodios en base de datos ni en ningún lado, sólo guárdalos en caché. Y esa opción es muy factible. Yo también usé algo similar en un proyecto que era contra una API y básicamente es, en vez de estar migrando constantemente los datos de los episodios y guárdandolos en Drupal, lo que puedes hacer es, bueno, pues cada vez que hay un usuario anónimo o logueado que va a una URL, o sea, por ejemplo, a una URL de un podcast, si no hay cachés de sus episodios en Drupal, lo que hace en Drupal es hacer una llamada a la URL, ya sea a una API o, como en este caso, a un feed, obtiene los datos, los cachea y los muestra el usuario. Con lo cual, el siguiente usuario que va a ver esa URL del podcast, en este caso de podcast, ese URL del nodo, como ya va a tener cachés, en vez me salto la consulta al servidor externo, a la API, al feed, directamente muestro los datos de que tengo un caché. Esto es factible, sobre todo si tienes relativamente poco contenido. Un caso que me pasó a mí, que fue con un proyecto, es de que cuando hay un bot, como puede ser Google o puede ser un bot que está indexando la web a saco porque es un bot chino, que también nos pasó en otro proyecto, bueno, total, que si tienes un bot que está indexando o escapeando de alguna forma la web, puede ser de que esté pasando por muchas URL al mismo tiempo o muy seguidamente, URL que usuarios normales visitan una vez al mes, por decir algo. URL que no debían estar en caché o que puede ser contraproducente que estén en caché, por el final estás ocupando una memoria RAM, si usas por ejemplo Memcache o Redis, o estás ocupando espacio en MySQL si la cachela estás guardando en la base de datos. Total, que es una cosa tener en cuenta, si tienes webs que tienen muchas visitas, o muchas, perdón, muchas visitas, muchas páginas de, por ejemplo, de esto, de un tipo de comer o escapear de productos con miles de productos, o en mi caso que tengo millones de URL, les tengo un millón y pico de URL de podcast, que me venga Google y me empiece a indexar toda la web, me va a generar muchas cachés, cosa que me va a consumir mucha CPU y mucha RAM, o sea la CPU para la primera carga de caché y mucha RAM para mantener la caché en caché. O sea, son, también se tiene en cuenta que sí que hay opciones como por ejemplo que todo esto se guarde, perdón, que se guarde, que se use vía Ajax, que no se haga en la primera solicitud, o sea que no ejecute PHP en la solicitud de página, que se use siempre vía Ajax, con lo cual, como muchos navegadores, o sea, muchos bots no usan navegador con JavaScript, básicamente no se va a ejecutar Ajax, con lo cual es contraposente si esperas que Google indexes los textos, porque Google no los va a detectar, pero al menos te ahorras la solicitud o te ahorras el, si, en final te ahorras la generación de esa caché. Otra opción es bloquear por IP, que esto es lo que hicimos en otro proyecto, de, vale, todo lo que viene de China, ignóralo porque, o sea, no. Bueno, es una cosa a tener en cuenta. Como digo, que me voy por ramas. En este caso en concreto sería, entre comillas, factible, de, vale, pues, cojo los datos, los mantengo en caché y cuando tengo un usuario que va a ver el podcast puedo mostrarle la lista de sus episodios. El problema es que solo están en caché para eso, no podría hacer búsquedas de texto que me permitieran encontrar podcasts donde se habla de X palabras que salen en los episodios y tampoco me permitiría hacer búsquedas de podcasts similares o recomendados, porque me hace falta tener esos textos en el Asicsearch o en una base de datos. Así que también descarte esta opción. Como digo, es una opción viable para aprender qué proyectos, pero en este caso en concreto mío, no. Vale, y la última opción, que esto ya no fue de una persona que escuchaba podcasts, fue de mi compañero de podcast de Webificando, que es otro podcast que tengo, que le comentó problemas que tengo con proyectos varios y me dijo, vale, pues, sácalo de etrúpar, o sea, si tu problema es que tienes una base de datos de etrúpar gigante, pues sácalo de allí, ponlo en otra base de datos, en un MySQL independiente, en una tabla custom tuya, si el problema que tienes es que las revisiones en Drupal te lo duplican todo, pues ponlo en una tabla custom, o ponlo en un Postgres o donde tú quieras, y al final digamos que opte por esta opción, pero no opte ni por Postgres ni MySQL, opte por meterlo en el Asicsearch. Y voy a comentar el motivo. Primero de todo, si eso es viable, depende de qué proyectos, es más, lo he hecho en algún proyecto, generar una tabla custom dentro del mismo Drupal, o sea, es un módulo custom que te genera una tabla y se guardan datos allí. Básicamente, como es una tabla custom, tienes total control sobre ello. Drupal no lo va a entender como una entidad, o sea, como un nodo, como un usuario, como una taxonomía, y no va a hacer nada con ello, o sea, no va a generar, pues, la cantidad de columnas y tablas como revisiones, no va a hacer nada de esto, con lo cual, pues va a pesar menos tamaño y tienes un mayor control. Problema con esto, en mi caso, que como tengo millones de nodos, o millones de episodios, igualmente voy a tener una base de datos dentro de Drupal que pesará un huevo y parte del otro, cosa que quiero evitar. O sea, ahora mismo ya pesa bastante, o sea, pesa unos cuantos gigas, no los 200 y pico que pesaba antes, pero siguen pesando unos cuantos gigas, así que intento evitar que pese más. Una opción viable sería, lo meto en un Postgres o en un MySQL, o sea, en una base de datos externa a Drupal, ya sea un Postgres, o sea, una base de datos dentro del mismo MySQL que se usa para Drupal, pero que no sea la base de datos de Drupal, es una base de datos externa a Drupal, que básicamente, para que no sepa, en Drupal puedes tener varias bases de datos, o sea, en tus settings específicas, pues tenemos la base de datos de Drupal y estas dos, o una, o tres externas que se usan para X cosas en el código. Total, en mi caso se podría haber usado esto, genero una base de datos externa y lo meto todo ahí. Yo lo hubiera hecho de esta forma si no tuviera tantos contenidos, ¿vale? Y seguramente lo hubiera hecho en MySQL, básicamente porque el servidor esté en Drupal, esté en MySQL y ya tenga un servidor MySQL. O sea, no me cuesta nada poner otra base de datos más allí, versus lo de tener un Postgres que al final también consume mucho más RAM, por el conocimiento que tengo yo. Total, es una opción viable. En mi caso opté por meterlo todo en Elasticsearch. Motivos. Primero, es un motor de búsqueda, igual que Solar, está mucho mejor pensado para temas de gran cantidad de datos y búsquedas de texto, mucho mejor que MySQL. Aunque metiese los datos yo en MySQL después de meterlos sí o sí en Elasticsearch para permitir búsquedas, o sea, por ejemplo, en cada página del podcast hay un buscador de episodios y ese de poder buscar por texto los episodios de ese podcast. Así que por cantidad de datos estaría bien metirlos en Elastic por rendimiento. Y después, y no menos importante, es que si hago una tabla custom, no tengo integración directa con views. O sea, no puedo usar las views en Drupal. Sí que me suena que en Drupal 7, me suena más que en Drupal 8, o sea, lo usé hace mucho tiempo, creo que en Drupal 7, hay un módulo que te permite conectar views con bases de datos externas y mostrar datos de forma simple, pero al final tienes que instalar un módulo más. En mi caso, como ya uso Elasticsearch para esta web, el módulo Elasticsearch Connector, que es el que estoy usando, ya viene con un sub-módulo que solo es activarlo, que te permite mostrar, o sea, que las views de Drupal se conecten con un índice existente en Elasticsearch, que es un índice externo a Drupal, que no ha generado el search API, sino es un índice cualquiera que tengas tú. Con lo cual básicamente mira muy simple a mí, lo volco todo en un índice en Elasticsearch y con Elasticsearch Connector, que es el módulo de Drupal, pues automáticamente puedo hacer views, o sea, puedo integrar directamente lo que tengo en Elasticsearch con Drupal de forma muy simple y con apenas código, depende del caso. Así que opté por esta opción, para mí tiene mucha más lógica, gran cantidad de datos, me dieron un motor de búsqueda. Y aparte, si tengo mejor integración con Drupal, que no en tablas custom en MySQL. Así que ese fue el motivo. Y también uno de los motivos a tener en cuenta es el tema de backups, que esto no lo he comentado, si meto todos los episodios dentro de la base de datos de Drupal, esa base de datos va a pesar un huevo, lo que significa que los backups van a ser más difíciles y sobre todo si quiero replicar, o sea, si quiero ponerme en local o en desarrollo, una copia de la base de datos va a tardar mucho más tiempo, porque pesará muchos más gigas. Así que si puedo tenerlo en una base de datos externa o en un Elasticsearch, ya que son datos, digamos, no muy importantes, en el sentido de que si pasase algo se puede volver a reindexar, o sea, son datos que están siempre disponibles en los feeds, me importa poco que estén o no, o sea, que estén o no dentro de un backup. Así que por esos motivos opté por usarlo en Elasticsearch. Y nada más, con esto creo que ya doy por finiquitado el tema de PodcastBerry, seguiré desarrollando cosillas, pero son cosas menores, de un onboarding para usuarios, modificaciones en la home que me quedan pendientes al día de hoy, pero el desarrollo grande de este proyecto creo que está acabado, ¿vale? No creo que lo traiga en este podcast a hablar mucho más porque no hay cosas relevantes a comentar, creo yo. El siguiente proyecto, así de ese proyecto mío, creo que puede ser relevante porque quiero intentar, ya veremos si soy capaz, de integrar Drupal con QRs, donaciones en cripto, ¿vale? O sea, el tema de donaciones en, no sé si en Ethereum, si en Bitcoin, si usando Metamask, ya veremos. Pero quiero meterme un poco en el mundillo de cripto e integrar un Drupal con todo esto. Ya digo, no sé si seré capaz, no sé si hay módulos que te hagan esto, no sé si tiene que ser todo con Coreo Custom, ni idea. Y esto no va a ser la semana que viene porque no tengo tiempo. De momento tengo que acabar ahora con agosto con PodcastBerry, así que en septiembre mi idea es empezar con este proyecto de tema de cripto. Así que no tengo ni idea de qué voy a hablar la semana que viene, ya me lo pensaré y seguramente sea algo un poco más teórico y no tan práctico como esto de proyectos y problemas que he tenido. Así que no sé, si tenéis alguna idea comentadlo por link de mí mismo o mi web, menetri.com, en contacto me decís, mira, quiero que hable de este tema, porque no sé de qué hablar la semana que viene. Cosas del verano y el calor que me da tonta. Nada más. Gracias por escucharme y hasta la semana que viene. Chao.