Clever Geek Handbook

值得关注的新数据库技术（第1部分）

在本文中，我们将讨论我们感兴趣的三种最新数据库技术：





在第二篇文章中，我们将向您介绍另外三个：





第三篇文章将专门讨论结论。



注意：这将仅专注于基础技术，并且在适当的地方，诸如企业功能之类的功能将在很大程度上被忽略。



瓷砖B



TileDB是围绕多维数组构建的数据库。它允许您使用不太适合现有关系数据库管理系统（RDBMS）的数据类型来简化工作，例如，密集和稀疏数组，数据帧。TileDB专为基因组学和地理空间数据等用例量身定制。



特色功能





我特别喜欢的东西



我们喜欢这样的“高度专业化”的数据库，它们针对一组特定的数据类型和任务进行了优化。当然，传统的RDBMS擅长于其相对通用性，可以涵盖极其广泛的用例（无须开玩笑）。但是有时在极端情况下，在最后阶段（a）“常规”系统的功能还不够，并且（b）这项任务对您的业务非常重要。



我们期望随着数据库用例和新主题领域的专业化出现其他类似的系统。好的老式RDBMS当然不会走光了，但是我想看看TileDB和其他类似系统如何发展和扩展可能的范围。我们希望会有非常“容易破解”的非整体数据库，该数据库具有用于连接插件的接口，以便您可以使用针对特定用例的非常特定的数据类型。但是稍后会更多。



对项目的疑问



  1. ? TileDB , , , ? .
  2. - ? , «TileDB -». ?


Materialize



Materialize被称为“第一个真正的流式SQL数据库”，也许这并不夸张！它本质上是一个与PostgreSQL “线兼容”的关系数据库，但是有一个重要的区别：它提供了实时刷新的实例化视图。



Materialize对“流存储”的定义似乎很有效。



例如，在标准Postgres中，您必须手动更新实例化视图： 



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;


可以以任何频率完成此操作，例如，使用脚本或调度程序任务。我们还没有看到（尽管我们一直很想看到）是一个数据库，它本身支持实例化视图的增量更新。是的，的确如此：Materialize跟踪指定数据源中的更改，并根据这些数据源中的更改来更新视图。



即使Materialize没有赢得或留在市场上的时间不够长，它提供的功能仍应继续，并且几乎可以肯定会在其他数据库中复制。



特色功能



  • , ( Postgres), JSON, CSV , Kafka Kinesis, .
  • : «» (timely dataflow) «» (differential dataflow). , . Materialize, , , Materialize — « », , .
  • Materialize «» Postgres, psql Postgres.




物化可能替代很多。最明显的是，该系统允许您使用所有可用的流程库来逐步更新您的物化视图。但这不是一个大胜利。



对我们而言，更重要的是，Materialize允许我们使分配用于跟踪数据源更改的数据堆栈部分无效。这可以在本地完成： 



CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';


现在，您的数据库“了解”可用于构建自动更新的实例化视图的数据源。在我看来，这种原生“流水线”比自动更新视图更具魔力。例如，如果运行仅跟踪的无服务器功能，Heron作业或Flink数据管道，并在其中添加运算符INSERT，那么Materialize将允许您简单地剥离堆栈的该部分。



对项目的疑问



  • 为什么要使用单独的数据库而不是Postgres扩展？我们确信，有很好的体系结构原因使扩展在此处无法如此工作，但是我想知道为什么。
  • 为其他数据源构建扩展有多容易？例如，如何编写Apache Pulsar的扩展？是否有计划为此目的向开发人员开放API？


棱镜



Prisma与其说是数据库，不如说是一组尽可能抽象数据库的工具。该系统目前在数据库方面与PostgreSQL，MySQL和SQLite兼容，并且在语言方面与JavaScript和TypeScript兼容（将来有望支持其他数据库和语言）。它被称为“现代应用程序的数据层”，通常是这样。



使用Prisma的“黄金方式”是这样的：



  1. 使用Prisma的SDL模式在应用程序级别定义数据类型。
  2. 根据创建的方案，为您选择的语言生成一个高度惯用的代码。
  3. 忙于构建REST API，GraphQL API以及您要构建的其他任何东西。


我们了解某些人对诸如Prisma之类的工具的怀疑。有一大批反对数据库抽象的开发人员。他们不需要智能DSL和GUI。他们想编写简单的SQL并手动创建所有数据库交互代码。我们了解保持这种控制程度的愿望，但是我们仍然建议您花20到30分钟尝试Prisma。我们认为找到蛮力和原始SQL之间的最佳结合点做得很好。



特色功能







Prisma的架构DSL不仅使您可以指定应用程序所需的数据类型，还可以确定要使用的代码生成器，以及要连接到的数据库的连接信息。



此外，枚举类型（枚举）设置，方便注释，比如@id，@relation和@default。让人想起从ActiveRecord和Ecto迁移数据库的DSL ，以及类似于协议缓冲区和Thrift中使用的IDL的DSL 。



我很乐意看到Prisma的SDL模式的改编或类似于独立于语言的标准（适用于特定于语言的库）的内容。现状假设每种编程语言都在改变方向。我们认为，采用一种独立于语言的方式来定义用于定义应用程序与数据库之间的交互的类型将是有用的。



顺便说一句，特别感谢Prisma提供的出色文档。我们绝对认为这是一个重要的区别，如果您的文档不属于博客文章的“我最喜欢的”部分，那么您应该投入更多的资源来创建白皮书。



对项目的疑问



Prisma在已经被广泛使用的对象关系映射（ORM）的语言中也会有用吗？如果将ActiveRecord用于Ruby或将Ecto用于Elixir，那么转换的动机是什么？


More articles:


All Articles