Un modelo de datos es una abstracción física que describe un determinado fenómeno o estado en el mundo real. Por ejemplo, usamos FSA para describir el fenómeno del día del Sr. Zhou, que consiste en abstraer el mundo real en un determinado modelo. El mundo real tiene muchas relaciones importantes: las publicaciones de blog tienen comentarios, las cuentas bancarias tienen múltiples transacciones, los clientes tienen múltiples cuentas bancarias, los pedidos tienen múltiples detalles de pedidos y los directorios de archivos tienen múltiples archivos y subdirectorios.
Relación de asociación de base de datos relacional:
Cada entidad (o fila, en el mundo relacional) puede identificarse de forma única mediante una clave principal.
Normalización de entidades (Paradigma). Los datos de una entidad única se almacenan solo una vez, mientras que una entidad relacionada solo almacena su clave principal. Los datos de esta entidad solo se pueden modificar en una ubicación específica.
Las entidades se pueden asociar con consultas y se pueden buscar entre entidades.
Los cambios en una sola entidad son atómicos, consistentes, aislados y duraderos. (Consulte Transacciones ACID para obtener más detalles).
La mayoría de las bases de datos relacionales admiten transacciones ACID en varias entidades.
Sin embargo, las bases de datos relacionales tienen sus limitaciones, incluido el soporte limitado para la recuperación de texto completo. El consumo de tiempo de consulta de asociación de entidades es muy caro, cuantas más asociaciones, más caro es el consumo. En particular, el costo de la asociación de entidades entre servidores es extremadamente alto y básicamente no está disponible. Pero hay un límite en la cantidad de datos en un solo servidor.
Elasticsearch, como la mayoría de las bases de datos NoSQL, es plana. Los índices son colecciones de documentos individuales. Que un documento coincida con una solicitud de búsqueda depende de si contiene toda la información requerida.
Los cambios de datos en un solo documento en Elasticsearch son ACIDic, mientras que las transacciones que involucran varios documentos no lo son. Cuando una transacción falla parcialmente, no hay forma de revertir los datos del índice al estado anterior.
El aplanamiento tiene las siguientes ventajas:
El proceso de indexación es rápido y sin bloqueos.
El proceso de búsqueda es rápido y sin bloqueos.
Debido a que cada documento es independiente entre sí, los datos a gran escala se pueden distribuir en varios nodos.
Pero las relaciones siguen siendo muy importantes. En algún momento, necesitamos cerrar la brecha entre los modelos relacionales aplanados y del mundo real. Los siguientes cuatro métodos comúnmente utilizados se utilizan para administrar datos relacionales en Elasticsearch:
Combinaciones del lado de la aplicación
Desnormalización de datos
Objetos anidados
Relaciones padre/hijo
Objetos y
entidades La relación entre objetos y entidades es el mapeo entre el mundo real y el modelo de datos. El modelo de dominio POJO que usamos a menudo cuando hacemos desarrollo Java es esta relación:
Especificación del modelo de dominio jerárquico:
DO (objeto de datos): correspondencia uno a uno con la estructura de la tabla de la base de datos, y el objeto de origen de datos se transmite hacia arriba a través de la capa DAO.
DTO (objeto de transferencia de datos): objeto de transferencia de datos, el objeto que el servicio o el administrador transfiere hacia el exterior.
BO (Objeto de Negocio): objeto de negocio. Un objeto que encapsula la salida de la lógica empresarial de la capa de servicio.
AO (Objeto de aplicación): objeto de aplicación. El modelo de objeto de reutilización abstracta entre la capa Web y la capa de Servicio es muy similar a la capa de presentación, y el grado de reutilización no es alto.
VO (objeto de visualización): objeto de capa de visualización, generalmente el objeto transmitido desde la Web a la capa del motor de representación de la plantilla.
POJO (Plain Ordinary Java Object): en este manual, POJO se refiere a clases simples con solo setter/getter/toString, incluidos DO/DTO/BO/VO, etc.
Consulta: objeto de consulta de datos, cada capa recibe la solicitud de consulta de la capa superior. Preste atención a la encapsulación de consultas con más de 2 parámetros, y está prohibido usar la clase Map para la transmisión.
Convención de nomenclatura de modelos de dominio:
Objeto de datos: xxxDO, donde xxx es el nombre de la tabla de datos.
Objeto de transferencia de datos: xxxDTO, donde xxx es el nombre relacionado con el dominio empresarial.
Objeto de visualización: xxxVO, donde xxx suele ser el nombre de la página web.
POJO es el nombre colectivo de DO/DTO/BO/VO, y está prohibido nombrarlo como xxxPOJO.
El proceso del
concepto de modelado de datos: requisitos => abstracción. Eso es abstraer las necesidades reales del usuario en un determinado modelo de datos. Por ejemplo, cuando almacenamos la lista de publicaciones, abstraemos el requisito de "almacenar la lista de publicaciones" en un modelo de datos abstracto de FST.
Lógica: Abstracta => Concreta. Aún tomando la "lista invertida de almacenamiento" como ejemplo, después de construir el modelo FST, necesitamos convertir su abstracción en código y objetos concretos, y convertir la implementación en algo visible a simple vista.
Física: Concreto => Aterrizaje. Igual que arriba, cuando tenemos la lógica, podemos programar archivos de datos reales a través de objetos y atributos específicos y guardarlos en su disco.
Importancia
Mi resumen personal es el siguiente, pero no se limita a los siguientes puntos:
Desarrollo: simplificar el proceso de desarrollo, mejorando así la eficiencia
Producto: mejorar la eficiencia del almacenamiento de datos y el rendimiento de las consultas
Gestión: preparación suficiente en la etapa inicial, reduciendo la posibilidad de problemas en la etapa posterior
Costo: combinación de varios factores, reduciendo los costos generales de operación y administración
Datos modelado Contenido incluido
Procesamiento de relaciones de asociación (relaciones de índice):
Combinaciones de modelos de datos: podemos (parcialmente) emular bases de datos relacionales implementando combinaciones en nuestra aplicación. La principal ventaja de las uniones de la capa de aplicación es la capacidad de normalizar los datos. El nombre del usuario solo se puede cambiar en el documento de usuario. La desventaja es que para unir documentos en el momento de la búsqueda, se debe ejecutar una consulta adicional
Desnormalización de datos: la mejor manera de obtener el mejor rendimiento de búsqueda con Elasticsearch es desnormalizar la desnormalización en el momento del índice a propósito. Mantener un cierto número de copias redundantes de cada documento puede evitar la asociación cuando se requiere acceso
Campos dispersos: evite documentos de campo disperso
Problemas de concurrencia: bloqueos globales, bloqueos de documentos, bloqueos de árbol (bloqueos exclusivos, bloqueos compartidos), bloqueos optimistas, bloqueos pesimistas
Tipo de objeto : El punto popular es usar una tabla grande y ancha para implementar un índice de grano grueso a través de la redundancia de campo, lo que puede aprovechar al máximo las ventajas de la planitud. Pero esto se produce a expensas del rendimiento y la flexibilidad de la indexación. La premisa de uso: los campos redundantes rara vez deben cambiarse; es más adecuado para procesar con un pequeño número de relaciones. Cuando la base de datos comercial no adopta un diseño no estandarizado, es difícil usar el esquema de sincronización incremental anterior para sincronizar los datos con el ES como la biblioteca de índice secundario. Debe personalizarse y desarrollarse en función de negocios específicos. únase a la asociación y empalme de entidades
Objetos anidados: el rendimiento del índice y el rendimiento de las consultas no se pueden lograr al mismo tiempo y se debe hacer una compensación. Los documentos anidados anidan y combinan relaciones de entidad dentro de un solo documento (similar a una estructura jerárquica de uno a muchos con json), lo que sacrifica el rendimiento del índice (cualquier cambio de atributo en el documento requiere volver a indexar el documento) a cambio del rendimiento de la consulta. Las entidades relacionales se pueden devolver al mismo tiempo, lo que es más adecuado para una pequeña cantidad de procesamiento de relaciones. Al usar documentos anidados, es imposible acceder a ellos usando métodos de consulta generales. Debe usar métodos de consulta apropiados (consulta anidada, filtro anidado, faceta anidada, etc.). En muchos escenarios, la complejidad de usar documentos anidados radica en la indexación fase Organización y montaje de relaciones de asociación Relación
padre-hijo: los documentos padre-hijo sacrifican cierto rendimiento de consulta a cambio del rendimiento del índice, que es adecuado para el procesamiento de relaciones de uno a muchos. Utiliza dos tipos de documentos para representar entidades padre-hijo, y los índices de los documentos padre-hijo son independientes. Las asignaciones de ID de documento padre-hijo se almacenan en Doc Values. Doc Values proporciona un procesamiento rápido del mapa cuando el mapa está completamente en la memoria y, por otro lado, proporciona suficiente escalabilidad al volcarse al disco cuando el mapa es muy grande. Al consultar alternativas padre-hijo, encontré una sintaxis de términos de filtro que requiere una lista de ID de entidades asociadas en un campo. El principio básico es que, en términos, para valores múltiples, si la identificación de la clave principal se conoce en otro índice o tipo, y un determinado campo tiene estos valores, puede anidar directamente la consulta. Para obtener más información, consulte el ejemplo en el documento oficial: a través de la relación de fans en el usuario, la relación entre Weibo y el usuario, para consultar la lista de Weibo publicada por los fans de un determinado usuario.
Escalabilidad: índice
de asignación de fragmentos , plantilla de índice, ciclo de vida del índice, arquitectura caliente y fría, gestión y planificación de fragmentos, índice variable y búsqueda entre clústeres de alias.