Quais problemas de escalabilidade você encontrou ao usar um repositório de dados NoSQL? [fechadas]


189

NoSQL refere-se a armazenamentos de dados não relacionais que rompem com o histórico de bancos de dados relacionais e garantias ACID. Os repositórios populares de dados NoSQL de código aberto incluem:

  • Cassandra (tabular, escrito em Java, usado pela Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit e Twitter)
  • CouchDB (documento escrito em Erlang, usado pela BBC e Engine Yard)
  • Dynomite (valor-chave, escrito em Erlang, usado por Powerset)
  • HBase (valor-chave, escrito em Java, usado pelo Bing)
  • Hipertabela (tabular, escrita em C ++, usada pelo Baidu)
  • Kai (valor-chave, escrito em Erlang)
  • MemcacheDB (valor-chave, escrito em C, usado pelo Reddit)
  • MongoDB (documento, escrito em C ++, usado pela Electronic Arts, Github, NY Times e Sourceforge)
  • Neo4j (gráfico, escrito em Java, usado por algumas universidades suecas)
  • Projeto Voldemort (valor-chave, escrito em Java, usado pelo LinkedIn)
  • Redis (valor-chave, escrito em C, usado pelo Craigslist, Engine Yard e Github)
  • Riak (valor-chave, escrito em Erlang, usado pela Comcast e Mochi Media)
  • Ringo (valor-chave, escrito em Erlang, usado pela Nokia)
  • Scalaris (valor-chave, escrito em Erlang, usado pelo OnScale)
  • Terrastore (documento, escrito em Java)
  • ThruDB (documento escrito em C ++, usado por JunkDepot.com)
  • Gabinete de Tóquio / Tokyo Tyrant (valor-chave, escrito em C, usado por Mixi.jp (site de rede social japonesa))

Gostaria de saber sobre problemas específicos que você - o leitor de SO - resolveu usando repositórios de dados e qual repositório de dados NoSQL você usou.

Questões:

  • Quais problemas de escalabilidade você usou os repositórios de dados NoSQL para resolver?
  • Qual repositório de dados NoSQL você usou?
  • Qual banco de dados você usou antes de mudar para um repositório de dados NoSQL?

Estou procurando experiências em primeira mão, portanto, não responda a menos que você tenha.


6
Bignose: I ver a recompensa como o meu 550 ponta reputação dada à pessoa que provê a resposta informativa mais :-)
knorv

1
Não se esqueça de soluções como o GemStone / S - um armazenamento de objetos Smalltalk.
Randal Schwartz

2
Não perca OrientDB ( orientechnologies.com )
Lvca

Respostas:


49

Mudei um pequeno subprojeto do MySQL para o CouchDB, para poder lidar com a carga. O resultado foi surpreendente.

Há cerca de 2 anos, lançamos um software auto-escrito em http://www.ubuntuusers.de/ (que é provavelmente o maior site da comunidade Linux alemã). O site foi escrito em Python e adicionamos um middleware WSGI que foi capaz de capturar todas as exceções e enviá-las para outro pequeno site com MySQL. Este pequeno site usou um hash para determinar diferentes erros e armazenou o número de ocorrências e a última ocorrência também.

Infelizmente, logo após o lançamento, o site traceback-logger não estava mais respondendo. Tivemos alguns problemas de bloqueio com o banco de dados de produção do site principal, que estava lançando exceções em quase todos os pedidos, além de vários outros bugs, que não exploramos durante a fase de teste. O cluster de servidores do site principal, chamado página de envio do traceback-logger várias k vezes por segundo. E isso foi demais para o pequeno servidor que hospedava o criador de logs de traceback (já era um servidor antigo, usado apenas para fins de desenvolvimento).

