专注闪存的 Regatta OLxP 数据库致力于为 AI 代理提供更快的数据访问

以色列初创公司 Regatta 正在构建一个可扩展的、支持事务处理 (OLTP) 和分析处理 (OLAP) 的关系型数据库 (OLxP)，并可扩展至半结构化和非结构化数据。该公司表示，这是 Postgres 的即插即用替代品，从一开始就被设计为支持 SSD 存储。其架构在联合创始人兼首席技术官 Erez Webman (前 ScaleIO 首席技术官，该公司于 2013 年被 EMC 收购) 的博客中有详细讨论。

这种 OLTP+OLAP 的组合已被其他供应商采用，如 SingleStore 添加了索引向量搜索以加快 AI 查询速度。SAP HANA、具有内存选项的 Oracle 数据库、具有内存 OLTP 的 Microsoft SQL Server、具有 Redshift Spectrum 的 Amazon Aurora、带有 Citus 或 Timescale DB 扩展的 PostgreSQL 都提供组合的事务和分析数据库功能。Regatta 正在进入一个相当成熟的市场，并认为其架构具有优势。

Webman 表示："Regatta 主要是一个无共享的集群架构，异构节点 (服务器、虚拟机、容器等) 可以协同工作，以并行/分布式方式执行长期 (以及短期) SQL 语句，节点之间支持多对多数据传播 (即中间数据无需通过中心节点)。"每个存储驱动器"只能由集群中的单个节点访问"。

Regatta 集群设计支持数千个节点，可支持不同大小和配置的节点，这些节点可以提供计算+存储、仅计算或仅存储功能。数据库可以托管在本地物理或虚拟服务器以及公共云中，并可作为服务使用。

Regatta 与 MongoDB 等分片扩展数据库的不同之处在于支持跨节点边界的分布式 JOIN，并确保即使行位于不同节点上也能保证强大的 ACID 特性。

该公司开发了自己的并发控制协议 (CCP)，提供完全可序列化和外部一致性的隔离级别。在数据库支持并发用户或应用程序访问的情况下，不同用户的操作需要保持独立，不互相干扰。这就是并发控制的目的，可以采用悲观或乐观设计。悲观设计假设事务之间的数据访问冲突可能发生，并使用锁确保同一时间只有一个事务可以访问或修改数据。

乐观设计假设事务数据访问冲突很少见，允许事务不受限制地进行，直到需要提交更改。在提交之前，每个事务都会经过验证阶段，检查其读取的数据自最初读取以来是否被其他事务修改 (使用时间戳或数据版本)。

Webman 表示，Regatta 的 CCP "主要是乐观的，但与大多数乐观协议不同，它在检测到冲突时不会导致事务中止 (当然，除了死锁情况，在这种情况下，乐观和悲观协议都倾向于中止每个死锁循环中的一个事务)"。它是无快照的，不需要时钟同步。

短期或长期一致/可序列化的只读查询可以在实时、最新的事务数据上执行，而不会阻塞写入事务的进行。

Regatta 直接在原始块存储之上实现自己的行存储数据布局以优化 I/O 性能，不需要任何底层文件系统。这是一个与 LSM 树设计有很大不同的日志结构数据布局。它的设计考虑了对其他类型行存储、列存储、blob 存储等的可扩展性。Webman 表示，"第一种行存储数据布局类型专门针对闪存媒体进行了优化。它使我们能够在同一个表中最优地支持传统的固定大小的小行和具有大动态范围大小的可变大小大行"。

据了解："Regatta 的 B+树 (例如用于索引) 大量利用闪存媒体的高并发读取特性，与假设使用更'通用'底层存储 (即磁性硬盘) 的算法相比，可以实现明显更快和更高效的 B+树访问。"

CEO 兼联合创始人 Boaz Palgi 告诉我们，Regatta 系统旨在确保： - 在完全实时的事务数据上执行复杂和实时查询 – 例如电信公司的客服代理收到刚刚为套餐添加漫游服务的用户关于漫游的问题。 - 执行事务，使同一代理理解用户应该同时添加意大利和法国的漫游服务，而不是仅添加法国，并需要进行相应修正。 - 通过简单添加更多节点，在不更改业务逻辑代码的情况下线性提升事务和分析性能。这对于在增加大量代理的同时保持业务运转至关重要。

他说："传统数据库无法提供性能来处理这种代理生成的负载，大多数数据库也无法在同一个数据库中结合 OLAP 和 OLTP。数据仓库无法支持代理的事务工作负载。当您希望代理不仅仅处理陈旧的基于存档的数据时，ETL 就成为一个问题。"

对于生成式 AI，"我们目前没有做任何特定的工作，不过我们将添加一些功能。"