Este artículo se comparte desde Huawei Cloud Community " Huawei Cloud GaussDB (for Influx) Revealing Issue 7: Best Practice Data Modeling ", autor: Base de datos GaussDB.
La base de datos de series temporales GaussDB (for Influx) de HUAWEI CLOUD brinda seguridad de datos, alto rendimiento, bajo costo de almacenamiento y capacidades libres de operación y mantenimiento para escenarios de IoT industrial con datos masivos de series temporales. Ha atraído cada vez más la atención de las empresas. Los desarrolladores reconocen cada vez más las declaraciones de consulta similares a SQL, que no requieren diseño de esquema y que son adecuadas para iteraciones comerciales rápidas.
Sin embargo, a medida que la escala del negocio continúa aumentando, también habrá problemas como cronogramas que se disparan, alta latencia de consulta y, a veces, inconsistencia en la consulta de datos debido al mismo nombre de Tag y Field. La razón fundamental es que no hay buen diseño del modelo de datos durante el uso. Este problema comenzará con el modelo de datos de GaussDB (para Influx), compartirá el mejor método de modelado de datos de GaussDB (para Influx) y evitará algunos problemas comunes en el proceso de uso.
0 1 Modelo de datos y conceptos clave
-
Base de datos
Es el mismo concepto que Base de datos en MySQL.
Crear comando: CREAR BASE DE DATOS "mydb".
Los permisos de usuario y las políticas de retención de datos se establecen en la granularidad de la base de datos. Por ejemplo, otorgue al usuario permiso de solo lectura para la base de datos "mydb": GRANT read ON mydb TO nombre de usuario.
-
Medición
Similar al concepto de tabla en MySQL. La diferencia es que GaussDB (para Influx) es Schemaless, no es necesario crear la medición con anticipación, ni es necesario diseñar los campos y tipos en la tabla. Las medidas se crean automáticamente cuando se escriben los datos, y los campos se pueden agregar o restar arbitrariamente, pero los tipos de datos de los mismos campos deben ser consistentes.
-
Política de retención (RP)
La política de retención de datos es un concepto que no existe en las bases de datos relacionales, está especialmente diseñado para escenarios de series de tiempo, significa que se especifica el tiempo máximo de retención de datos en la base de datos y los datos caducados se limpiarán automáticamente.
-
Etiqueta
Identificador de fuente de datos, solo admite tipo de cadena
-
Campo
Recopilar indicadores, cadena de soporte, flotante, int, tipos bool
-
Protocolo de línea (modelo de datos)
Como se muestra en la figura, al escribir datos en GaussDB (para Influx), una sola pieza de datos consta de seis partes: medición, Tag_key, Tag_value, Field_key, Field_value y timestamp. <Tag_key= Tag_value> puede ser uno o más, <Field_key=Field_value> puede ser uno o más, y cada dato debe llevar una marca de tiempo.
-
Punto _
El punto generalmente contiene cuatro partes: medición+Etiquetas+Campo+marca de tiempo. Por ejemplo, los siguientes datos contienen 2 Puntos.
<monitorInfo，area=“葡萄花”，，device=“钻机A” pressure=1.8，level=35 1650443961100400200>
Point1：
<monitorInfo，area=“葡萄花”，device=“钻机A”，pressure=1.8 1650443961100400200>
Point2：
<monitorInfo，area=“葡萄花”，device=“钻机A”，level=35 1650443961100400200>Es decir, cuántas claves de campo contiene un dato puede considerarse simplemente como cuántos puntos existen. En GaussDB (para Influx), un dato puede contener un punto o varios puntos.
-
Serie (línea de tiempo)
En GaussDB (para Influx), llamamos línea de tiempo a la combinación de un indicador + un conjunto de etiquetas. Debajo de una línea de tiempo, los datos muestreados en puntos de tiempo consecutivos son datos de series de tiempo. Por ejemplo hay datos:
monitorInfo，area=”葡萄花”，device=”钻机A”，pressure=1.8，1650443961100400200
monitorInfo，area=”葡萄花”，device=”钻机B”，pressure=1.6，1650443961100400200
monitorInfo，area=”榆树林”，device=”钻机B”，pressure=1.7，1650443961100400200
monitorInfo，area=”榆树林”，device=”钻机A”，pressure=1.5，1650443961100400200Representa 4 líneas de tiempo, a saber:
Sensor de presión (presión) en la plataforma A en el campo petrolífero de Putaohua
Sensor de presión (presión) en la plataforma B en el campo petrolífero de Putaohua
Sensor de presión (presión) en la plataforma B en el campo petrolífero de Yushulin
Sensor de presión (presión) en la plataforma A del campo petrolífero de Yushulin
0 2 mejores prácticas para el modelado de datos
A menudo, el modelado de datos se realiza para que las consultas sean más simples y eficientes. Para la mayoría de los casos de uso, recomendamos las siguientes pautas de diseño:
1. Diseño razonable de etiqueta y campo
-
La etiqueta solo admite el tipo de cadena, los datos numéricos y booleanos deben diseñarse como campo;
-
Diseñe condiciones de consulta comunes y condiciones de agrupación como etiquetas;
Porque Tag creará un índice y Field no tendrá un índice. Por ejemplo, en los negocios, a menudo se consulta la utilización promedio de CPU de una determinada máquina:
SELECT mean(cpu)
FROM monitor
WHERE host=“192.168.1.1” AND time > now() – 1hO consulta la generación eléctrica media horaria de cada aerogenerador de un parque eólico:
SELECT mean(elect)
FROM monitor
WHERE farm_id=“737f738a-bd63” AND time > now() – 24h
GROUP BY time(1h)，device_idEl host, farm_id, device_id en la declaración de consulta anterior debe establecerse en Etiqueta, siempre que el tipo de cadena se pueda establecer en Etiqueta.
-
time es una palabra clave incorporada y no se puede usar como Tag_key y Field_key;
-
Los campos que utilizan las funciones de InfluxQL (Máx., Mín., Conteo, etc.) se almacenan como Campos.
2. Siga la convención de nomenclatura de Tag_Key y Field_Key
-
No utilice palabras clave reservadas como clave (nombre) de Etiqueta y Campo;
-
Tag y Field no usan el mismo nombre, de lo contrario habrá problemas inesperados;
-
Los nombres de etiquetas y campos deben ser lo más cortos y claros posible, lo que puede ahorrar espacio en la memoria del índice y hacer que las consultas sean más eficientes;
-
Evite los significados de varias capas en una etiqueta, como máquina = "192.168.2.1-Ubuntu", incluida la dirección IP y el nombre del sistema operativo, se recomienda dividir en dos etiquetas: host y os;
-
Se recomienda configurar los datos con pequeños cambios como Etiqueta. Por ejemplo, el nombre del proceso se puede configurar como Etiqueta y se recomienda configurar el ID del proceso como Campo.
3. Evite exceder la cantidad de líneas de tiempo que puede manejar la especificación del nodo
La relación correspondiente entre las especificaciones de GaussDB (para Influx) y el número de líneas de tiempo es la siguiente:
Si la línea de tiempo excede el límite, el rendimiento caerá drásticamente, lo que puede afectar la operación comercial. Se debe considerar la expansión de la capacidad del nodo.
4. Evite demasiadas etiquetas o
Se recomienda almacenar el mismo tipo de datos comerciales en una tabla, como los datos de monitoreo de vehículos de logística. Se colocan demasiados datos comerciales en la misma tabla, lo que provocará un aumento en la cantidad de etiquetas y campos, lo que afectará directamente la eficiencia de las consultas. Cuando hay demasiados campos, el cálculo de cada campo se calculará por separado, lo que puede provocar que se agote el tiempo de espera de la consulta al ejecutar una consulta difusa.
5. Evite almacenar datos de múltiples usuarios en la misma política de retención
El tiempo de caducidad de los diferentes datos comerciales es diferente. Debe almacenarse en diferentes RP de acuerdo con las necesidades específicas del negocio. De lo contrario, los datos caducados no se pueden eliminar a tiempo y aún ocupan espacio de almacenamiento, lo que aumenta el costo del almacenamiento de datos y afecta la eficiencia de la consulta.
6. Evite almacenar datos de múltiples usuarios en la misma base de datos
Dado que la granularidad de control de permisos actual de GaussDB (para Influx) está en el nivel de base de datos, la misma base de datos guarda datos de múltiples usuarios, lo que puede conducir fácilmente a que otros usuarios accedan y modifiquen los datos. Se recomienda usar bases de datos separadas para diferentes usuarios y otorgar acceso a un solo usuario.
0 3 Resumen
En las industrias industriales de IoT, como la fabricación, la energía, la agricultura y la energía eléctrica, la mayoría de los sistemas de información digital se basan en bases de datos relacionales como MySQL. Sin embargo, con la mayor expansión del negocio empresarial y la escala, y el rápido crecimiento del volumen de datos, las bases de datos relacionales como MySQL se enfrentan a muchos problemas, como la concurrencia, el costo de almacenamiento, el rendimiento de las consultas, la escalabilidad y el mantenimiento, y están siendo reemplazadas gradualmente por el tiempo. bases de datos en serie.
GaussDB (para Influx) abandona las complicadas reglas de diseño del paradigma de la base de datos relacional, admite el diseño sin esquema y el negocio se puede modelar de una manera simple y eficiente. Frente a los escenarios de IoT industrial con cambios comerciales rápidos y una gran diversificación de los dispositivos de acceso, el modelado de datos de GaussDB (por Influx) es más flexible, compatible con diferentes dispositivos sin cambiar los servicios y es más adecuado para escenarios de IoT industrial.
0 4 fin
El autor de este artículo: HUAWEI CLOUD Database Innovation Lab y HUAWEI CLOUD Spatiotemporal Database Team
¡Bienvenido a unirse a nosotros!
Cloud Database Innovation Lab (Chengdu, Beijing) Correo electrónico de entrega de currículum: [email protected]
HUAWEI CLOUD Equipo de base de datos espaciotemporal (Xi'an, Shenzhen) Correo electrónico de entrega de currículum: [email protected]
Haga clic en Seguir para conocer las nuevas tecnologías de HUAWEI CLOUD por primera vez ~