java - Sobre el uso de Terracotta como solución de persistencia
transactions persistence (2)
Terracotta es solo Java. Si está bien para usted estar encerrado en esta tecnología, sin la posibilidad de simplemente escribir algunos scripts (sin JVM) en otros idiomas, entonces continúe con esto.
El artículo Kill Your Database with Terracotta fue realmente agradable.
¿Sería una buena idea usar Terracotta como solución de persistencia (reemplazando una base de datos)? Me pregunto específicamente sobre problemas de integridad de datos y soporte para sistemas transaccionales.
Terracotta es transaccional (bloques sincronizados forman transacciones de objetos modificados) pero no es y no quiere ser compatible con JTA. Hay una discusión bastante larga de las transacciones y algunos conceptos erróneos comunes sobre Terracota aquí .
Escribí una publicación en un blog sobre la vida útil de los datos y cómo eso debe enmarcar su pensamiento sobre la identificación de oportunidades para el uso de Terracotta. En resumen, el punto ideal de Terracotta es el caso de uso en el que necesita persistencia y disponibilidad (su aplicación podría bloquearse pero aún necesita los datos), pero donde los datos no son necesariamente críticos a largo plazo.
Un ejemplo canónico es importante en el contexto de una sesión de usuario en una aplicación web, como la información del carrito de compras. Desea mantener esa información persistente para que, si su aplicación web falla, mantenga el carrito de compras. Pero el carrito en sí puede o no ser comprado. Entonces, lo almacena en Terracotta hasta que lo compra, luego lo guarda en la base de datos como datos del "sistema de registro".
Históricamente, los datos que almacenaba en una base de datos eran siempre datos del "sistema de registro" que era fundamental para el éxito a largo plazo de su empresa: clientes, pedidos, etc. Con las arquitecturas "sin estado" de hoy (que realmente no son apátridas) , llevamos todos los datos de mediano plazo a la base de datos. Esto significa que estamos castigando innecesariamente nuestra base de datos (con trabajo y almacenamiento extra) y nuestros desarrolladores (que tienen que manejar el desajuste de impedancia relacional entre objetos, incluso si usan ORM). Un mejor enfoque es dejarlo en objetos y agruparlo con Terracota. Varios usuarios recientes de Terracotta han utilizado esta técnica para reducir significativamente la huella de su base de datos (ahorrándoles millones de dólares) al mismo tiempo que aumentan su capacidad de escalar.
Está la cuestión del punto de integración con la base de datos y cómo hacer la transferencia de manera confiable. Vimos esto como un caso de uso en el recientemente lanzado Examinator (una aplicación web de referencia Spring / Terracotta / Tomcat / MySql). Cuando los exámenes están en progreso, el estado (respuestas a preguntas, orden de elección aleatoria, preguntas marcadas para revisión) se almacena en Terracota. Pero cuando se completan los exámenes, el puntaje resultante se calcula y almacena a largo plazo en la base de datos.
Para hacer esto de manera segura, usamos una estrategia clave de Hibernate que genera la identificación de la fila de la base de datos en el objeto en Terracotta primero, luego guarda los datos en la base de datos y luego los elimina de Terracotta. Este escenario tiene una posible condición de carrera si la aplicación se bloquea después de guardarla en la base de datos, pero antes de eliminarla de Terracotta. En ese caso, la aplicación podría intentar volver a guardar los datos en el archivo db, posiblemente creando dos filas. Pero debido a la identificación pregenerada, podemos decir si la fila se escribió con anterioridad o no y evitar ese problema.
En resumen, no creo que Terracotta reemplace su base de datos a corto plazo. Es demasiado nuevo desde el punto de vista operativo incluso para ser considerado como tal en la mayoría de las tiendas. El modelo de uso es muy diferente. No hay consulta o capacidad de SQL en el montón (su capacidad de consulta está definida por su modelo de objeto). Creo que puede y está empezando a reemplazar el uso de datos a mediano plazo, donde es una alternativa mucho más barata y fácil. Sin embargo, algunas personas están empezando a experimentar con él para el almacenamiento a largo plazo.