为什么MyWorld从Cassandra切换到CockroachDB

“今日社区”的客座作者丹尼尔·佩拉诺(Daniel Perano)是“我的世界”(MyWorld)的全栈开发者和创始人。他是使用CockroachDB构建有趣项目的众多开发人员之一。如果你想客串写一篇关于你的项目的博客，请联系我们的社区闲置频道。

MyWorld是下一代虚拟世界初创公司。当前的社交虚拟世界(如Second Life和OpenSimulator)是建立在几十年前的技术之上的，它们的设计从根本上是有限的。MMOG(大规模多人在线游戏)开发人员缺乏一个通用的、可扩展的平台，这意味着需要多年的工作和数百万美元才能为几乎每一个MMOG构建一个自定义引擎-迫使独立工作室和许多其他小型开发人员完全退出市场。在MyWorld，我们正在从头开始构建一个全新的虚拟世界平台，使用现代工具和技术创建一个快速、可伸缩和可扩展的平台，为下一代社交虚拟世界和大型多人在线游戏提供动力。

此外，我们想要一个数据库，它遵循我们自己的哲学，即制作尽可能自我维护的软件，并且只需要最少的人工交互来操作。最后，我们需要我们使用的任何数据库都是开源或开放核心的-这种开放性是MyWorld传统和设计理念的核心，而且由于MyWorld将在alpha和beta发布之后的某个时候开放源代码，我们不能考虑关闭源代码或供应商锁定的数据库。

在幕后，我们的技术堆栈在很大程度上建立在内部代码和一些业内最好的开源软件的组合上。数据库层基于轻量级ORM模式-Postgres JDBC驱动程序、HikariCP连接池和jNimble ORM，上面有一个薄层，用于将我们的域对象映射到SQL或从SQL映射(为了设计灵活性和性能，所有查询都是手写的-我们现在不使用jNimble的自动映射特性)。在更高的层次上，我们的物理引擎是Bullet，我们在服务器端和客户端都使用jMonkeyEngine游戏引擎。世界模拟是通过内部实体系统处理的，脚本编写是使用强大的高级内部脚本语言(使用类、一流函数、动态类型和多态性面向对象)完成的。我们使用Jetty HTTP服务器满足嵌入式HTTP需求，客户端UI使用JavaFX完成。

在移植数据库后端以使用CockroachDB之前，我们使用的是Cassandra。最初，这很顺利，因为我们的数据模型总是被设计成在数据库表示方面尽可能简单和直接。然而，随着我们的增长和发现越来越多的查询需求，Cassandra的非规范化模式和缺乏灵活的索引开始成为一个真实且非常明显的限制，特别是因为它的范围严重受限的查询意味着在其开箱即用功能之上实现我们自己的更高级别的索引将是一项非常困难的工作。

我们在Cassandra上坚持了尽可能长的时间-它是一个非常快速和可伸缩的数据库，并且它已经在与任何其他数据库都不同的规模上进行了试验和验证(苹果的集群超过了75k活动节点)。真正的水平可伸缩性和在节点关闭的情况下保持操作的能力对我们至关重要。然而，我们越是遇到卡桑德拉对我们数据模型的限制，我们就越意识到卡桑德拉对我们设计的影响：

使用Cassandra过度影响了模型，限制了我们更高级别的设计选择，并迫使我们在应用程序级别而不是在数据库中维护某些区域的数据一致性。一些设计权衡总是必须在分布式环境中进行，但是Cassandra正在以数据库不应该影响的方式影响更高级别的设计选择。

卡桑德拉很出色，但我们的需求只是超出了卡桑德拉的设计能力。此外，虽然Cassandra的“CCM”工具可以很好地管理开发中的仅限本地的数据库集群，但我们越来越担心Cassandra在生产中可能需要的运营开销水平。

