¿Transacciones en NoSQL?

Question

Estoy buscando en NoSQL alternativas escalables a una base de datos.¿Qué hago si quiero cosas basadas en transacciones que sean sensibles a este tipo de cosas?

Answer 1

En general, las soluciones NoSQL tienen más ligero de peso semántica transaccional que bases de datos relacionales, pero todavía tienen facilidades para operaciones atómicas en algún nivel.

Generalmente, los que hacen la replicación maestro-maestro proporcionan menos en el camino de la coherencia, y más disponibilidad. Así que uno debe elegir la herramienta adecuada para el problema de la derecha.

Muchas transacciones de oferta en la solo documento (o fila etc.) de nivel. Por ejemplo, con MongoDB existe la atomicidad en el documento único - pero los documentos puede ser bastante rica por lo que esta por lo general funciona bastante bien - más información aquí .

Answer 2

Esta es la respuesta más cercana que encontré que se aplicaría a cualquier base de datos NoSQL. Está en una entrada del blog de 2007, de Adam Wiggins de Heroku.com:

  

El viejo ejemplo del uso de una transacción de base de datos para envolver la transferencia de dinero de una cuenta bancaria a otra es toro total. La solución correcta es la de almacenar una lista de eventos del libro mayor (transferencias entre cuentas) y mostrar el saldo actual como una suma de la balanza. Si está programando en un lenguaje funcional (o pensar de esa manera), esto es obvio.

De: http://adam.heroku.com/past/2007 / 12/17 / a_world_without_sql / (Su sitio web es grande para obtener ideas sobre la escalabilidad.)

I interpretado el párrafo anterior como:

1. Crear una base de datos de cuentas de usuario.
2. Crear una cola de mensajes. Sobrenombre que "libro mayor".
3. Añadir en el fondo trabajadores para cumplir con cada solicitud en la cola.

Más información. en colas / trabajadores fondo: http://adam.heroku.com/past/ 2009/4/14 / building_a_queuebacked_feed_reader_part_1 /

El cliente (esto es miembro o cliente) sigue estos pasos para sacar dinero:

1. Presentar una solicitud para sacar dinero.
2. solicitud se envía al servidor.
3. Servidor coloca en una cola. El mensaje es: "Sacar $ 5.000"
Se muestra
4. Cliente: "Por favor, espere como petición se está cumpliendo ..."
5. servidor de máquinas cliente urnas cada 2 segundos preguntando, "¿Se ha cumplido la solicitud?"
6. En el servidor, los trabajadores de fondo están cumpliendo con las peticiones anteriores de otros miembros de primero en entrar, primero en salir de la moda /. Con el tiempo, llegan a la solicitud de su cliente para sacar dinero.
7. Una vez que la solicitud se ha cumplido, el cliente recibe un mensaje con su nuevo equilibrio.

Puede utilizar Heroku.com para crear una pequeña maqueta de forma rápida si se siente cómodo con Node.js o Rubí / Rack.

La idea general parece bastante fácil y mucho mejor que el uso de transacciones horno en la base de datos que hacen que sea súper difícil de escalar.

Renuncia: no he implementado esto en modo alguno todavía. He leído acerca de estas cosas por curiosidad a pesar de que no tengo necesidad práctica para ellos. Sí, @gbn es justo que un RDBMS con transacciones probablemente sería suficiente para las necesidades de Tim y yo. Sin embargo, sería divertido ver qué tan lejos puede tener bases de datos NoSQL con herramientas de código abierto y un how-to sitio web llamado " A Tornado de Razorblades ".

Answer 3

NoSQL abarca un conjunto diverso de herramientas y servicios, incluyendo la clave de valor, documentos , gráfico y de toda la columna almacena. Por lo general, tratan de mejorar la escalabilidad del almacén de datos, por lo general mediante la distribución de procesamiento de datos. Transacciones requieren propiedades de la forma DB realizan las operaciones del usuario ACID . ÁCIDO restringe la forma en la escalabilidad se puede mejorar: la mayor parte de las herramientas NoSQL relajarse criterios de consistencia de los operatioins para obtener tolerancia a fallos y la disponibilidad para escalar, lo que hace que la implementación de transacciones ACID muy duro.

A comúnmente citado razonamiento teórico de almacenes de datos distribuidos es los href="http://en.wikipedia.org/wiki/CAP_theorem" teorema CAP : consistencia, la disponibilidad y la tolerancia de partición no se puede lograr al mismo tiempo. las herramientas de SQL, NoSQL y NewSQL se pueden clasificar de acuerdo a lo que se dan por vencidos; una buena cifra podría ser encontrado aquí .

Un nuevo, conjunto más débil de los requisitos reemplazando el ácido es BASE ( "básicamente avalilable, suave estado, consistencia eventual "). Sin embargo, con el tiempo las herramientas consistentes ( "finalmente todos los accesos a un elemento devolverá el último valor actualizado") son difícilmente aceptable en las aplicaciones transaccionales como la banca. Aquí una buena idea sería utilizar en memoria, columna-orientado y distribuido SQL / bases de datos de ácidos, por ejemplo VoltDB ; Sugiero mirar estas soluciones "NewSQL".

