nosql couchdb cassandra redis

nosql - Redis, CouchDB o Cassandra?



(2)

¿Cuáles son las fortalezas y debilidades de las diversas bases de datos NoSQL disponibles?

En particular, parece que Redis es débil cuando se trata de distribuir carga de escritura en varios servidores. Es ese el caso? ¿Es un gran problema? ¿Qué tan grande debe crecer un servicio antes de que eso pueda ser un problema importante?

Las fortalezas y debilidades de las bases de datos NoSQL (y también las bases de datos SQL) dependen en gran medida de su caso de uso. Para proyectos muy grandes, el rendimiento es el rey; pero para proyectos completamente nuevos, o proyectos donde el tiempo y el dinero son limitados, la simplicidad y el tiempo de comercialización son probablemente los más importantes. Para enseñarte a ti mismo (ampliar tu perspectiva, convertirte en un programador mejor y más valioso), quizás lo más importante sean los conceptos fundamentales simples y sólidos.

¿Qué tipo de proyecto tienes en mente?

Algunas fortalezas y debilidades, fuera de mi cabeza:

  • Redis
    • Muy simple valor clave "servidor variable global"
    • Sistema de consulta muy simple (algunos dirían "inexistente")
    • Fácilmente el más rápido en esta lista
    • Actas
    • El conjunto de datos debe caber en la memoria
    • Agrupación inmadura, con un futuro incierto (estoy seguro de que será genial, pero aún no se ha decidido).
  • Cassandra
    • Posiblemente el impulso más comunitario de las bases de datos tipo BigTable
    • Probablemente la más fácil de esta lista para administrar en clusters grandes / en crecimiento
    • Soporte para mapa / reducir, bueno para análisis, almacenamiento de datos
    • Replicación MUlti-datacenter
    • Consistencia / disponibilidad sintonizable
    • No hay un solo punto de falla
    • Debe saber qué consultas ejecutará temprano en el proyecto, para preparar la forma e índices de datos
  • CouchDB
    • Manos a la obra el mejor soporte de sincronización (replicación), compatible con maestro / esclavo, maestro / maestro y arquitecturas más exóticas
    • El protocolo HTTP, los navegadores / aplicaciones pueden interactuar directamente con el DB parcial o totalmente. (La sincronización también se realiza a través de HTTP)
    • Después de una breve curva de aprendizaje, un sistema de consulta bastante sofisticado que usa Javascript y map / reduce
    • La operación en clúster (sin SPOF, consistencia / disponibilidad sintonizable) es actualmente una bifurcación significativa (BigCouch). Probablemente se fusionará en Couch, pero no hay una hoja de ruta.
    • De manera similar, la agrupación en clúster y el centro de datos múltiples son teóricamente posibles (lo "exótico" que mencioné), sin embargo, debe escribir todas las herramientas usted mismo en este momento.
    • Agregar solo formato de archivo (tanto bases de datos como índices) consume disco sorprendentemente rápido, y debe ejecutar manualmente la compactación (aspiración) que hace una copia completa de todos los registros en la base de datos. Lo mismo se requiere para cada archivo de índice. De nuevo, debes ser tu propio herrero de herramientas.