Estou prestes a desenvolver um aplicativo que armazenará principalmente dados criptografados pelo usuário. Cada pedaço de dados sendo criptografado graças a uma chave AES, criptografada com a chave RSA pública de cada usuário concedido.
Dado que o volume de dados não criptografados é insignificante (provavelmente apenas login de usuários, algumas datas e chaves estrangeiras), me pergunto se "DBMS padrão", como PostgreSQL ou MySQL, seria uma boa escolha.
De fato, esses SGBDs são otimizados para lidar com diferentes tipos de dados (texto, inteiros, datas, ...), índices, cálculos de processos, agregações e assim por diante.
No meu caso, a grande maioria dos dados que armazenarei seriam grandes blocos de texto (ou talvez dados binários). E a maior parte do cálculo necessário será processada no lado do cliente, após a descriptografia.
Portanto, também não poderei analisar meus dados. Portanto, mesmo que eu tivesse um banco de dados enorme, ele não seria qualificado como "Big data". No entanto, eu me pergunto se MongoDb, MemSQL ou qualquer outro não seria uma escolha mais precisa. E se não, qual seria o melhor SGBD e a melhor forma de utilizá-lo para o meu propósito?
Em outras palavras, acho que cada DBMS tem que fazer sacrifícios para ser mais eficiente nos recursos mais importantes. Também acho que o caso detalhado acima não é tão casual assim. Portanto, presumo que haja muitos recursos de que não preciso (ou não posso usar, como a pesquisa FULLTEXT, por exemplo). Por outro lado, posso precisar de recursos que são descartados pelo "DBMS padrão".
Como regra geral: se seus dados são bem estruturados, bem conhecidos (com antecedência) e de tamanho limitado por entrada (sem mega BLOBs), os bancos de dados relacionais são realmente bons para armazená-los. Mesmo que você não use os recursos avançados de indexação.
Gerenciar espaço, especialmente espaço vazio em arquivos de dados, é um problema muito difícil de resolver. Os bancos de dados relacionais lidam com isso há mais de 20 anos - e vale a pena usá-los só para isso. Além disso, os bancos de dados relacionais oferecem os benefícios de um longo histórico de ajuste de desempenho. Eles executam código nativo altamente otimizado para que você não tenha que lutar com implementações Java ruins, pilhas de rede ruins, uso excessivo de memcpy, coleta de lixo, bloqueio grosseiro e todas as outras patologias que novos produtos (especialmente o material noSQL) tendem a ter.
Para armazenar dados criptografados, use os tipos de dados BINARY. MSSQL, MySQL e Postgres suportam esses tipos. Você pode não querer fazer operações diretamente nesses tipos (embora você POSSA fazer manipulação binária se quiser). Observe também que é relativamente fácil implementar a criptografia/descriptografia no próprio banco de dados, pois todas as bibliotecas de criptografia acima suportam. Você também se beneficiará da indexação nas colunas chave/estrangeira para que possa encontrar seus dados rapidamente. Um banco de dados relacional é um excelente armazenamento de chave/valor para tipos de valores pequenos - o SQL Server fornecerá facilmente mais de 1-10 milhões de pesquisas de chave/valor/s, mesmo em uma caixa pequena - espero que MySQL e PostGres forneçam resultados no mesmo estádio.
Também é fácil encontrar programadores que possam consultar um banco de dados relacional com eficiência. O SQL existe há muito tempo e é uma linguagem extraordinariamente poderosa. O MSSQL oferece até execução paralela automatizada. Alguns programadores não vão "pegar" - mas se não entenderem, é provável que também não groquem paralelismo ou expressões lambda (duas habilidades cruciais de um codificador moderno).
Além de tudo isso, você também obtém poderosas ferramentas de backup e monitoramento para todos os bancos de dados relacionais padrão.
Então, basicamente, a menos que você tenha um motivo REALMENTE bom para usar NoSQL - apenas use bancos de dados relacionais.
Não há informações suficientes na questão para tomar uma decisão informada, mas aqui estão alguns pontos básicos. Se você quiser mais detalhes, explique mais sobre como os dados serão consultados e quão grandes devem crescer, e quão grandes devem ser os segmentos criptografados e assim por diante.
Portanto, em geral - independentemente do que mais for decidido, eu colocaria os "dados de controle" (login dos usuários, algumas datas etc.) em um RDBMS de sua escolha. No que diz respeito ao resto dos dados, há algumas considerações:
como as informações criptografadas serão recuperadas? Você vai procurar strings binárias? tem alguns metadados que ajudarão a localizar o valor certo? pares chave-valor?
Se o acesso for por pesquisa de chave, um Berkley DB ou Mongo com algum tipo de cache local (como memcache) seria mais do que adequado.
Se uma pesquisa bem-sucedida exigir mais "pensamento", um armazenamento relacional pode ser necessário para suportar a lógica de pesquisa.
Não é aconselhável usar um DBMS que esteja apontando para um arquivo (como o Mongo faz) para armazenar texto, pelo menos não para texto do seu tamanho. Cada vez que você deseja acessar uma única string, significa E/S, e todos nós sabemos o que isso faz com o desempenho. Então, de fato, você deve se ater ao MySQL ou mesmo ao SQL Server (se puder pagar por isso).
Principalmente porque cada um deles possui um datatype especializado para este tipo de dados: TEXT. Já ouvi muitas vezes que TEXT é adequado para armazenar apenas texto, como alternativa a VARCHAR ou mesmo VARCHAR(MAX). Isto está errado. O tipo de dados TEXT é tratado de forma diferente pelo mecanismo de banco de dados e, é claro, otimizado para situações como a sua.
Além disso, se as linhas em sua tabela não forem acessadas inteiramente, ie. as outras colunas são consultadas com frequência, MAS a sua TEXT (não tipo de consulta "SELECT *"), você deve considerar converter a tabela em 1NF e referenciar as enormes colunas TEXT somente quando necessário.
MAS, se você decidir manter todos os dados em uma única tabela, um índice é obrigatório. A última coisa que você deseja é uma verificação completa, que preencherá seu cache de buffer rapidamente.