开发分布式SQL数据库的6种技术挑战
5.我们可以构建软件定义的原子钟吗? 作为分布式数据库,YugaByte DB支持跨多个节点的多键ACID事务(快照和可序列化隔离级别),即使存在故障也是如此。这需要一个可以跨节点同步时间的时钟。 Google Spanner使用TrueTime,这是一个具有严格错误界限的高可用性全局同步时钟的示例。但是,许多部署中都没有此类时钟。 物理时钟(或挂钟)不能在节点之间完美同步。因此,他们无法跨节点排序事件(建立因果关系)。除非存在中央时间戳权限,否则诸如Lamport时钟和向量时钟之类的逻辑时钟不会跟踪物理时间,这成为可扩展性瓶颈。 我们的方案: 混合逻辑时钟(HLC)通过将使用NTP粗略同步的物理时钟与跟踪因果关系的Lamport时钟相结合来解决该问题。 YugaByte DB使用HLC作为高可用性群集宽时钟,具有用户指定的最大时钟偏差上限值。HLC值在Raft组中用作关联更新的方式,也用作MVCC读取点。结果是符合ACID的分布式数据库,如Jepsen测试所示。 6.重写或重用PostgreSQL查询层? 最后但同样重要的是,我们需要决定是否重写或重用PostgreSQL查询层。 我们的初步决定 YugaByte数据库查询层在设计时考虑了可扩展性。通过在C ++中重写API服务器,已经在这个查询层框架中构建了两个API(YCQL和YEDIS),首先重写PostgreSQL API似乎更容易和自然。 我们的最终决定 在我们意识到这不是一条理想的道路之前,我们沿着这条路走了大约5个月。与PostgreSQL成熟,完整的数据库相比,其他API要简单得多。然后我们重新完成整个工作,回到绘图板并重新开始重新使用PostgreSQL的查询层代码。虽然这在开始时很痛苦,但回顾起来它是一个更好的策略。 这种方法也有其自身的挑战。我们的计划是首先将PostgreSQL系统表移动到DocDB(YugaByte DB的存储层),最初支持一些数据类型和一些简单查询,并随着时间的推移添加更多数据类型和查询支持。 不幸的是,这个计划并没有完全解决。要从psql执行看似简单的最终用户命令,实际上需要支持大量SQL功能。例如,d用于列出所有表的命令在内部执行以下查询:
WHERE支持操作符,例如IN,不等于,正则表达式匹配等。满足上述查询需要支持以下功能:
显然,这代表了各种各样的SQL功能,因此我们必须在创建单个用户表之前使所有这些功能都可用!我们在Google Spanner架构上发布分布式PostgreSQL - 查询层突出显示了查询层的详细工作方式。 结论 即使对于专家用户来说,不得不在市场上可用的许多数据库之间进行选择,一开始看起来似乎势不可挡。这是因为为给定类型的应用程序选择数据库取决于这些数据库在其体系结构中所做的权衡。 通过YugaByte DB,我们以一种新颖的方式组合了一组非常实用的架构决策,以创建一个独特的开源分布式SQL数据库。PostgreSQL强大的SQL功能现在可供您使用,零数据丢失,水平写入可扩展性,低读取延迟以及在公共云或Kubernetes中本机运行的能力。 (编辑:PHP编程网 - 黄冈站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |