Puede que hayas oído que MongoDB tiene problemas con la escalabilidad fuera. Puede que hayas oído que Viber está sustituyendo MongoDB por Couchbase Server. Has oído cómo escalar con MongoHQ?
Estoy de acuerdo con MongoHQ en una cosa. Es más fácil escalar arriba. Mientras que la escala arriba puede ser la única solución para MongoDB, no es la solución adecuada. Qué pasa cuando no hay más espacio para escalar arriba? Creo que MongoHQ preferiría escalar, pero se han dado cuenta de que MongoDB no está diseñado para ello.
El resultado es una pérdida de funcionalidad...
En MongoDB, por ejemplo, las escalas horizontales implican perder índices secundarios únicos (una de las pocas restricciones de esquema que MongoDB admite actualmente) para una colección determinada.
Requiere decisiones difíciles...
En MongoDB, esta elección es la "decisión de clave de fragmento" de la que oirás hablar a los usuarios experimentados de MongoDB con tintes de temor.
Es complejo de configurar y mantener...
Pero una vez que su base de datos fragmentada está en producción, existe la realidad subyacente de que su sistema tiene más "partes móviles" de lo que sería ideal, porque más partes móviles significan más cosas que pueden ir mal.
El resultado es una pérdida de rendimiento...
En una configuración sharded, la conectividad de red entre el router Mongo, los servidores de configuración y cada shard influye en el rendimiento general.
Couchbase Server, por otro lado, fue diseñado para escalar. No supone una pérdida de funcionalidad. No requiere decisiones difíciles. No es complejo de configurar y mantener. No supone una pérdida de rendimiento.
- Couchbase Server no requiere configuración manual de sharding. Es automática.
- Couchbase Server no tiene muchas partes móviles. Hay un tipo de nodo.
- Cuando Couchbase Server es escalado, el rendimiento se incrementa.
Creo que la sección sobre oplog tailling era bastante problemática. Creo que pone de relieve el hecho de que MongoDB no fue diseñado para escalar. Resulta que los administradores y desarrolladores confían en un archivo de registro para la comprensión y la integración. El problema con el escalado de MongoDB es que requiere que los desarrolladores sigan múltiples archivos de registro. Hay un archivo de registro por nodo.
Couchbase Server, por otro lado, no requiere que los administradores y desarrolladores sigan un archivo de registro para obtener información e integración. Los administradores pueden monitorizar Couchbase Server desde cualquier nodo. Los desarrolladores pueden integrarse con Elasticsearch o Apache Hadoop sin tener que interactuar con nodos individuales de Couchbase Server. La topología es transparente. Ese es el beneficio de un sistema distribuido con una arquitectura de nada compartida.
Vale la pena señalar que Couchbase Server soporta replicación entre centros de datos. Permite replicar los datos de un cluster a otro cluster diferente. De hecho, así es como nos integramos con Elasticsearch. Es como un cluster diferente al que Couchbase Server puede replicar datos. Que sea un cluster de Elasticsearch es irrelevante. Es simplemente un cluster diferente al que replicar datos.
Únete a la conversación en reddit (enlace).
Únete a la conversación en Hacker News (enlace).
Lecturas complementarias
Por qué empezamos a escalar verticalmente (Google Web Cache)
Nota: MongoHQ ha eliminado el mensaje original y ahora redirige a uno nuevo.
Topología: La arquitectura de los sistemas distribuidos
Nota: Esto incluye una visión general de la piezas móviles dentro de una implementación de MongoDB que se amplía.
Integración de Couchbase Server con Elasticsearch (página | doc)
Integración del servidor Couchbase con Apache Hadoop (página | doc)
¿entonces couchbase es mejor?
Yo no diría que uno es mejor o peor. Realmente depende de sus necesidades. Si investigas lo suficiente, verás que todos los proveedores NoSQL tendrán una historia de varias migraciones de un almacén de datos potencial a otro (incluyendo Riak). Sólo dos centavos...
{full disclosure Basho employee}
Este es un gran tema, sin embargo, escalar a cabo. Algunas ideas:
Sin embargo, a medida que Couchbase añade nodos, ¿cómo se escalan los distintos rendimientos de las cargas de trabajo (es decir, el ratio Escritura/Lectura) dado que las réplicas de vBuckets no son participantes iguales, existen dos estrategias de replicación: 1:n maestro/esclavo y 1..n encadenado.
A "gran escala", se producen más fallos (por ejemplo, falta de tiempo en los nodos, cerebro dividido, fallos parciales), ¿cómo aborda el sistema los fallos y qué grado de intervención humana se requiere?
Este comentario no pretende provocar y poner Riak en una luz favorable, ya que hace estas cosas "mejor" .......pero para pedir a los lectores a pensar y hacer preguntas al leer cualquier material. Riak tiene su propio conjunto de limitaciones, tales como consultas de campo JSON, etc y Couchbase es fantástico para aquellos en Memcache API.
La tecnología, al fin y al cabo, no es más que una herramienta y debe evaluarse en función del uso/caso. Espero que esto ayude raluca. Saludos. :)
Hola Frank,
Nunca he tenido nada malo que decir sobre Riak, y todavía no lo tengo. Dicho esto, no estoy del todo seguro de entender tu comentario. A medida que se añaden nodos, los vBuckets se reparten uniformemente por todo el cluster. Añadir nodos aumenta el rendimiento ya que cada nodo gestiona lecturas y escrituras para menos vBuckets. Sólo hay una estrategia de replicación. Escribe en todas las réplicas (uno a muchos). No encadena las escrituras en las réplicas.
Sí, pero no tienes que creerme. Creo que los problemas de rendimiento de MongoDB son bien conocidos.
No tienes que buscar demasiado para encontrar gente en la comunidad MongoDB que te diga que no necesitas sharding. Cuando alguien te dice que no necesitas algo, es porque no puede hacerlo. El primer ejemplo que me viene a la mente es el iPhone con copiar y pegar ;)
Bueno, suena como un infomercial ..
Es difícil comparar Couchbase con MongoDB.
Mientras que MongoDB es un NoSQL de propósito general, Couchbase está diseñado para el almacenamiento en caché: la mayor parte del conjunto de datos tiene que estar en la memoria, no hay consultas complejas, etc .
Además, el hashing de Couchbase significa menor disponibilidad, ya que la caída de un nodo afecta a todo el conjunto de datos.
1. Couchbase Server no está diseñado para el almacenamiento en caché. Puede ser desplegado como caché, como almacén de claves/valores, como base de datos de documentos, o como las tres cosas. Ese es el beneficio de una gran arquitectura, y es algo que tienes que hacer bien al principio. Es por eso que MongoDB tiene los problemas que tiene.
2. El hashing no tiene nada que ver con la disponibilidad. No, un nodo averiado no afecta a todo el conjunto de datos. Puedes configurar réplicas. Si un nodo falla, una de las réplicas puede ser "promovida". No hay pérdida de disponibilidad. Incluso si no hay réplicas, un nodo fallido sólo provoca la pérdida de los datos en dicho nodo.
1. Cuando la mayor parte del conjunto de datos tiene que estar en memoria para que Couchbase funcione, se optimiza para el almacenamiento en caché ...
2. No tengo forma de controlar donde viven los datos debido al hashing consistente en Couchbase (a diferencia de MongoDB donde puedo usar particionado de rango). Por lo tanto un nodo caído puede causar que muchas peticiones fallen (hasta que el fail over se complete después de 30 segundos) ya que los documentos estarán distribuidos entre los nodos. La adición de algo hash adicional permitirá resolver ese problema.
1. ¿Por qué sigues diciendo que la mayoría de los datos tienen que estar en memoria? ¿No utiliza MongoDB archivos mapeados en memoria? Una "caché" implica que los datos son transitorios o que persisten en una base de datos separada. Cuando Couchbase Server se usa como almacén de claves/valores o como base de datos de documentos, ninguna de las dos cosas es cierta.
2. El problema del particionamiento por rangos es que limita el rendimiento hasta que la base de datos está llena. Por eso la mayoría de las bases de datos (NoSQL) se basan en hashing consistente.
3. Couchbase Server es un sistema distribuido de CP. Mantiene la consistencia. Sí, esperará 30 segundos antes de fallar sobre un nodo. Esto es para asegurarse de que el nodo en cuestión está caído y no lento. Si es lento, los datos que posee pueden o no estar disponibles. No querrás conmutar por error cada nodo cada vez que tarde demasiado en responder a una petición. Sería inestable. Mientras que los datos que posee un nodo dudoso pueden o no estar disponibles durante 30 segundos, los datos que poseen los otros nodos están disponibles.