bases de datos NoSQL son ahí para resolver varias cosas, principalmente:
(zumbido) bigdata => pensar TB, PB, etc ..
Trabajar con Sistemas Distribuidos/datasets => dicen que tienes 42 productos, por lo que 13 de ellos vivirán en el centro de datos de Chicago, 21 en NY y 8 en algún lugar de Japón, pero una vez que consultes los 42 productos, no necesitarás saber dónde están ubicados: NoSQL DB lo hará. Esto también permite a participar mucho más el poder del cerebro (servidores) para resolver problemas computacionales difíciles [no parece que encajaría su caso de uso, pero es una cosa interesante notar]
Partición => tener su DB se distribuirá fácilmente, además de esos 8 productos geniales en Japón, también permite una replicación de datos fácil, 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 mínimas diarias 1000 usuarios
1000 usuarios diarios es un volumen extremadamente bajo, a menos que elija una solución NoSQL que era escrito ayer a las 3 am 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?
soluciones NoSQL sólidas permiten especificar algo que se llama un quorum: "La cantidad de réplicas que deben responder a una solicitud de lectura o de escritura antes de que se considera exitosa". Algunas soluciones también hacen algo llamado hinted handoff: "nodos vecinos toman temporalmente las operaciones de almacenamiento para el nodo fallido". En general, debería poder controlar la disponibilidad según sus requisitos.
(a partir de sus comentarios)
- Estamos planeando expandirse. Y no quiero la base de datos sea una limitació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.
- De lo que he leído, en ninguna base de datos SQL que no tiene que pensar en el esquema de una gran cantidad
En mi experiencia, si construyo un sistema que es bueno, lo SIEMPRE hay que pensar en el esquema. Las bases de datos NoSQL le permiten ser un poco más flexible con los datos que persiste, pero eso no significa que deba pensar en el esquema menos. Piense en la indexación de los datos, por ejemplo, o sharding por encima de varios clústeres, o incluso los 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 sea 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 => people feel MUCHO más cómodo con SQL. Por esa razón, por ejemplo, Cassandra chicos, lanzó CQL en 0.8, que es un subconjunto muy limitado de SQL. Términos como maintenance también deben estar hombro a 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 tienen Expertise, pero tendrías que pagar por eso.
Su principal Pregunta
- He leído en un blog que la base de datos NoSQL no son tan buenos para el dinero en línea de transacción es decir,donde la integridad de datos es la más alta importancia. (Mi producto tiene las transacciones de dinero en línea)
Sin realmente saber cuál es su producto, es difícil decir si una base de datos NoSQL sería/no sería un buen ajuste. Si el objetivo principal del producto es "Transacción de dinero en línea", entonces sugeriría contra 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 bases de datos escritas en Erlang (por ejemplo, Riak, CouchDB, etc.), ya que Erlang como lenguaje ya resuelve con éxito la mayor parte de las cosas distribuidas durante décadas.
Se recomienda realizar transacciones en tales sistemas. Puede emular transacciones con nosql pero inventará la rueda. – varela
@varela: ¿Puede explicar su punto, no puedo entender lo que tiene que decir exactamente? – Akamad007
el mayor problema es la concurrencia. Si quiere, por ejemplo, financiar dinero, entonces no puede simplemente 1) verificar la cantidad disponible 2) substruir si el usuario tiene dinero. Primero debe bloquear la cuenta de usuario de los cambios con una bandera especial y luego realizar operaciones. Con las bases de datos SQL tienes formas estándar de hacer esto. – varela