¿Puede CouchDB manejar miles de bases de datos separadas?

Question

¿Puede CouchDB manejar miles de bases de datos separadas en la misma máquina?

Imagine que tiene una colección de BankTransaction s. Hay muchos miles de registros. (EDITAR: no almacenar transacciones, solo piense en un gran número de registros muy pequeños y que se actualizan frecuentemente. Básicamente es una tabla de unión de SQL-land.)

Cada día desea obtener una vista resumida de las transacciones que ocurrieron solo en su sucursal bancaria local. Si todos los registros están en una única base de datos, la regeneración de la vista procesará todos de las transacciones de todos de las ramas. Este es un trabajo mucho más grande e innecesario para el usuario que solo se preocupa por su subconjunto particular de documentos.

Esto hace que parezca que cada sucursal bancaria debe ser particionada en su propia base de datos, para que las vistas se generen en trozos más pequeños, e independientemente el uno del otro. Pero nunca escuché que alguien lo haya hecho y parece un antipatrón (por ejemplo, duplicar el mismo documento de diseño en miles de bases de datos diferentes).

¿Hay alguna otra manera de modelar este problema? (¿Las particiones deben realizarse entre máquinas separadas, no bases de datos separadas en la misma máquina?) En caso negativo, ¿puede CouchDB manejar las miles de bases de datos que se necesitarán para mantener las particiones pequeñas?

(Gracias!)

Answer 1

[Advertencia, estoy suponiendo que se está ejecutando este en algún tipo de entorno de producción. Simplemente vaya con la respuesta breve si esto es para un proyecto de escuela o mascota.]

La respuesta es "sí".

La respuesta larga es que hay algunas cosas que hay que mirar hacia fuera para ...

• Vas a estar jugando golpe-a-mole con una gran cantidad de configuraciones del sistema como máximo del archivo descriptores.

• También jugará whack-a-mole con la configuración erlang vm.

• CouchDB tiene la opción "max open databases". Aumenta esto o tendrás solicitudes pendientes acumulándose.

• Va a ser un PITA para agregar múltiples bases de datos para generar informes. Puede hacerlo sondeando el feed _changes de cada base de datos, modificando los datos y volviéndolos a una base de datos central/agregada. Las herramientas para hacer esto más fácil aún no están ahí en la API de CouchDB. Casi, pero no del todo.

Sin embargo, el mayor problema que se va a ejecutar en si intenta hacer esto es que hace CouchDB no horizontalmente escala [también] por sí mismo. Si agrega más servidores CouchDB, todos tendrán duplicados de los datos. Claro, su recuento máximo de db abiertos se escalará linealmente con cada nodo agregado, pero otras cosas como el tiempo de compilación de vista no (por ejemplo, todos tendrán que hacer sus propias compilaciones de vista).

Considerando que he visto miles de bases de datos abiertas en un clúster de BigCouch.Anecdóticamente, eso se debe a la agrupación de dínamo: más nodos haciendo cosas diferentes en paralelo, frente a los servidores CouchDB amurallados replicando entre sí.

Saludos.

Answer 2

Son posibles varias bases de datos, pero para la mayoría de los casos creo que la base de datos agregada realmente dará un mejor rendimiento a sus sucursales. Tenga en cuenta que solo está optimizando cuando un documento se actualiza en la vista; cada documento solo se analizará una vez por vista.

Para el sondeo al final del día en una base de datos global, la primera rama causará que se procese el 100% de los nuevos documentos, y pagará el 100% de la demora. Todas las otras ramas pagarán 0%. Entonces la mayoría de las ramas se benefician. Para las encuestas al final del día en bases de datos separadas, todas las sucursales pagan una parte de la penalidad proporcional a su volumen, por lo que la mayoría sale ligeramente rezagada.

Para ver las actualizaciones frecuentes a lo largo del día, las sucursales activas prefieren el agregado y las ramas de bajo volumen prefieren las que están separadas. Si una rama en 10 agrega el 99% de los documentos, la mayor parte del trabajo de actualización se realizará en las encuestas de otras ramas, por lo que 9 de cada 10 prefieren dbs por separado.

Si esta latencia importa, y suponiendo que el sofá tiene algunos ciclos de reloj sin usar, puede escribir un script de 3 líneas de bucle/vista/dormir que actualice algunos documentos antes de que cualquier usuario esté esperando.

Answer 3

Agregaría que tener una gran cantidad de bases de datos crea problemas en cuanto a la compactación y la replicación. No solo se deben desencadenar cosas como la replicación continua por base de datos (lo que significa que tendrá que escribir lógica personalizada para recorrer todas las bases de datos), sino que también generarán los daemons de replicación por base de datos. Esto puede convertirse rápidamente en prohibitivo.