Nesse momento, o CouchDB era bastante popular, então decidi experimentar e escrever um pequeno traceback-logger com ele. O novo criador de logs consistia apenas em um único arquivo python, que fornecia uma lista de erros com opções de classificação e filtro e uma página de envio. E, em segundo plano, iniciei um processo do CouchDB. O novo software respondeu extremamente rapidamente a todas as solicitações e pudemos ver a enorme quantidade de relatórios automáticos de erros.

Uma coisa interessante é que a solução anterior estava sendo executada em um servidor dedicado antigo, onde o novo site baseado no CouchDB, por outro lado, estava sendo executado apenas em uma instância xen compartilhada com recursos muito limitados. E eu nem usei a força das lojas de valores-chave para escalar horizontalmente. A capacidade do CouchDB / Erlang OTP de lidar com solicitações simultâneas sem bloquear nada já era suficiente para atender às necessidades.

Agora, o logger CouchDB-traceback escrito rapidamente ainda está em execução e é uma maneira útil de explorar erros no site principal. De qualquer forma, cerca de uma vez por mês, o banco de dados se torna muito grande e o processo do CouchDB é interrompido. Mas então, o comando compact-db do CouchDB reduz o tamanho de vários GBs para alguns KBs novamente e o banco de dados está novamente em funcionamento (talvez eu deva considerar adicionar um cronjob lá ... 0o).

Em resumo, o CouchDB foi certamente a melhor escolha (ou pelo menos uma escolha melhor que o MySQL) para este subprojeto e ele faz seu trabalho bem.


Acho que eu li em algum lugar que você poderia fazer couchdb fazer a compressão automaticamente quando os dados não comprimidos atingiu um certo nível ...
Ztyx

50

Meu projeto atual, na verdade.

Armazenando 18.000 objetos em uma estrutura normalizada: 90.000 linhas em 8 tabelas diferentes. Demorou 1 minuto para recuperá-los e mapeá-los para o nosso modelo de objeto Java, com tudo indexado corretamente etc.

Armazenando-os como pares de chave / valor usando uma representação de texto leve: 1 tabela, 18.000 linhas, 3 segundos para recuperar todos eles e reconstruir os objetos Java.

Em termos de negócios: a primeira opção não era viável. Segunda opção significa que nosso aplicativo funciona.

Detalhes da tecnologia: rodando no MySQL para SQL e NoSQL! Aderência ao MySQL para um bom suporte a transações, desempenho e histórico comprovado por não corromper dados, dimensionar razoavelmente bem, suporte para clustering etc.

Nosso modelo de dados no MySQL agora é apenas campos-chave (inteiros) e o grande campo "value": basicamente, um grande campo de TEXTO.

Não acompanhamos nenhum dos novos players (CouchDB, Cassandra, MongoDB etc.) porque, embora cada um deles ofereça ótimos recursos / desempenho, sempre houve desvantagens para as nossas circunstâncias (por exemplo, suporte Java ausente / imaturo).

Benefício extra de (ab) usando MySQL - os bits do nosso modelo que fazer o trabalho relacional pode ser facilmente ligado a nossos armazenar dados de chave / valor.

Atualização: aqui está um exemplo de como representamos o conteúdo de texto, não o domínio de negócios real (não trabalhamos com "produtos"), pois meu chefe me matava, mas transmite a ideia, incluindo o aspecto recursivo (uma entidade, aqui um produto "contendo" outros). Esperamos que fique claro como, em uma estrutura normalizada, isso pode ser bastante útil, por exemplo, associar um produto à sua variedade de sabores, quais outros produtos estão contidos, etc.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

2
Onde estão os dois bancos de dados em questão (sql e NoSQL)?
mavnn

Ambos eram MySQL (editei minha resposta para fornecer essas informações, esqueci-as inicialmente). Mesmo banco de dados, resultados de desempenho muito diferentes das abordagens SQL e NoSQL. Muito feliz com a abordagem de chave / valor com o MySQL.
Brian

