IBM Netezza Performance Server Avaliações e Detalhes do Produto - Página 8

Alta taxa de processamento. O cálculo de fatos em tempo real é muito robusto e retorna dados sobre grandes quantidades de dados rapidamente. Isso nos ajuda a criar e relatar fatos diretamente a partir de dados desagregados em tempo real.

Estamos lidando com um grande volume de dados de transações e pré-agregar os fatos seria proibitivamente caro e quase impossível de fazer. Ter a capacidade de realizar operações em massa de dados em tempo real é muito útil para nossa organização. Análise coletada por e hospedada no G2.com.

O tamanho máximo que uma caixa Netezza pode suportar é pré-determinado pela configuração. Ou seja, não é escalável infinitamente.

O custo dos servidores é muito grande para uma empresa de pequeno porte. Análise coletada por e hospedada no G2.com.

Se você está procurando um banco de dados com alta capacidade de armazenamento e, paralelamente, alto desempenho, então o Netezza é o melhor para isso. O Netezza é útil para appliances de data warehouse e aplicações de análises avançadas, incluindo uso em data warehousing empresarial, inteligência de negócios, análises preditivas e planejamento de continuidade de negócios.

Equipe de Suporte Técnico Rápido da IBM Análise coletada por e hospedada no G2.com.

Você precisa conhecer a melhor maneira de projetar seu banco de dados. Como usar a chave de organização e a chave de distribuição para torná-lo melhor e o melhor. Não há nada nisso para não gostar. Uma sugestão que quero dar à equipe da IBM é que tornem o NZadmin melhor do que os outros... Análise coletada por e hospedada no G2.com.

Não tendo muita experiência com outras soluções de BI/DW, gosto que a administração do dispositivo seja tão simples. De uma perspectiva de design, gosto que haja uma consideração cuidadosa em ofuscar os elementos físicos e lógicos do dispositivo. Análise coletada por e hospedada no G2.com.

Minha organização investiu milhões na aquisição de aparelhos Netezza quando a Netezza era uma empresa independente. Não para culpar a IBM aqui, mas com a segurança sendo um foco principal, eu não fiquei entusiasmado com a ideia de qualquer organização adquirir novo hardware para se beneficiar da criptografia de hardware. Pessoalmente, acho que deveria haver algum suporte legado para não ter apenas uma solução de criptografia baseada em software. Análise coletada por e hospedada no G2.com.

A velocidade bruta do sistema permite um processo de desenvolvimento que normalmente não é realizado. Por exemplo, é possível executar testes de desempenho completos enquanto você testa unidades. Você também pode criar tabelas que são muito maiores do que você faria em um banco de dados típico (por exemplo, armazenando linhas atuais e de arquivo nas mesmas tabelas).

A simplicidade do sistema permite uma manutenção mínima. O envolvimento do DBA pode ser quase nulo. Análise coletada por e hospedada no G2.com.

A simplicidade do sistema também pode causar problemas em casos de uso mistos.

Em outros bancos de dados, você também tem a capacidade de melhorar o desempenho por vários meios, como particionamento, indexação, alocação de hardware de servidor, etc. Netezza essencialmente tem apenas duas maneiras—no que diz respeito à arquitetura física—de lidar com o desempenho: ordenação de dados e distribuição de dados.

A ordenação de dados é feita diretamente na tabela, evitando a necessidade de índices clusterizados. Mas isso só é útil se a consulta que você executa utiliza essa ordenação. Por exemplo, se você ordenar por data tornando o campo Data a chave ORGANIZE BY, qualquer consulta que não utilize Data na cláusula WHERE terá que fazer uma varredura na tabela. Você pode criar visões materializadas que essencialmente agem como índices, mas não pode usar tanto MVs quanto chaves ORGANIZE BY. Em outras palavras, se você usar até mesmo uma MV para ordenar, não pode forçar a ordenação dos dados na tabela a menos que realmente recarregue os dados com uma cláusula ORDER BY na instrução INSERT. O problema com as MVs é que, embora ajam como um índice, você tem que atualizá-las como uma MV típica para ordenar qualquer novo dado. Em um sistema que é carregado ou atualizado intradiariamente, isso pode causar problemas.

