La base de datos nosql es buena para la gestión de transacciones en línea de dinero

Estoy planeando usar la base de datos nosql como back-end para mi producto web. Tengo algunas dudas muy básicas.

1) He leído en un blog que la base de datos Nosql no es tan buena para transacciones de dinero en línea, es decir, donde la integridad de los datos es la más importante. (Mi producto tiene transacciones de dinero en línea)

2) Habrá alrededor de un mínimo diario de 1000 usuarios.

3) ¿La disponibilidad será un problema?

¿Puede indicar más pros y contras relacionados con la base de datos Nosql? Estoy planeando usar MongoDb. ¿Puede esto satisfacer mis consultas anteriores?

¿Está clara mi pregunta o necesito dar más información? Por favor comente y haré los cambios necesarios.

Las bases de datos NoSQL están ahí para resolver varias cosas, principalmente:

  • (zumbido) BigData => piensa TB, PB, etc.

  • Trabajar con sistemas distribuidos / datasets => dice que tiene 42 productos, por lo que 13 de ellos vivirán en el centro de datos de Chicago, 21 en NY y otros 8 en algún lugar de Japón, pero una vez que consulte los 42 productos, no necesitaría saber donde se encuentran: NoSQL DB lo hará. Esto también permite contratar mucha más potencia cerebral (servidores) para resolver problemas informáticos duros [no parece que se ajuste a su caso de uso, pero es algo interesante de notar]

  • Partitioning => tener tu DB distribuida fácilmente, además de esos 8 geniales productos en Japón, también permite una fácil replicación de datos, por lo que esos 42 productos se replicarán con un factor de 3, por ejemplo, lo que significaría que DB tendría 3 copias para cada producto Por lo tanto, si algo falla, no hay problema => aquí hay una réplica disponible. Aquí es donde realmente brillan las bases de datos NoSQL vs. RDBMS. Concedido, puedes fragmentar, particionar y agrupar Oracle / MySQL / PostgreSQL / etc. PERO es un proceso de varias magnitudes más complicado y generalmente un dolor de cabeza de mantenimiento para la mayoría de las personas que emplearías.

(a sus preguntas)

  • Habrá alrededor de un mínimo diario de 1000 usuarios

    1000 usuarios diarios son un volumen extremadamente bajo, a menos que elijas una solución NoSQL que se escribió ayer a las 3 a. M. Como un concepto de prueba, no debería haber preocupaciones aquí. Pero si tiene éxito y tendrá 100,000,000 de usuarios en un par de meses, NoSQL sería más simple de escalar.

  • ¿La disponibilidad será un problema?

    Las soluciones sólidas de NoSQL le permiten especificar algo que se denomina quorum : ” La cantidad de réplicas que debe responder a una solicitud de lectura o escritura antes de que se considere exitosa “. Algunas soluciones también hacen algo llamado hinted handoff : ” los nodos vecinos toman temporalmente las operaciones de almacenamiento para el nodo fallido “. En general, debería poder controlar la disponibilidad según sus requisitos.

(de tus comentarios)

  • Estamos planeando expandirnos. Y no quiero que la base de datos sea una restricción

Expanding es un término muy relativo. “La industria financiera está bastante expandida”, y todavía usan principalmente RDBMS para las operaciones diarias. Facebook usa MySQL. Los bancos principales, para los que trabajé, utilizan Oracle / MySQL / PostgreSQL / DB2 / etc. y solo algunos de ellos usan NoSQL, pero NO para datos que requieren un 100% de consistencia todo el tiempo. Incluso Facebook usa Cassandra solo para cosas como “búsqueda en la bandeja de entrada”. Pero si por expansión quiere decir más datos y más usuarios (solicitudes, conexiones, etc.), NoSQL será mucho más fácil de escalar. Nuevamente, eso no significa que no pueda escalar RDBMS, es simplemente más tedioso / complicado.

  • Por lo que he leído, en ninguna base de datos SQL no tenemos que pensar mucho en el esquema

En mi experiencia, si construyo un sistema que sea bueno, SIEMPRE tengo que pensar en el esquema. Las bases de datos NoSQL te permiten ser un poco más flexible con los datos que persistes, pero eso no significa que debas pensar menos en el esquema. Piense en indexar los datos, por ejemplo, o fragmentarlos en múltiples clústeres, o incluso contratos / interfaces que puede exponer a los clientes, etc.

  • El mantenimiento requerido para la base de datos NoSQL es muy inferior

No diría que esto es cierto en general, a menos que estemos hablando de BigData. Tome PostgreSQL por ejemplo. Es una pieza de software extremadamente impresionante, que es bastante fácil de trabajar y mantener. Otra ventaja para RDBMS world => las personas se sienten MUCHO más cómodas con SQL. Por esa razón, por ejemplo, los chicos de Cassandra lanzaron CQL en 0.8, que es un subconjunto muy limitado de SQL. Términos como el maintenance también deben estar hombro con hombro con términos como Talent , Knowledge , Expertise . Dado que si usas Cassandra, por ejemplo, esa chica es muy “de alto mantenimiento”, pero no para los chicos de DataStax que sí tienen Expertise , pero tendrías que pagar por eso.

Tu pregunta principal

  • He leído en un blog que la base de datos NoSQL no es tan buena para transacciones de dinero en línea, es decir, donde la integridad de los datos es la más importante. (Mi producto tiene transacciones de dinero en línea)

Sin saber realmente cuál es su producto, es difícil decir si una base de datos NoSQL sería / no sería una buena opción. Si el objective principal del producto es “Transacción de dinero en línea”, sugeriría una base de datos NoSQL (al menos hoy en el año de 2011). Si “Transacción de dinero en línea” es solo uno de los requisitos, pero no “el núcleo” de su producto, dependiendo de qué es “el núcleo”, definitivamente puede probar la base de datos NoSQL y, por ejemplo, usar un servicio externo para procesar (por ejemplo, Google Checkout, etc.) sus transacciones con una consistencia garantizada.

Como nota técnica, si el problema que está tratando de resolver se ve beneficiado por la distribución, recomendaría las bases de datos escritas en Erlang (por ejemplo, Riak, CouchDB, etc.), ya que Erlang como idioma ya resuelve con éxito la mayoría de las distribuciones cosas por décadas.

MarkLogic es una base de datos NoSQL con transacciones ACID que se usa para administrar tanto la moneda virtual en los juegos como los intercambios bancarios de la vida real.