armazenamento de valor-chave escalável dinamicamente horizontal

Question

Existe um armazenamento de valor-chave que me dará o seguinte:

• Permita-me simplesmente adicionar e remover nós e redistribuir os dados automaticamente
• Permita-me remover nós e ainda ter 2 nós de dados extras para fornecer redundância
• Permita-me armazenar texto ou imagens de até 1 GB de tamanho
• Pode armazenar dados de tamanho pequeno até 100 TB de dados
• Rápido (permitirá que consultas sejam realizadas em cima dele)
• Deixe tudo isso transparente para o cliente
• Funciona em Ubuntu/FreeBSD ou Mac
• Gratuito ou de código aberto

Basicamente, quero algo que possa usar um "único" e não precise me preocupar em ter memcached, um banco de dados e vários componentes de armazenamento, então sim, quero um banco de dados "bala de prata", você poderia dizer.

Obrigado

Zubair

Respostas até agora:MogileFS em cima do BackBlaze - Até onde posso ver, este é apenas um sistema de arquivos e, após algumas pesquisas, parece ser apropriado apenas para arquivos de imagem grandes

Tirano de Tóquio - Precisa de nuvem de luz.Isso não é dimensionado automaticamente à medida que você adiciona novos nós.Eu olhei para isso e parece que é muito rápido para consultas que cabem em um único nó

Riak - Este é um que estou investigando, mas ainda não tenho nenhum resultado

Amazon S3 - Alguém está usando isso como única camada de persistência na produção?Pelo que vi parece ser usado para armazenamento de imagens, pois consultas complexas são muito caras

@shaman sugeriu Cassandra - definitivamente uma que estou procurando

Até o momento parece que não existe nenhum banco de dados ou armazenamento de chave-valor que atenda aos critérios que mencionei, nem mesmo depois de oferecer uma recompensa de 100 pontos a pergunta foi respondida!

Answer 1

Você está pedindo demais do software de código aberto.

Se você tem algumas centenas de milhares de dólares em seu orçamento para algum software de classe empresarial, existem algumas soluções.Nada vai fazer o que você quer fora da caixa, mas há empresas que têm produtos que se aproximam do que você procura.

"Rápido (permitirá que consultas sejam realizadas em cima dele)"

Se você tiver um armazenamento de valores-chave, tudo deverá ser muito rápido.No entanto, o problema é que, sem uma ontologia ou esquema de dados construído sobre o armazenamento de valores-chave, você acabará percorrendo todo o banco de dados para cada consulta.Você precisa de um índice contendo a chave para cada “tipo” de dados que deseja armazenar.

Nesse caso, geralmente você pode realizar consultas em paralelo em todas as aproximadamente 15.000 máquinas.O gargalo é que os discos rígidos baratos atingem 50 buscas por segundo.Se o seu conjunto de dados couber na RAM, seu desempenho será extremamente alto.No entanto, se as chaves estiverem armazenadas na RAM, mas não houver RAM suficiente para os valores serem armazenados, o sistema irá para o disco em quase todas as pesquisas de valores-chave.Cada uma das chaves está localizada em posições aleatórias na unidade.

Isso limita você a 50 pesquisas de valores-chave por segundo por servidor.Considerando que quando os pares chave-valor são armazenados na RAM, não é incomum obter 100 mil operações por segundo por servidor em hardware comum (ex.Redis).

No entanto, o desempenho de leitura de disco serial é extremamente alto.Procurei unidades que chegassem a 50 MB/s (800 Mb/s) em leituras seriais.Portanto, se você estiver armazenando valores em disco, será necessário estruturar o armazenamento para que os valores que precisam ser lidos no disco possam ser lidos serialmente.

Esse é o problema.Você não pode obter um bom desempenho em um armazenamento de chave-valor Vanilla, a menos que armazene os pares de chave-valor completamente na RAM (ou chaves na RAM com valores em unidades SSD) ou se você definir algum tipo de esquema ou sistema de tipo no topo do chaves e, em seguida, agrupar os dados no disco para que todas as chaves de um determinado tipo possam ser recuperadas facilmente por meio de uma leitura de disco serial.