由于我们对Cassandra的投资以及对性能权衡的担忧，我们最初评估CockroachDB的速度很慢。然而，一旦我们尝试移植一些数据库代码，并尝试使用Cassandra时遇到困难的领域，几乎就会做出决定。我们可以以任何最适合每个区域的方式对数据建模，如果我们需要对几个不相关的数字列进行范围查询(这在Cassandra中很难高效完成)，我们总是可以添加一个索引，然后或多或少地忘记它。

切换到SQL意味着我们可以按照应该建模的方式对数据建模，并依赖完全的多表事务和SQL约束来维护数据完整性。从Cassandra迁移到SQL的过程出奇地轻松-我们的数据模型已经是强类型的表格形式，而且由于我们选择将查询编写为手写CQL(Cassandra查询语言，本质上是SQL的子集)，而不是使用ORM，所以我们只需对现有查询进行最小程度的语法和类型更改，就可以有一个运行CockroachDB的功能起点。

选择SQL意味着获得灵活的索引、完整性约束、功能齐全的事务，以及以远远超过Cassandra所允许的灵活性高效地对数据建模的能力。选择CockroachDB尤其意味着我们可以拥有SQL的强大功能，只进行最低限度的性能权衡(更重要的是，能够以Cassandra无法支持的方式进行权衡)，在我们可以处理的流量和数据规模上有效地不妥协，并且操作几乎不需要人工干预。

对我们来说，CockroachDB与Postgres的兼容性是另一个很大的优势--这意味着用久经考验的Postgres驱动程序&；库来开发我们的代码，在最糟糕的情况下，如果CockroachDB出现灾难性的问题，只需很少甚至不需要修改代码就可以切换到Postgres(尽管这会对可伸缩性造成严重影响)。

最后但并非最不重要的一点是，CockroachDB只能在开发中工作。当我第一次尝试它时，我拼凑了一个基本的3行shell脚本来启动一个3节点集群。

初始安装和设置只花了大约30分钟，包括摆弄集群参数和内置的Web仪表板。这让我很震惊-数据库不会出现这种情况，尤其是在集群配置中。

您不需要下载软件，然后就像这样启动并运行一个3节点群集。在我得到了我喜欢的初始配置之后，我从来没有花费任何时间来修复任何东西-它就是不会坏。Cassandra的“CCM”工具也非常有效，但是在版本升级期间每隔几个月(或者仅仅是运气不好)就会出问题，我会花费数小时将数据库集群恢复到我的开发机器上。这种情况在CockroachDB中从未发生过一次。CockroachDB微不足道的适应服务器和本地开发环境的能力对我们来说是一个巨大的好处。

我们还没有向公众推出MyWorld平台。我们的第一个公开测试版计划在2020年第二季度发布。现在，我们在一台开发机器上运行一个轻量级的3节点集群。我们预计将在全球范围内采用，这意味着我们将需要在地理上分布我们的集群，以降低用户的延迟，并遵守GDPR和其他全球数据本地化法规。虽然我们承诺只收集对操作至关重要的个人用户数据(例如帐户的电子邮件地址和入侵检测的IP地址日志)，但我们收集的数据可能会受到数据地方性法律的约束-因此我们可能需要CockroachDB的地理分区功能来将用户数据保存在它所属的国家/地区。

如果您正在为您自己的产品评估CockroachDB，我强烈建议您只下载它并从命令行运行几个查询-您很快就会对它在开发中的处理方式有一个很好的感觉。[编者按：CockroachCloud是另一个快速启动和运行的选择--它是我们完全托管和托管的数据库即服务。我们从这里开始。]。如果您有正在考虑移植的现有代码库，请慢慢来阅读迁移指南和功能支持页面-我发现文档全面而清晰地说明了哪些是受支持的，哪些是不受支持的，以及您应该知道的任何注意事项。

在这篇博客文章之后，我将用一个“第2部分”来讨论在我们推出MyWorld平台并扩大用户群之后生产中的数据库性能。同时，如果您想了解更多关于“我的世界”或关注我们的进展，请访问我们的网站，在Twitter或Facebook上关注我们，或者来与我们就不和谐或在CockroachDB社区闲聊！