En el segundo artículo te contamos tres más:
Y el tercer artículo estará dedicado a las conclusiones.
Nota: Esto se centrará únicamente en la tecnología subyacente, y las características como las características empresariales se ignorarán en su mayoría (cuando corresponda).
TileD B
TileDB es una base de datos construida alrededor de matrices multidimensionales . Le permite simplificar el trabajo con tipos de datos que no encajan del todo en los sistemas de administración de bases de datos relacionales (RDBMS) existentes, por ejemplo, matrices densas y dispersas , marcos de datos . TileDB está diseñado específicamente para casos de uso como genómica y datos geoespaciales .
Características notables
- Backends de datos intercambiables con soporte para Amazon S3 , MinIO y más.
- Integraciones de almacenamiento para HDFS , PrestoDB , Apache Spark , Dask y más.
- Enlaces de lenguaje para C / C ++ , Python , R , Java y Go .
Lo que me gustó especialmente
Nos gustan estas bases de datos "altamente especializadas", perfeccionadas para un conjunto específico de tipos de datos y tareas. Los RDBMS tradicionales son, por supuesto, buenos en su relativa versatilidad para cubrir una amplia gama de casos de uso (no es broma). Pero a veces hay casos extremos, cuando en la última etapa (a) las capacidades de los sistemas "convencionales" no son suficientes y (b) la tarea es muy importante para su negocio.
Esperamos que surjan otros sistemas similares a medida que crece la especialización de casos de uso de bases de datos y surgen nuevas áreas temáticas. El viejo RDBMS, por supuesto, no irá a ninguna parte, pero me gustaría ver cómo TileDB y otros sistemas similares evolucionan y expanden los límites de lo que es posible. Esperamos que haya bases de datos no monolíticas muy “pirateadas” que tengan una interfaz para conectar complementos para que pueda trabajar con tipos de datos que son muy específicos para casos de uso específicos. Pero más sobre eso más adelante.
Preguntas al proyecto
- ? TileDB , , , ? .
- - ? , «TileDB -». ?
Materialize
Materialise se comercializa como "la primera base de datos SQL de transmisión verdadera" y quizás esto no sea una exageración. Es esencialmente una base de datos relacional que es "compatible con cables" con PostgreSQL , pero con una diferencia importante: ofrece vistas materializadas actualizadas en tiempo real.
Existe la definición de Materialise de " almacenamiento de transmisión ", que parece funcionar .
En Postgres estándar, por ejemplo, debe actualizar manualmente las vistas materializadas:
CREATE MATERIALIZED VIEW my_view (/* ... */);
REFRESH MATERIALIZED VIEW my_view;
/* The underlying tables change */
REFRESH MATERIALIZED VIEW my_view;
/* More stuff happens */
REFRESH MATERIALIZED VIEW my_view;
Esto se puede hacer con cualquier frecuencia, por ejemplo, mediante un script o una tarea del programador. Lo que aún no hemos visto (aunque siempre quisimos ver) es una base de datos que admite de forma nativa actualizaciones incrementales de vistas materializadas. Sí, de hecho: Materialise realiza un seguimiento de los cambios en las fuentes de datos especificadas y actualiza las vistas según los cambios en estas fuentes.
Incluso si Materialise no gana o no permanece en el mercado el tiempo suficiente, las capacidades que ofrece deberían continuar y es casi seguro que se replicarán en otras bases de datos.
Características notables
- , ( Postgres), JSON, CSV , Kafka Kinesis, .
- : «» (timely dataflow) «» (differential dataflow). , . Materialize, , , Materialize — « », , .
- Materialize «» Postgres, psql Postgres.
Materialise tiene el potencial de reemplazar mucho. Lo más obvio: el sistema te permite utilizar todo el arsenal de procesos disponible para actualizar progresivamente tus vistas materializadas. Pero eso no es una gran victoria.
Mucho más importante para nosotros es que Materialise nos permite desactivar aquellas partes de la pila de datos que están asignadas para rastrear cambios en las fuentes de datos. Esto se puede hacer de forma nativa :
CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';
Su base de datos ahora "sabe" acerca de la fuente de datos que puede utilizar para crear vistas materializadas actualizadas automáticamente. Esta "canalización" nativa me parece incluso más mágica que la actualización automática de vistas. Si ejecuta, por ejemplo, funciones sin servidor, trabajos de Heron o canalizaciones de datos de Flink , que solo están rastreando, y agrega un operador allí
INSERT, entonces Materialise le permitirá simplemente eliminar esa parte de la pila.
Preguntas al proyecto
- ¿Por qué una base de datos separada y no una extensión de Postgres ? Estamos seguros de que existen buenas razones arquitectónicas por las que la extensión no funcionará así aquí, pero me gustaría saber por qué.
- ¿Qué tan fácil es crear extensiones para otras fuentes de datos? ¿Cómo se puede escribir, por ejemplo, una extensión para Apache Pulsar ? ¿Hay planes para abrir API a los desarrolladores con este fin?
Prisma
Prisma es menos una base de datos que un conjunto de herramientas para abstraer su base de datos tanto como sea posible . El sistema es actualmente compatible con PostgreSQL , MySQL y SQLite en el lado de la base de datos, y con JavaScript y TypeScript en términos de lenguaje (con la perspectiva de soportar otras bases de datos y lenguajes en el futuro). Se factura como la "capa de datos para aplicaciones modernas", lo que generalmente es cierto.
La "forma dorada" de usar Prisma es algo como esto:
- Defina sus tipos de datos a nivel de aplicación utilizando el esquema SDL de Prisma.
- Basado en el esquema creado, genere un código altamente idiomático para el idioma de su elección.
- Ocúpese creando API REST, API GraphQL y cualquier otra cosa que desee construir.
Entendemos las dudas de algunas personas sobre herramientas como Prisma. Hay un gran grupo de desarrolladores que se oponen a la abstracción de bases de datos. No necesitan DSL ni GUI inteligentes. Quieren escribir SQL simple y crear todo el código de interacción de la base de datos a mano. Entendemos el deseo de mantener este grado de control, pero aún así recomendamos que dedique entre 20 y 30 minutos a probar Prisma. Nos parece que hace un muy buen trabajo al encontrar la "media dorada" entre "fuerza bruta" y SQL sin formato.
Características notables
- Prisma SDL , . .
- Prisma Migrate ( , SQL). , A , .
- Prisma Studio — , Prisma.
El esquema DSL de Prisma le permite no solo especificar los tipos de datos requeridos para su aplicación, sino también determinar qué generador de código desea usar, así como la información de conexión para la base de datos a la que se está conectando.
Además, se proporcionan tipos enumerados (enumeraciones), anotaciones convenientes como
@id, @relationy @default. Con reminiscencias del DSL para migrar bases de datos desde ActiveRecord y Ecto , así como IDL similares a los que se utilizan en Protocol Buffers y Thrift .
Me encantaría ver una adaptación de los esquemas SDL de Prisma o algo similar como un estándar independiente del idioma (adecuado para bibliotecas específicas del idioma). El status quo asume que cada lenguaje de programación reinventa la rueda. Creemos que sería útil tener una forma independiente del lenguaje de definir los tipos que definen la interacción entre la aplicación y la base de datos.
Por cierto, un agradecimiento especial a Prisma por la excelente documentación. Definitivamente consideramos que esto es una diferencia importante, y si su documentación no encaja en la sección "Lo que más me gustó" de una publicación de blog, entonces debería invertir más recursos en la creación de documentos técnicos.
Preguntas al proyecto
¿Prisma también será útil en lenguajes que ya tienen mapeos relacionales de objetos (ORM) ampliamente utilizados? Si usa ActiveRecord para Ruby o Ecto para Elixir, ¿cuál es el incentivo para cambiar?