Elegir el ajuste adecuado: ¿persistencia inmediata o eventual?
Con la aparición de las bases de datos NoSql, la "persistencia eventual" es una opción disponible para acelerar las lecturas y escrituras en la base de datos. La persistencia, también conocida popularmente como durabilidad en disco, ha sido reconocida y apreciada durante mucho tiempo como una de las características deseables de un sistema de base de datos compatible con ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad).
Cuando oí hablar por primera vez de la persistencia eventual, me sacudió mi fuerte mentalidad de base de datos relacional, en la que la durabilidad es como una creencia religiosa.
Con el tiempo me he dado cuenta de que no todas las aplicaciones necesitan una persistencia inmediata, especialmente cuando la contrapartida es el rendimiento y el coste, porque las lecturas y escrituras en disco son lentas. Las ventajas de la persistencia eventual a veces superan con creces a las de la persistencia inmediata.
Es hora de exorcizar el miedo a la persistencia eventual de los usuarios de bases de datos.
Inmediato y eventual
persistencia - Entonces, ¿cuál es el
¿Diferencia?
En pocas palabras, la persistencia eventual significa que cada vez que se escriben datos en la base de datos parece que la fila se ha escrito correctamente en el disco porque el sistema de base de datos reconoce la escritura. El host que desencadena esta escritura recibe un acuse de recibo de la base de datos indicando que la escritura se ha realizado correctamente, aunque en realidad la base de datos no ha escrito los datos en el disco, sino que los ha escrito en una capa intermedia como la memoria o una caché del sistema de archivos. La escritura real en el disco se pone en cola y ocurre de forma asíncrona.
Persistencia inmediata significa que la escritura en el disco es sincrónica y que la escritura se reconoce sólo después de que los datos se hayan escrito en el disco.
Pocos segundos después de que esto se mencione a los 3NFers (mi nombre para los usuarios de bases de datos relacionales ), la reunión termina muy rápidamente o las soluciones de bases de datos que proporcionan persistencia eventual se descartan como soluciones inviables. El reconocimiento de las escrituras después de que persistan en el disco ha sido la única manera.
Este blog examina si ciertas cargas de trabajo pueden funcionar con una escritura diferida en disco en favor del rendimiento y el coste SI la escritura inicial se realiza en una capa fiable, totalmente redundante y a prueba de fallos con varias capas de opciones de alta disponibilidad.
Factores a tener en cuenta
elegir la persistencia adecuada
opción
Creo que en muchos, muchos escenarios podemos prescindir de la persistencia eventual en favor del rendimiento y el coste. Examinémoslo.
Antes de profundizar en este tema, permítanme afirmar categóricamente que la durabilidad es una gran característica, pero a costa del rendimiento y de mayores CAPEX/OPEX. Mayor CAPEX/OPEX porque será necesario invertir en un almacenamiento más rápido para ofrecer un mejor rendimiento. Si puede arreglárselas porque tiene otras características de redundancia integradas en su producto y el rendimiento es un factor muy importante, entonces debe considerar la persistencia eventual como una posible solución.
Volvamos a lo básico por un segundo y examinemos lo que un usuario de una aplicación realmente quiere de su interacción con una base de datos
- Escribir datos rápidamente
- Lea los datos que he escrito cada vez con respuestas coherentes
- No perder nunca lo que he escrito. Lo que esto significa en realidad es minimizar la pérdida de datos. Fíjate en que utilizo la palabra minimizar porque hay varios escenarios en los que incluso la "férrea" garantía de las bases de datos RDBMS puede venirse abajo.
Las bases de datos RDBMS existen desde hace mucho, mucho tiempo. Sin duda, han minimizado y abordado estos errores. Tiene mucho sentido para cargas de trabajo muy sensibles que podrían provocar la pérdida de oportunidades causada por resultados incoherentes. Lo que quiero decir es que es una solución de todo o nada. Para aplicaciones que realmente no necesitan este tipo de durabilidad, el compromiso con el rendimiento resulta caro.
¿Qué pasaría si su solución de base de datos le permitiera escribir datos rápidamente, leer sistemáticamente lo que ha leído, no perder nunca lo que ha escrito, proporcionar aislamiento de transacciones sin sacrificar la velocidad y el rendimiento a una fracción del coste de lo que tiene actualmente en la planta? ¿Le parecería lógico? Yo creo que sí.
¿Y si su solución de base de datos es
- Centrado en la memoria que le permite escribir datos muy rápido.
- Mantiene sus datos en la memoria, lo que le permite leer de la memoria muy rápido, esencialmente dejándote sistemáticamente leer lo que has escrito.
- Ha incorporado funciones de HA que permite tienes copias de los datos en una implementación que tiene en cuenta el bastidor y el centro de datos, de modo que si un nodo se cae antes de que una escritura pueda persistir en el disco, siempre puedes confiar en otros nodos o en otro clúster para recuperar el tiempo perdido.
Las ventajas de esta arquitectura son que
- Las aplicaciones que pueden tolerar algunos casos muy, muy raros de caída de datos pueden seguir funcionando porque hay varios niveles de redundancia incorporados.
- La velocidad y el rendimiento no se sacrifican.
- El coste de la solución es bajo.
¿Podemos garantizar que nunca haya
pérdida de datos en un sistema ya sea
¿Sistemas relacionales o NoSQL?
En realidad, la respuesta es no, porque sólo se puede minimizar el número de errores, no eliminarlos por completo. Aunque muchos argumentarán que la escritura en disco es la forma más segura de proteger los datos, yo, que provengo de este mundo, he visto y reparado varios escenarios en los que se perdieron datos debido a unidades defectuosas, corrupción de datos, trabajos ETL fallidos, etc. Las soluciones existentes no ofrecen necesariamente una garantía 100% de que sus datos estén seguros. La cuestión es que tenemos que considerar las distintas dimensiones implicadas y las compensaciones que tenemos que hacer.
Si opta por la persistencia eventual, es imprescindible asegurarse de que
1) Funciones integradas de alta disponibilidad entre clústeres para compensar la pérdida de datos causada por la imposibilidad de persistir los datos.
2) Varios niveles de redundancia mediante funciones de HA entre clústeres o replicación en centros de datos alternativos.
3) ¿Procesos de control de calidad sólidos que puedan detectar y reparar rápidamente datos erróneos o perdidos?
4) ¿El rendimiento, la velocidad y el coste son primordiales para su empresa?
Couchbase Server le proporciona la funcionalidad de durabilidad tradicional con las características de escalado y ampliación mediante pulsadores, un rendimiento fulgurante a una fracción del coste de las soluciones de bases de datos tradicionales.
Conclusión
La durabilidad es deseable, pero en función de los requisitos de latencia, el perfil de la aplicación y el gasto en que se esté dispuesto a incurrir, podríamos arreglárnoslas con una persistencia eventual. Si su solución de base de datos tiene las siguientes características
- Dispone de redundancia integrada y varios niveles de funciones de alta disponibilidad que minimizan la pérdida de datos.
- Puede proporcionar un rendimiento fulgurante
- A una fracción del coste de la solución que tiene actualmente
Entonces la persistencia eventual es una solución más que viable.
Las posibilidades de que una aplicación sufra una pérdida de datos en un sistema totalmente duradero son casi tantas como las que tendría en un sistema eventualmente persistente, con la sobrecarga adicional de costes, rendimiento y escalabilidad. En ese caso, ¿no está sobrevalorada la durabilidad?
_____________________________________________________________________________________
Este artículo ha sido escrito por Sandhya Krishnamurthy, Ingeniera Superior de Soluciones de Couchbaseproveedor líder de bases de datos NoSql.
Póngase en contacto con el autor en sandhya.krishnamurthy@couchbase.com
- Hable con nosotros en los foros
- Síguenos en https://twitter.com/couchbasedev y https://twitter.com/couchbase
Visite los siguientes sitios para obtener más información sobre los productos Couchbase, descargas gratuitas de productos y formación gratuita
http://www.couchbase.com/nosql-databases/downloads/
http://training.couchbase.com/online