A distribuição tem dois componentes que às vezes podem estar em conflito entre si: distribuir uniformemente os dados para compartilhar a carga de trabalho e colocar dados em colocalização para junções. Mas se a coluna que faz sentido distribuir para fins de colocalização não distribui uniformemente os dados, você será forçado a fazer um compromisso em um em prol do outro.

Além disso, em um esquema estrela, você pode colocar em colocalização a chave estrangeira da tabela de fatos com a chave primária de uma dimensão, mas isso é melhor usado se você consultar com um parâmetro nessa dimensão na cláusula WHERE. Se você executar uma consulta que não pode filtrar nessa dimensão, a chave de distribuição pode não ajudar. Além disso, você só pode escolher uma dimensão para colocar em colocalização com o fato. Escolher uma distribuição de múltiplas colunas do fato com base em várias chaves de dimensão não coloca o fato em colocalização com _cada_ dimensão. Em vez disso, distribui o fato com uma chave de hash baseada na combinação concatenada dos valores da chave de distribuição de múltiplas colunas (ou seja, o fato não será colocado em colocalização com _nenhuma_ dimensão).

Além disso, o fato de que Netezza não lançou opções em memória ou colunares me faz questionar se a arquitetura do appliance permite tais possibilidades. Em outras palavras, a falta de flexibilidade pode estar surgindo novamente se a natureza do appliance não permitir tal funcionalidade variada. Análise coletada por e hospedada no G2.com.

Em primeiro lugar, o Netezza requer administração mínima de DBA. Isso significa que pode ser mantido com menos recursos de sys e dba. Em segundo lugar, não possui recurso de disco compartilhado, nada como o armazenamento compartilhado do Oracle. Tem sua própria arquitetura e algoritmo para mover dados. E não está usando índice algum. O chamado "Zone mapping" ajuda muito em consultas pesadas dos usuários de BI. Análise coletada por e hospedada no G2.com.

Nossa empresa Netezza não foi realmente construída para replicação em tempo real. Tenho que gastar muito tempo para resolver esse problema chamado CDC. Análise coletada por e hospedada no G2.com.

Este é um ótimo aparelho de data warehouse se você deseja manter as coisas simples e resolver problemas de dados que exigem escala. Análise coletada por e hospedada no G2.com.

Muitas falhas de hardware (embora intercambiáveis a quente) causando solicitações constantes ao suporte da IBM. Análise coletada por e hospedada no G2.com.

Incrivelmente rápido para consultas.

Muito pouca manutenção, portanto, precisa de suporte mínimo do DBA. Análise coletada por e hospedada no G2.com.

Concorrência - o desempenho diminui com o número de consultas simultâneas. Se houver mais de 48 consultas simultâneas, elas são enfileiradas.

Escalabilidade - Se seus dados aumentarem, você precisará de um aparelho maior. Não é possível adicionar incrementalmente.

Backup e Replicação :-(

Alguns tipos de Consultas Correlacionadas não são suportados. Análise coletada por e hospedada no G2.com.

Como arquiteto de data warehouse, construí um data mart com esquema estrela no Netezza. Gostei da arquitetura paralela do Netezza, que ajudou a processar múltiplos terabytes de dados em velocidade relâmpago. Análise coletada por e hospedada no G2.com.

Não há muito do que não gostar. Mas seria ótimo se o Netezza melhorasse seu sistema de monitoramento de desempenho e alertas. Análise coletada por e hospedada no G2.com.

Imenso tempo para valor

Baixos custos administrativos

Ótimas capacidades de compressão de hardware

Escalabilidade Análise coletada por e hospedada no G2.com.

Carregamento de utilitário não tão rápido quanto a concorrência

Grande sobrecarga para conversões de uma implementação existente para Netezza (principalmente devido à falta de índices) Análise coletada por e hospedada no G2.com.

Tenho usado o Netezza há três anos, trabalhei extensivamente com TwinFin, Striper e agora com Mako. Posso definitivamente dizer que é o melhor processamento de consultas analíticas que já vi. Este é um bom candidato para igualar ou superar a velocidade de processamento de mainframe em termos de processamento em lote. Análise coletada por e hospedada no G2.com.

como eles vão lidar com big data Análise coletada por e hospedada no G2.com.