开发分布式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中本机运行的手段。 (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |