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

Question

Realmente quiero usar SimpleDB, pero me preocupa que sin un bloqueo 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 una base de datos inconsistente perpetuaría el caos en toda la base de datos de una manera que es muy difícil de rastrear. Espero que solo sea una verruga de preocupación ...

Answer 1

Esta es la batalla bastante clásica entre consistencia y escalabilidad y, en cierta medida, disponibilidad. Algunos datos no siempre necesitan ser tan consistentes. Por ejemplo, mire digg.com y el número de diggs contra una historia. Hay una buena posibilidad de que el valor esté duplicado en el " digg " registrar en lugar de obligar a la base de datos a unir contra el "usuario_digg" mesa. ¿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 día 1 que tiene que lidiar con una escala masiva, me apegaría a sistemas simples más convencionales como RDBMS. Si está trabajando en algún lugar con un modelo comercial razonable, es de esperar que vea un gran aumento en los ingresos si hay un gran aumento en el tráfico. Luego puede usar ese dinero para ayudar a resolver los problemas de escala. El escalado es difícil y el escalado es difícil de predecir. La mayoría de los problemas de escala que te lastiman serán los que nunca esperas.

Preferiría poner en marcha un sitio y pasar algunas semanas arreglando problemas de escala cuando el tráfico aumenta, luego pasar tanto tiempo preocupándome por la escala que nunca llegamos a producción porque se nos acaba el dinero. :)

Answer 2

Suponiendo que está hablando de este SimpleDB , usted no estás siendo un preocupado; hay razones reales para no usarlo como un DBMS del mundo 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. La A y la D tienen que ver principalmente con fallas del sistema, y ??la C y yo tenemos que ver con la operación regular. Son todas las cosas que las personas dan por sentado al trabajar con bases de datos comerciales, por lo que si trabajas con una base de datos que no tiene una o más de ellas, es posible que te encuentres con muchas sorpresas desagradables.

Atomicidad : cualquier transacción se completará completamente o no se completará (es decir, se confirmará o cancelará limpiamente). Esto se aplica a las declaraciones individuales (como la tabla "ACTUALIZAR ...") así como a las transacciones más largas y complicadas. Si no tiene esto, cualquier cosa que salga mal (como que el disco se llene, la computadora se bloquee, etc.) podría dejar algo a medio hacer. En otras palabras, nunca puede confiar en que el DBMS realmente haga las cosas que le dice, porque cualquier cantidad de problemas del mundo real puede interponerse, e incluso una simple declaración de ACTUALIZACIÓN podría completarse parcialmente.

Consistencia : 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, nada de lo que alguien haga al sistema de la base de datos puede romper esa regla: fallará cualquier operación que intente. Esto no es tan importante si todo su código es perfecto ... pero realmente, ¿cuándo es ese el caso? Además, si te estás perdiendo esta red de seguridad, las cosas se ponen realmente desagradables cuando pierdes ...

Aislamiento : cualquier acción tomada en la base de datos se ejecutará como si ocurriera en serie (una a la vez), incluso si en realidad suceden simultáneamente (intercaladas entre sí). Si más de un usuario va a acceder a esta base de datos al mismo tiempo, y no tiene esto, entonces las cosas que ni siquiera puede imaginar saldrán mal; incluso las declaraciones atómicas pueden interactuar entre sí de manera imprevista y arruinar las cosas.

Durabilidad : si pierde energía o el software falla, ¿qué sucede con las transacciones de la base de datos que estaban en progreso? Si tiene durabilidad, la respuesta es "nada; todos son seguros". Las bases de datos hacen esto usando algo llamado '' Deshacer / Rehacer registro '', donde cada pequeña cosa que haces a la base de datos se registra primero (generalmente en un disco separado por seguridad) de tal manera que puedas 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 te importa? La respuesta tiene mucho que ver con los tipos de transacciones que está haciendo y lo que garantiza que desea en una situación de falla. Es posible que haya casos (como una base de datos de solo lectura) en los que no los necesite, pero tan pronto como comience a hacer algo no trivial y ocurra algo malo, deseará tenerlos. Tal vez esté bien que vuelva a una copia de seguridad cada vez que ocurra algo inesperado, pero supongo que no es así.

También tenga en cuenta que la eliminación de todas estas protecciones no garantiza que su base de datos funcione mejor; de hecho, es probablemente lo contrario. Esto se debe a que el software DBMS del mundo real también tiene toneladas de código para optimizar el rendimiento de las consultas. Entonces, si escribe una consulta que une 6 tablas en SimpleDB, no asuma que descubrirá la forma óptima de ejecutar esa consulta; podría terminar esperando horas para que se complete, cuando un DBMS comercial podría usar un hash indexado unirse y obtenerlo en .5 segundos. Hay un trillón de pequeños trucos