Actualmente estoy escribiendo una aplicación con bastantes necesidades diferentes de persistencia de datos en capas muy diferentes y sigo preguntándome ... ¿cuándo es apropiado y cuándo no es apropiado usar couchDB para satisfacer mis necesidades de persistencia?¿Cuándo es apropiado usar couchDB?
¿Tiene un requisito relacional? CouchDb (como usted sabe) no tiene la estructura relacional de una base de datos normal.
¿Es la naturaleza RESTful de CouchDb importante para lo que estás haciendo?
Quizás lo más importante, ¿quién va a apoyar esto en el futuro, y serán capaces de manejar CouchDb? Es una herramienta bastante específica, y no será fácil encontrar personas con experiencia en ella.
Es realmente una cosa, caso por caso, diría yo. CouchDB es simplemente un tipo de base de datos, dependiendo de su proyecto, podría ser un ajuste perfecto o podría ser una limitación dolorosa, al igual que un RDBMS puede ser un ajuste perfecto o una pesadilla.
Más información?
Después de implementar dos sistemas de producción además de db no relacionales, llegué a la conclusión de que los dbs no relacionales necesitan acercarse un poco más a sql para ser realmente "alternativos" a él. Entiendo la alternativa como "obtienes la misma funcionalidad sin una gran diferencia en calidad, esfuerzo o costo".
Respuesta corta: No es que a menudo
Respuesta larga. El principal beneficio para las bases de datos no relacionales son alta disponibilidad, sin esquema y escalabilidad. Todo esto viene con un precio significativo. Si su aplicación necesita flexibilidad de consulta (y/o orden de clasificación, ...) y si tiene grandes requisitos de datos o rendimiento, estará mejor con DB tradicional como mysql o mejores postgres. El principal desafío con la base de datos no relacional es que si necesita una nueva forma de combinar datos (como todas las publicaciones que el usuario le gusta por orden de tiempo) necesitará un nuevo documento para insertar y ver para implementar la consulta. Couchdb está basado en documentos y es bueno para la flexibilidad, ya que no necesita mantener el esquema en la base de datos y simplemente puede "olvidar" los datos antiguos que faltan en los nuevos campos. Las bases de datos de documentos no alcanzan todo el potencial con lenguajes tipados estáticos, ya que de todos modos tiene que corregir más o menos la estructura de datos en su código.
db no relacional requiere arquitectura push. Todos los datos para todas las consultas posibles (incluso los raros de administración) deben presionarse cuando inserte o actualice datos. Esto cuesta como CPU y disco, pero obtienes consultas rápidas. En SQL basado db puede simplemente insertar la fila y pagar el precio como consultas lentas. CouchDB crea índices en la primera consulta, algunas otras bases de datos en insertar (MongoDB, Google App Engine)
Las consultas de Couchdb se definen como vistas de JavaScript que son poderosas pero bastante difíciles de escribir, mantener y depurar. Ver cambio significa que couchdb necesita volver a indexar todos los documentos que es realmente lento si tiene millones o más de documentos. Los mensajes de error de couchdb no pueden ser descifrados por el administrador habitual.
El mantenimiento de Couchdb necesita un poco de esfuerzo manual para compactar los archivos de datos y los índices, pero las nuevas versiones tienen compactación automática, pero su uso requiere cierto cuidado.Las compactaciones deben programarse fuera de los picos, etc. Sin embargo, esto puede guionarse muy fácilmente. Db dump, backup y esas herramientas son todavía muy infantiles.
En resumen, no vale la pena el esfuerzo si no va a necesitar el rendimiento o la escalabilidad de la couchdb. Personalmente creo que es posible "emular" la mayoría de los beneficios de rendimiento db no relacionales con SQL db, redis y pila de memcache. Al menos mientras no haya demasiados datos.