如何将YugabyteDB设置为最终一致的分布式键值数据库？

Question

我正在创办一家提供网络SaaS (https://tuilder.com/)的初创公司。伟大的计划和潜力。

我对YugaByte的全局复制感兴趣。目前，我已经在BadgerDB上构建了一个抽象，这是一个用GoLang编写的键值数据库。我们的抽象维护索引，有点像graphql，而且速度非常快。是否可以将带有全局复制的YugaByte DB用作键值存储？

我的目标是全球分布的KeyValue的性能。

正如我所理解的，随着每个额外的复制节点的增加，写操作的速度会降低。是那么回事吗？是否有可能转而支持速度并在节点之间建立一个最终一致的模型呢？我们在建果酱堆。因此，我们需要在服务器上在YugaByte和客户端之间建立一个身份验证层，理想情况下，该层将提供我们目前用Go编写的抽象。

节点之间的负载平衡如何--将请求路由到最近的地理位置？

在YugaByte平台下，这一切都有可能吗？

Answer 1

感谢您对Yugabyte的兴趣！这绝对是一个很好的用例。请在线查看答案。

我对YugaByte的全局复制感兴趣。目前，我已经在BadgerDB上构建了一个抽象，这是一个用GoLang编写的键值数据库。我们的抽象维护索引，有点像graphql，而且速度非常快。是否可以使用带有全局复制的YugaByte DB作为键值存储，而不是GoLang？我的目标是全球分布的KeyValue的性能。

是的，您绝对可以使用Yugabyte实现高性能、全局分布的键值部署.您可以看到一个在这里进行全球分布式部署示例。

正如我所理解的，随着每个额外的复制节点的增加，写操作的速度会降低。是那么回事吗？是否有可能转而支持速度并在节点之间建立一个最终一致的模型呢？

作为一般规则，是的，延迟随着复制因子的增加而增加。复制因素主要是为了提高容错能力，但看起来您希望为接近最终用户的读取服务。在这个场景中，您有两个选项：

• 读取副本是集群中主数据的只读扩展。在此场景中，集群的主数据部署在一个区域中的多个区域或附近区域。读取副本不会添加到写入延迟，因为写入不会同步地将数据复制到它们--数据被复制到异步读取副本。您可以写入副本，但写入会在内部重定向到真相的来源。
• 多主部署目前正在作为我们测试版2.0版本的一部分发布。这个特性允许独立的集群与最后一个作者wins语义相互复制。这是一个关于多主部署的详细设计文档。

假设您想要全局读取和单个集群，我认为读取副本可能是您要寻找的。

因此，我们需要在服务器上在YugaByte和客户端之间建立一个身份验证层，理想情况下，该层将提供我们目前用Go编写的抽象。

是的，Yugabyte在Go客户端驱动程序中支持授权的身份验证和RBAC。

节点之间的负载平衡如何--将请求路由到最近的地理位置？

目前，YCQL支持从最近的地理区域读取数据，因此您应该已经能够轻松地做到这一点了。YCQL是半关系型的，但是对于键值应用程序来说，这应该足够了！

希望这有帮助，如果你还有其他问题，请告诉我！

Answer 2

正如我所理解的，随着每个额外的复制节点的增加，写操作的速度会降低。是那么回事吗？

前面的答案假设additional replicated node实际上是一个额外的副本。但是，如果它意味着集群中的一个新节点，那么答案是一个新节点不会增加写延迟。一个新节点只需为集群提供更多的写(读)吞吐量，因为它现在可以承载集群中的一些领导者和追随者碎片(也就是平板)。键值写入操作的延迟由集群的复制因子( RF )控制，对于生产部署，典型的RF为3。在这种部署中，每个碎片将有3个副本位于集群的3个独立节点上。在将操作返回到应用程序客户端之前，写入必须在领导者副本和至少两个跟随副本中的一个副本上提交。总之，只有在执行下列任何一项或两项操作时，写操作的延迟才会增加：

1. 增加承载3个副本的节点之间的地理距离
2. 将RF从3增加到5(这将导致4个副本中有3个需要在客户端ack之前提交写入)。

是否有可能转而支持速度并在节点之间建立一个最终一致的模型呢？

最终的一致性在Yugabyte 中是不可能的，因为处理写入请求的节点之间依赖于每个碎片分布式协商一致(使用Raft作为协商一致协议)。您可以在"Paxos/Raft与非协商一致的复制协议“一节中回顾Raft与在分布式数据库中，基于共识的复制是如何工作的？中最终一致性的区别。正如前面的答案所强调的那样，当跨区域写入延迟引起关注时，解决方案是使用读取副本集群(用于为时间线供电-在远离接受写入请求的区域中一致读取)或使用多主群集(用于在多个具有冲突的写入请求的区域(通过latency解决冲突的写入请求)进行异步复制)。