Modelo de datos de red relacional

El modelo relacional ha perdido su exclusividad.

Los requisitos para la funcionalidad y estructura de las bases de datos (DB), que se implementan más completamente en los sistemas relacionales, ahora están bajo la presión de nuevos requisitos.

El primer problema es la baja eficiencia para Big Data. Las fuentes de big data son las redes sociales, los sistemas de videovigilancia, los sensores espaciales, la facturación, etc. Una base de datos relacional (RDB) funciona bien si el esquema de datos se define con precisión por adelantado, antes de iniciar la aplicación. Pero el big data es inherentemente difícil de estructurar en la etapa de diseño de la base de datos. Solo a medida que se recopila información, gradualmente, su estructura es más evidente.

La segunda , la búsqueda de consultas informáticas en RDB con tablas enormes, es una tarea de alta complejidad algorítmica. El uso de indexación y hashing funciona bien en BDB más o menos estáticos, que se llenan en gran medida antes de que el sistema se ponga en funcionamiento. Y en las condiciones de la rápida llegada de nuevas matrices de datos en tiempo real, las ventajas de estos métodos se nivelan, ya que los costos generales aumentan considerablemente.

El tercer inconveniente del RDB se deriva de los estrictos requisitos para los circuitos de datos en el marco de las "formas normales" canónicas. La necesidad de una gran cantidad de una amplia variedad de aplicaciones requiere esfuerzos significativos para crear modelos de datos, y el nivel desigual de habilidad de los programadores y los plazos ajustados conducen a errores que requieren correcciones y alteraciones. Pero cualquier cambio que ya esté "vivo", lleno de DBD ("migración") es una tarea aún más compleja y laboriosa, que en algunos casos no tiene otra solución, como reemplazar completamente la base de datos anterior por una nueva.

La "belleza" y el rigor del modelo relacional implementado en SQL, durante 3 décadas, ha encantado a los programadores. Los "viejos" modelos: red o jerárquicos fueron casi olvidados. Sí, casi no existen tales productos de software, con la posible excepción de los IDMS "casi inmortales" [1].

En la última década, se está trabajando activamente para crear sistemas alternativos de administración de bases de datos (DBMS), que simplemente se denominan NoSQL. Bajo este concepto, ahora caen sistemas muy diferentes que son muy diferentes entre sí. ¡Curiosamente, la red "antigua" y los modelos jerárquicos no están incluidos en el concepto de NoSQL! Se pueden encontrar buenas críticas en esta área en [2,3,4].

La categoría NoSQL incluye bases de datos "gráficas" [5], que están abstractamente cerca del modelo de red canónica CODASYL [6]. Como su nombre lo indica, tales sistemas son dos conjuntos no organizados: nodos (vértices) y aristas (arcos). La principal ventaja de las bases de datos de red: la navegación se "determina" no al momento de procesar la solicitud , como en el RDB, sino al momento de agregar nuevos datos (para gráficos - vértices y bordes), también es cierto para los sistemas de gráficos. Pero la base de datos de gráficos no está estructurada antes de que se complete, a diferencia de la base de datos CODASYL.

Otras clases de bases de datos NoSQL más populares son "clave-valor" (ejemplo - Redis [7]) y "almacenamiento de documentos" (ejemplo - MongoDB [8]). Dado que una revisión detallada de tales sistemas no es el propósito de este artículo, es importante tener en cuenta solo lo siguiente.

Los sistemas NoSQL, como regla, operan sobre la base de sistemas de archivos distribuidos que proporcionan escalabilidad y confiabilidad [9]. Pero el problema que se resuelve matemáticamente rigurosamente dentro del marco del modelo relacional es la integridad y la consistencia de la base de datos (siempre que, por supuesto, el diseño profesionalmente competente del esquema normalizado) no se plantee en absoluto en la mayoría de los sistemas NoSQL.

En total, hoy la situación es aproximadamente la siguiente: el 75% de las bases de datos son relacionales, NoSQL en su forma pura se usa en sistemas altamente especializados, y las combinaciones de varios modelos de bases de datos se usan en proyectos de red global altamente cargados: Google, Facebook, Instagram, WhatsApp y similares.

Bases de datos relacionales sin SQL

Además de los problemas prácticos descritos anteriormente, el uso de RDB ha visto recientemente otras tendencias importantes.

Además de la a veces excesiva "rigidez" del modelo relacional, su mayor inconveniente práctico (no teórico) es la complejidad de la manipulación de datos. La primera opción es utilizar la canalización de operaciones en conjuntos: unificación, intersección, filtrado, etc. en la práctica, casi nunca se usa, ya que está asociado con el gasto de recursos colosales y se justifica solo con el procesamiento "por lotes" de conjuntos de solicitudes del mismo tipo. La segunda opción: el intérprete de SQL requiere un alto profesionalismo, un buen conocimiento de la teoría de conjuntos, la teoría de bases de datos y una considerable experiencia práctica.