Se uma chave tiver vários tipos (por exemplo, se você tiver relacionamentos de herança de tipo de dados no banco de dados), a chave será um elemento de várias tabelas de índice.Nesse caso, você terá que fazer compensações tempo-espaço para estruturar os valores de modo que possam ser lidos serialmente no disco.Isso envolve o armazenamento de cópias redundantes do valor da chave.

O que você deseja será um pouco mais avançado do que um armazenamento de valores-chave, especialmente se você pretende fazer consultas.O problema de armazenar arquivos grandes, entretanto, não é problema.Finja que seu sistema pode armazenar até 50 megas.Depois, basta dividir um arquivo de 1 giga em segmentos de 50 megas e associar uma chave ao valor de cada segmento.Usando um servidor simples, é fácil traduzir a parte do arquivo que você deseja em uma operação de pesquisa de valor-chave.

O problema de conseguir redundância é mais difícil.É muito fácil "código-fonte" ou "arquivo parcial" da tabela de valores-chave de um servidor, para que os dados do servidor possam ser reconstruídos em velocidade de fio (1 Gb/s) em um servidor em espera, se um servidor específico morrer.Normalmente, você pode detectar a morte do servidor usando um sistema de "pulsação" que é acionado se o servidor não responder por 10 segundos.É até possível fazer pesquisas de valores-chave nas tabelas de valores-chave codificadas em arquivos parciais, mas é ineficiente fazer isso, mas ainda fornece um backup para o caso de falha do servidor.Um problema maior é quase impossível manter o backup atualizado e os dados podem ter 3 minutos.Se você estiver fazendo muitas gravações, a funcionalidade de backup introduzirá alguma sobrecarga de desempenho, mas a sobrecarga será insignificante se o seu sistema estiver fazendo principalmente leituras.

Não sou especialista em manter a consistência do banco de dados e as restrições de integridade em modos de falha, portanto não tenho certeza de quais problemas esse requisito introduziria.Se você não precisa se preocupar com isso, simplifica muito o design do sistema e seus requisitos.

Rápido (permitirá que consultas sejam realizadas em cima dele)

Primeiro, esqueça as junções ou qualquer operação que seja escalonada mais rapidamente que n*log(n) quando seu banco de dados for tão grande.Há duas coisas que você pode fazer para substituir a funcionalidade normalmente implementada por junções.Você pode estruturar os dados para que não precise fazer junções ou pode "pré-compilar" as consultas que está fazendo e fazer uma compensação tempo-espaço e pré-calcular as junções e armazená-las para pesquisa antecipada .

Para bancos de dados da Web semântica, acho que veremos pessoas pré-compilando consultas e fazendo compensações tempo-espaço para alcançar um desempenho decente, mesmo em conjuntos de dados de tamanho modesto.Acredito que isso pode ser feito de forma automática e transparente pelo back-end do banco de dados, sem nenhum esforço por parte do programador da aplicação.Entretanto, estamos apenas começando a ver bancos de dados corporativos implementando essas técnicas para bancos de dados relacionais.Até onde eu saiba, nenhum produto de código aberto faz isso e eu ficaria surpreso se alguém ainda estivesse tentando fazer isso para dados vinculados em bancos de dados escalonáveis ​​horizontalmente.

Para esses tipos de sistemas, se você tiver RAM ou espaço de armazenamento extra, o melhor uso é pré-calcular e armazenar o resultado de subconsultas comuns por motivos de desempenho, em vez de adicionar mais redundância ao armazenamento de valores-chave.Pré-calcule os resultados e ordene pelas chaves que você irá consultar para transformar uma junção n^2 em uma pesquisa de log(n).Qualquer consulta ou subconsulta com escala pior que n*log(n) é algo cujos resultados precisam ser executados e armazenados em cache no armazenamento de valores-chave.

