Armazenamento de arquivos: CouchDB vs SQL Server + sistema de arquivos

Question

Estou explorando diferentes maneiras de armazenar arquivos enviados por usuários (todos são documentos ou similares do MS Office) em nosso site de alta carga. Está atualmente projetado para armazenar documentos como arquivos e ter um banco de dados SQL para armazenar todos os metadados para esses arquivos. Estou preocupado com o crescimento do desempenho do servidor de armazenamento e do SQL Server quando o número de documentos atinge centenas de milhões. Eu estava lendo muitas informações boas sobre o CouchDB, incluindo sua escalabilidade e desempenho integrados, mas não tenho certeza de como o armazenamento de arquivos como anexos no CouchDB se compararia ao armazenamento de arquivos em um sistema de arquivos em termos de desempenho.

Alguém usou clusters do CouchDB para armazenar grandes quantidades de documentos e em ambientes de alta carga?

    

Answer 1

Em resposta a Redmumba. A equipe de desenvolvimento do CouchDB estaria interessada nas falhas que você está vendo.

Além disso: toda a arquitetura do CouchDB é baseada no princípio fail-early. Todos os subsistemas, assim como o servidor principal, são projetados de maneira a finalizar e recuperar imediatamente quando ocorre um erro. "crashes" são apenas parte da operação normal, isso torna o software muito mais confiável (ironicamente, mas essa é toda a filosofia da Erlang).

Quanto à questão, o CouchDB atenderá aos requisitos bons o suficiente. O streaming de anexos do CouchDB está definitivamente ligado à velocidade do sistema de arquivos. Os documentos do CouchDB fornecem todo o espaço necessário para os metadados e os anexos de documentos mantêm os dados binários por perto. Não há necessidade de usar sistemas diferentes para isso.

    

Answer 2

As experiências que tivemos com o CouchDB em um ambiente de alta carga não foram tão boas; vimos muita instabilidade (queda freqüente), que as listas de discussão tendem a indicar, podem simplesmente ser resolvidas instalando-se um daemon de monitor para reiniciá-lo se ele falhar. Não usamos grandes conjuntos de valores, mas o atingimos com bastante frequência - mas tenha isso em mente, pois arquivos maiores significam tempos de conexão mais longos. O que significa que baixar no meio da transferência seria ainda mais doloroso dependendo da largura de banda e do tamanho do arquivo.

Eu recomendaria investigar o MongoDB com o suporte do GridFS. O MongoDB seria bom para você (com base em sua especificação) porque parece que você tem metadados adicionais que você pode querer armazenar ao lado do arquivo; porque é orientado a documentos, você poderá armazenar esses metadados junto com os arquivos binários. Para esse fim, o GridFS permite armazenar arquivos grandes no banco de dados.

    

Answer 3

BBC parece estar usando é com sucesso. Eu acredito que há um vídeo no TED discutindo o que eles estão fazendo com isso.

    

Answer 4

Eu não usei o CouchDB, mas tenho experiência com o SQL Server. Se você armazenar os arquivos no servidor SQL (varbinary (max) é fisicamente armazenado no sistema de arquivos), acho que você ficará melhor. Ele será dimensionado para bilhões de linhas e o desempenho, independentemente do banco de dados usado (oracle, sql server, etc ...), dependerá do design do aplicativo e do hardware. Eu acho que essa é a chave. Os problemas de desempenho são quase sempre o resultado de aplicativos ou infraestrutura mal projetados e não do banco de dados de classe empresarial subjacente.