100 TeraBytes Capacity Database - Recursos e estimativas de tempo


10

Estou trabalhando em um cálculo de "parte traseira do envelope" para uma configuração de banco de dados de relatórios de 100 TB. Estou procurando pensamentos dos especialistas aqui. Ambiente proposto:

  1. Capacidade de armazenamento ~ 100 TB
  2. Tabelas ~ 200, tamanhos que variam de 1 GB a 5 TB. tamanho médio pode estar entre 100GB-200GB
  3. ETL - os trabalhos podem exigir junção entre tabelas de dezenas de milhões de linhas, com chaves de junção que variam de 10 a 500 bytes. essas junções devem terminar em menos de 2-5 minutos
  4. Seleção ao vivo - inicialmente, apenas interessado em velocidades selecionadas. deve suportar 500 seleções / segundo. As atualizações / segundo serão um número relativamente menor e podem ser ignoradas para este exercício.
  5. precisa de disponibilidade 24x7. 2 servidores de banco de dados independentes devem estar disponíveis para atender chamadas selecionadas (com dados replicados).

Questões:

  1. No momento, estou olhando para o Oracle. Como tem sido sua experiência com outras soluções comerciais (ou) de código aberto para grandes bancos de dados?
  2. Qual sistema operacional de hardware você viu funcionar melhor? Estou planejando o Linux na Dell.
  3. O armazenamento em rede, como o NetApp, é obrigatório? Que problemas você prevê com o uso de discos comerciais prontos para uso?
  4. Quando o hardware e o sistema operacional estiverem prontos, quanto tempo você reservaria para instalar, configurar o banco de dados, o armazenamento etc.
  5. Quais composições de equipe funcionaram melhor nos ambientes que você observou? Quero dizer, os vários administradores (administrador de SO, Oracle DB Admin?) Necessários para gerenciar e operar essa configuração. Quantos deles podem ser necessários para obter um tempo de atividade 24x7.
  6. Qualquer aproximação / intervalo em licenças de banco de dados, custos de armazenamento em rede.

Eu sei que não tenho todos os detalhes do ambiente. Não estou procurando detalhes exatos, basta uma aproximação. Embora algumas das perguntas possam ser melhor respondidas pelos gerentes, estou interessado na perspectiva dos administradores. Agradeço sua opinião.


11
Eu acho que essa pergunta é muito ampla para responder. Vou deixar os outros verem se eles concordam antes de eu progredir.
Philᵀᴹ

11
@ Phil Concordo, não tinha certeza se isso deveria ser dividido em várias perguntas, para que usuários com conhecimentos diferentes pudessem responder a diferentes partes. Mas a descrição do ambiente é a mesma para todas as perguntas; portanto, você fez uma única pergunta. Eu acho que essa pode ser minha primeira pergunta sobre SO (embora seja um usuário comum de SO), então me considere como novato e, se houver uma maneira melhor de fazer essa pergunta, sugira.
Kash

10
Isso soa como um projeto de vários milhões de dólares. Você basearia esse projeto nos conselhos do fórum?
Remus Rusanu

11
@RemusRusanu Esta não é a única fonte de informação. Quando isso vai para a fase de avaliação formal, haverá muitas outras atividades. Eu tenho uma opinião alta dos conselhos que os usuários dão. Enquanto escrevia a pergunta, tinha certeza de que encontraria alguns detalhes muito úteis nos quais não havia pensado.
Kash

11
@RemusRusanu - é. O último preço que vi para o Netezza foi de US $ 20k / TB para os sistemas TwinFin. Não sei ao certo qual seria a caixa Exadata dessa capacidade. Além disso, o SLA é bastante agressivo e o sistema parece ter uma grande base de usuários. Pode ser necessário um número maior de servidores de data mart para lidar com a carga da consulta.
ConcernedOfTunbridgeWells

Respostas:


21

Primeiras impressões

  1. Dependendo dos seus requisitos de desempenho, 100 TB é um volume de dados bastante agressivo. Se você deseja Oracle, verifique os sistemas Exadata. Além disso, dê uma olhada nas ofertas de Netezza ou Teradata. Com esse volume de seleções, convém examinar um front end baseado em OLAP ou, pelo menos, o uso bastante agressivo de visualizações materializadas e reescrita de consultas. Você não obterá 500 digitalizações de mesa / s em nada.

    Para itens com requisitos de latência menos rigorosos, convém considerar um número maior de data marts para fornecer a capacidade de geração de relatórios à sua comunidade de usuários. Nesse caso, o SQL Server e o SSAS podem ser uma opção para os data marts, pois o licenciamento em um número maior de servidores será mais barato do que tentar fazer o mesmo com o Oracle.

  2. Veja (1). O hardware convencional em uma arquitetura de disco compartilhado provavelmente será lento nesse tamanho de conjunto de dados.

  3. NÃO! Se alguém sugerir NFS, dê um bom chute. Armazenamento de conexão direta ou SAN de vários controladores com muitos controladores de médio alcance. Pense em termos de, talvez, algumas dúzias de controladores da série MD3000 ou algo semelhante - se você não optar por uma plataforma de 'big data' criada especificamente.

  4. Obtenha um especialista em armazenamento com experiência nas plataformas de data warehouse da gama PB. Você provavelmente está pronto para um trabalho de desenvolvimento de ETL significativo e para muitos testes se precisar cumprir um SLA rígido.

  5. 24x7 em um data warehouse é ambicioso na melhor das hipóteses. Esta é uma plataforma de relatórios operacionais? Talvez você possa elaborar um pouco seus requisitos.

  6. Sphincter - extremamente caro e dependente dos seus requisitos de desempenho. A última vez que vi (alguns anos atrás) o Netezza citava US $ 20.000 / TB para sistemas TwinFin, tornando sua plataforma US $ 2 milhões por 100 TB mais o custo do seu servidor redundante e hardware de backup. O Exadata é, acredito, um pouco mais barato, mas não tenho preços à mão.

    Dê uma olhada no Netezza, no Exadata e na plataforma Teradata para comparação e nos custos do Ab Initio como uma ferramenta ETL.

Esse é um conjunto de requisitos bastante agressivo - normalmente, 24 horas por dia, 7 dias por semana em um data warehouse, e os volumes de dados são grandes o suficiente para colocá-lo no reino de uma plataforma de 'big data'. Se você possui um requisito de relatório operacional, deve analisar cuidadosamente o que é isso. Mantenha-o separado de suas análises, a menos que você tenha um motivo específico (por exemplo, um feed de dados de mercado de baixa latência) para não fazê-lo. Misturar requisitos operacionais e analíticos na mesma plataforma é péssimo.

Eu acho que você realmente precisa contratar especialistas para avaliar suas necessidades. Sem olhar mais de perto o que você está tentando alcançar, tudo o que posso dar é algumas sugestões empíricas sobre o que fazer ou não.


8

Algumas outras opções a serem consideradas ao lidar com grandes volumes de dados como este incluem:

  1. Tudo o que @ConcernedOfTunbridgeWells postou
  2. Greenplum da EMC
  3. Data Warehouse Paralelo da Microsoft

Não planeje economizar nos custos de hardware em qualquer lugar. Um sistema com esses tipos de especificações custará muito dinheiro.

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.