{"id":2345,"date":"2016-07-22T02:10:45","date_gmt":"2016-07-22T02:10:44","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2345"},"modified":"2024-09-12T01:55:02","modified_gmt":"2024-09-12T08:55:02","slug":"immediate-or-eventual-persistence","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/immediate-or-eventual-persistence\/","title":{"rendered":"Elegir el ajuste adecuado: \u00bfpersistencia inmediata o eventual?"},"content":{"rendered":"

Elegir el ajuste adecuado: \u00bfpersistencia inmediata o eventual?<\/h2>\n

Con la aparici\u00f3n de las bases de datos NoSql, la \"persistencia eventual\" es una opci\u00f3n disponible para acelerar las lecturas y escrituras en la base de datos. La persistencia, tambi\u00e9n conocida popularmente como durabilidad en disco, ha sido reconocida y apreciada durante mucho tiempo como una de las caracter\u00edsticas deseables de un sistema de base de datos compatible con ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad).<\/p>\n

Cuando o\u00ed hablar por primera vez de la persistencia eventual, me sacudi\u00f3 mi fuerte mentalidad de base de datos relacional, en la que la durabilidad es como una creencia religiosa.<\/p>\n

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\u00a0las lecturas y escrituras en disco son lentas.\u00a0<\/strong>Las ventajas de la persistencia eventual a veces superan con creces a las de la persistencia inmediata.<\/p>\n

\u00a0Es hora de exorcizar el miedo a la persistencia eventual de los usuarios de bases de datos.<\/p>\n

Inmediato y eventual<\/h2>\n

persistencia\u00a0-\u00a0<\/em>Entonces, \u00bfcu\u00e1l es el<\/h2>\n

\u00bfDiferencia?<\/h2>\n

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\u00e9 del sistema de archivos. La escritura real en el disco se pone en cola y ocurre de forma as\u00edncrona.<\/p>\n

Persistencia inmediata significa que la escritura en el disco es sincr\u00f3nica y que la escritura se reconoce s\u00f3lo despu\u00e9s de que los datos se hayan escrito en el disco.<\/p>\n

Pocos segundos despu\u00e9s de que esto se mencione a los 3NFers (mi nombre para los usuarios de bases de datos relacionales ), la reuni\u00f3n termina muy r\u00e1pidamente o las soluciones de bases de datos que proporcionan persistencia eventual se descartan como soluciones inviables. El reconocimiento de las escrituras despu\u00e9s de que persistan en el disco ha sido la \u00fanica manera.<\/p>\n

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.<\/strong><\/p>\n

Factores a tener en cuenta<\/h2>\n

elegir la persistencia adecuada<\/h2>\n

opci\u00f3n<\/h2>\n

Creo que en muchos, muchos escenarios podemos prescindir de la persistencia eventual en favor del rendimiento y el coste. Examin\u00e9moslo.<\/p>\n

Antes de profundizar en este tema, perm\u00edtanme afirmar categ\u00f3ricamente que la durabilidad es una gran caracter\u00edstica, pero a costa del rendimiento y de mayores CAPEX\/OPEX. Mayor CAPEX\/OPEX porque ser\u00e1 necesario invertir en un almacenamiento m\u00e1s r\u00e1pido para ofrecer un mejor rendimiento. Si puede arregl\u00e1rselas porque tiene otras caracter\u00edsticas de redundancia integradas en su producto y el rendimiento es un factor muy importante, entonces debe considerar la persistencia eventual como una posible soluci\u00f3n.<\/em><\/strong><\/p>\n

Volvamos a lo b\u00e1sico por un segundo y examinemos lo que un usuario de una aplicaci\u00f3n realmente quiere de su interacci\u00f3n con una base de datos<\/p>\n

    \n
  1. Escribir datos r\u00e1pidamente<\/li>\n
  2. Lea los datos que he escrito cada vez con respuestas coherentes<\/li>\n
  3. No perder nunca lo que he escrito. Lo que esto significa en realidad es minimizar la p\u00e9rdida de datos. F\u00edjate en que utilizo la palabra minimizar porque hay varios escenarios en los que incluso la \"f\u00e9rrea\" garant\u00eda de las bases de datos RDBMS puede venirse abajo.<\/li>\n<\/ol>\n

    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\u00edan provocar la p\u00e9rdida de oportunidades causada por resultados incoherentes. Lo que quiero decir es que es una soluci\u00f3n de todo o nada. Para aplicaciones que realmente no necesitan este tipo de durabilidad, el compromiso con el rendimiento resulta caro.<\/p>\n

    \u00bfQu\u00e9 pasar\u00eda si su soluci\u00f3n de base de datos le permitiera escribir datos r\u00e1pidamente, leer sistem\u00e1ticamente lo que ha le\u00eddo, no perder nunca lo que ha escrito, proporcionar aislamiento de transacciones sin sacrificar la velocidad y el rendimiento a una fracci\u00f3n del coste de lo que tiene actualmente en la planta? \u00bfLe parecer\u00eda l\u00f3gico? Yo creo que s\u00ed.<\/p>\n

    \u00bfY si su soluci\u00f3n de base de datos es<\/p>\n

      \n
    1. Centrado en la memoria que le permite\u00a0escribir datos muy r\u00e1pido<\/strong>.<\/li>\n
    2. Mantiene sus datos en la memoria, lo que le permite\u00a0leer de la memoria muy r\u00e1pido,\u00a0<\/strong>esencialmente dej\u00e1ndote\u00a0sistem\u00e1ticamente<\/strong>\u00a0leer lo que has escrito.<\/li>\n
    3. Ha incorporado funciones de HA<\/strong>\u00a0que\u00a0permite<\/strong>\u00a0tienes copias de los datos en una implementaci\u00f3n 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\u00faster para recuperar el tiempo perdido.<\/li>\n<\/ol>\n

      \u00a0Las ventajas de esta arquitectura son que<\/p>\n

        \n
      1. Las aplicaciones que pueden tolerar algunos casos muy, muy raros de ca\u00edda de datos pueden seguir funcionando porque hay varios niveles de redundancia incorporados.<\/li>\n
      2. La velocidad y el rendimiento no se sacrifican.<\/li>\n
      3. El coste de la soluci\u00f3n es bajo.<\/li>\n<\/ol>\n

        <\/p>\n

        \u00bfPodemos garantizar que nunca haya<\/h2>\n

        p\u00e9rdida de datos en un sistema ya sea<\/h2>\n

        \u00bfSistemas relacionales o NoSQL?<\/h2>\n

        En realidad, la respuesta es no, porque s\u00f3lo se puede minimizar el n\u00famero de errores, no eliminarlos por completo. Aunque muchos argumentar\u00e1n que la escritura en disco es la forma m\u00e1s 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\u00f3n de datos, trabajos ETL fallidos, etc. Las soluciones existentes no ofrecen necesariamente una garant\u00eda 100% de que sus datos est\u00e9n seguros. La cuesti\u00f3n es que tenemos que considerar las distintas dimensiones implicadas y las compensaciones que tenemos que hacer.<\/p>\n

        Si opta por la persistencia eventual, es imprescindible asegurarse de que<\/p>\n

        1) Funciones integradas de alta disponibilidad entre cl\u00fasteres para compensar la p\u00e9rdida de datos causada por la imposibilidad de persistir los datos.<\/p>\n

        2) Varios niveles de redundancia mediante funciones de HA entre cl\u00fasteres o replicaci\u00f3n en centros de datos alternativos.<\/p>\n

        3) \u00bfProcesos de control de calidad s\u00f3lidos que puedan detectar y reparar r\u00e1pidamente datos err\u00f3neos o perdidos?<\/p>\n

        4) \u00bfEl rendimiento, la velocidad y el coste son primordiales para su empresa?<\/p>\n

        Couchbase Server le proporciona la funcionalidad de durabilidad tradicional con las caracter\u00edsticas de escalado y ampliaci\u00f3n mediante pulsadores, un rendimiento fulgurante a una fracci\u00f3n del coste de las soluciones de bases de datos tradicionales.<\/strong><\/p>\n

        Conclusi\u00f3n<\/h2>\n

        La durabilidad es deseable, pero en funci\u00f3n de los requisitos de latencia, el perfil de la aplicaci\u00f3n y el gasto en que se est\u00e9 dispuesto a incurrir, podr\u00edamos arregl\u00e1rnoslas con una persistencia eventual. Si su soluci\u00f3n de base de datos tiene las siguientes caracter\u00edsticas<\/p>\n

          \n
        1. Dispone de redundancia integrada y varios niveles de funciones de alta disponibilidad que minimizan la p\u00e9rdida de datos.<\/li>\n
        2. Puede proporcionar un rendimiento fulgurante<\/li>\n
        3. A una fracci\u00f3n del coste de la soluci\u00f3n que tiene actualmente<\/li>\n<\/ol>\n

          Entonces la persistencia eventual es una soluci\u00f3n m\u00e1s que viable.<\/p>\n

          Las posibilidades de que una aplicaci\u00f3n sufra una p\u00e9rdida de datos en un sistema totalmente duradero son casi tantas como las que tendr\u00eda en un sistema eventualmente persistente, con la sobrecarga adicional de costes, rendimiento y escalabilidad. En ese caso, \u00bfno est\u00e1 sobrevalorada la durabilidad?<\/p>\n

          _____________________________________________________________________________________<\/u><\/p>\n

          Este art\u00edculo ha sido escrito por Sandhya Krishnamurthy, Ingeniera Superior de Soluciones de\u00a0Couchbase<\/strong>proveedor l\u00edder de bases de datos NoSql.<\/p>\n

          P\u00f3ngase en contacto con el autor en\u00a0sandhya.krishnamurthy@couchbase.com<\/a><\/p>\n