Mil millones de operaciones en la base de datos en 0.3 segundos. No compare OLTP con OLAP, pero QuestDB con PostgreSQL

Muy a menudo, durante mis 15 a帽os de experiencia como desarrollador de software y l铆der de equipo, me encuentro con lo mismo. La programaci贸n se convierte en una religi贸n: rara vez alguien intenta introducir tecnolog铆a basada en una elecci贸n razonable, razonablemente, teniendo en cuenta las restricciones, la portabilidad, la evaluaci贸n del grado de apego al proveedor, el precio real, las perspectivas de la tecnolog铆a y la libertad de licencias. Los desarrolladores van a conferencias o leen publicaciones: comienzan a exagerar, y sus directores y gerentes de TI se alimentan no solo de historias de un futuro 谩gil y brillante en eventos, varios visionarios, ventas y consultores. Y resulta que las tecnolog铆as estaban en el proyecto, sin tener en cuenta la conveniencia del desarrollo y la implementaci贸n, los requisitos no funcionales del proyecto, sino porque es exagerado y Google se usa a s铆 mismo,amazon recomienda (aunque sus vacantes dicen que ellos mismos no lo usan a menudo) o la gerencia de la compa帽铆a tom贸 la decisi贸n m谩s alta de implementar "esto".


Pero la diversi贸n especial es elegir una base de datos. Cuanto mayor es el volumen de informaci贸n almacenada, cuanto m谩s compleja es la estructura de datos en el proyecto y sus cambios / evoluci贸n, mayores son los requisitos de tiempo de respuesta o rendimiento, m谩s costoso es el error de selecci贸n al comienzo en las etapas posteriores del proyecto.

Tengo una idea de por qu茅 esto es as铆: en pocas palabras, la creaci贸n de prototipos y la comparaci贸n de diferentes tecnolog铆as es "costosa" (tiempo, licencias, capacitaci贸n o ingenier铆a inversa) y existe la tentaci贸n de activar instintos antiguos y pasar de la parte de evidencia que consume mucho tiempo a divertido y simple, tocando el abismo de la irracionalidad. Tambi茅n hice esto, y tambi茅n vi c贸mo suceden las cosas m谩s rid铆culas en el trabajo de mis amigos y yo, y no solo por decisi贸n de especialistas t茅cnicos. Por lo tanto, la elecci贸n de un lenguaje de programaci贸n, marcos, colas de mensajes o proveedores en la nube tambi茅n se puede hacer sobre la base de publicaciones en redes, informes en conferencias, manuales de Gartner para gerentes o adivinaci贸n. Es una pena que no pueda contar muchas historias de mi trabajo, porque tengo miedo por mi vida despu茅s de eso ...

Lo que afecta la elecci贸n de la base de datos.


Desde mi punto de vista, al elegir una base de datos, tengo que resolver al menos los siguientes compromisos:

  • procesamiento de transacciones en tiempo real o procesamiento anal铆tico en l铆nea
  • escalable vertical u horizontalmente
  • en el caso de una base distribuida - consistencia de datos / disponibilidad / resistencia de separaci贸n (teorema CAP)
  • Un esquema de datos espec铆fico y restricciones en la base de datos o almacenamiento que no requieren un esquema de datos
  • modelo de datos: clave-valor, jer谩rquico, gr谩fico, documento o relacional
  • l贸gica de procesamiento lo m谩s cercana posible a los datos o todo el procesamiento en la aplicaci贸n
  • trabajar principalmente en RAM o con un subsistema de disco
  • soluci贸n universal o especializada
  • Utilizamos la experiencia existente en una base de datos que no es particularmente adecuada para los requisitos del proyecto o desarrollamos una nueva en capacitaci贸n adecuada pero no familiar, "sangre y sudor" (lo mismo se aplica no solo al desarrollo, sino tambi茅n a la operaci贸n)
  • incorporado o en otro proceso / red
  • inconformista o retr贸grado

A menudo obtenemos un "regalo" para la soluci贸n implementada:

  • Lenguaje de consulta "extranjero"
  • la 煤nica API nativa para trabajar con la base de datos, lo que complicar谩 la transici贸n a otras bases de datos (se gast贸 tiempo, esfuerzo de equipo y presupuesto del proyecto)
  • indisponibilidad de controladores para otras plataformas / idiomas / sistemas operativos
  • falta de c贸digos fuente, descripciones del formato de datos en el disco (o prohibici贸n de licencias de ingenier铆a inversa, especialmente Oracle con la coherencia con errores)
  • crecimiento de costo de licencia a帽o por a帽o
  • ecosistema propio y dificultad para encontrar especialistas
  • , ,

