Para obtener más información sobre la persistencia en Cassandra y otras bases de datos NoSQL, consulte ¿Qué es NoSQL?
Comprender el significado de persistencia es importante para evaluar diferentes sistemas de almacenamiento de datos. Dada la importancia del almacén de datos en la mayoría de las aplicaciones modernas, tomar una decisión mal informada podría significar un tiempo de inactividad sustancial o pérdida de datos. En esta publicación, discutiremos los enfoques de persistencia y diseño de almacenes de datos y proporcionaremos algunos antecedentes sobre estos en el contexto de Cassandra.
La persistencia es «la continuación de un efecto después de que se elimina su causa». En el contexto del almacenamiento de datos en un sistema informático, esto significa que los datos sobreviven una vez finalizado el proceso con el que se crearon. En otras palabras, para que un almacén de datos se considere persistente, debe escribir en un almacenamiento no volátil.
Si necesita persistencia en su almacén de datos, también debe comprender los cuatro enfoques de diseño de man que puede adoptar un almacén de datos y cómo (o si) estos diseños proporcionan persistencia:
-
Pura memoria, sin persistencia, como memcaches o Scalaris
-
En memoria con instantáneas periódicas, como Oracle Coherence o Redis
-
Basado en disco con escritura de actualización in situ, como MySQL ISAM o MongoDB
-
Basado en Commitlog, como todas las bases de datos OLTP tradicionales (Oracle, SQL Server, etc.)
Los enfoques en memoria pueden alcanzar una velocidad increíble, pero a costa de limitarse a un conjunto de datos relativamente pequeño. La mayoría de las cargas de trabajo tienen un subconjunto «activo» (caliente) relativamente pequeño de sus datos totales; los sistemas que requieren que todo el conjunto de datos quepa en la memoria en lugar de solo la parte activa están bien para las cachés, pero son malos para la mayoría de las otras aplicaciones. Debido a que los datos solo están en memoria, no sobrevivirán a la terminación del proceso. Por lo tanto, estos tipos de almacenes de datos no se consideran persistentes.
La forma más fácil de agregar persistencia a un sistema en memoria es con instantáneas periódicas al disco en un intervalo configurable. Por lo tanto, puede perder hasta el valor de las actualizaciones de ese intervalo.
Los sistemas basados en actualizaciones in situ y commitlog se almacenan en memoria no volátil de inmediato, pero solo la persistencia basada en commitlog proporciona durabilidad, la D en ÁCIDO, con cada escritura persistida antes de que se devuelva el éxito al cliente.
Cassandra implementa un diseño de persistencia basado en registros de confirmación, pero al mismo tiempo proporciona niveles de durabilidad sintonizables. Esto le permite decidir cuál es el equilibrio adecuado entre seguridad y rendimiento. Puede elegir, para cada operación de escritura, esperar a que esa actualización se almacene en búfer en memoria, se escriba en disco en una sola máquina, se escriba en disco en varias máquinas o incluso se escriba en disco en varias máquinas en diferentes centros de datos. O bien, puede optar por aceptar las escrituras lo más rápido posible, acusando recibo de ellas inmediatamente antes de que hayan sido deserializadas por completo de la red.
Al final del día, eres el único que sabe cuál es el equilibrio entre rendimiento y durabilidad adecuado para tus datos. Tomar una decisión informada sobre las tecnologías de almacenamiento de datos es fundamental para abordar este compromiso en sus términos. Debido a que Cassandra proporciona tal capacidad de ajuste, es una opción lógica para sistemas que necesitan un almacenamiento de datos duradero y de rendimiento.