我经常在公司使用 SQLite 来创建简单的程序。数据库放在文件服务器上。只要同时使用数据库的用户不超过 50 个（但取决于是读还是写），这种方法就没问题。一旦超过这个数字，如果服务器上有大量并发写入，他们会注意到速度变慢，因为大量时间都花在了锁上，而且没有数据库服务器，所以没有缓存之类的东西。
不需要数据库服务器的优点是，建立公司 Wiki 或类似系统的时间可以从几个月缩短到几天。通常需要几个月的时间，因为某些 IT 部门需要订购服务器，并且需要符合公司政策和安全规则，并且需要将其放置在外包服务器托管设施上，而这会导致问题，并将其放置在错误的位置等。
因此，我想到了一个创建分布式数据库服务器的想法。该过程如下：公司计算机上的用户在 Wiki 页面上编辑某些内容（该页面使用此数据库作为其后端），为此，他读取本地硬盘上的文件，该文件指出了最后一台要作为数据库服务器的台式计算机的 IP 地址。然后，他尝试通过 TCP/IP 直接联系这台计算机。如果它没有应答，那么他将读取文件服务器上的文件，该文件指出最后一台要作为数据库服务器的台式计算机的 IP 地址。如果这台服务器也没有应答，他自己的台式计算机将成为数据库服务器，并在同一个文件中注册其 IP 地址。然后可以执行 SQL 更新语句，其他台式计算机可以直接连接到他的台式计算机。
这种架构的要点是，负载越高，其功能就越好，因为每台台式计算机始终都知道数据库服务器的 IP 地址。此外，使用这种设置，我相信放置在文件服务器上的数据库可以为数百台台式计算机提供服务，而不是当前的 50 台左右。我也不相信已成为数据库服务器的单台台式计算机上的负载会很明显，因为此台式计算机上不会有硬盘操作，只有文件服务器上有硬盘操作。
这个想法可行吗？它已经存在了吗？什么样的数据库可以支持这样的架构？
编辑：我应该指出，这个想法并不漂亮、稳定、最佳实践，或者我真正引以为豪的东西。我仍然对可行性感兴趣的原因是我的一些客户是银行，而获取数据库访问权限所涉及的官僚机构非常庞大。由于他们对获取服务器访问权限的极端安全担忧，此类项目的项目发起人通常需要高于副总裁级别。不用说，这意味着建立 Wiki 需要做大量工作。如果 Wiki 后来被证明是成功的，当然应该将其迁移到合适的数据库服务器上。
编辑2：这个想法的原因是当数据库放在文件服务器上时，使用 SQLite 时降低 Writer Starvation 的风险。此问题在第 5.1 节中描述这里。利用台式计算机缓存最常访问的信息（即 Wiki 页面），意味着文件服务器的工作量将大大减少。这又应该会改善用户体验。你真的认为我的想法还远远不够吗？
答案1
如果您将读写操作分区（或定位）到不同的数据库，您实际上可以构建一个良好的分布式数据库环境。我们做这样的工作，诀窍很简单。您在文件服务器上拥有主数据库，并将所有写入定位到它。您在每个用户的计算机上都有数据库的本地副本，并将读取定位到它。现在，您还需要主数据库和本地数据库之间的同步机制。这可以通过多种方式完成。一种方法是在主数据库中有一个“增量”表。此增量表将包含已在主数据库中应用的事务。每当用户的应用程序执行读取或写入操作时，首先检查主数据库中的增量并在本地更新。只有尚未应用的增量中的事务（可以根据时间戳进行检查）才需要应用。您甚至可以让后台进程连续执行此操作。当刷新时，此增量可能是每日增量（或每周增量）。如果用户一周左右没有登录，您只需将整个数据库复制到用户的计算机上。拥有本地副本的优势在于用户即使处于离线状态也可以查询内容，而且 - 不管你信不信 - 即使你在线更新内容，速度也非常快。
答案2
这个想法可行吗？
不。
它已经存在了吗？
从来没听说过。
什么样的数据库可以支持这样的架构？
往上看。
老实说，从很多层面来说，这都是一个很糟糕的主意。公司将关键数据保存在数据中心内是有原因的。您不希望业务应用程序依赖于 X 台台式机的启动和运行。另一个问题是防火墙 - 在所有小型环境之外，都无法保证桌面 X 能够与桌面 Y 通信，并且祝您的网络团队好运，希望防火墙的更改能顺利通过。
您的公司没有一个维护良好的中央数据库服务器供此应用程序使用，这是为什么呢？公司 wiki 没有理由需要自己的数据库服务器。
答案3
这个问题与系统管理无关，但当我读到它时，许多警告响起，所以我必须回答。
我真的必须告诉你，你的整个概念都离题太远了，你不会找到其他人这样做的。首先，SQLite 不适合这样的工作，而你使用它取得一些成功更多的是因为好运气，而不是其他什么。
你的计划有太多漏洞，我真的不知道从哪里开始，但我会告诉你，这将是一个过于复杂的系统，将被证明是极其不可靠和性能不佳的。
你的评论
建立公司 Wiki 或类似内容的时间可以从几个月缩短到几天
告诉我很多。设置 wiki 通常只需几分钟，任何像样的 wiki 系统都会有助手来加速从其他系统导入数据。
我建议你放弃当前的设计理念，看看其他人是如何做这些事情的。使用任何一种常见的 wiki 系统（我更喜欢 MediaWiki）和常规数据库系统（MySQL 非常流行），你不仅可以节省大量时间，而且最终会得到一个更可用、更强大的系统，而且实施起来更便宜。
简而言之，不要再试图重新发明轮子了，因为您当前的设计最终会更像一个中间有一个洞的正方形。
答案4
您的描述听起来很像 POS（销售点）系统所使用的。启动时会声明一个主终端，用于处理数据库。主终端和所有从属终端之间会同步数据库副本以进行备份。
如果主终端发生故障，所有其他终端都会弹出一条消息，提示“让我成为新主终端？”。您按“是”，一切将继续。这种情况会一直持续，直到有一个终端可以继续运行。
它确实有效，而且有点防傻瓜，但一天结束时数据库损坏是很常见的。幸运的是，终端只存储当天的销售额，因此由于某些订单没有正确保存，您的每日总数可能会有一点偏差。这比系统停机几个小时并损失销售额要好。
在发生大规模网络/电力中断时，加班就是为了完成一天结束时的清理工作，因为当天的销售可能分散在多个不同的终端，你必须把所有事情都整理出来。我很高兴我不再做这项工作了。
坚持使用一个具有良好备份的大型数据库服务器。