这种分布式数据库服务器集中存储的想法可行吗？

Question

我经常使用 SQLite 在公司中创建简单的程序。数据库放置在文件服务器上。只要不超过大约 50 个用户同时处理数据库（尽管取决于它是读取还是写入），这就可以正常工作。一旦超过这个数量，如果服务器上有大量并发写入，他们会注意到速度变慢，因为大量时间花在锁上，并且没有像缓存这样的东西，因为没有数据库服务器。

不需要数据库服务器的优点是设置公司 Wiki 或类似内容的时间可以从几个月减少到几天。通常需要几个月的时间，因为一些 IT 部门需要订购服务器，它需要符合公司政策和安全规则，并且需要放置在外包服务器托管设施上，这会搞砸并将其放置在错误的位置等等等等

因此，我想到了创建分布式数据库服务器的想法。过程如下：公司计算机上的用户在 Wiki 页面（使用此数据库作为其后端）上编辑某些内容，为此他读取本地硬盘上的文件，该文件说明最后一台台式计算机的 IP 地址成为数据库服务器。然后，他尝试通过 TCP/IP 直接联系这台计算机。如果它没有回答，那么他将读取文件服务器上的一个文件，指出最后一台台式计算机的 IP 地址作为数据库服务器。如果这台服务器也没有回答，他自己的台式机将成为数据库服务器，并在同一个文件中注册它的 ip 地址。然后就可以执行SQL更新语句，其他台式电脑就可以直接连接到他的了。

这种架构的要点在于，负载越高，它的功能就越好，因为每台台式计算机总是知道数据库服务器的 IP 地址。此外，使用此设置，我相信放置在文件服务器上的数据库可以为数百台台式计算机提供服务，而不是目前的 50 台左右。我也不相信已经成为数据库服务器的单台台式计算机的负载会很明显，因为在这个桌面上不会有硬盘操作，只有文件服务器上。

这个想法可行吗？它已经存在了吗？什么样的数据库可以支持这样的架构？

编辑：我应该指出，这个想法并不漂亮、稳定、最佳实践，或者我真正引以为豪的东西。我仍然对可行性感兴趣的原因是我的一些客户是银行，而访问数据库所涉及的官僚主义是巨大的。此类项目的项目发起人通常需要高于副总裁级别，因为他们对访问服务器的极端安全问题感到担忧。不用说，这意味着建立 Wiki 需要做很多工作。以后如果 Wiki 证明是成功的，当然应该将其迁移到适当的数据库服务器上。

Edit2：这个想法的原因是为了降低在将数据库放在文件服务器上时使用SQLite时发生Writer Starvation的风险。此问题在此处的第 5.1 节中进行了描述。利用台式计算机缓存最常访问的信息（即 Wiki 页面），意味着文件服务器上的工作负载将大大减少。这应该再次改善用户体验。你真的认为我对这个想法还很遥远吗？

Answer 1

这个想法可行吗？

不。

它已经存在了吗？

从来没听说过。

什么样的数据库可以支持这样的架构？

看上面。

老实说，这在很多层面上都是一个非常糟糕的主意。公司将关键数据保存在数据中心内是有原因的。您不希望业务应用程序依赖于 X 台台式机的启动和运行。另一个问题是防火墙——在除小型环境之外的所有环境中，无法保证桌面 X 能够与桌面 Y 通信，祝你好运，让防火墙更改通过您的网络团队。

您的公司是否有任何原因没有此应用程序可以使用的维护良好的中央数据库服务器？公司维基没有理由需要自己的数据库服务器。

Answer 2

这个问题与系统管理无关，但是当我阅读它时，发出了很多警告警报，我只需要回答即可。

我真的必须告诉你，你的整个概念太离谱了，你找不到其他人这样做。对于初学者来说，SQLite 不适合这样的工作，事实上你已经取得了一些成功更多是因为好运而不是其他任何事情。

你的计划有很多漏洞，我真的不知道从哪里开始，但我会告诉你，这将是一个过于复杂的系统，将被证明是非常不可靠和性能不佳的。

你的评论

建立公司 Wiki 或类似内容的时间可以从几个月减少到几天

告诉我很多。建立一个 wiki 通常只需要几分钟，任何像样的 wiki 系统都会有助手来加快从其他系统导入数据的速度。

我建议你放弃你目前的设计理念，看看其他人是如何做这些事情的。将任何一种常见的 wiki 系统（我更喜欢 MediaWiki）与常规数据库系统（MySQL 非常流行）一起使用，您不仅会节省大量时间，而且最终会得到一个更实用和更健壮，而且实施起来更便宜。

简而言之，停止尝试重新发明轮子，因为您当前的设计最终会更像是一个中间有一个洞的正方形。

Answer 3

如果您将读写分区（或定位）到不同的数据库，您实际上可以构建一个良好的分布式数据库环境。我们做这样的工作，技巧很简单。您在文件服务器上拥有主数据库，并将所有写入都定位到该数据库。您在每个用户的计算机上都有数据库的本地副本，并且您将读取的目标定位到它。您现在还需要主数据库和本地数据库之间的同步机制。这可以通过多种方式完成。一种方法是在主数据库中有一个“增量”表。该增量表将包含已在主数据库中应用的事务。每当用户的应用程序执行读取或写入操作时，首先会在本地检查并更新主服务器上的增量。仅需要应用Delta中尚未应用的交易（可以根据时间戳检查）。您甚至可以让后台进程连续执行此操作。当刷新时，该增量可以是每日增量（或每周增量）。如果用户一周左右没有登录，您只需将整个数据库复制到用户的计算机上即可。拥有本地副本的优点是，用户即使在离线状态下也可以查询内容，并且无论您相信与否，即使您在线更新内容，这也相当快。