A criação de Gerenciáveis ​​Estruturas de Dados Big

Como a computação mudou-se para o mercado comercial, os dados foram armazenados em arquivos simples que impuseram nenhuma estrutura. Hoje, grande dados requer estruturas de dados gerenciáveis. Quando as empresas necessários para chegar a um nível de compreensão detalhada sobre os clientes, eles tiveram que aplicar métodos de força bruta, incluindo modelos de programação muito detalhados para criar algum valor.

Mais tarde, na década de 1970, as coisas mudaram com a invenção do modelo de dados relacional eo sistema de gerenciamento de banco de dados relacional (RDBMS) que impôs estrutura e um método para melhorar o desempenho. Mais importante ainda, o modelo relacional adicionou um nível de abstração para que fosse mais fácil para os programadores para satisfazer as demandas de negócios crescentes para extrair valor de dados.

O modelo relacional oferecido um ecossistema de ferramentas a partir de um grande número de empresas de software emergentes. Encheu uma crescente necessidade de ajudar as empresas a organizar melhor seus dados e ser capaz de comparar as transações de uma geografia para outro.

Além disso, ele ajudou os gerentes de negócios que queriam ser capaz de examinar as informações, tais como inventário e compará-lo com informações sobre o pedido do cliente para fins de tomada de decisão. Mas um problema surgiu a partir dessa demanda explosiva por respostas: Armazenar este volume crescente de dados era cara e acessando foi lento. Para piorar as coisas, os lotes de duplicação de dados existiam, e o valor de negócio real de que os dados foi difícil de medir.

Quando o volume de dados que as organizações necessárias para gerenciar cresceu fora de controle, o armazém de dados forneceu uma solução. O armazém de dados permitiu que a organização de TI para selecionar um subconjunto dos dados sendo armazenados de forma que seria mais fácil para a empresa para tentar obter insights.

O armazém de dados destinava-se a ajudar as empresas a lidar com cada vez maiores quantidades de dados estruturados que precisavam ser capazes de analisar, reduzindo o volume dos dados a algo menor e mais focado em uma área específica do negócio. Encheu a necessidade de separar o processamento de apoio à decisão operacional e de apoio à decisão - por motivos de desempenho.

Armazéns, muitas vezes armazenar dados de anos anteriores para a compreensão do desempenho organizacional, identificando tendências e ajudando a expor padrões de comportamento. É também fornecida uma fonte integrada de informações a partir de várias fontes de dados que podem ser utilizados para a análise. Hoje, ambos os sistemas de gerenciamento de conteúdo e data warehouses são capazes de tirar proveito das melhorias na escalabilidade de hardware, tecnologias de virtualização, e a capacidade de criar sistemas de hardware e software integrados.

Às vezes, esses dados armazéns próprios eram demasiado complexo e grande e não oferecem a velocidade e agilidade que a empresa requerida. A resposta foi um refinamento dos dados a ser gerido através de data marts. Estes data marts se concentraram em questões de negócios específicas e apoiou a necessidade da empresa para consultas rápidas. O armazém tem evoluído para apoiar as tecnologias emergentes, tais como sistemas integrados e dispositivos de dados.

data warehouses e data marts resolvido muitos problemas para as empresas que precisam de uma maneira consistente para gerenciar dados transacionais maciças. Mas quando se trata de gerenciar grandes volumes de dados não estruturados ou semi-estruturados, o armazém não era capaz de evoluir o suficiente para responder às novas exigências.

Para complicar, armazéns de dados são normalmente alimentados em intervalos de lotes, geralmente semanal ou diária. Isso é bom para o planejamento, relatórios financeiros e campanhas de marketing tradicionais, mas é muito lento para ambientes empresariais e de consumidores cada vez mais em tempo real.

Como as empresas seriam capazes de transformar suas abordagens de gerenciamento de dados tradicionais para lidar com o volume crescente de elementos de dados não estruturados? A solução não surgiu durante a noite. Como as empresas começaram a armazenar dados não estruturados, os vendedores começaram a adicionar recursos como BLOBs (objetos binários grandes).

Em essência, um elemento de dados não estruturados seriam armazenados numa base de dados relacional como um pedaço contíguo de dados. Este objeto pode ser rotulado, mas você não podia ver o que estava dentro daquele objeto. Claramente, isso não ia resolver em mudança dos clientes ou necessidades de negócios.

Digite o sistema de gerenciamento de banco de dados objeto (ODBMS). O banco de dados objeto armazenado no BLOB como um conjunto endereçável de peças de modo que você pudesse ver o que estava lá dentro. Ao contrário do BLOB, que era uma unidade independente anexado a um banco de dados relacional tradicional, o banco de dados de objeto fornecido uma abordagem unificada para lidar com dados não estruturados.

bases de dados de objectos incluem uma linguagem de programação e uma estrutura para os elementos de dados de modo que é mais fácil de manipular vários objectos de dados sem programação e junta-se complexo. As bases de dados de objeto introduzido um novo nível de inovação que ajudou a levar à segunda onda de gerenciamento de dados.