5
Oi Brian, seria possível fornecer um exemplo do esquema da sua estrutura normalizada e um exemplo dos pares de valores-chave "schema"? Também estamos enfrentando problemas de desempenho com uma estrutura normalizada e atualmente estamos considerando duas opções: desnormalizar nossas tabelas ou avançar para um repositório de dados NoSQL. Devido às taxas de licenciamento e manutenção que já estamos pagando, gostaríamos de alavancar nossa pilha Oracle atual e, portanto, estamos inclinados a uma solução RDBMS desnormalizada. Um exemplo seria interessante!
tth 24/02

@ Brian: Como 4 dos exemplos estão escritos em java, quais recursos de suporte a Java estavam ausentes ou imaturos? Não tenho experiência neste campo, mas isso me parece um pouco surpreendente.
Jimmy

tthong - não sei como incluir de forma concisa nosso esquema normalizado, mas adicionamos um exemplo de como armazenamos nosso conteúdo em um único campo de texto. É um pouco artificial, não pude incluir um exemplo real, já que meu chefe fica balístico, de modo que qualquer "problema" com esse "modelo de dados" é mais provável por esse motivo. Aconselho aferição Oracle e algumas outras soluções, mas se a sua organização tem experiência boa Oracle, DBAs, backups, etc, poderia ser uma boa opção a considerar
Brian

22

O site highscalability.com de Todd Hoff tem muita cobertura do NoSQL, incluindo alguns estudos de caso.

O DBMS colunar comercial da Vertica pode atender aos seus propósitos (mesmo que ele suporte SQL): é muito rápido comparado aos DBMSs relacionais tradicionais para consultas de análise. Veja o artigo recente do CACM de Stonebraker, et al., Contrastando a Vertica com a redução de mapa.

Atualização: E o Twitter selecionou Cassandra entre várias outras, incluindo HBase, Voldemort, MongoDB, MemcacheDB, Redis e HyperTable.

Atualização 2: Rick Cattell acaba de publicar uma comparação de vários sistemas NoSQL no High Performance Data Stores . E a opinião de highscalability.com no artigo de Rick está aqui .


3
Você também deve ler cacm.acm.org/magazines/2010/1/…
24/02/10

@ar: Obrigado, esse é um bom link. O pessoal da Vertica gerou uma quantidade razoável de controvérsia.
Jim Ferrans

8

Movemos parte de nossos dados do mysql para o mongodb, não tanto por escalabilidade, mas mais porque é mais adequado para arquivos e dados não tabulares.

Atualmente, na produção, armazenamos:

  • 25 mil arquivos (60 GB)
  • 130 milhões de outros "documentos" (350 GB)

com um volume de negócios diário de cerca de 10 GB.

O banco de dados é implantado em uma configuração "emparelhada" em dois nós (6x450GB sas raid10) com clientes apache / wsgi / python usando o mongodb python api (pymongo). A configuração do disco provavelmente é um exagero, mas é isso que usamos para o mysql.

Além de alguns problemas com os poços de threads do pymongo e a natureza de bloqueio do servidor mongodb, foi uma boa experiência.


Você poderia elaborar um pouco sobre os problemas que você nomeou, por favor?
Felixfbecker

5

Peço desculpas por contrariar seu texto em negrito, já que não tenho experiência em primeira mão, mas esse conjunto de postagens no blog é um bom exemplo de solução de um problema com o CouchDB.

CouchDB: Um Estudo de Caso

Essencialmente, o aplicativo de texto usava o CouchDB para lidar com o problema explosivo dos dados. Eles descobriram que o SQL era muito lento para lidar com grandes quantidades de dados de arquivo e os transferiram para o CouchDB. É uma excelente leitura, e ele discute todo o processo de descobrir quais problemas o CouchDB poderia resolver e como eles acabaram resolvendo-os.


5