Answer 4

Sólo quería comentar al asesoramiento de transacciones de dinero en este hilo. Las transacciones son algo que realmente desea utilizar con las transferencias de dinero.

El ejemplo dado ¿cómo Que las transferencias es muy agradable y ordenado.

Pero en la vida real la transferencia de dinero puede incluir cuotas o pagos a otras cuentas. Las personas reciben bonificaciones para el uso de ciertas cartas que vienen de otra cuenta o pueden conseguir tasas tomados de su cuenta a otra en un mismo sistema. Los honorarios o pagos pueden variar de transacciones financieras y puede que tenga que seguir el ritmo sistema de contabilidad que muestra crédito y débito de cada transacción, ya que viene.

Esto significa que desea actualizar más de una fila mismo tiempo ya que el crédito en una cuenta puede ser de débito en una o más cuentas. En primer lugar se bloquea las filas de modo que nada puede cambiar antes de la actualización se está garantizando datos escritos es consistente con la transacción.

Es por eso que realmente desea utilizar transacciones. Si algo va mal escrito a una fila puede revertir toda montón de cambios sin los datos de las transacciones financieras que terminan inconsistente.

Answer 5

El problema con una transacción y dos operaciones (por ejemplo, una paga $5,000, la segunda recibe $5,000) es que tiene dos cuentas con la misma prioridad.No puede utilizar una cuenta para confirmar la segunda (o en orden inverso).En este caso, puede garantizar que solo una cuenta será correcta (la que está confirmada), la segunda (la que confirma) puede tener fallas.Veamos por qué puede fallar (al usar un mensaje, el remitente es confirmado por el receptor):

1. Escribe +$5000 a la cuenta del destinatario
2. Si tiene éxito, escriba -$5000 a la cuenta del remitente
3. Si falla, inténtelo de nuevo, cancele o muestre el mensaje.

Garantizará ahorro para el número 1.¿Pero quién garantiza si falla el punto 2?Lo mismo para el orden inverso.

Pero esto es posible para que las implementaciones sean seguras sin transacciones y con NoSQL.Siempre se le permite utilizar una tercera entidad que será confirmada por el remitente y el receptor y garantizará que su operación se realizó:

1. Generar una identificación de transacción única y crear una entidad de transacción
2. Escriba +$5000 a la cuenta del destinatario (con referencia a la identificación de la transacción)
3. Si tiene éxito, establezca el estado de la transacción para enviar
4. Escriba -$5,000 en la cuenta sedned (con referencia a la identificación de la transacción)
5. Si tiene éxito, establezca el estado de la transacción para recibir

Este registro de transacción garantizará que se realizó correctamente el envío/recepción de masajes.Ahora puede verificar cada mensaje por ID de transacción y si tiene estado recibido o completado, lo toma en cuenta para el saldo del usuario.

Answer 6

depende de su base de datos, pero ... Yo diría que, en general, se puede usar 'transacciones optimistas ' para lograr esto, pero me imagine uno debe asegurarse de entender de la aplicación de base de datos atomicidad garantías (por ejemplo, qué tipo de operaciones de escritura y lectura son atómica).

Parece que hay algunos debates sobre el neta sobre las transacciones HBase , si eso ayuda.

Answer 7

Siempre se puede usar un enfoque NoSQL en una base de datos SQL. NoSQL parece utilizar generalmente "almacenes de datos clave / valor": siempre se puede implementar esto en su RDBMS preferidos y por lo tanto mantener las cosas buenas como las transacciones, propiedades ACID, el apoyo de su DBA amigable, etc, mientras que la realización de las prestaciones y flexibilidad beneficios NoSQL , p.ej a través de una tabla como

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

Bono es que se puede añadir campos adicionales para enlazar su contenido en otras tablas relacionales, adecuadamente, sin dejar de mantener su contenido voluminosos en el BLOB principal (o texto si apt) campo.

En lo personal estoy a favor de una representación de texto por lo que no está atado a un idioma para trabajar con los datos, por ejemplo, el uso de Java serializado significa que se puede acceder al contenido de Perl para la presentación de informes, por ejemplo. TEXTO es también más fácil de depurar y por lo general trabajan con como desarrollador.

Answer 8

echar un vistazo a su Scalaris un no db SQL con una fuerte consistencia y las transacciones realizadas.

Answer 9

Es por eso que estoy creando una solución de almacenamiento de documentos NoSQL para poder utilizar las transacciones "reales" en las aplicaciones de la empresa con el poder de enfoque de los datos no estructurados. Echar un vistazo a http://djondb.com y no dude en añadir cualquier característica usted que podría ser útil.

Answer 10

• Nueva almacén de claves-valor FoundationDB
• Antiguo almacén de claves-valor Berkeley DB

sin duda hay otros

Answer 11

Puede implementar transacciones optimistas en la parte superior de la solución NoSQL si admite comparación y conjunto. Escribí un ejemplo y una explicación sobre un página de GitHub cómo hacerlo en MongoDB, pero se puede repetir en cualquier solución NoSQL adecuado.