O modelo relacional perdeu sua exclusividade
Os requisitos para a funcionalidade e estrutura dos bancos de dados (DB), que são implementados mais completamente em sistemas relacionais, agora estão sob pressão de novos requisitos.
O primeiro problema é baixa eficiência para big data. As fontes de big data são redes sociais, sistemas de vigilância por vídeo, sensores espaciais, cobrança, etc. Um banco de dados relacional (RDB) funcionará bem se o esquema de dados for definido com precisão com antecedência, antes de iniciar o aplicativo. Mas o big data é inerentemente difícil de estruturar no estágio de design do banco de dados. Somente à medida que as informações são coletadas, gradualmente, sua estrutura é mais aparente.
A segunda - consultas de pesquisa e computação em RDBs com tabelas enormes - é uma tarefa de alta complexidade algorítmica. O uso de indexação e hash funciona bem em BDBs mais ou menos estáticos, que são amplamente preenchidos antes que o sistema seja colocado em operação. E nas condições da rápida chegada de novas matrizes de dados em tempo real, as vantagens desses métodos são niveladas, uma vez que os custos indiretos aumentam acentuadamente.
A terceira desvantagem do RDB decorre dos rigorosos requisitos para circuitos de dados no âmbito das "formas normais" canônicas. A necessidade de um grande número de uma ampla variedade de aplicativos requer esforços significativos para criar modelos de dados, e o nível de habilidade desigual dos programadores e prazos apertados levam a erros que exigem correções e alterações. Porém, qualquer mudança que já esteja "viva", preenchida com DBD ("migração") é uma tarefa ainda mais complexa e trabalhosa, que em alguns casos não tem outra solução, como substituir completamente o banco de dados antigo por um novo.
A “beleza” e o rigor do modelo relacional implementado no SQL, por 3 décadas, encantaram os programadores. Os modelos "antigos": rede ou hierárquicos foram quase esquecidos. Sim, quase não existem produtos de software, com a possível exceção do IDMS “quase imortal” [1].
Na última década, está em andamento um trabalho ativo para criar sistemas alternativos de gerenciamento de banco de dados (DBMS), que são chamados simplesmente de - NoSQL. Sob esse conceito, agora caem sistemas muito diferentes que são muito diferentes um do outro. Curiosamente, a rede "antiga" e os modelos hierárquicos não estão incluídos no conceito de NoSQL! Boas críticas nesta área podem ser encontradas em [2,3,4].
A categoria NoSQL inclui bancos de dados “gráficos” [5], que são abstratamente próximos do modelo de rede canônica CODASYL [6]. Como o nome indica, esses sistemas são dois conjuntos desorganizados - nós (vértices) e arestas (arcos). A principal vantagem dos bancos de dados de rede - a navegação é "determinada" não no momento do processamento da solicitação , como no RDB, mas no momento de adicionar novos dados (para gráficos - vértices e arestas), também é verdade para sistemas de gráficos. Mas o banco de dados gráfico não é estruturado antes de ser preenchido, diferente do banco de dados CODASYL.
Outras classes de banco de dados NoSQL mais populares são “valor-chave” (exemplo - Redis [7]) e “armazenamento de documentos” (exemplo - MongoDB [8]). Como uma revisão detalhada desses sistemas não é o objetivo deste artigo, é importante observar apenas o seguinte.
Os sistemas NoSQL, como regra, operam com base em sistemas de arquivos distribuídos que fornecem escalabilidade e confiabilidade [9]. Mas o problema que é matematicamente resolvido rigorosamente na estrutura do modelo relacional é a integridade e consistência do banco de dados (desde que, é claro, o design profissionalmente competente do esquema normalizado) não seja colocado na maioria dos sistemas NoSQL.
No total, hoje a situação é aproximadamente a seguinte: 75% dos bancos de dados são relacionais, o NoSQL em sua forma pura é usado em sistemas altamente especializados, e combinações de vários modelos de banco de dados são usadas em projetos de rede global altamente carregados: Google, Facebook, Instagram, WhatsApp e similares.
Bancos de dados relacionais sem SQL
Além dos problemas práticos descritos acima, o uso de RDBs viu recentemente outras tendências importantes.
Além da às vezes excessiva “rigidez” do modelo relacional, sua principal desvantagem prática (não teórica) é a complexidade da manipulação de dados. A primeira opção é usar o pipeline de operações em conjuntos - unificação, interseção, filtragem etc. na prática, quase nunca é usado, uma vez que está associado ao gasto de recursos colossais e justificado apenas pelo processamento em "lote" de conjuntos de solicitações do mesmo tipo. A segunda opção - o intérprete SQL requer alto profissionalismo, bons conhecimentos de teoria de conjuntos, teoria de banco de dados e considerável experiência prática.
A programação orientada a objetos (OOP) tornou-se o padrão, mas o SQL é uma linguagem declarativa cuja gramática não se encaixa nas linguagens OOP mais comuns (C ++, Java, JavaScript, Python). Como resultado, a solução para “incorporar” RDBs (trabalhando com consultas SQL) com base em bibliotecas de classes denominadas ORM (Mapeamento Relacional a Objetos - Mapeamento Relacional a Objetos (Transformação) [9]) ganhou popularidade.
O uso de classes ORM permite que o programador fique sem SQL ao usar RDBs. O ORM gera automaticamente consultas SQL para os RDBs para criar tabelas e manipular dados. A maioria dos ORMs possui interfaces com vários DBMSs populares - SQLite, MySQL, PostgreSQL e outros, o que dá uma opção sem modificar o código do programa.
Existem muitas implementações de ORM, até várias para cada linguagem de programação. Todos eles são semelhantes, portanto, por definição, no futuro, por ORM, queremos dizer a biblioteca (pacote) correspondente de modelos da classe Model da estrutura do Django [10] na linguagem Python [11].
O ORM é muito "conveniente" e os programadores não acham que, usando essa API, eles obtenham não apenas as vantagens do modelo relacional, mas todas as suas desvantagens. Por exemplo, no próprio código, você não pode substituir os modelos de tabela - adicione ou remova uma coluna, adicione uma nova tabela etc. Para fazer a migração do banco de dados, primeiro você deve reescrever o código, "subir um andar mais alto" e reiniciar o programa. Como resultado, é impossível criar um aplicativo que forneça até as alterações mais simples no esquema de dados durante a operação do programa sem alterar o próprio programa.
A recuperação de dados no ORM é implementada usando cadeias de métodos, por exemplo, "objects.all ()", "objects.get (...)", "objects.filter (...)" no Django. Simples, bonito e conveniente, mas que complexidade algorítmica da execução de consultas SQL geradas pelo ORM levará a isso não é visível a olho nu.
Quando uma pessoa escreve uma consulta SQL, supõe-se que ele pense e compreenda o custo dos recursos de computação. O ORM oculta essa tarefa.
Hypertable como um banco de dados de nova geração
Desenvolvemos um novo conceito, métodos e maneiras práticas de combinar os modelos de banco de dados relacional e de rede com as vantagens da idéia ORM - a rejeição do uso de linguagens de consulta especiais, o que nos permitiu criar um novo modelo e tecnologia de banco de dados.
O conceito principal é a hipertabela (GT) - este é um banco de dados como um conjunto de relações (tabelas) nas quais são usadas:
- Atributos "relacionais" (domínios de dados), cujos valores, como no RDB, são campos de campo com dados auto-definidos para as colunas da tabela correspondentes
- Atributos de "Rede" (domínios de link). Vamos chamá-los de ATS - atributo do tipo "link"
Os valores dos campos do PBX nas linhas da tabela são referências explícitas a quaisquer linhas em quaisquer tabelas incluídas na hipertabela.
O conceito de uma hipertabela apresentada por nós não tem nada a ver com o projeto [13], que foi reduzido em 2016.
Existe um protótipo funcional - um conjunto de ferramentas em Python - o Hyper Table Management System (HTMS), que inclui os seguintes níveis (de cima para baixo):
- O editor de hipertabela HTed (cliente) é um serviço de suporte tecnológico implementado como um site na estrutura do Django, que pode se conectar a qualquer servidor com uma hipertabela, independentemente dos aplicativos (é funcionalmente próximo ao utilitário PgAdmin para PostgeSQL, até certo ponto);
- biblioteca de utilitários e classes de nível lógico - API para criar um banco de dados e manipular dados no nível de programação de aplicativos (substituindo o ORM);
- biblioteca de utilitários e classes do nível físico de trabalho com o banco de dados, em que utilitários e classes do nível lógico são baseadas (como a API pode ser usada por programadores de sistema experientes);
- Classe Cage, projetada para criar uma camada "virtual" de acesso remoto em cache aos arquivos do banco de dados no lado do cliente (aplicativo);
- Servidor de arquivos CageServer - software que funciona nos modos multiprograma e multiencadeado, implementa funções para acesso remoto multiusuário a arquivos em um servidor usando o protocolo TCP.
Em princípio, em vez do Cage, é possível usar o subsistema de arquivos local usual do SO para gerenciar arquivos e também usar a API Cage e o software CageServer como uma ferramenta independente do HTMS para implementar o acesso remoto a arquivos distribuídos em qualquer sistema.
Em artigos futuros, está planejado apresentar os leitores ao sistema HTMS com mais detalhes.