Movemos alguns de nossos dados que costumamos armazenar no Postgresql e no Memcached para o Redis . Os armazenamentos de valores-chave são muito mais adequados para armazenar dados de objetos hierárquicos. Você pode armazenar dados de blob muito mais rápido e com muito menos tempo e esforço de desenvolvimento do que usar um ORM para mapear seu blob para um RDBMS.

Eu tenho um cliente de código aberto c # redis que permite armazenar e recuperar qualquer objeto POCO com 1 linha:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Os armazenamentos de valores-chave também são muito mais fáceis de expandir, pois você pode adicionar um novo servidor e particionar sua carga uniformemente para incluir o novo servidor. Importante, não há servidor central que limite sua escalabilidade. (embora você ainda precise de uma estratégia de hash consistente para distribuir suas solicitações).

Considero o Redis um 'arquivo de texto gerenciado' em esteróides que fornece acesso rápido, simultâneo e atômico a vários clientes; portanto, qualquer coisa que usei para usar um arquivo de texto ou um banco de dados incorporado, agora uso o Redis. Por exemplo, para obter um registro de erros contínuos combinados em tempo real para todos os nossos serviços (o que foi notoriamente uma tarefa difícil para nós), agora é realizado com apenas algumas linhas, basta aguardar o erro na lista do servidor Redis e em seguida, aparar a lista para manter apenas os últimos 1000, por exemplo:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

4

Não tenho experiências em primeira mão., Mas achei esta entrada de blog bastante interessante.


3

Acho que o esforço para mapear objetos de domínio de software (por exemplo, aSalesOrder, aCustomer ...) para um banco de dados relacional bidimensional (linhas e colunas) requer muito código para salvar / atualizar e depois instanciar uma instância de objeto de domínio de várias tabelas . Sem mencionar o impacto no desempenho de ter todas essas junções, todas essas leituras de disco ... apenas para exibir / manipular um objeto de domínio, como um pedido de vendas ou registro de cliente.

Mudamos para ODBMS (Object Database Management Systems). Eles estão além dos recursos dos sistemas noSQL listados. O GemStone / S (para Smalltalk) é um exemplo. Existem outras soluções ODBMS que possuem drivers para vários idiomas. Um dos principais benefícios do desenvolvedor, sua hierarquia de classes é automaticamente seu esquema, subclasses e tudo do banco de dados. Basta usar sua linguagem orientada a objetos para tornar os objetos persistentes no banco de dados. Os sistemas ODBMS fornecem uma integridade de transação no nível ACID, para que também funcione em sistemas financeiros.


3

Eu mudei do MySQL (InnoDB) para cassandra para um sistema M2M, que basicamente armazena séries temporais de sensores para cada dispositivo. Cada dado é indexado por (device_id, date) e (device_id, type_of_sensor, date). A versão do MySQL continha 20 milhões de linhas.

MySQL:

  • Configuração na sincronização mestre-mestre. Poucos problemas apareceram em torno da perda de sincronização . Foi estressante e, especialmente, no começo, poderia levar horas para corrigir.
  • O tempo de inserção não foi um problema, mas a consulta exigia mais e mais memória à medida que os dados cresciam. O problema é que os índices são considerados como um todo. No meu caso, eu estava usando apenas uma parte muito fina dos índices necessários para carregar na memória (apenas alguns por cento dos dispositivos eram frequentemente monitorados e estavam nos dados mais recentes).
  • Foi difícil fazer backup . O Rsync não pode fazer backups rápidos em grandes arquivos de tabela do InnoDB.
  • Logo ficou claro que não era possível atualizar o esquema de tabelas pesadas , porque levava muito tempo (horas).
  • A importação de dados levou horas (mesmo quando a indexação foi feita no final). O melhor plano de resgate era sempre manter algumas cópias do banco de dados (arquivo de dados + logs).
  • Mudar de uma empresa de hospedagem para outra foi realmente um grande negócio . A replicação tinha que ser tratada com muito cuidado.

