您应该关注的最新数据库技术
我是数据库的超级粉丝，以至于我写了一本关于所谓的“NoSQL”数据库的书，我花了我在技术上最有成就的几年时间在非常有影响力的分布式数据库Riak上工作，我甚至在去年建立了一个名为Purple的数据库，只是为了好玩。
当然，当我浏览Twitter、Reddit和HackerNews时，我总是在关注数据库和与DB相关的工具方面的新的、令人兴奋的发展。在这篇文章中，我想谈谈最近出现的三种我觉得很有趣的数据库技术：
在第3部分中，我将以一些结束语结束。注意：我将只关注核心技术，而主要忽略诸如企业特性之类的东西(在适用的情况下)。
我的选择标准纯粹是主观的。如果这里有什么你认为我应该检查的东西，发推特给我，让我知道！我的名字是“Lucperkins”。
TileDB是围绕多维数组构建的数据库，它使您能够轻松处理不太适合现有RDBMS系统的类型，如密集和稀疏数组和数据帧。TileDB专门面向基因组学和地理空间数据等用例。
我非常喜欢这样的“专业”数据库，它们专注于一组特定的数据类型和问题。传统RDBMS的伟大之处在于，它们的通用性足以涵盖非常广泛的用例(不是双关语)，但有时您会遇到“最后一英里”的边缘用例，这些用例既超出了“厨房水槽”系统的能力，也是您业务的核心。
我期望看到更多这样的系统出现，因为数据库用例变得越来越专业化，并且出现了新的问题领域。当然，老保守的RDBMS哪儿也不会去，但看到TileDB和其他人挑战极限还是令人鼓舞的。我真正希望的是出现极端“可破解”的、绝对非整体式的DB，它们为高度特定于用例的数据类型提供插件接口，但这是我稍后要讨论的内容。
与数据库端相比，客户端库端完成了多少工作？TileDB客户端本质上是特定于语言的数学库，用于在本地操作复杂的数据类型，偶尔会将结果保存到所需的后端，还是像其他DB客户端库一样，大多数情况下只是将命令中继到数据库？从文档中看，这一点并不完全清楚。
在现有K/V选项过多的情况下，提供键值存储的理由是什么？文档甚至说“TileDB不是被设计成作为特殊用途的键值存储来工作的。”在这样的功能上棘轮有什么价值？
Materialize在其网站上将自己吹捧为“第一个真正的SQL流数据库”，这实际上可能并不夸张！它本质上是一个与PostgreSQL完全兼容的关系数据库，但最重要的区别在于它提供了实时更新的物化视图。
创建实体化视图MY_VIEW(/*.*/)；刷新实体化视图MY_VIEW；/*底层表变*/刷新实体化视图MY_VIEW；/*发生更多事情*/刷新实体化视图MY_VIEW；
您可以随心所欲地频繁执行此操作，也许可以使用脚本或cron作业。然而，我还没有看到但总是秘密地想要的是一个本机支持对实例化视图的增量更新的数据库。是的，没错：MATERIALIZE侦听您指定的数据源中的更改，并在这些源更改时更新视图。
即使实现不会“取胜”或停留很长时间，我怀疑它给桌面带来的功能会一直存在，并且几乎肯定会在未来的DB中重现。
多种多样的数据源，包括其他表(如标准Postgres中的)、JSON、CSV和其他文件、Kafka和Kinesis主题，以及将来很可能出现的许多其他主题。
核心引擎由两个真正强大的结构驱动：实时数据流和差异数据流。我不会在这里详述这些，但我强烈建议您自己钻研这些概念。非常注重学术的Materialize的创建者已经深入参与了这两个项目，所以你可以相信Materialize不是“黑客精神”的产物，而是一个极其谨慎、挑剔的过程。
因为Materialize与Postgres是有线兼容的，所以您仍然可以使用psql和您已经习惯的所有其他Postgres工具。
物化有可能取代很多东西。最明显的是，它允许您完全抛弃用于增量更新实例化视图的任何现有进程。这是一个中等规模的胜利。
然而，对我来说，更大的胜利是，Materialize允许您停用数据堆栈中专门用于侦听数据源更改的那些部分。你可以本能地做这样的事情：
您的DB现在“知道”一个数据源，它可以用它来构造自动更新的实例化视图。对我来说，这种原生的“管道”比自动更新视图更神奇。比方说，如果您运行的是无服务器函数、Heron作业或Flink管道，它们只不过是在这里侦听，在那里编写一条INSERT语句，那么Materialize将使您能够随意地删除堆栈中的那部分。
为什么是单独的数据库而不是Postgres扩展？我相信扩展在这里不会有很好的架构原因，但我很想知道是什么原因。
为其他数据源构建扩展有多容易？例如，我如何编写Apache Pulsar的扩展？您是否计划向开发人员公开这方面的API？
Prisma不是一个数据库，而是一组试图尽可能抽象您的数据库的工具。它目前在DB端兼容PostgreSQL、MySQL和SQLite，在语言端兼容JavaScript和TypeScript(即将支持更多的数据库和语言)。它将自己吹捧为“现代应用程序的数据层”，这听起来是对的。
总体而言，我确实理解一些人可能对Prisma这样的东西犹豫不决。很大一部分开发人员不希望将数据库抽象化。他们不想要聪明的DSL和GUI。他们希望编写纯SQL，并且希望手工编写所有的DB交互代码。我对那件事本身没有意见。值得一提的是，许多人试图做普里斯玛做的事情，但失败了，因为他们。
Prisma Client使您能够使用专门的模式SDL来定义所需的数据类型，该模式会为您生成代码。甚至数据库的连接信息也会从您的应用程序代码中消失，消失在生成的代码中。
PRISMA Migrate使您能够以声明方式定义数据库迁移(而不是像使用SQL那样强制定义)。DB如何从状态A转到状态B的混乱细节隐藏在视图之外。
Prisma Studio是一个可视化编辑器，本质上提供了超越其他Prisma工具的GUI。
Prisma schema DSL不仅可以定义应用程序所需的数据类型，还可以定义要使用的代码生成器以及要连接到的DB的连接信息。
此外，它还提供枚举、方便的注释，如@id、@Relation和@Default。它让人想起ActiveRecord和ECTO中的DB迁移DSL，以及Protocol Buffers和Thrift使用的IDL。
我真的很希望看到Prisma schema SDL或类似的东西被采纳为语言中立的标准(可由特定于语言的库使用)。现状是，每种编程语言都在重新发明轮子。我认为，以一种与语言无关的方式定义那些定义应用程序和数据库之间关系的类型将是有益的。
与此相关的是，我们要快速喊出普里斯玛极其精美的文档。我绝对认为这是一个功能，如果你的文档不属于博客文章的“我最喜欢的”部分，那么你应该在技术写作上投入更多的资源。
Prisma在已经广泛使用ORM的语言中也有用吗？如果我为Ruby使用ActiveRecord，或者为Elixir使用ECTO，我转换的动机是什么？
这很尴尬，但是为什么Prisma是一家公司呢？我不知道怎么付钱给你，也不知道🤷🏼♂️的钱是多少，我喜欢免费的东西，所以我会拿着它，但我很想知道这一切的去向。
我目前正在寻找一份新的工作，并愿意获得报酬，再次在数据库工作。如果你想聊天，可以发邮件到[email protected]找我。我在围棋、Java和Elixir方面相当危险，有大量的技术写作和DevRel经验，对Kubernetes、Prometheus、Apache Pulsar、Heron和簿记以及许多其他技术的实时三位一体了如指掌。你可以在主页上找到更多关于我的信息。我也愿意承揽各种合同工作。
