20 bilhões de linhas / Mês - HBase / colmeia / Greenplum / O quê?

votos
31

Eu gostaria de usar sua sabedoria para pegar a solução certa para um sistema de armazenamento de dados. Aqui estão alguns detalhes para entender melhor o problema:

Os dados são organizados em uma estrutura de esquema em estrela com um fato BIG e ~ 15 dimensões.
Linhas 20B fato por mês
10 Dimensões com centenas de linhas (um pouco hierarquia)
5 dimensões com milhares linhas
2 dimensões com ~ 200K linhas
2 grandes dimensões com linhas 50M-100M

Duas consultas típicas executadas contra este DB

Principais membros em dimq:

select    top X dimq, count(id) 
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 
group by  dimq 
order by  count(id) desc

Medidas para evitar uma tupla:

select    count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),...
from      fact 
where     dim1 = x and dim2 = y and dim3 = z 

Questões:

  1. Qual é a melhor plataforma para executar essas consultas
  2. Que tipo de hardware necessário
  3. Onde ele pode ser hospedado (EC2?)


    (Por favor ignore importação e carregamento questões no momento)

Tnx,
Ageu.

Publicado 09/12/2008 em 22:05
fonte usuário
Em outras línguas...                            


7 respostas

votos
55

Eu não posso forçar este bastante: Obter algo que funciona muito bem com ferramentas de relatórios off-the-shelf.

20 bilhões de linhas por mês coloca em território VLDB, então você precisa de particionamento. As dimensões baixa cardinalidade Também gostaria de sugerir que os índices bitmap seria uma vitória desempenho.

  • Esqueça os sistemas em nuvem ( Hive , HBase ) até que tenham suporte SQL maduro. Para uma aplicação de data warehouse você quer algo que trabalha com ferramentas de relatórios convencionais. Caso contrário, você vai encontrar-se perpetuamente atolado escrito e manter programas de relatório ad-hoc.

  • Os volumes de dados são administráveis com um SGBD mais convencionais como Oracle - Eu sei de uma grande empresa de telecomunicações europeia que carrega 600GB por dia em um a Oracle banco de dados. Todas as outras coisas sendo iguais, isso é duas ordens de magnitude maior do que os seus volumes de dados, de modo arquiteturas de disco compartilhado ainda tem espaço para você. Um compartilhado nada arquitetura como Netezza ou Teradata provavelmente será mais rápido ainda, mas estes volumes não estão em um nível que está além de um sistema de disco compartilhado convencional. Tenha em mente, porém, que estes sistemas são todos muito caro.

  • Também tenha em mente que MapReduce é não um algoritmo de seleção de consulta eficiente . É fundamentalmente um mecanismo para distribuição de cálculos de força bruta. Greenplum tem um back-end MapReduce, mas um motor de nada compartilhada propositadamente construído será muito mais eficiente e fazer mais trabalho por menos hardware.

Minha opinião sobre isso é que Teradata ou Netezza provavelmente seria a ferramenta ideal para o trabalho, mas definitivamente o mais caro. A Oracle , Sybase IQ ou mesmo SQL Server também lidar com os volumes de dados envolvidos, mas será mais lento - eles são arquiteturas de disco compartilhado, mas ainda pode gerir este tipo de volume de dados. Veja Esta postagem para um resumo sobre os recursos relacionados VLDB em Oracle e SQL Server, e ter em mente que a Oracle acaba de introduzir a plataforma de armazenamento Exadata também.

Meu plano capacidade de back-of-a-fag-packet sugere talvez 3-5 TB ou mais por mês, incluindo índices para Oracle ou SQL Server. Provavelmente menos no Oracle com índices de mapa de bits, apesar de uma folha de índice tem um ROWID de 16 bytes no Oracle contra uma referência página 6 bytes no SQL Server.

Sybase IQ faz uso extensivo de índices de bitmap e é otimizado para consultas de data warehouse. Apesar de uma arquitetura de disco compartilhado, é muito eficiente para este tipo de consulta (IIRC foi a arquitetura orientada a coluna original). Este seria provavelmente melhor do que Oracle ou SQL Server, pois é especializado para este tipo de trabalho.

Greenplum pode ser uma opção mais barata, mas eu nunca realmente é utilizado, então não posso comentar sobre como ele funciona bem na prática.

Se você tem 10 dimensões com apenas algumas centenas de linhas considere fundi-las em uma única dimensão lixo que vai emagrecer a sua tabela de fatos mediante a fusão das dez chaves para apenas um. Você ainda pode implementar hierarquias em uma dimensão lixo e isso iria bater 1/2 ou mais fora do tamanho de sua tabela de fatos e eliminar uma grande quantidade de uso do disco por índices.

