A transição de um modelo de RDBMS para HBase
Se você está enfrentando a fase de design para a sua aplicação e você acredita que HBase seria um bom ajuste, em seguida, projetar suas chaves de linha e de esquema para se ajustar ao modelo de dados HBase e arquitetura é a abordagem correta. No entanto, às vezes, faz sentido para mover um banco de dados projetado originalmente para um RDBMS para HBase.
Um cenário comum em que esta abordagem faz sentido é uma instância de banco de dados MySQL que atingiu os seus limites de escalabilidade. Existem técnicas para dimensionar horizontalmente uma instância de MySQL (sharding, em outras palavras), mas este processo é normalmente complicado e problemático porque MySQL simplesmente não foi projetado originalmente para sharding.
A transição do modelo relacional para o modelo HBase é uma disciplina relativamente nova. No entanto, certos padrões estabelecidos de pensamento estão surgindo e reuniram-se em três princípios fundamentais a seguir quando se aproxima uma transição. Estes princípios são desnormalização,duplicação, e chaves inteligentes (DDI).
desnormalização: O modelo de banco de dados relacional depende de a) um esquema de banco de dados normalizado e b) junta-se entre as mesas para responder a operações SQL. normalização de dados é uma técnica que protege contra a perda de dados, redundância e outras anomalias como os dados são atualizados e recuperados.
Há um certo número de regras os especialistas seguem para se chegar a um esquema de base de dados normalizada (e normalização de dados é um estudo completo em si), mas o processo geralmente envolve a divisão tabelas maiores em mesas mais pequenas e que define as relações entre eles. desnormalização banco de dados é o oposto de normalização, onde menor, mesas mais específicos são juntou-se à maior mesas, mais gerais.
Este é um padrão comum quando a transição para HBase porque se junta não são fornecidos através de tabelas, e junta-se pode ser lento uma vez que envolvem operações de disco caros. Protegendo contra a atualização e anomalias de recuperação agora é o trabalho de seu aplicativo cliente HBase, uma vez que as protecções oferecidas você pela normalização são nulas.
Duplicação: Como você desnormalizar seu esquema de banco de dados, você provavelmente vai acabar duplicando os dados, porque pode ajudar a evitar operações de leitura caros em várias tabelas. Não se preocupar com o armazenamento extra (dentro da razão, é claro) - você pode usar a escalabilidade automática de HBase para a sua vantagem.
Esteja ciente, porém, que o trabalho extra será exigido pelo seu aplicativo cliente para duplicar os dados e lembrar que nativamente HBase só fornece operações atômicas nível de linha não cruzada de linha (com a exceção descrita no HBase-5229 JIRA) ou mesa cruz.
Chaves inteligentes: Como os dados armazenados no HBase é ordenada por chave de linha, ea chave de linha é o único índice nativo fornecido pelo sistema, o design inteligente cuidadosa da chave de linha pode fazer uma enorme diferença. Por exemplo, a sua chave de linha poderia ser uma combinação de um número de ordem de serviço e número de identificação do cliente que fez a encomenda serviço.
Este projeto chave de linha permitem que você olhar para cima os dados relacionados com a ordem de serviço ou procurar dados relacionados com o cliente usando a mesma chave de linha na mesma tabela. Esta técnica será mais rápido para algumas consultas e evitar tabela caro junta.
Para esclarecer esses padrões particulares de pensamento, tomar um Customer Contact tabela Informações e colocá-lo dentro do contexto de um banco de dados típica ordem de serviço. A figura mostra o que um esquema de banco de dados da ordem de serviço normalizado pode parecer.
Seguindo as regras de RDBMS normalização, configurar a tabela Informações de contato da amostra do cliente para que ele seja separado da tabela de ordem de serviço, a fim de evitar a perda de dados de clientes quando as ordens de serviço estão fechadas e possivelmente eliminado. Ter a mesma abordagem para a tabela de produtos, o que significa que os novos produtos podem ser adicionados à base de dados fictícia empresa independente de ordens de serviço.
Ao confiar em RDBMS juntar operações, esse esquema suporta pesquisas que revelam o número de ordens de serviço que são abertas contra um determinado produto, juntamente com a localização do cliente em que o produto está em uso.
Isso é tudo muito bem e dândi, mas é um esquema que você usaria com RDBM. Como você transição deste esquema para um esquema HBase? A figura a seguir ilustra um possível esquema de HBase - um que segue o padrão de design DDI.
A tabela de Informação ao Cliente Fale foi desordenado, incluindo o nome do cliente e informações de contato no lugar das chaves estrangeiras utilizadas anteriormente. Além disso, os dados são duplicados, mantendo tabela Informações do Cliente Fale como é. Agora junta-se à mesa mesa e Customer Contact Informação da ordem de serviço não são necessárias.
Além disso, uma concepção chave de linha inteligente tem sido empregue que combina o número de produto com o número do cliente de modo a formar o número de ordem de serviço (A100 | 00001, por exemplo). Usando esta chave inteligente, a tabela de ordem de serviço pode fornecer relatórios vitais sobre deficiências de produtos e clientes que estão experimentando atualmente problemas do produto.
Todas estas consultas podem ser apoiados por HBase em uma forma atômica nível de linha para a aplicação. Porque você sabe que HBase chaves ordens de linha e classifica-as de uma forma lexicográfica, seu aplicativo pode fazer certas suposições educadas sobre localidade de dados quando da emissão de scans para relatórios. (Tudo o que um números de produtos * série serão armazenados juntos, por exemplo.)
O banco de dados da ordem de serviço representado pelo esquema HBase é um exemplo relativamente simples, mas ilustra como HBase pode, em certos casos, se cruzam com o mundo RDBMS e fornecer um valor significativo. Se a empresa fictícia tem terabytes ou até mesmo petabytes de dados chamada de serviço para armazenar, HBase faria uma enorme diferença em termos de custo, confiabilidade, desempenho e escala.
Você pode, é claro, projetar sua ordem de serviço do esquema HBase de várias maneiras diferentes. É certo que o projeto Tudo depende das consultas que devem ser suportados, mas você tem a capacidade de transição alguns bancos de dados relacionais aplicações HBase a muito poderosas para uso em produção, enquanto você trabalhar a partir de uma sólida compreensão da arquitetura HBase e o padrão de design DDI.
Este exemplo assume que as consultas foram realizadas por um aplicativo Java aproveitando as APIs cliente HBase, ou talvez através de outro idioma usando Apache Thrift. Este modelo de aplicação podem se adequar às exigências muito bem e proporcionar opções de desempenho e personalização úteis para a empresa de serviços de ficção.