1. Principios de zonificación
El principio general de la partición es hacer que la gestión de datos sea más eficiente, mejorar el rendimiento de consultas y cálculos, y lograr una baja latencia y un alto rendimiento.
1.1 Elija el campo de partición apropiado
El tipo de datos del campo de partición DolphinDB puede ser un número entero, una fecha y un tipo de SÍMBOLO. Tenga en cuenta que los tipos de datos STRING, FLOAT y DOUBLE no se pueden utilizar como campos de partición.
Aunque DolphinDB admite la partición de campos de tipo TIME, SECOND y DATETIME, debe usarse con precaución en el uso real y evitar la partición de valores, para evitar que la granularidad de la partición sea demasiado fina y se gaste mucho tiempo en crear o consultar cientos de millones de solo unas pocas entradas. El directorio de archivos grabados.
El campo de la partición debería ser bastante importante en el negocio. Por ejemplo, en el campo de la negociación de valores, muchas tareas están relacionadas con las fechas de negociación de las acciones o los códigos de las acciones, por lo que es razonable utilizar estos dos campos para la partición.
1.2 La granularidad de la partición no debe ser demasiado grande
El número máximo de registros admitidos por una sola partición de DolphinDB es 2 mil millones. Pero el número razonable de registros debería ser mucho menor que este número. Varias columnas en una partición se almacenan de forma independiente en el disco como archivos y los datos generalmente se comprimen. Cuando está en uso, el sistema lee las columnas requeridas del disco, las descomprime y las carga en la memoria. Si la granularidad de la partición es demasiado grande, puede causar memoria insuficiente cuando varios subprocesos de trabajo son paralelos o hacer que el sistema cambie con frecuencia entre el disco y la memoria de trabajo, lo que afecta el rendimiento. Una fórmula empírica es que la memoria disponible del nodo de datos es S y el número de trabajadores es W. Se recomienda que el tamaño de cada partición en la memoria después de la descompresión no exceda S / 8W. Suponiendo que el límite superior de la memoria de trabajo es de 32 GB y 8 subprocesos de trabajo, se recomienda que el tamaño de una sola partición después de la descompresión no supere los 512 MB.
Las subtareas de DolphinDB se basan en particiones. Por lo tanto, la granularidad de la partición es demasiado grande, lo que imposibilita el uso efectivo de las ventajas de múltiples nodos y múltiples particiones, y convierte las tareas que se pueden calcular en paralelo en tareas de cálculo secuencial.
DolphinDB está optimizado para escenarios OLAP, admite la adición de datos y no admite la eliminación o actualización de filas individuales. Si desea modificar los datos, sobrescriba todos los datos en una partición. Si la partición es demasiado grande, reduzca la eficiencia. Cuando DolphinDB replica datos entre nodos, también utiliza particiones como unidad, que son demasiado grandes, lo que no favorece la replicación de datos entre nodos.
En función de varios factores, se recomienda que el tamaño de los datos originales de una partición antes de la compresión se controle entre 100M y 1G. Por supuesto, esta cifra se puede ajustar según las condiciones reales. Por ejemplo, en aplicaciones de big data, a menudo vemos diseños de tablas anchas, una que expresa varios cientos de campos, pero solo una parte de los campos se usa en una sola aplicación. En este caso, el rango del límite superior se puede ampliar de forma adecuada.
Si encuentra que la granularidad de la partición es demasiado grande, puede usar varios métodos, (1) usar una partición combinada (COMPO), (2) aumentar el número de particiones, (3) cambiar la partición de rango a una partición de valor.
1.3 La granularidad de la partición no debe ser demasiado pequeña
Si la granularidad de la partición es demasiado pequeña, un trabajo de consulta y cálculo a menudo generará una gran cantidad de subtareas, lo que aumentará los costos de comunicación y programación entre los nodos de datos y los nodos de control, así como entre los nodos de control. Si la granularidad de la partición es demasiado pequeña, también provocará muchos accesos al disco ineficientes (leer y escribir archivos pequeños), lo que provocará que el sistema se sobrecargue. Además, todos los metadatos de la partición residirán en la memoria del nodo de control. Si la granularidad de la partición es demasiado pequeña y el número de particiones es demasiado grande, la memoria del nodo de control puede ser insuficiente. Recomendamos que el volumen de datos de cada partición antes de la compresión no sea inferior a 100M.
Por ejemplo, si los datos comerciales de alta frecuencia de las acciones se dividen de acuerdo con la combinación de la fecha de la transacción y el valor del código de la acción, se generarán muchas particiones extremadamente pequeñas, porque el volumen de datos de la transacción de muchas acciones inactivas es demasiado pequeño. Si las dimensiones del código de existencias se dividen en datos de acuerdo con el método de partición de rango y se combinan varias existencias inactivas en una partición, el problema de una granularidad de partición demasiado pequeña se puede resolver eficazmente y se puede mejorar el rendimiento del sistema.
2. Cómo particionar los datos de manera uniforme
Cuando la cantidad de datos en cada partición es muy diferente, provocará que la carga del sistema esté desequilibrada, algunos nodos sean demasiado pesados y otros nodos estén en un estado de espera inactivo. Cuando una tarea tiene varias subtareas, solo se completa la última subtarea antes de devolver el resultado al usuario. Dado que una subtarea corresponde a una partición, si los datos no se distribuyen uniformemente, puede aumentar la demora del trabajo y afectar la experiencia del usuario.
Para facilitar la partición de acuerdo con la distribución de los datos, DolphinDB proporciona una función muy útil cutPoints (X, N, [freq]). X es un dato, N representa el número de grupos generados, freq es una matriz de la misma longitud que X y cada elemento corresponde a la frecuencia del elemento en X. Esta función devuelve una matriz con (N + 1) elementos, de modo que los datos en X se distribuyen uniformemente en N grupos.
En el siguiente ejemplo, los datos de cotización de acciones deben dividirse en dos dimensiones: fecha y código de acciones. Si simplemente divide el rango por la primera letra de la acción, es fácil causar una distribución de datos desigual, porque un número muy pequeño de códigos de acciones comienza con U, V, X, Y, Z y otras letras. Se recomienda utilizar la función cutPoints para dividir particiones según los datos de muestra.
// Importar los datos el día de 2007.08.01
t = ploadText (WORK_DIR + "/ TAQ20070801.csv")
// Seleccionar la distribución del código de existencias de los datos en el día de 2007.08.01 para calcular la regla de agrupación
t = seleccionar recuento (*) como ct de t donde fecha = 2007.08.01 agrupar por símbolo
// Generar 128 intervalos en orden alfabético según el código de stock. El número de filas de datos en cada intervalo es equivalente al 2007.08.01.
buckets = cutPoints (t.symbol, 128, t.ct)
// El límite final del último intervalo está determinado por los datos de 2007.08.01. Para excluir nuevos después de 2007.08.01, reemplace el límite final del último intervalo con el código de stock más grande que no aparecerá.
buckets [size (buckets) -1] = `ZZZZZ
// Los resultados de los buckets son los siguientes:
// [" A ", 'ABA', 'ACEC', 'ADP', 'AFN', 'AII', 'ALTU', 'AMK', ..., 'XEL', 'XLG', 'XLPRACL', 'XOMA', 'ZZZZZ']
dateDomain = database ("", VALUE, 2017.07.01..2018.06.30)
symDomain = database ( "", RANGO,
Además de utilizar la partición de rango, la partición de lista también es una forma eficaz de resolver la distribución desigual de datos.
3. Partición de tipo de temporización
El tiempo es la dimensión más común en los datos reales. DolphinDB proporciona una gran cantidad de tipos de tiempo para satisfacer las necesidades de los usuarios. Cuando usamos el campo de tipo de tiempo como campo de partición, necesitamos reservar suficiente espacio para el valor de tiempo para acomodar datos futuros. En el siguiente ejemplo, creamos una base de datos para particionar las fechas desde 2000.01.01 hasta 2030.01.01 en días. Tenga en cuenta que solo cuando los datos reales se escriben en la base de datos, la base de datos realmente creará las particiones necesarias.
dateDB = database ("dfs: // testDate", VALUE, 2000.01.01 .. 2030.01.01)
DolphinDB también tiene una ventaja especial cuando se usa el tipo de tiempo como campo de partición. El tipo de campo de partición definido por la base de datos y el tipo de tiempo real utilizado en la tabla de datos pueden ser inconsistentes, siempre que la precisión del tipo de datos del campo de partición definido sea menor o igual que el tipo de datos real. Por ejemplo, si la base de datos está dividida por mes (mes), los campos de la tabla de datos pueden ser mes, fecha, fecha y hora, marca de tiempo y nanotimestamp. El sistema convertirá automáticamente el tipo de datos.
4. Los datos de la misma partición de diferentes tablas se almacenan en el mismo nodo
En una base de datos distribuida, generalmente lleva mucho tiempo unir (unir) tablas de datos de múltiples particiones, porque las particiones involucradas pueden estar en diferentes nodos y los datos necesitan ser replicados entre diferentes nodos. Para resolver este problema, DolphinDB ha introducido un mecanismo de partición que comparte ubicaciones de almacenamiento. DolphinDB garantiza que los datos de todas las tablas de la misma partición en la misma base de datos distribuida se almacenen en el mismo nodo. Esta disposición asegura que estas tablas sean muy eficientes cuando estén conectadas. La versión actual de DolphinDB no proporciona funciones de combinación para varias tablas de particiones que utilizan diferentes mecanismos de partición.
dateDomain = database ("", VALUE, 2018.05.01..2018.07.01)
symDomain = database ("", RANGE, string ('A' .. 'Z') join `ZZZZZ)
stockDB = database (" dfs: / / stockDB ", COMPO, [dateDomain, symDomain])
quoteSchema = table (10: 0,` sym`date`time`bid`bidSize`ask`askSize, [SYMBOL, DATE, TIME, DOUBLE, INT, DOUBLE, INT] )
stockDB.createPartitionedTable (quoteSchema, "quotes", `date`sym)
tradeSchema = table (10: 0,` sym`date`time`price`vol, [SYMBOL, DATE, TIME, DOUBLE, INT])
stockDB.createPartitionedTable (tradeSchema, "trades", `date`sym)
En el ejemplo anterior, las dos tablas de partición de cotizaciones y operaciones utilizan el mismo mecanismo de partición.
DolphinDB es un sistema diseñado para OLAP, principalmente para resolver el almacenamiento y cálculo rápido de datos estructurados masivos, y para lograr un procesamiento de datos de alto rendimiento a través de bases de datos de memoria y transmisión de datos. DolphinDB no es adecuado para sistemas comerciales OLTP con cambios de datos frecuentes. La escritura de datos de DolphinDB es similar a Hadoop HDFS, que inserta rápidamente datos en lotes al final de cada partición o archivo. Los datos insertados se comprimirán y almacenarán en el disco, y la relación de compresión general es del 20% al 25%. Una vez que los datos se agregan a la tabla de datos basada en disco, algunos registros calificados no se pueden actualizar o eliminar rápidamente, y la tabla de datos debe modificarse por partición. Esta es también una de las razones por las que una sola partición no debería ser demasiado grande.
5. Mecanismo de copias múltiples
DolphinDB permite reservar múltiples copias de cada partición. El número predeterminado de copias es 2. Puede modificar el parámetro dfsReplicationFactor del nodo de control para establecer el número de copias.
Hay dos propósitos para configurar datos redundantes: (1) Cuando un nodo de datos falla o los datos del disco están dañados, el sistema brinda tolerancia a fallas para continuar brindando servicios; (2) Cuando una gran cantidad de usuarios concurrentes acceden, múltiples copias brindan equilibrio de carga Función para mejorar el rendimiento del sistema y reducir la demora de acceso.
DolphinDB utiliza un mecanismo de confirmación de transacciones de dos fases para garantizar una sólida coherencia de datos entre varios nodos cuando se escribe la misma copia.
En el archivo de parámetros controller.cfg del nodo de control, hay un parámetro muy importante dfsReplicaReliabilityLevel. Este parámetro determina si se permite que varias copias residan en varios nodos de datos del mismo servidor físico. En la etapa de desarrollo, se permite configurar varios nodos en una máquina y se permite que varias copias residan en el mismo servidor físico (dfsReplicaReliabilityLevel = 0), pero la etapa de producción debe establecerse en 1; de lo contrario, no funcionará como una copia de seguridad tolerante a fallas.
// El número de copias de cada partición de tabla o bloque de archivo. El valor predeterminado es 2. dfsReplicationFactor = 2 // Si varias copias pueden residir en el mismo servidor físico. Nivel 0: Permitir; Nivel 1: No ejecutar. El valor predeterminado es 0. dfsReplicaReliabilityLevel = 0
6. Mecanismo de transacción
DolphinDB admite transacciones para la lectura y escritura de tablas de bases de datos basadas en disco (sistema de archivos distribuido), lo que significa garantizar la atomicidad, coherencia, aislamiento y durabilidad de las transacciones. DolphinDB utiliza un mecanismo de múltiples versiones para lograr el aislamiento a nivel de instantánea. Bajo este mecanismo de aislamiento, las operaciones de lectura y escritura de datos no se bloquean entre sí, lo que puede optimizar el rendimiento de las lecturas del almacén de datos en la mayor medida posible.
Para optimizar el rendimiento de la consulta, el análisis y el cálculo del almacén de datos, DolphinDB impone algunas restricciones a las transacciones:
En primer lugar, una transacción solo puede incluir escritura o lectura, no escritura y lectura al mismo tiempo.
En segundo lugar, una transacción de escritura puede abarcar varias particiones, pero varios escritores no pueden escribir simultáneamente la misma partición. Es decir, cuando una partición está bloqueada por una determinada transacción A y otra transacción B intenta bloquear la partición nuevamente, el sistema lanzará inmediatamente una excepción y provocará que la transacción B falle y retroceda.
7. Escritura paralela de varios escritores
DolphinDB proporciona un poderoso mecanismo de partición. Una sola tabla de datos puede admitir varios millones de particiones, lo que crea las condiciones para la carga de datos en paralelo de alto rendimiento. Especialmente cuando se importan cantidades masivas de datos de otros sistemas a DolphinDB, o cuando es necesario escribir datos en tiempo real en el almacén de datos casi en tiempo real, la carga paralela es particularmente importante.
El siguiente ejemplo carga datos de cotización de acciones (cotizaciones) en la base de datos stockDB en paralelo. stockDB usa la fecha y el código de stock como una partición compuesta. Los datos se almacenan en archivos csv y cada archivo guarda los datos de cotización de un día.
) // Para cada archivo, el nombre de archivo genera el prefijo jobId.
// Utilice la función submitJob para enviar el demonio y llamar a loadTextEx para cargar los datos en la base de datos stockDB.
para (fname en nombres de archivo) {
jobId = fname.strReplace (". txt", "")
submitJob (jobId ,, loadTextEx {db, "quotes", `date`sym, fileDir + '/' + fname})
}
}
// La tarea loadJob se envía a cada nodo de datos del clúster a través de pnodeRun para la carga en paralelo.
pnodeRun (loadJob)
Cuando varios escritores cargan datos en paralelo, asegúrese de que estos escritores no escriban datos en la misma partición al mismo tiempo, de lo contrario, la transacción fallará. En el ejemplo anterior, cada archivo almacena los datos de un día, y un campo de partición de la tabla de cotizaciones es la fecha, para garantizar que todos los trabajos que cargan datos no generen transacciones superpuestas.
Bienvenido a visitar el sitio web oficial para descargar la versión de prueba de DolphinDB