我正在成立一家提供Web SaaS（https://tuilder.com/）的新兴公司。大计划和潜力。
我对与YugaByte进行全局复制感兴趣。目前，我已经基于BadgerDB建立了一个抽象，它是用GoLang编写的键值数据库。我们的抽象维护索引，有点图形化，并且非常快。可以将具有全局复制功能的YugaByte DB用作键值存储吗？
我的目标是实现全球分布式KeyValue的性能。
据我了解，写入速度随着每个额外的复制节点而降低。那正确吗？是否有可能会偏向于速度并在节点之间建立最终一致的模型呢？ 我们正在构建JAM堆栈。因此，我们需要在服务器端YugaByte和客户端之间的身份验证层，理想情况下，该层将提供与当前用Go编写的相同的抽象。
将请求路由到最近地理位置的节点之间的负载平衡如何？
YugaByte平台能否做到所有这些？
答案 0 :(得分：3)
感谢您对Yugabyte DB的关注！这绝对是一个很好的用例。请在线查看答案。
我对与YugaByte进行全局复制感兴趣。目前，我已经基于BadgerDB建立了一个抽象，它是用GoLang编写的键值数据库。我们的抽象维护索引，有点图形化，并且非常快。是否可以将具有全局复制功能的YugaByte DB代替GoLang用作键值存储？我的目标是提高全球分布KeyValue的性能。
是的，您可以使用Yugabyte DB绝对实现高性能，全局分布的键值部署。您可以看到一个globally distributed deployment here的示例。
据我了解，写入速度随着每个额外的复制节点而降低。那正确吗？是否有可能会偏向于速度并在节点之间建立最终一致的模型呢？
通常，是的，延迟随着复制因子而增加。复制因子主要是为了提高容错能力，但看起来您想为最终用户提供读取服务。在这种情况下，您有两个选择：
只读副本是集群中主数据的只读扩展。在这种情况下，群集的主数据部署在一个区域中的多个区域或附近区域中。只读副本不会添加到写入延迟中，因为写入不会将数据同步复制到这些副本中-数据被复制到异步副本中。您可以写副本，但是写会在内部重定向到真相。
多主机部署当前作为Beta 2.0版的一部分发布。此功能允许独立集群以 last writer wins 语义相互复制。这是detailed design doc about multi-master deployments。
假设您需要全局读取和单个群集，我认为您可能正在寻找只读副本。
因此，我们需要在服务器端YugaByte和客户端之间建立一个身份验证层，理想情况下，该层将提供与当前用Go语言编写的抽象层相同的抽象层。
是的，Yugabyte DB在Go客户端驱动程序中支持authentication and RBAC for authorization。
将请求路由到最近地理位置的节点之间的负载平衡如何？
YCQL API当前支持从最近的地理区域读取数据，因此您应该已经可以轻松实现这一目标。 YCQL API是半关系式的，但是对于键值应用而言，这足够了！
希望有帮助，如果您还有其他问题，请告诉我！
答案 1 :(得分：2)
据我了解，写入速度随着每个额外的复制节点而降低。那正确吗？
上一个答案假设additional replicated node实际上是一个附加副本。但是，如果这意味着群集中有一个新节点，那么答案是新节点不会增加写入延迟。由于新节点现在可以托管集群中存在的某些领导者和跟随者碎片（又名平板电脑），因此它可以为集群提供更多的写入（和读取）吞吐量。键值写操作的延迟由群集的复制因子（RF）控制，对于生产部署，典型的RF为3。在这样的部署中，每个分片将有3个副本位于群集的3个独立节点上。在必须将操作确认回应用程序客户端成功之前，写操作必须在领导者副本和2个跟随者副本中的至少1个提交。总之，仅当以下两个或两个操作同时执行时，写操作的延迟才会增加：
增加托管3个副本的节点之间的地理距离
将RF从3增大到5（这将导致4个副本中的3个需要在客户端确认之前提交写入操作。）
是否有可能更喜欢速度并在节点之间建立最终一致的模型？
在Yugabyte DB中不可能实现最终一致性，因为在处理写入请求的节点之间依赖于每个分片的分布式共识（使用Raft作为共识协议）。您可以在这篇文章How Does Consensus-Based Replication Work in Distributed Databases?的“ Paxos / Raft与非共识复制协议”部分中查看Raft与最终一致性的区别。如上一个答案中突出显示的那样，当需要考虑跨区域写入延迟时，解决方案是使用跨区域的异步复制，方法是使用只读副本集群（用于为远离接受写入请求的区域的区域提供时间轴一致的读取）或多-主群集（用于为多个区域中的写入提供动力，并通过上次写入者获胜解决冲突的写入请求。）