La escala horizontal de los sistemas es bastante compleja y requiere la experiencia del equipo. Los desarrolladores experimentados son bastante caros en el mercado, las aplicaciones distribuidas son m谩s dif铆ciles de desarrollar, depurar y probar. Por lo tanto, si es posible cambiar el servidor a uno m谩s potente y la cantidad de datos que permite el sistema, a menudo lo hacen. Ahora los servidores pueden tener terabytes de RAM y cientos de n煤cleos de procesador a bordo. Entonces, como nunca antes, es importante usar todos los recursos del servidor de la manera m谩s eficiente posible. El costo de las licencias de bases de datos tambi茅n es importante, y si se venden por n煤cleos de procesador, el presupuesto operativo, incluso con escala vertical, puede costar tanto como un programa espacial de superpotencia. Por lo tanto, es importante tener esto en cuenta para no poder escalar el rendimiento de la base de datos debido a las licencias.

Est谩 claro que con la ayuda del marketing tratar谩n de convencerlo de que solo la soluci贸n de una determinada empresa resolver谩 todos sus problemas (pero no mencionan cu谩ntos nuevos aparecer谩n). No existe una base de datos ideal que se adapte a todos y que sea adecuada para todo.

Por lo tanto, en el futuro previsible, a煤n admitiremos varias bases de datos diferentes para procesar los mismos datos para diferentes tipos de consultas en diferentes sistemas. Sin soluciones para Data Fabric sin almacenamiento en cach茅 de datos, Data Lake a煤n no se puede comparar con bases de datos con arquitectura de paralelo en masa en t茅rminos de rendimiento y optimizaci贸n de consultas. Los datos transaccionales a煤n se almacenar谩n en PostgreSQL, Oracle, MS Sql Server, las consultas anal铆ticas en Citus, Greenplum, Snowflake, Redshift, Vertica, Impala, Teradata y los pantanos de datos sin procesar en HDFS / S3 / ADLS (Azure) ser谩n administrados por Dremio , Redshift Spectrum, Apache Spark, Presto.

Pero las soluciones enumeradas anteriormente no son adecuadas para analizar datos de series temporales con un tiempo de respuesta bajo. Seg煤n su popularidad al trabajar con datos de series temporales, ahora est谩 en los favoritos de InfluxDB. En el nicho de la base de datos en memoria, kdb + y memSQL mantienen sus lugares.

QuestDB


驴Qu茅 puede oponerse a todas estas soluciones QuestDB de c贸digo abierto con una licencia de Apache?

  • Un intento de aprovechar al m谩ximo el hardware para realizar consultas anal铆ticas: vectorizaci贸n de funciones de agregaci贸n, trabajar con datos a trav茅s de archivos mapeados en memoria
  • SQL como lenguaje de consultas DML y operaciones DDL para gestionar la estructura de la base de datos
  • soporte para tablas de uni贸n espec铆ficas para series temporales DB
  • soporte para funciones de ventana y agregaci贸n en SQL
  • la capacidad de incrustar una base de datos en una aplicaci贸n en la JVM
  • JVM, ServiceLoader
  • Influx DB line protocol (ILP) UDP Telegraf. 芦What makes QuestDB faster than InfluxDB禄
  • PostgreSql 11 PostgreSQL: JDBC, ODBC psql
  • web - REST endpoint , SQL json
  • ,
  • zero-GC API, .
  • ( )
  • 64 Windows, Linux, OSX, ARM Linux FreeBSD
  • , open source,

Cu谩ndo puede serle 煤til esta base de datos: si est谩 desarrollando sistemas financieros en la JVM con una latencia baja y necesita una soluci贸n para el an谩lisis de datos en RAM. Como reemplazo de kdb + debido al costo de las licencias. Si recopila m茅tricas de acuerdo con el protocolo Influx / Telegraf, pero el rendimiento y la facilidad de uso de trabajar con InfluxDB no son satisfactorios. Si su proyecto se ejecuta en la JVM y necesita una base de datos integrada para almacenar m茅tricas o datos de aplicaciones que solo se agregan y no se actualizan.

La nueva versi贸n 4.2.0 con soporte para instrucciones SIMD caus贸 una ola de comentarios en Reddit . Para que los fan谩ticos participen en la competencia de conocimiento del hardware moderno y su programaci贸n efectiva, 隆recomiendo hablar con el autor de la base de datos (bluestreak01) en los comentarios!

Operaciones SIMD


El equipo del proyecto realiz贸 una prueba de datos sint茅ticos y compar贸 QuestDB 4.2.0 con kdb 4.0 para agregar mil millones de valores, aprovechando las instrucciones SIMD de los procesadores.

En la plataforma Intel 8850H:



en la plataforma AMD Ryzen 3900X:



est谩 claro que todas estas son pruebas en un "vac铆o", pero puede comparar sus datos si su proyecto usa kdb y compartir los resultados con la comunidad.

Ejecutando la imagen de la base de datos de Docker


La base de datos se publica en dockerhub con cada versi贸n. Se describen m谩s detalles en la documentaci贸n del proyecto .

Obtenga la imagen de QuestDB:

