Pacific 版本新特性：Ceph 上的 SQL

batrick

Pacific 版本中提供了一个新的 libcephsqlite 库，它提供了一个 ceph SQLite3 虚拟文件系统 (VFS)。该 VFS 实现了对 SQLite3 的后端支持，以便在 Ceph 的分布式对象存储 RADOS 上存储和操作数据库文件。使用 SQLite 的普通未修改的应用程序只需进行微不足道的重新配置即可切换到这个新的 VFS。

SQLite 被选为 Ceph 的 SQL 引擎，因为它被广泛认为是灵活且强大的应用程序数据存储。它甚至被合理地认为是 “全球部署和使用最多的数据库引擎”。除此之外，它的 虚拟文件系统 架构也使其具有吸引力且易于移植。一个简单的胶水库就足以让 SQLite 与替代存储系统进行通信。

对于 Ceph，这个胶水库通过将读取、写入和文件锁转换为对 Ceph 的 RADOS 中一系列对象的相应操作来工作。这主要涉及在 Ceph 中将 SQLite 数据库文件 条带化 到多个对象上。（这是我们已经在 CephFS 和 RBD 中经常做的事情。）

用法

要使用 RADOS 上的 SQLite，只需要让应用程序加载插件库 libcephsqlite。这通过 扩展加载 API 或通过 sqlite3 实用程序命令来完成

.LOAD libcephsqlite.so

加载 VFS 后，就可以打开或创建存储在 RADOS 上的 SQLite 数据库。通常的做法是通过 URI 来实现

.OPEN file:///mypool:mynamespace/main.db?vfs=ceph

这会将 SQLite 数据库存储在池 mypool 中，在 RADOS 命名空间 mynamespace 中，在一系列对象中，统称为 main.db。可以使用环境变量配置要使用的 Ceph 配置、密钥环和客户端标识符，请 参阅文档。

配置好后，应用程序可以继续像往常一样使用 SQLite，只需注意一些 注意事项。

仅限串行写入器

ceph VFS 通过获取数据库第一个对象的 RADOS 独占锁来执行事务。这与在常规 POSIX 文件系统上使用 POSIX 文件锁以确保修改期间独占访问的行为相同。因此，RADOS 上的 SQLite 仅支持串行写入事务：您可以拥有多个数据库写入器，但每个事务都是串行执行的。

并行读取支持 计划中。

性能调优

自然地，将数据库文件存储在 RADOS 上会比本地 SSD 慢。即便如此，仍然可以进行许多性能优化以获得令人满意的性能。首先要探索的优化是提高应用程序中的事务效率。小事务涉及过多的锁定和与分布式对象存储的同步点。更大的事务将显著提高性能。之后，您可以

最后，请阅读 文档 中的性能说明。在生产集群上正确调整的数据库连接可以实现毫秒级的事务，并以读写速度饱和网络链路。

将 SQLite 放在 RADOS 上的好处

将 SQLite 数据库存储在 RADOS 上提供了将数据移动到分布式存储系统中的典型好处。数据变得更可用、访问速度更快且易于扩展大小。强大的用例将使用 SQLite 来存储 CephFS 或 RGW 等典型 Ceph 服务之外的表格数据。例如，可以使用一系列 SQLite 数据库作为多个客户端易于索引的 blob 存储。（但是，请注意 并行读取支持尚未实现。）

元数据的替代存储格式

这个新的 SQLite 插件的主要驱动力之一是将应用程序（包括一些内部 Ceph 服务）从使用 RADOS omap 存储转变为快速、可扩展且强大的 SQL 存储。应用程序将单个对象的 omap 用作某些应用程序数据的通用键/值存储的做法已经很常见。不幸的是，这无法扩展到一定数量的键/值对，并且用于操作键/值对的 API 对高级应用程序不友好。（RADOS omap 并非用于琐碎的应用程序元数据。）SQLite 允许我们弥合这一差距。

在 Ceph 中，我们正在进行更改以使用 SQLite 来存储 Ceph 管理器模块的状态。从 Quincy 版本开始的 Ceph 集群将使用一个新的专用池（“.mgr”），该池存储每个模块的持久数据库。所需的 更改 非常简单。例如，devicehealth 模块将是第一个使用 SQLite 的模块，并且只需要增加 36 行代码。

结论

在使用 Ceph 上的 SQLite 之前，请仔细阅读 如何避免因滥用而损坏数据库。在 Ceph 上构建高度可用的客户端权威数据库时，尤其重要的是不要忽略内置保护。尽管如此，我们相信这将成为 Ceph 上一种流行的替代存储介质。开发人员渴望了解插件的运行情况以及您的应用程序看到的性能如何。