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

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

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

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

据我了解，每个额外的复制节点都会降低写入速度。是对的吗？是否有可能支持速度并在节点之间建立最终一致的模型？
我们正在构建 JAM 堆栈。所以我们在 YugaByte 和客户端之间的服务器上需要一个身份验证层，理想情况下，该层将提供我们目前用 Go 编写的相同抽象。

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

YugaByte 平台可以实现这一切吗？

最佳答案

感谢您对 Yugabyte DB 的关注!这绝对是一个很好的用例。请查看内联答案。



是的，您绝对可以使用 Yugabyte DB 实现高性能、全局分布式的键值部署。您可以看到 globally distributed deployment here 的示例。



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

只读副本 是集群中主数据的只读扩展。在这种情况下，集群的主要数据部署在一个区域的多个可用区中，或者跨附近的区域。只读副本不会增加写入延迟，因为写入不会将数据同步复制到它们 - 数据会异步复制到只读副本。您可以写入副本，但写入会在内部重定向到真实来源。

多主部署 目前正在作为测试版 2.0 版本的一部分发布。此功能允许独立的集群以最后写入者获胜的语义相互复制。这是一个 detailed design doc about multi-master deployments 。

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



是的，Yugabyte DB 在 Go 客户端驱动程序中支持 authentication and RBAC for authorization。



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

希望有帮助，如果您有任何其他问题，请告诉我!

关于saas - 如何将 YugabyteDB 设置为最终一致的分布式键值数据库？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/57949195/