La programación orientada a objetos (OOP) se ha convertido en el estándar, pero SQL es un lenguaje declarativo cuya gramática no se ajusta a los lenguajes OOP más comunes (C ++, Java, JavaScript, Python). Como resultado, la solución para "incrustar" RDBs (trabajando con consultas SQL) basadas en bibliotecas de clase llamadas ORM (Object-Relational Mapping - Object-Relational Mapping (Transformation) [9]) ha ganado popularidad.

El uso de clases ORM permite al programador prescindir de SQL cuando usa RDB. ORM genera automáticamente consultas SQL a los RDB para crear tablas y manipular datos. La mayoría de los ORM tienen interfaces con varios DBMS populares: SQLite, MySQL, PostgreSQL y otros, lo que permite elegir sin modificar el código del programa.

Hay muchas implementaciones de ORM, incluso varias para cada lenguaje de programación. Todos ellos son similares, por lo tanto, por definición, en el futuro, por ORM nos referimos a la biblioteca (paquete) correspondiente de modelos de la clase Model del marco Django [10] en el lenguaje Python [11].

ORM es muy "conveniente" y los programadores realmente no piensan que al usar esta API obtienen no solo las ventajas del modelo relacional, sino todas sus desventajas. Por ejemplo, en el código mismo, no puede anular modelos de tabla: agregar o eliminar una columna, agregar una nueva tabla, etc. Para realizar la migración de la base de datos, primero debe volver a escribir el código, luego "subir un piso más alto" y luego reiniciar el programa. Como resultado, es imposible crear una aplicación que proporcione incluso los cambios más simples en el esquema de datos durante la operación del programa sin cambiar el programa en sí.

La recuperación de datos en ORM se implementa utilizando cadenas de métodos, por ejemplo, "objects.all ()", "objects.get (...)", "objects.filter (...)" en Django. Simple, hermoso y conveniente, pero la complejidad algorítmica de ejecutar consultas SQL generadas por ORM llevará a que esto no sea visible a simple vista.

Cuando una persona escribe una consulta SQL, se supone que piensa y comprende el costo de los recursos informáticos. ORM vela esta tarea.

Hipertable como una base de datos de nueva generación

Hemos desarrollado un nuevo concepto, métodos y formas prácticas de combinar los modelos de bases de datos relacionales y de red con las ventajas de la idea ORM: el rechazo del uso de lenguajes de consulta especiales, lo que nos permitió crear un nuevo modelo y tecnología de base de datos.

El concepto clave es el hipertable (GT): esta es una base de datos como un conjunto de relaciones (tablas) en las que se utilizan:

1. Atributos "relacionales" (dominios de datos), cuyos valores, como en el RDB, son campos de campo con datos autodefinidos para las columnas de la tabla correspondiente
2. Atributos de "red" (dominios de enlace). Los llamaremos ATS - atributo de tipo "enlace"

Los valores de los campos PBX en las filas de la tabla son referencias explícitas a cualquier fila en cualquier tabla incluida en el hipertable.

El concepto de un hipertable introducido por nosotros no tiene nada que ver con el proyecto [13], que se redujo en 2016.

Hay un prototipo que funciona, un conjunto de herramientas en Python, el HTMS (Hyper Table Management System), que incluye los siguientes niveles (de arriba a abajo):

• HTed hypertable editor (cliente): un servicio de soporte tecnológico implementado como un sitio web en el marco de Django, que puede conectarse a cualquier servidor con un hipertable independientemente de las aplicaciones (está funcionalmente cerca de la utilidad PgAdmin para PostgeSQL en cierta medida)
• biblioteca de utilidades y clases de nivel lógico: API para crear una base de datos y manipular datos a nivel de programación de aplicaciones (reemplazando ORM);
• una biblioteca de utilidades y clases del nivel físico de trabajo con la base de datos en la que se basan las utilidades y clases del nivel lógico (cómo los programadores de sistemas experimentados pueden utilizar la API);
• Clase Cage, que está diseñada para crear una capa "virtual" de acceso remoto en caché a archivos de base de datos en el lado del cliente (aplicación);
• Servidor de archivos CageServer: software que funciona en modo multiprograma y multiproceso, implementa funciones para el acceso remoto multiusuario a archivos en un servidor utilizando el protocolo TCP.

En principio, en lugar de Cage, es posible usar el subsistema de archivos local habitual del sistema operativo para administrar archivos, así como también usar la API Cage y el software CageServer como una herramienta HTMS independiente para implementar el acceso remoto a archivos distribuidos en cualquier sistema.

En futuros artículos, se planea presentar a los lectores el sistema HTMS con más detalle.