Bancos de dados NoSQL como o Couchbase mantêm muitos documentos na memória, portanto, sua velocidade é enorme, mas também exige mais o tamanho da memória do (s) servidor (es) em que está sendo executado.

Estou procurando a melhor estratégia entre várias estratégias contrárias de armazenamento de documentos em um banco de dados NoSQL. Esses são:

Otimize para velocidade

Colocar todas as informações em um documento (grande) tem a vantagem de que, com um único GET, as informações podem ser recuperadas da memória ou do disco (se elas foram eliminadas da memória antes). Com os bancos de dados NoSQL sem esquema, isso quase desejava. Mas, eventualmente, o documento ficará muito grande e consumirá muita memória; menos documentos poderão ser mantidos na memória no total

Otimizar para memória

Dividir todos os documentos em vários documentos (por exemplo, usando chaves compostas como descrito nesta pergunta:Projetando chaves de registro para banco de dados orientado a documentos - práticas recomendadas especialmente quando esses documentos retinham apenas as informações necessárias em uma operação específica de leitura / atualização, permitindo que mais documentos (transitórios) fossem retidos na memória.

O caso de uso que estou analisando é o CDR (Call Detail Records) dos provedores de telecomunicações. Todos esses CDRs chegam a centenas de milhões, normalmente por dia. No entanto, muitos desses clientes não fornecem um único registro a cada dia (estou analisando o mercado do Sudeste Asiático com seu domínio pré-pago e ainda menos saturação de dados). Isso significaria que, normalmente, um grande número de documentos realiza uma leitura / atualização em dias alternados, apenas uma pequena porcentagem terá vários ciclos de leitura / atualização por dia.

Uma solução que me foi sugerida é a construção de 2 buckets, com mais RAM sendo alocada para os mais transitórios e menos RAM sendo alocada para o segundo bucket com os documentos maiores. Isso permitiria um acesso mais rápido aos dados mais transitórios e mais lento ao documento maior, que contém informações de perfil / usuário que não estão mudando. No entanto, vejo duas desvantagens dessa proposta: uma é que você não pode criar uma visualização (mapear / reduzir) em dois buckets (especificamente para o Couchbase, outra solução NoSQL pode permitir isso) e a segunda seria mais sobrecarga no gerenciamento de perto do equilíbrio entre a alocação de memória para ambos os buckets à medida que a base de usuários cresce.

Alguém mais foi desafiado por isso e qual foi sua solução para esse problema? Qual seria a melhor estratégia do seu POV e por quê? Claramente, pode ser algo no meio de ambas as estratégias, ter apenas um documento ou um grande documento dividido em centenas de documentos não pode ser a solução ideal para IMO.

EDIT 2014-9-14 Ok, embora isso chegue perto de responder à minha própria pergunta, mas na ausência de qualquer solução oferecida até o momento, e após um comentário aqui, é um pouco mais histórico de como agora planejo organizar meus dados, tentando obter um bom resultado. local entre velocidade e consumo de memória:

Mobile_No: perfil

isso mantém informações de perfil de uma tabela, não diretamente de um CDR. Dados menos transitórios entram aqui, como idade, sexo e nome. A chave é uma chave composta que consiste no número de celular (MSISDN) e no perfil da palavra, separados por um ":"

Nº celular: receita

isso mantém informações transitórias, como contadores de uso e variáveis que acumulam a receita total gasta pelo cliente. A chave é novamente uma chave composta que consiste no número de celular (MSISDN) e na palavra receita, separados por um ":"

Mobile_No: Optin

isso contém informações semi-transitórias sobre quando um cliente optou pelo programa e quando ele optou por sair do programa novamente. Isso pode acontecer várias vezes e é tratado através de uma matriz. A chave é novamente uma chave composta que consiste no número de celular (MSISDN) e na palavra optin, separados por um ":"

Connection_Id

isso contém informações sobre uma conexão A / B específica (remetente / receptor) que foi feita via chamada de voz ou vídeo ou SMS / MMS. A chave consiste em ambos os mobile_no's que são concatenados.

Antes dessas mudanças na estrutura do documento, eu colocava todas as informações de perfil, receita e inscrição em um grande documento, mantendo sempre o connection_id como um documento separado. Esperamos que esta nova estratégia de armazenamento de documentos me ofereça um melhor compromisso entre velocidade e consumo de memória, pois dividi o documento principal em vários documentos para que cada um deles tenha apenas as informações importantes que são lidas / atualizadas em uma única etapa do aplicativo.

Isso também cuida das diferentes taxas de alterações ao longo do tempo, com alguns dados sendo muito transitórios (como os contadores e o campo de receita acumulativa que é atualizado a cada entrada de CDR) e as informações do perfil praticamente inalteradas. Espero que isso dê uma melhor compreensão do que estou tentando alcançar, comentários e feedback são mais que bem-vindos.