Eu recomendo fortemente que você vá com algo que funciona muito bem com um corte transversal razoável de ferramentas de relatórios. Isso significa que um front-end SQL. Sistemas comerciais como o Crystal Reports permitem relatórios e análises a ser feito por pessoas com um conjunto mais facilmente obtidos de habilidades SQL. O mundo open-source também gerou BIRT , Jasper Reports e Pentaho. . Hive ou HBase colocá-lo no negócio de construção de um front-end personalizado, que você realmente não quer a menos que você está feliz em passar os próximos 5 anos escrevendo formatadores de relatórios personalizados em Python.

Finalmente, hospedá-lo em algum lugar que você pode facilmente obter um feed de dados rápida de seus sistemas de produção. Isso provavelmente significa que o seu próprio hardware em seu próprio centro de dados. Este sistema será de E / S ligado; que está fazendo o processamento simples em grandes volumes de dados. Isto significa que você precisará de máquinas com subsistemas de disco rápidos. Os provedores de nuvem tendem a não suporta este tipo de hardware, uma vez que é uma ordem de magnitude mais caro do que o tipo de caixa de 1U descartável tradicionalmente usada por estes equipamentos. Rápido Disk I / O não é uma força de arquiteturas em nuvem.

Respondeu 09/12/2008 em 22:49
fonte usuário

votos
9

Eu tenho tido grande sucesso com vertica . Estou neste momento a carregar em qualquer lugar entre 200 a 1.000 milhões linhas em um dia - uma média de cerca de 9 billons remar um mês - apesar de eu ter ido tão alto quanto 17 bilhões em um mês. Eu tenho perto de 21 dimensões e as consultas correr incrivelmente rápido. Nós mudou-se do sistema mais antigo quando nós simplesmente não tinha as janelas de tempo para fazer a dataload.

fizemos um estudo muito exaustivo e estudo de soluções diferentes - e praticamente olhou para tudo no mercado. Embora ambos Teradata e Netezza teria adequado para nós, eles eram simplesmente demasiado caro para nós. Vertica vencê-los tanto na relação preço / desempenho. É pela forma como um banco de dados colunar.

Temos cerca de 80 usuários agora - e espera-se crescer para cerca de 900 até o final do próximo ano, quando nós começamos a implantar-se completamente.

Estamos usando extensivamente serviços ASP.NET/dundas/reporting para relatórios. Ele também desempenha agradável com soluções de relatórios de terceiros - embora não tenhamos tentado.

Pela maneira que você vai usar para dataload? Estamos usando informatica e têm sido muito satisfeito com ele. SSIS nos levou até a parede.

Respondeu 20/12/2008 em 01:50
fonte usuário

votos
3

Usando HBase e JasperServer relatórios hbase pluging, relatórios decentes podem ser criados. Low OLAP latência podem ser criados em HBase. Isto irá funcionar o mesmo que o SQL. JasperServer HBase plug-in fornece linguagem de consulta HBase que é uma extensão HBase comando de digitalização.

Respondeu 01/10/2012 em 10:23
fonte usuário

votos
2

Estou curioso para saber o que você finalmente selecionados. Sua pergunta era ao fim da cauda de 2008. Hoje, a situação é diferente com HBase, Greenplum, porco etc. dando SQL como o acesso.

Respondeu 25/01/2012 em 17:22
fonte usuário

votos
2

Leia o site da Monash: http://www.dbms2.com/ Ele escreve sobre grandes bases de dados.

Talvez você possa usar o Oracle Exadata ( http://www.oracle.com/solutions/business_intelligence/exadata.html e http://kevinclosson.wordpress.com/exadata-posts/ ) ou talvez você pode usar Hadoop. Hadoop é gratuito.

Respondeu 20/12/2008 em 01:17
fonte usuário

votos
0

NXC, você tem certeza sobre esses 600 bilhões de linhas por dia? Mesmo se uma linha seria apenas um byte, que é de 600 GB de dados diariamente. Assumindo um mais razoáveis ​​100 bytes por linha, estamos falando de 60 TB de dados por dia, 1,8 PB por mês. Eu realmente duvido que alguém está bombeando que muitos dados através do Oracle.

Outras fontes parecem confirmar que a Oracle se torna bastante difícil de lidar quando o volume de dados atinge números TB de 2 dígitos.

Respondeu 12/12/2008 em 14:42
fonte usuário

votos
0

Uma alternativa para um número reduzido de utilizadores seria um (beowulf) cluster. 20K, você compra 50 nettops com 500G cada um. Isso é cerca de potência de pico 3KW. Ou 4 meses de armazenamento em nuvem.

Respondeu 11/12/2008 em 14:41
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more