Cassandra:

  • Ainda mais fácil de instalar do que o MySQL.
  • Requer muita RAM. Uma instância de 2 GB não pode ser executada nas primeiras versões, agora pode funcionar em uma instância de 1 GB, mas não é uma idéia (muitas descargas de dados). Dar 8 GB foi suficiente no nosso caso.
  • Depois de entender como você organiza seus dados, o armazenamento é fácil. Solicitar é um pouco mais complexo. Mas uma vez contornado, é muito rápido (você realmente não pode cometer erros, a menos que realmente queira).
  • Se o passo anterior foi feito corretamente, é e permanece super rápido.
  • Quase parece que os dados estão organizados para backup. Todos os novos dados são adicionados como novos arquivos. Pessoalmente, mas não é uma coisa boa, libero os dados todas as noites e antes de cada desligamento (geralmente para atualização), para que a restauração leve menos tempo, porque temos menos logs para ler. Ele não cria muitos arquivos, eles são compactados.
  • A importação de dados é rápida como o inferno. E quanto mais hosts você tiver, mais rápido. Exportar e importar gigabytes de dados não é mais um problema.
  • Não ter um esquema é uma coisa muito interessante, porque você pode fazer com que seus dados evoluam para seguir suas necessidades. O que pode significar ter versões diferentes dos seus dados ao mesmo tempo na mesma família de colunas.
  • Adicionar um host foi fácil (embora não rápido), mas não o fiz em uma configuração de vários datacenters.

Nota: Eu também usei elasticsearch (documento orientado com base no lucene) e acho que deve ser considerado como um banco de dados NoSQL. É distribuído, confiável e geralmente rápido (algumas consultas complexas podem ter um desempenho muito ruim).


2

Eu não. Gostaria de usar um armazenamento de valores-chave simples e gratuito que posso chamar em processo, mas tal coisa não existe na plataforma Windows. Agora eu uso o Sqlite, mas gostaria de usar algo como o Tokyo Cabinet. BerkeleyDB tem "problemas" de licença.

No entanto, se você deseja usar o sistema operacional Windows, sua escolha de bancos de dados NoSQL é limitada. E nem sempre há um provedor de C #

Eu tentei o MongoDB e era 40 vezes mais rápido que o Sqlite, então talvez eu deva usá-lo. Mas ainda espero uma solução simples no processo.


3
O provedor de AC # é principalmente irrelevante, pois esses sistemas NÃO possuem uma interface que se parece com um banco de dados convencional (daí o "NoSQL"), portanto uma interface do ADO.NET seria um pino redondo em um buraco quadrado.
precisa saber é o seguinte

2
Na verdade, você não precisa de um provedor que implemente a interface ADO.NET, mas ainda precisa de algum tipo de driver / provedor para associar o db ao .NET. Existe um para o MongoDB, mas ainda não é perfeito. O tratamento de exceções, por exemplo, precisa ser aprimorado.
Theo

Eu tenho um cliente c # de código aberto para redis @ code.google.com/p/servicestack/wiki/ServiceStackRedis, ele permite que você armazene 'POCOs digitados' como blobs de texto e fornece interfaces IList <T> e ICollection <T> para o servidor redis listas e conjuntos -SIDE, etc.
mythz

2

Usei o redis para armazenar mensagens de log entre máquinas. Foi muito fácil de implementar e muito útil. Redis realmente arrasa


2

Substituímos um banco de dados do postgres por um banco de dados de documentos do CouchDB, porque não ter um esquema fixo era uma grande vantagem para nós. Cada documento possui um número variável de índices usados ​​para acessar esse documento.


1

Eu usei o Couchbase no passado e encontramos problemas de reequilíbrio e diversos outros problemas. Atualmente estou usando o Redis em vários projetos de produção. Estou usando o redislabs.com, que é um serviço gerenciado para Redis que cuida de dimensionar seus clusters Redis. Publiquei um vídeo sobre persistência de objetos no meu blog em http://thomasjaeger.wordpress.com que mostra como usar o Redis em um modelo de provedor e como armazenar seus objetos C # no Redis. Dê uma olhada.


