replica - sharding mongodb español
¿Hay una alternativa confiable(servidor único) MongoDB? (11)
Me gusta la idea de las bases de datos de documentos, especialmente MongoDB. Permite un desarrollo más rápido ya que no tenemos que ajustar el esquema de la base de datos. Sin embargo, MongoDB no es compatible con transacciones de documentos múltiples y no garantiza que las modificaciones se escriban en el disco de inmediato, como las bases de datos normales (sé que puede hacer que el intervalo de tiempo sea bastante pequeño, pero todavía no es garantía).
La mayoría de nuestros proyectos no son tan grandes que necesitan cosas como entornos de servidores múltiples. Así que tenlo en cuenta. ¿Hay alguna base de datos de documentos similar a MongoDB de servidor único que admita transacciones de múltiples documentos y un enjuague confiable en el disco?
Berkeley DB es uno que usamos. Es compatible con ACID. Tiene transacciones, pero en cuanto a su término "multidocumento" se aplica, no estoy del todo seguro. Imagino que siempre que cada base de datos (es decir, documento individual) comparta el mismo entorno BDB (es decir, donde se almacenan las transacciones), entonces tal vez eso obtenga lo que desea. Sin embargo, BDB tiene otras compensaciones. Con total durabilidad y alta concurrencia, las confirmaciones son bastante lentas.
No es necesario ajustar los esquemas en los almacenes de datos de documentos, pero eso no significa que no necesite algún tipo de esquema ya que probablemente quiera hacer algo significativo con sus datos. Parece que le gustaría una base de datos ACID. Si tiene datos relacionales y necesita transacciones con esos datos, parece que necesita una base de datos relacional.
Con las bases de datos "NoSQL" como Mongo, usted está renunciando a ACID por características como muchas réplicas editables, fragmentación y acceso rápido a datos de documentos. Parece que no te beneficias de eso, ¿por qué tomas la compensación? Mucha gente ha estado haciendo enfoques híbridos últimamente con PostgreSQL al almacenar documentos en una tabla relacional como blobs de JSON. Con esto, puede tener la ventaja de almacenar sus datos como columnas no estrictamente estructuradas donde no es necesario.
Entonces, si tiene varios documentos que necesita para ser transaccional en la actualización, puede anotar las claves, y tener una columna de "documento" o algo donde simplemente se trata de una burbuja de JSON donde la serializa y la deserializa. Esto no critica a Mongo u otras tiendas de documentos como una base de datos, pero simplemente no es realmente una buena opción para los datos multidocumento transaccionales. MarkLogic Creo que también hace ACID sobre múltiples documentos.
Creo que mucha gente encuentra atractivo con mongodb debido a la ausencia de esquema, pero creo que al final se vuelven un poco tratando de meterle un modelo relacional. Entonces, como siempre, la elección de DB depende de cómo sean sus datos.
Personalmente, creo que realmente necesita verificar cuáles son sus requisitos.
Debido a la dinámica de cómo funciona el sistema operativo de su servidor, es complicado decir que todo "inmediatamente" va al disco, incluso cuando se lo indique. ciertamente sé que los técnicos de ACID como SQL son vulnerables a la corrupción parcial a través de negocios pendientes y la pérdida de operaciones dentro de una ventana específica cuando un solo servidor se cae, desafortunadamente este es uno de los problemas de usar un único servidor; no tienes más remedio que aceptarlo.
Debo señalar que una transacción no garantiza que su servidor reciba toda la información antes de fallar ( http://en.wikipedia.org/wiki/Database_transaction ), quiero decir, ¿qué ocurre si el servidor muere a mitad de camino a través de una transacción?
Puede realizar una reversión segura en función de las restricciones de las transacciones, pero pocas bases de datos proporcionarán la capacidad de continuar reproduciendo la transacción a menos que ya hayan recibido todos los datos necesarios (que normalmente no es el caso), momento en el que los datos podrían incluso ser rancio de todos modos.
De hecho, debido al peso de algunas transacciones y la cantidad de consultas realizadas dentro de ellas, creo que puede obtener una mayor ventana de pérdida operativa utilizando las transacciones de la que podría tener en la ventana de escritura de 60 ms en MongoDB a veces. Pero, por supuesto, eso depende del abuso, sin embargo, al igual que los procedimientos almacenados, este abuso es un lugar común.
Las transacciones brillan en las eliminaciones en cascada y escenarios típicos como transferir dinero en una cuenta bancaria, sin embargo, las eliminaciones en cascada normalmente se realizan mejor (como lo hacen la mayoría de los sitios) mediante un cronjob con la aplicación marcando la fila como eliminada (para evitar la reversión de una transacción los datos eliminados vuelven al usuario); De esta forma, puede hacer muchas cosas para garantizar la coherencia que no puede hacer en tiempo real mientras el usuario utiliza su aplicación.
Entonces, realmente debería preguntarse por qué necesita una tecnología y qué tendrá éxito al hacerla, la brevedad de su pregunta me dice que no está completamente seguro de sus requisitos.
Pruébalo para: http://www.orientdb.org/
"OrientDB tiene la flexibilidad de las bases de datos de documentos y la potencia de las bases de datos Graph para gestionar las relaciones. Puede funcionar en modo sin esquema, en esquema completo o en una combinación de ambas. Admite características avanzadas tales como transacciones ACID, índices rápidos, nativos y consultas SQL. Importa y exporta documentos en JSON. OrientDB usa un nuevo algoritmo de indexación llamado MVRB-Tree, derivado del Árbol Rojo-Negro y del Árbol B + con beneficios de ambos: inserción rápida y búsqueda ultra rápida ".
Si yo fuera tú, echaría un vistazo de cerca a Solr. La capa de datos subyacente (Lucene) es, con mucho, la más madura de las bases de datos NoSQL, y Solr hace que la instalación, configuración e integración de una tienda lucene de un solo servidor sea trivial.
En respuesta a su pregunta, admite transacciones delineadas por el usuario. La naturaleza de lectura optimizada de Lucene puede hacer que sea inadecuado para muchas aplicaciones, pero la mayoría de ellas son adecuadas para Solr / Lucene + [SQL, Cassandra, CouchDB, RDF] dependiendo de los requisitos.
Personalmente tiendo a comenzar con Solr + SQL o Solr + RDF, pero conozco a algunas personas que adoran todo el estilo NodeJS + CouchDB, y estoy convencido del valor de la flexibilidad que ofrece.
La conclusión es que hay suficientes extensiones SQL y NoSQL que se preocupan por la integridad de los datos para satisfacer cualquier requisito que usted tenga sin tener que comprometerlo a usted o a los datos de sus usuarios.
Sugeriría que mires a Couchbase.
Couchbase puede ejecutarse en un solo servidor y puede agregar nodos más adelante si lo desea.
Couchbase ha integrado memcached para que tenga un rápido almacenamiento en caché de datos comunes, con un método confiable para escribir actualizaciones en el disco.
También tienen un nuevo lenguaje de consulta (en desarrollo pero puede usarlo ahora) llamado NQL ("Nickel") que le proporciona acceso similar a SQL, si eso es importante para usted.
Con la replicación de centros de datos cruzados, puede mantener dos bases de datos en diferentes máquinas o centros de datos sincronizados, lo que es bueno para tener una copia de seguridad externa. Esto también le permite agregar búsqueda elástica si desea tener un motor de búsqueda de texto completo para esos tipos de consultas.
En resumen, Couchbase es una solución bastante completa, de código abierto y tiene una arquitectura inteligente (en mi opinión) para abordar los problemas típicos de las bases de datos distribuidas (por ejemplo, cada documento es "propiedad" de un nodo dado, por lo que todos los cambios van a ese nodo, y luego las actualizaciones se replican; creo que esto es mejor que decir Riak, donde puede hacer que las actualizaciones vayan a dos nodos y luego tengan que reconciliarse).
Puede usar Couchbase en un nodo para ejecutar la base de datos para muchos proyectos separando los proyectos en diferentes segmentos.
Tengo algo de experiencia con CouchDB y ArangoDB que puedo compartir:
Puede ejecutar CouchDB con durabilidad activada (delayed_commits = false) para que también sincronice sus datos en el disco. Sin embargo, esta es una configuración global, por lo que afecta a todas las escrituras. AFAIK no puede establecerlo en un nivel por colección (el término CouchDB para "colección" sería "base de datos").
Con respecto a las operaciones de varios documentos: CouchDB tiene MVCC, por lo que leer múltiples documentos de la misma base de datos proporciona un resultado consistente incluso frente a escritores paralelos. Escribir documentos múltiples en la misma base de datos también se puede hacer transaccional para casos especiales, por ejemplo, cuando se usa la API de documentos masivos. Pero no hay forma de ejecutar operaciones entre bases de datos en CouchDB. Esto simplemente no es intencionado.
En ArangoDB: en ArangoDB puedes activar la sincronización inmediata en el disco en un nivel por colección: puedes activarlo para colecciones en las que no puedes tolerar ninguna pérdida de datos. Puedes desactivar la sincronización inmediata para colecciones no tan importantes para razones de rendimiento. Seguirá sincronizando modificaciones en el disco con frecuencia, pero no de inmediato. Proporciona transacciones de múltiples documentos y múltiples colecciones.
Una respuesta muy breve a sus requisitos específicos (pero breves):
¿Hay alguna base de datos de documentos similar a MongoDB de servidor único que admita transacciones de múltiples documentos y un enjuague confiable en el disco?
RavenDB [ 1 ] proporciona soporte para transacciones multi-documentos [ 2 ]. Lamentablemente, no sé que maneja la durabilidad.
CouchDB [ 3 ] proporciona escrituras durables, pero no transacciones de varios documentos
RethinkDB [ 4 ] proporciona escrituras durables, pero no transacciones multi-documentos.
Entonces, ¿podría preguntarse qué es diferente acerca de estas 3 soluciones? La mayor parte del tiempo es su soporte de consultas (yo diría que RethinkDB tiene el más avanzado que cubre casi todos los tipos de consultas: sub-consultas, JOINs, agregaciones, etc.), su historial (léase: preparación para la producción - aquí probablemente diría que CouchDB está a la cabeza), su modelo de distribución (usted mencionó que no es interesante para usted), sus licencias (RavenDB: comercial, CouchDB: Apache License, Rethinkdb: AGPL).
El siguiente paso sería que revise brevemente su conjunto de características y descubra cuál se acerca a sus necesidades y pruébelo.
hay tantas bases de datos nosql y definitivamente es difícil elegir una. Tendrá que encontrar los requisitos adecuados y saber exactamente lo que quiere. El siguiente enlace comparó casi todas las bases de datos populares de nosql http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Espero que esto ayude.
Puede valer la pena mirar a ArangoDB . Es una base de datos de modelo múltiple con un modelo de datos flexible para documentos, gráficos y valores-clave. Con respecto a sus requisitos específicos, la base de datos ArangoDB tiene transacciones ACID completas que pueden abarcar múltiples documentos en la misma colección y en varias colecciones (consulte Transacciones en ArangoDB ). Es decir, puede ejecutar un grupo de manipulaciones en sus documentos en una transacción y garantizar la atomicidad y el aislamiento. Si además configuras waitForSync: true (como se describe más abajo en dicha página), obtienes una sincronización garantizada en el disco antes de que la transacción reporte la finalización. Tenga en cuenta que esto sucede automáticamente si su transacción abarca múltiples colecciones.