Se você estiver fazendo um grande número de gravações, as subconsultas armazenadas em cache serão invalidadas mais rapidamente do que podem ser processadas e não haverá benefício de desempenho.Lidar com a invalidação do cache para subconsultas armazenadas em cache é outro problema intratável.Acho que uma solução é possível, mas não a vi.

Bem-vindo ao inferno.Você não deve esperar obter um sistema como este gratuitamente por mais 20 anos.

Até o momento parece que não existe nenhum banco de dados ou armazenamento de chave-valor que atenda aos critérios que mencionei, nem mesmo depois de oferecer uma recompensa de 100 pontos a pergunta foi respondida!

Você está pedindo um milagre.Espere 20 anos até que tenhamos bancos de dados milagrosos de código aberto ou você estará disposto a pagar por uma solução personalizada para as necessidades de sua aplicação.

Answer 2

A Amazon S3 é uma solução de armazenamento, não um banco de dados.

Se você precisar apenas de chave/valor simples, sua melhor aposta seria usar a Amazon Simpledb em combinação com o S3. Os arquivos grandes são armazenados no S3, enquanto os meta -dados da pesquisa são armazenados no SimpleDB. Isso fornece um sistema de chave/valor escalável horizontalmente com acesso direto ao S3.

Answer 3

Há outra solução, que parece ser exatamente o que você está procurando: o projeto Apache Cassandra: http://incubator.apache.org/cassandra/

No momento

Answer 4

O HBase e o HDFS juntos atendem à maioria desses requisitos.O HBase pode ser usado para armazenar e recuperar pequenos objetos.HDFS pode ser usado para armazenar objetos grandes.O HBase compacta objetos pequenos e os armazena como objetos maiores no HDFS.A velocidade é relativa - o HBase não é tão rápido em leituras aleatórias do disco quanto o mysql (por exemplo) - mas é bastante rápido servindo leituras da memória (semelhante ao Cassandra).Possui excelente desempenho de gravação.HDFS, a camada de armazenamento subjacente, é totalmente resiliente à perda de vários nós.Ele replica entre racks, permitindo também a manutenção em nível de rack.É uma pilha baseada em Java com licença Apache - executa praticamente a maioria dos sistemas operacionais.

Os principais pontos fracos dessa pilha são o desempenho inferior ao ideal de leitura aleatória de disco e a falta de suporte entre data centers (que é um trabalho em andamento).

Answer 5

Posso sugerir duas soluções possíveis:

1) Compre o serviço da Amazon (Amazon S3). Por 100 TB, custará 14 512 $ mensalmente.
2) Solução muito mais barata:

Construa duas vagens de armazenamento de backblaze personalizadas (link) e execute um Mogilefs em cima dele.

Atualmente, estou investigando como armazenar petabytes de dados usando soluções semelhantes; portanto, se você encontrar algo interessante nisso, publique suas anotações.

Answer 6

Dar uma olhada em Tokyo Tyrant. É um daemon muito leve, de alto desempenho, exportando um daemon Gabinete de Tóquio armazenamento de valor-chave para a rede. Eu ouvi coisas boas sobre isso.

Answer 7

Pelo que vejo em sua pergunta Projeto Voldemort parece ser o mais próximo. Dê uma olhada no seu Página de design.

O único problema que vejo é como ele lidará com arquivos enormes e de acordo com este tópico, coisa não é boa. Mas você sempre pode contornar isso com bastante facilidade usando arquivos. No final - esse é o objetivo exato de um sistema de arquivos. Dê uma olhada no Lista da Wikipedia de sistemas de arquivos - A lista é enorme.

Answer 8

Você pode querer dar uma olhada em MongoDB.

Pelo que posso dizer, você está procurando um mix de banco de dados/sistema de arquivos distubitado, que pode ser difícil ou até impossível de encontrar.

