Las bases de datos NoSQL como Couchbase contienen una gran cantidad de documentos en la memoria, de ahí su enorme velocidad, pero también aumentan la demanda del tamaño de la memoria de los servidores en los que se está ejecutando.

Estoy buscando la mejor estrategia entre varias estrategias contrarias de almacenar documentos en una base de datos NoSQL. Estos son:

Optimizar para la velocidad

Poner toda la información en un documento (grande) tiene la ventaja de que con un solo GET, la información se puede recuperar de la memoria o del disco (si antes se purgó de la memoria). Con las bases de datos NoSQL sin esquema esto casi deseó. Pero eventualmente el documento se hará demasiado grande y consumirá mucha memoria, menos documentos podrán mantenerse en la memoria en total.

Optimizar para memoria

Dividir todos los documentos en varios documentos (por ejemplo, usando claves compuestas como se describe en esta pregunta:Diseño de claves de registro para bases de datos orientadas a documentos: mejor práctica especialmente cuando esos documentos solo contendrían la información necesaria en una operación específica de Lectura / Actualización permitiría que más documentos (transitorios) se guarden en la memoria.

El caso de uso que estoy viendo es Registros de detalles de llamadas (CDR) de proveedores de telecomunicaciones. Todos estos CDR van a cientos de millones típicamente por día. Sin embargo, muchos de estos clientes no proporcionan un solo registro en cada día dado (estoy mirando el mercado del sudeste asiático con su dominio prepago y aún menos saturación de datos). Eso significaría que, por lo general, una gran cantidad de documentos tienen una lectura / actualización cada dos días, solo un pequeño porcentaje tendrá varios ciclos de lectura / actualización por día.

Una solución que me sugirieron es construir 2 depósitos, con más RAM asignada a los más transitorios y menos RAM asignada al segundo depósito que contiene los documentos más grandes. Eso permitiría un acceso más rápido a los datos más transitorios y más lento al documento más grande que, por ejemplo, contiene información de perfil / usuario que no cambia en absoluto. Sin embargo, veo dos desventajas de esta propuesta, una es que no se puede construir una vista (Mapa / Reducir) en dos segmentos (esto es específicamente para Couchbase, otra solución NoSQL podría permitir esto) y la segunda sería más sobrecargada en administrar de cerca el equilibrio entre la asignación de memoria para ambos segmentos a medida que crece la base de usuarios.

¿Alguien más ha sido desafiado por esto y cuál fue su solución a ese problema? ¿Cuál sería la mejor estrategia de tu POV y por qué? Claramente, es algo que se encuentra en el medio de ambas estrategias, tener un solo documento o tener un gran documento dividido en cientos de documentos no puede ser la solución ideal de la OMI.

EDITAR 2014-9-14 Ok, aunque eso se acerca a responder mi propia pregunta, pero en ausencia de una solución ofrecida hasta ahora y después de un comentario aquí hay un poco más de información sobre cómo planeo organizar mis datos, tratando de lograr una buena respuesta punto entre velocidad y consumo de memoria:

Mobile_No: Perfil

esto contiene información de perfil de una tabla, no directamente de un CDR. Aquí entran menos datos transitorios, como edad, sexo y nombre. La clave es una clave compuesta que consiste en el número móvil (MSISDN) y el perfil de la palabra, separados por un ":"

Móvil_No: Ingresos

esto contiene información transitoria como contadores de uso y variables que acumulan los ingresos totales que el cliente gastó. La clave es nuevamente una clave compuesta que consiste en el número móvil (MSISDN) y la palabra ingresos, separados por un ":"

Móvil_No: Optin

esto contiene información semi transitoria sobre cuándo un cliente optó por el programa y cuándo volvió a optar por salir del programa. Esto puede suceder varias veces y se maneja a través de una matriz. La clave es nuevamente una clave compuesta que consiste en el número móvil (MSISDN) y la palabra optin, separadas por un ":"

Connection_Id

esto contiene información sobre una conexión A / B específica (remitente / receptor) que se realizó a través de una llamada de voz o video o SMS / MMS. La clave consiste en ambos mobile_no's que están concatenados.

Antes de estos cambios en la estructura del documento, estaba poniendo toda la información de perfil, ingresos e información en un solo documento grande, manteniendo siempre el connection_id como un documento separado. Con suerte, esta nueva estrategia de almacenamiento de documentos me ofrece un mejor compromiso entre la velocidad y el consumo de memoria, ya que divido el documento principal en varios documentos para que cada uno de ellos solo tenga la información importante que se lee / actualiza en un solo paso de la aplicación.

Esto también se ocupa de la diferente tasa de cambios a lo largo del tiempo, ya que algunos datos son muy transitorios (como los contadores y el campo de ingresos acumulativos que se actualiza con cada CDR que ingresa) y la información del perfil permanece prácticamente sin cambios. Espero que esto dé una mejor comprensión de lo que estoy tratando de lograr, los comentarios y comentarios son más que bienvenidos.