在 docker 上读取多个数据库分片是个好主意吗？

Question

所以我有一个带有多个 CPU 内核的服务器，它安装了一个数据库。你认为如果我们用docker安装多个数据库（数据分片），那么每个请求都会去不同的数据库是个好主意吗？每个数据库中的数据都不同，并且根据来自客户端的请求，它将查询不同的数据库。

我不知道这会比包含所有数据的专用数据库更糟糕吗？

Answer 1

分片的问题在于应用程序必须知道要查询哪个分片。通常，这是通过对客户端之类的东西进行分片来完成的。我将改编我的一篇旧博客文章作为我的答案。

当您为大量客户端构建应用程序时，有两种常见的数据库设计方法：

• 选项 A：将所有客户端放在同一个数据库中
• 选项 2：为每个客户端构建一个数据库

将所有客户端放在同一个数据库中

很简单：只需在架构顶部添加一个 Client 表，添加一个 ClientUsers 表以确保人们只能看到他们自己的数据，然后我们就可以了。

这种方法的好处：

更轻松的架构管理。当开发人员部署新版本的应用程序时，他们只需在一个数据库中进行架构更改。不用担心不同的客户不同步或使用错误的版本。

更容易的性能调优。我们可以在一个地方检查索引使用情况和统计​​数据，轻松实施改进，并立即查看所有客户的效果。对于成百上千的数据库，即使是最小的更改也很难协调。我们可以检查我们的过程缓存内容，并确定哪些查询或存储过程在我们的整个应用程序中是最密集的，而如果我们为每个客户端使用单独的数据库，我们可能会在不同的执行计划中聚合查询使用更困难。

更容易构建外部 API。如果我们需要授予外部人员访问我们整个数据库的权限以构建产品，如果所有数据都在一个数据库中，我们可以更容易地做到这一点。如果 API 必须处理来自多个服务器上的多个数据库的数据分组，则会增加开发和测试时间。（另一方面，“多服务器”的事情开始暗示一个数据库到规则所有场景的限制：一个数据库通常意味着我们所有的负载只影响一个数据库服务器。）

更轻松的高可用性和灾难恢复。如果我们只需要担心一个数据库，那么管理数据库镜像、日志传送、复制和集群真的非常简单。我们可以快速构建大量基础设施。

将每个客户端放在自己的数据库或分片中

您仍然需要一个客户端列表，但现在它变成了一个目录 - 对于每个客户端，您还跟踪它所在的分片。在启动时，您的应用程序查询此表，并将其缓存在 RAM 中。当它需要客户端的数据时，它会直接连接到该分片（数据库和服务器）。

这种方法的好处：

更轻松的单客户端还原。客户是不可靠的肉包。（除了我的——它们是可靠的肉包。）他们有各种各样的“糟糕”时刻，他们想要将所有数据恢复到某个时间点，如果他们的数据与同一表中的其他客户数据。在单客户端数据库场景中恢复非常简单：只需恢复客户端的数据库即可。没有其他人受到影响。

更轻松的数据导出。客户喜欢接触他们的数据。他们想要知道他们可以随时获取数据的安全性，避免可怕的供应商锁定情况，并且他们想要做自己的报告。将每个客户的数据隔离到他们自己的数据库中，我们可以简单地给他们一份他们自己的数据库备份的副本。我们不必构建数据导出 API。

更轻松的多服务器可扩展性。当我们的应用程序需要比我们从单个服务器获得更多的能力时，我们可以在多个服务器之间划分数据库。我们还可以在地理上分散负载，将亚洲或欧洲的服务器放置在离客户更近的位置。

更轻松的每客户端性能调整。如果某些客户端使用不同的功能或报告，我们可以为这些客户端构建一组专门的索引或索引视图，而不会增加每个人的数据大小。诚然，这里存在一些风险——通过允许客户端之间的模式差异，我们只是使我们的代码部署风险更大，我们的性能管理更加困难。

更轻松的安全管理。只要我们正确锁定每个数据库一个用户的安全性，我们就不必担心客户端 X 访问客户端 Y 的数据。但是，如果我们只是为每个人使用单一登录，那么我们还没有真正解决这个问题。

更容易的维护窗口。 在客户分散在全球各地的全球环境中，如果我们可以分组或区域进行维护，则更容易让客户离线进行维护。

哪一个适合你？

没有一个正确的选择：您必须了解自己公司的优势和劣势。让我们以我的两个客户为例。

A 公司擅长硬件性能调优。他们真的非常擅长从硬件中榨取最后一点性能，而且他们不介意在 12-18 个月的周期内更换他们的 SQL Server 硬件。（他们每 4-6 个月更新一次 Web 服务器！）他们的致命弱点是极端的合规性和安全性要求。他们有令人难以置信的审计需求，对他们来说，在单个服务器、单个数据库上实施防弹控制比在数十台服务器上的数千个数据库中管理这些需求更容易。他们选择了一个数据库、一台服务器和许多客户端。

公司 2 擅长开发实践。跨数千个数据库管理架构更改和代码部署对他们来说不是问题。他们在世界各地都有客户，他们全天候为这些客户处理信用卡交易。他们需要能够在地理上分散负载，而且他们不想每 12-18 个月更换一次世界各地的服务器。他们为每个客户选择了一个数据库，并且随着他们开始在亚洲和欧洲为他们的离岸客户部署 SQL Servers，它得到了回报。