Sei que isso é um tiro no escuro agora, mas que problemas no reequilíbrio você teve em particular?
quer

1

Gostaria de encorajar qualquer pessoa que esteja lendo isso a experimentar o Couchbase mais uma vez agora que o 3.0 está disponível. Existem mais de 200 novos recursos para iniciantes. Os recursos de desempenho, disponibilidade, escalabilidade e gerenciamento fácil do Couchbase Server criam um banco de dados extremamente flexível e altamente disponível. A interface do usuário de gerenciamento é integrada e as APIs descobrem automaticamente os nós do cluster para que não haja necessidade de um balanceador de carga do aplicativo para o banco de dados. Embora não tenhamos um serviço gerenciado no momento, você pode executar o couchbase em coisas como AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers como CloudSoft e muito mais. Em relação ao reequilíbrio, depende do que você está se referindo especificamente, mas o Couchbase não reequilibra automaticamente após uma falha do nó, conforme projetado, mas um administrador pode configurar o failover automático para a falha do primeiro nó e, usando nossas APIs, você também pode obter acesso aos vbuckets de réplica para leitura antes de ativá-los ou usar o RestAPI, para aplicar um failover por uma ferramenta de monitoramento. Este é um caso especial, mas é possível fazer isso.

Nós tendemos a não reequilibrar praticamente em qualquer modo, a menos que o nó esteja completamente offline e nunca mais volte ou um novo nó esteja pronto para ser equilibrado automaticamente. Aqui estão alguns guias para ajudar qualquer pessoa interessada em ver o que é um dos bancos de dados NoSQL com maior desempenho.

  1. Couchbase Server 3.0
  2. Guia de Administração
  3. API REST
  4. Guias do desenvolvedor

Por fim, também encorajo você a verificar o N1QL para consultas distribuídas:

  1. Tutorial do N1QL
  2. Guia N1QL

Obrigado pela leitura e informe-me ou a outras pessoas se precisar de mais ajuda!

Austin


0

Eu usei o Vertica no passado. Ele se baseia na compactação colunar, agiliza as leituras de disco e reduz as necessidades de armazenamento para aproveitar ao máximo seu hardware. Carregamentos de dados mais rápidos e simultaneidade mais alta permitem fornecer dados de análise a mais usuários com latência mínima.

Anteriormente, estávamos consultando o banco de dados Oracle com bilhões de registros e o desempenho foi muito abaixo do ideal. As consultas demoravam de 8 a 12 segundos para serem executadas, mesmo após a otimização com o SSD. Por isso, sentimos a necessidade de usar um banco de dados mais rápido, otimizado para leitura e orientado a análises. Com os Vertica Clusters por trás da camada de serviço enxuta, poderíamos executar APIs com desempenho de menos de um segundo.

A Vertica armazena dados em projeções em um formato que otimiza a execução da consulta. Semelhante às visualizações materializadas, as projeções armazenam conjuntos de resultados no disco OU SSD em vez de computá-los sempre que são usados ​​em uma consulta. As projeções fornecem os seguintes benefícios:

  1. Compactar e codificar dados para reduzir o espaço de armazenamento.
  2. Simplifique a distribuição no cluster de banco de dados.
  3. Forneça alta disponibilidade e recuperação.

A Vertica otimiza o banco de dados distribuindo dados por cluster usando a segmentação.

  1. A segmentação coloca uma parte dos dados em um nó.
  2. Distribui uniformemente dados em todos os nós. Assim, cada nó executa uma parte do processo de consulta.
  3. A consulta é executada no cluster e cada nó recebe o plano de consulta.
  4. Os resultados das consultas são agregados e usados ​​para criar a saída.

Para mais informações, consulte a documentação da Vertica em https://www.vertica.com/knowledgebase/

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.