- TileDB
- Materializar
- Prisma
No segundo artigo, vamos falar sobre mais três:
- EdgeDB
- Tremor
- Debezium
E o terceiro artigo será dedicado às conclusões.
Observação: isso se concentrará apenas na tecnologia subjacente, e recursos como recursos corporativos serão amplamente ignorados (quando apropriado).
TileD B
TileDB é um banco de dados construído em torno de arrays multidimensionais . Ele permite que você simplifique o trabalho com tipos de dados que não se encaixam perfeitamente nos sistemas de gerenciamento de banco de dados relacional (RDBMS) existentes, por exemplo, matrizes densas e esparsas , quadros de dados . O TileDB é adaptado especificamente para casos de uso, como genômica e dados geoespaciais .
Características notáveis
- Back-ends de dados alternáveis com suporte para Amazon S3 , MinIO e muito mais.
- Integrações de armazenamento para HDFS , PrestoDB , Apache Spark , Dask e muito mais.
- Vinculações de linguagem para C / C ++ , Python , R , Java e Go .
O que eu gostei principalmente
Gostamos desses bancos de dados "altamente especializados", aguçados para um conjunto específico de tipos de dados e tarefas. Os RDBMSs tradicionais são, é claro, bons em sua relativa versatilidade, permitindo-lhes abranger uma gama extremamente ampla de casos de uso (sem brincadeira). Mas às vezes há casos extremos, quando no último estágio (a) os recursos dos sistemas "convencionais" não são suficientes e (b) a tarefa é muito importante para o seu negócio.
Esperamos que outros sistemas semelhantes surjam conforme a especialização de casos de uso de banco de dados e novas áreas de assunto surjam. O bom e velho RDBMS, é claro, não irá a lugar nenhum, mas eu gostaria de ver como o TileDB e outros sistemas semelhantes evoluem e expandem os limites do que é possível. Esperamos que existam bancos de dados não monolíticos e muito "hackeados", que terão uma interface para conectar plug-ins para que você possa trabalhar com tipos de dados que são muito específicos para casos de uso específicos. Mas mais sobre isso mais tarde.
Perguntas para o projeto
- ? TileDB , , , ? .
- - ? , «TileDB -». ?
Materialize
Materialize é comercializado como "o primeiro banco de dados SQL de streaming verdadeiro" e talvez isso não seja um exagero! É essencialmente um banco de dados relacional que é "compatível com fio" com PostgreSQL , mas com uma diferença importante: oferece visualizações materializadas atualizadas em tempo real.
Existe a definição de " armazenamento de streaming " do Materialize , que parece funcionar para isso .
No Postgres padrão, por exemplo, você deve atualizar manualmente as visualizações 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;
Isso pode ser feito em qualquer frequência, por exemplo, usando um script ou uma tarefa do planejador. O que ainda não vimos (embora sempre quiséssemos ver) é um banco de dados que suporta nativamente atualizações incrementais de visões materializadas. Sim, de fato: Materialize rastreia as mudanças nas fontes de dados especificadas e atualiza as visualizações dependendo das mudanças nessas fontes.
Mesmo que o Materialize não ganhe ou permaneça no mercado por tempo suficiente, os recursos que ele oferece devem continuar e quase certamente serão replicados em outros bancos de dados.
Características notáveis
- , ( Postgres), JSON, CSV , Kafka Kinesis, .
- : «» (timely dataflow) «» (differential dataflow). , . Materialize, , , Materialize — « », , .
- Materialize «» Postgres, psql Postgres.
Materializar pode potencialmente substituir muito. O mais óbvio é que o sistema permite que você use todo o arsenal de processos disponível para atualizar progressivamente suas visões materializadas. Mas isso não é uma grande vitória.
Muito mais importante para nós é que Materializar nos permite tornar inativas as partes da pilha de dados que são alocadas para rastrear mudanças nas fontes de dados. Isso pode ser feito nativamente :
CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';
Seu banco de dados agora "sabe" sobre a fonte de dados que pode usar para construir visualizações materializadas atualizadas automaticamente. Esse "pipelining" nativo me parece ainda mais mágico do que a atualização automática de visualizações. Se você executar, por exemplo, funções sem servidor ou tarefas Heron ou pipelines de dados Flink , que são apenas rastreamento, e adicionar um operador lá
INSERT, então o Materializar permitirá que você simplesmente retire essa parte da pilha.
Perguntas para o projeto
- Por que um banco de dados separado e não uma extensão do Postgres ? Temos certeza de que existem boas razões arquitetônicas pelas quais a extensão não funcionará assim aqui, mas eu gostaria de saber por quê.
- É fácil construir extensões para outras fontes de dados? Como escrever, por exemplo, uma extensão para o Apache Pulsar ? Existem planos para abrir APIs para desenvolvedores com essa finalidade?
Prisma
O Prisma é menos um banco de dados do que um conjunto de ferramentas para abstrair seu banco de dados o máximo possível . O sistema é atualmente compatível com PostgreSQL , MySQL e SQLite no lado do banco de dados, e com JavaScript e TypeScript em termos de linguagem (com perspectiva de suportar outros bancos de dados e linguagens no futuro). É considerada a “camada de dados para aplicativos modernos”, o que geralmente é verdade.
A "maneira de ouro" de usar o Prisma é mais ou menos assim:
- Defina seus tipos de dados no nível do aplicativo usando o esquema SDL do Prisma.
- Com base no esquema criado, gere um código altamente idiomático para o idioma de sua escolha.
- Ocupe-se construindo APIs REST, APIs GraphQL e tudo o mais que você deseja construir.
Compreendemos as dúvidas de algumas pessoas sobre ferramentas como o Prisma. Há um grande grupo de desenvolvedores que se opõe à abstração do banco de dados. Eles não precisam de DSLs e GUIs inteligentes. Eles querem escrever SQL simples e criar todo o código de interação do banco de dados manualmente. Nós entendemos o desejo de manter esse grau de controle, mas ainda recomendamos que você gaste 20-30 minutos experimentando o Prisma. Parece-nos que ele faz um trabalho muito bom em encontrar o "meio-termo" entre "força bruta" e SQL bruto.
Características notáveis
- Prisma SDL , . .
- Prisma Migrate ( , SQL). , A , .
- Prisma Studio — , Prisma.
O esquema DSL do Prisma permite não apenas especificar os tipos de dados necessários para seu aplicativo, mas também determinar qual gerador de código você deseja usar, bem como as informações de conexão para o banco de dados ao qual está se conectando.
Além disso, são fornecidos tipos enumerados (enums), anotações convenientes como
@id, @relatione @default. Uma reminiscência do DSL para a migração de bancos de dados do ActiveRecord e Ecto , bem como IDLs semelhantes aos usados em Buffers de protocolo e Thrift .
Eu adoraria ver uma adaptação dos esquemas SDL do Prisma ou algo semelhante como um padrão independente de linguagem (adequado para bibliotecas específicas de linguagem). O status quo pressupõe que toda linguagem de programação reinventa a roda. Achamos que seria útil ter uma maneira independente de linguagem de definir os tipos que definem a interação entre o aplicativo e o banco de dados.
A propósito, um agradecimento especial à Prisma pela excelente documentação. Definitivamente, consideramos que essa é uma diferença importante e, se sua documentação não se enquadrar na seção “O que mais gostei” de uma postagem no blog, você deve investir mais recursos na criação de white papers.
Perguntas para o projeto
O Prisma também será útil em linguagens que já usam mapeamentos objeto-relacional (ORMs)? Se estiver usando ActiveRecord para Ruby ou Ecto para Elixir, qual é o incentivo para mudar?