docker pull questdb/questdb

Lanzamos:

docker run --rm -it -p 9000:9000 -p 8812:8812 questdb/questdb

Despu茅s de eso, puede conectarse usando el protocolo PostgreSQL al puerto 8812, la consola web est谩 disponible en el puerto 9000.

Acceso jdbc


Dependiendo de nuestro proyecto, agregamos el controlador jdbc PostrgreSQL org.postgresql: postgresql: 42.2.12 , para esta prueba utilizo mi m贸dulo QuestDB para testcontainers . La prueba est谩 disponible en github junto con el script de compilaci贸n:

import org.junit.jupiter.api.Test;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

import static org.assertj.core.api.Assertions.*;

public class QuestDbDriverTest {

    @Test
    void containerIsUpTestByJdbcInvocation() throws Exception {
        try (Connection connection = DriverManager.getConnection("jdbc:tc:questdb:///?user=admin&password=quest")){
            try (Statement statement = connection.createStatement()){
                try (ResultSet resultSet = statement.executeQuery("select 42 from long_sequence(1)")){
                    resultSet.next();
                    assertThat(resultSet.getInt(1)).isEqualTo(42);
                }
            }
        }
    }
}

La ejecuci贸n de Docker genera una sobrecarga adicional, y esto se puede evitar simplemente implementando org.questdb: core: jar: 4.2.0 como una dependencia del proyecto y ejecutando io.questdb.ServerMain:

import io.questdb.ServerMain;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

import java.nio.file.Path;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.Statement;

public class QuestDbJdbcTest {
    @Test
    void embeddedServerStartTest(@TempDir Path tempDir) throws Exception{
        ServerMain.main(new String[]{"-d", tempDir.toString()});
        try (DriverManager.getConnection("jdbc:postgresql://localhost:8812/", "admin", "quest")){
            try (Statement statement = connection.createStatement()){
                try (ResultSet resultSet = statement.executeQuery("select 42 from long_sequence(1)")){
                    resultSet.next();
                    assertThat(resultSet.getInt(1)).isEqualTo(42);
                }
            }
        }
    }
}

Incrustar en la aplicaci贸n Java


Pero esta es la forma m谩s r谩pida de trabajar con la base de datos utilizando la API de Java en proceso:

import io.questdb.cairo.CairoEngine;
import io.questdb.cairo.DefaultCairoConfiguration;
import io.questdb.griffin.CompiledQuery;
import io.questdb.griffin.SqlCompiler;
import io.questdb.griffin.SqlExecutionContextImpl;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.io.TempDir;

import java.nio.file.Path;

public class TruncateExecuteTest {
    @Test
    void truncate(@TempDir Path tempDir) throws Exception{
        SqlExecutionContextImpl executionContext = new SqlExecutionContextImpl();
        DefaultCairoConfiguration configuration = new DefaultCairoConfiguration(tempDir.toAbsolutePath().toString());
        try (CairoEngine engine = new CairoEngine(configuration)) {
            try (SqlCompiler compiler = new SqlCompiler(engine)) {
                CompiledQuery createTable = compiler.compile("create table tr_table(id long,name string)", executionContext);
                compiler.compile("truncate table tr_table", executionContext);
            }
        }
    }
}

Consola web


El proyecto incluye una consola web para consultar QuestDB



Y descargar datos a una base de datos en formato csv a trav茅s de un navegador.



驴Necesitas otra base de datos?


Este proyecto es joven y a煤n carece de algunas caracter铆sticas corporativas, pero se est谩 desarrollando bastante r谩pido y varios colaboradores est谩n trabajando activamente en el proyecto. He estado siguiendo QuestDB desde agosto pasado y desarroll茅 un par de extensiones para este proyecto ( funci贸n jdbc y osquery ), y tambi茅n integr茅 este proyecto con testcontainers. Ahora estoy tratando de resolver mis problemas actuales en Dremio con la carga de datos incremental, la partici贸n de datos y las transacciones largas a las fuentes de datos en producci贸n usando QuestDB, complementando con funciones de exportaci贸n de datos. Planeo compartir mi experiencia en las siguientes publicaciones. Me soborna especialmente porque puedo depurar mis funciones y mi base de datos en la plataforma con la que estoy familiarizado, escribir pruebas unitarias que se ejecutan a la velocidad de la luz.

T煤 decides como desarrollador experimentado. Una vez m谩s, QuestDB no es un reemplazo para las bases de datos OLTP: PostgreSQL, Oracle, MS Sql Server, DB2 o incluso un reemplazo H2 para las pruebasen la JVM Esta es una poderosa base de datos especializada de c贸digo abierto con soporte para los protocolos de red PostgreSQL, Influx / Telegraf. Si su escenario de uso se ajusta a las caracter铆sticas que se implementan en 茅l y al escenario principal de usar una base de datos de columnas, 隆entonces la elecci贸n est谩 justificada!

All Articles