¿Hasta dónde puede llegar realmente con una consistencia "eventual" y sin transacciones (también conocido como SimpleDB)?

Question

Realmente quiero usar SimpleDB, pero me preocupa que sin bloqueos y transacciones reales todo el sistema tenga fallas fatales. Entiendo que para aplicaciones de alta lectura/baja escritura tiene sentido, ya que eventualmente el sistema se vuelve consistente, pero ¿qué pasa con ese tiempo intermedio? Parece que la consulta correcta en un DB inconsistente perpetuaría los estragos en toda la base de datos de una manera que es muy difícil de rastrear. Espero que solo sea una verruga preocupante ...

Answer 1

Esta es la batalla bastante clásica entre la consistencia y la escalabilidad y, hasta cierto punto, la disponibilidad. Algunos datos no siempre necesitan ser tan consistentes. Por ejemplo, mira digg.com y el número de diggs en una historia. Existe una buena posibilidad de que el valor se duplique en el registro "digg" en lugar de forzar al DB a unirse en la tabla "user_digg". ¿Importa si ese número no es perfectamente exacto? Probablemente no. Entonces, usar algo como SimpleDB podría ser una buena opción. Sin embargo, si está escribiendo un sistema bancario, probablemente debería valorar la coherencia por encima de todo. :)

A menos que sepa desde el primer día que debe lidiar con una escala masiva, me limitaría a los sistemas simples más convencionales, como RDBMS. Si está trabajando en un lugar con un modelo comercial razonable, con suerte verá un gran aumento en los ingresos si hay un gran aumento en el tráfico. Entonces puede usar ese dinero para ayudar a resolver los problemas de escala. Escalar es difícil y escalar es difícil de predecir. La mayoría de los problemas de escala que te duelen serán los que nunca esperas.

Prefiero ponerme a trabajar en un sitio y pasar unas semanas arreglando problemas de báscula cuando el tráfico aumenta y luego paso tanto tiempo preocupándome por la escala que nunca llegamos a la producción porque nos quedamos sin dinero. :)

Answer 2

Suponiendo que estás hablando de this SimpleDB, no estás siendo un problemático; hay razones reales para no usarlo como un DBMS real.

Las propiedades que obtiene del soporte de transacciones en un DBMS se pueden abreviar con el acrónimo "A.C.I.D.": atomicidad, consistencia, aislamiento y durabilidad. El A y el D tienen principalmente que ver con bloqueos del sistema, y ​​el C y el I tienen que ver con el funcionamiento normal. Son cosas que las personas totalmente dan por sentado cuando trabajan con bases de datos comerciales, por lo que si trabajas con una base de datos que no tiene uno o más de ellos, es posible que tengas muchas sorpresas desagradables.

Atomicity: Cualquier transacción se completará completamente o no se realizará (es decir, se confirmará o abortará limpiamente). Esto se aplica a declaraciones individuales (como "tabla de ACTUALIZACIÓN ...") así como a transacciones más largas y complicadas. Si no tiene esto, todo lo que sale mal (como el disco que se llena, la computadora se cuelga, etc.) puede dejar algo a medio hacer. En otras palabras, nunca puede confiar en que el SGBD realmente haga las cosas que le dice, ya que cualquier número de problemas del mundo real puede interponerse, e incluso una simple declaración de ACTUALIZACIÓN podría completarse parcialmente.

Coherencia: Siempre se aplicarán las reglas que haya establecido sobre la base de datos. Por ejemplo, si tiene una regla que dice que A siempre es igual a B, entonces nada de lo que haga el sistema de base de datos puede violar esa regla: fallará cualquier operación que lo intente. Esto no es tan importante si todo tu código es perfecto ... pero realmente, ¿cuándo es ese el caso? Además, si se está perdiendo esta red de seguridad, las cosas se ponen realmente asqueroso cuando se pierde ...

Aislamiento: Cualquier acción tomada en la base de datos se ejecutará como si ocurrieron en serie (uno a la vez), incluso si en realidad están sucediendo simultáneamente (intercalados entre sí).Si más de un usuario va a llegar a esta base de datos al mismo tiempo, y usted no tiene esto, entonces las cosas que ni siquiera puede soñar saldrán mal; incluso las declaraciones atómicas pueden interactuar entre sí de formas imprevistas y arruinar las cosas.

Durabilidad: Si pierde potencia o el programa falla, ¿qué ocurre con las transacciones de la base de datos que estaban en progreso? Si tiene durabilidad, la respuesta es "nada, todos están seguros". Las bases de datos hacen esto usando algo llamado "Deshacer/Rehacer el registro", donde cada pequeña cosa que haces a la base de datos se registra primero (generalmente en un disco separado por seguridad) de manera que puedes reconstruir el estado actual después de una falla. Sin eso, las otras propiedades anteriores son inútiles, porque nunca puedes estar 100% seguro de que las cosas se mantendrán consistentes después de un bloqueo.

¿Alguna de estas cosas le importa? La respuesta tiene todo que ver con los tipos de transacciones que está haciendo y las garantías que desea en una situación de falla. Puede haber casos (como una base de datos de solo lectura) donde no los necesite, pero tan pronto como empiece a hacer algo que no sea trivial y ocurra algo malo, deseará tenerlos. Quizás esté bien que vuelvas a hacer una copia de seguridad en cualquier momento que ocurra algo inesperado, pero creo que no es así.

También tenga en cuenta que abandonar todas estas protecciones no hace que su base de datos funcione mejor; de hecho, es probablemente lo opuesto. Eso es porque el software DBMS del mundo real también tiene un montón de código para optimizar el rendimiento de la consulta. Por lo tanto, si escribe una consulta que une 6 tablas en SimpleDB, no suponga que descubrirá la forma óptima de ejecutar esa consulta; es posible que termine esperando horas para que se complete, cuando un DBMS comercial podría usar una indexado hash join y consíguelo en .5 segundos. Hay un trillón de pequeños trucos que puede hacer para optimizar el rendimiento de las consultas, y créame, realmente los extrañará cuando se hayan ido.

Nada de esto se entiende como un knock en SimpleDB; tómalo desde el author of the software: "Aunque es una gran herramienta de enseñanza, no puedo imaginar que alguien quiera usarlo para cualquier otra cosa".