Você pode querer dar uma olhada em sistemas de arquivos distribuídos como Moosefs ou Brilho e mantenha seus dados como arquivos. Ambos os sistemas são tolerantes a falhas e distribuídos (você pode colocar e retirar nós como quiser), e ambos são transparentes para os clientes (construídos sobre o fusível) - você está usando o OPS simples do sistema de arquivos. Isso abrange os seguintes recursos: 1), 2), 3), 4), 6), 7), 8). Estamos usando o Moosefs para armazenamento de filmes digitais com algo de 1,5 pb de armazenamento e upload/download é tão rápido quanto a configuração de rede permitir (para que o desempenho dependa de E/S dependente, não dependente do protocolo ou da implementação). Você não terá consultas (recurso 5) na sua lista), mas pode acoplar esse sistema de arquivos com algo como MongoDB Ou mesmo algum mecanismo de pesquisa como Lucene (ele tem índices em cluster) para consultar dados armazenados no sistema de arquivos.

Answer 9

Zubair,

Estou trabalhando em uma loja de valores-chave que até agora é mais rápido do que qualquer outra coisa.

Ainda não usa a replicação, perdendo seus 2 primeiros requisitos, mas essa pergunta me inspirou - obrigado por isso!

Não: permita -me simplesmente adicionar e remover nós e o Redstribute dos dados automaticamente
Não: permita -me remover nós e ainda ter 2 nós de dados extras para fornecer redundância
OK: permita -me armazenar texto ou imagens de até 1 GB de tamanho (sim: ilimitado)
OK: pode armazenar dados de tamanho pequeno de até 100 TB de dados (sim: ilimitado)
OK: Fast (então permitirá que as consultas sejam executadas em cima dele) (Sim: MAIS FASTER que o Array Fixado de TC do Gabinete de Tóquio)
OK: Faça tudo isso transparente para o cliente (Sim: integrado ao servidor da web)
OK: funciona no ubuntu/freeBSD ou mac (Sim: Linux)
Ok: código aberto ou de código aberto (sim: freeware)

Além das performances de tiro único, com tábuas de hash e brees B, esta loja KV é a única que conheço "sem espera" (sem bloquear, nem atrasar qualquer operação).

Answer 10

Marklogic está indo nessa direção. Nem um pouco livre, no entanto ...

Answer 11

Além do que os outros mencionaram - você pode dar uma olhada no OrientDB - http://code.google.com/p/orient/ Um documento e uma loja K/V que parecem muito promissores.

Answer 12

Verificação de saída BigCouch. É CouchDB, mas otimizado para clusters (e todos os clusters de Big Data Problems são apropriados). BigCouch está recebendo fundido no projeto CouchDB Enquanto falamos, pelo pessoal de Nuvem, muitos dos quais são os principais compromissos do CouchDB.

Resumo de seus requisitos:

Permita -me simplesmente adicionar e remover nós e o Redstribute os dados automaticamente

Permita -me remover nós e ainda ter 2 nós de dados extras para fornecer redundância

Sim. O BigCouch usa o conceito de quorum do Dynamo para definir quantos nós mantêm quantas cópias de seus dados.

Permita -me armazenar texto ou imagens de até 1 GB de tamanho

Sim. Assim como o CouchDB, você pode transmitir blobs (como arquivos) de tamanho arbitrário para o banco de dados.

Pode armazenar dados de tamanho pequeno até 100 TB de dados

Sim. A equipe que construiu o BigCouch o fez porque estava enfrentando um sistema gerando petabytes de dados por segundo.

Rápido (então permitirá que as consultas sejam executadas em cima dele)

Sim. As consultas são feitas pelo MapReduce em O (log n) tempo.

Faça tudo isso transparente para o cliente

Funciona no Ubuntu/FreeBSD ou Mac

Livre ou de código aberto

Sim! Código aberto sob a licença Apache 2.0. As instruções de instalação padrão são para um sistema Debian, como o Ubuntu.