我经常使用SQLite在公司中创build简单的程序。 数据库被放置在文件服务器上。 只要没有超过50个用户同时处理数据库（尽pipe取决于读取还是写入），这可以正常工作。 一旦出现这种情况，如果服务器上有大量的并发写入操作，会花费很多时间在锁上，而且没有数据库服务器，所以就没有任何caching。
不需要数据库服务器的好处是，设置公司Wiki或类似的东西的时间可以从几个月缩短到几天。 这通常需要几个月的时间，因为一些IT部门需要订购服务器，并且需要符合公司政策和安全规则，并且需要将其放置在外包的服务器托pipe设施上，等等
因此，我想到了创build一个分布式数据库服务器的想法。 这个过程如下：公司计算机上的用户在Wiki页面（使用这个数据库作为其后端）上编辑某些内容，为此，他在本地硬盘上读取一个文件，说明最后一台台式计算机的IP地址成为一个数据库服务器。 然后他试图通过TCP / IP直接联系这台计算机。 如果它没有回答，那么他将读取文件服务器上的一个文件，说明最后一台台式计算机的IP地址是数据库服务器。 如果这台服务器也不回答，他自己的台式计算机将成为数据库服务器，并将其IP地址注册到同一个文件中。 然后可以执行SQL更新语句，其他桌面计算机可以直接连接到他。
这种架构的重点在于，负载越高，function就越好，因为每台台式计算机总是知道数据库服务器的IP地址。 此外，使用这种设置，我相信放置在文件服务器上的数据库可以服务数百台台式电脑，而不是目前的50台左右。 我也不相信已经成为数据库服务器的单个台式计算机的负载将会变得明显，因为在这个桌面上不会有硬盘操作，只能在文件服务器上操作。
这个想法是否可行？ 它已经存在了吗？ 什么样的数据库可以支持这样的架构？
编辑：我应该指出，这个想法是不漂亮，稳定，最佳实践，或者我真的感到自豪。 我仍然对可行性感兴趣的原因是，我的一些客户是银行，涉及访问数据库的官僚机构是巨大的。 通常这些项目的项目发起人需要高于副总裁级别，因为他们对获得服务器的访问极度担心。 不用说，这意味着build立一个Wiki有很多工作。 后来如果Wikicertificate是成功的，那么它当然应该被移植到一个合适的数据库服务器上。
编辑2：这个想法的原因是当数据库被放置在文件服务器上时使用SQLite时降低写作者饥饿的风险。 这个问题在5.1节中描述。 利用台式电脑获得访问量最大的信息（即Wiki页面）的caching，意味着文件服务器上的工作负载将大大降低。 这又应该改善用户体验。 你真的认为我还有这个想法吗？
如果你在不同的数据库上分区（或者定位）你的读写，你实际上可以build立一个良好的分布式数据库环境。 我们做这样的工作，诀窍很简单。 您拥有文件服务器上的主数据库，并将所有写入作为目标。 您在每个用户的计算机上都有一个本地数据库副本，并将读取作为目标。 您现在还需要主数据库和本地数据库之间的同步机制。 这可以通过多种方式完成。 一种方法是在主数据库中有一个“增量”表。 此增量表将包含已在主数据库中应用的事务。 每当用户的应用程序执行读取或写入操作时，首先在主机上检查和更新主机上的增量。 只有尚未应用的增量中的交易（可以基于时间戳进行检查）才需要应用。 你甚至可以有一个后台进程不断这样做。 这个三angular洲可能是一个每天的三angular洲（或每周三angular洲），当它被刷新。 如果用户一个星期左右没有login，只需将整个数据库复制到用户的计算机即可。 拥有本地副本的好处是用户即使在离线状态下也可以查询资料 – 不pipe信不信 – 即使您在线更新资料，这个速度也相当快。
这个想法是否可行？
没有。
它已经存在了吗？
从来没听说过。
什么样的数据库可以支持这样的架构？
往上看。
老实说，这在很多方面都是一个非常糟糕的主意。 公司在数据中心保留关键数据是有原因的。 您不希望业务应用程序依赖于X台桌面机启动并运行。 另一个问题是防火墙 – 除了小环境之外，不能保证Desktop X能够与Desktop Y进行通信，并且让防火墙通过networking团队变好。
是否有任何理由你的公司没有一个中央维护良好的数据库服务器，这个应用程序可以使用？ 公司wiki没有理由需要自己的数据库服务器。
这个问题与系统pipe理无关，但是当我读到这么多警告时，我只能回答。
我真的不得不告诉你，你的整个概念是非常重要的，你不会find其他人这样做。 对于初学者来说，SQLite不适合这样的工作，事实上，你已经取得了一些成功，更多的是由于其他的好运。
你的计划有很多漏洞，我真的不知道从哪里开始，但是我会告诉你，这将是一个过于复杂的系统，将被certificate是非常不可靠的，performance不佳。
你的评论
时间设置像一个公司维基或类似的东西可以从几个月减less到几天
告诉我很多。 build立一个维基通常只需要几分钟的时间，任何体面的维基系统都将有助于加速从其他系统导入数据。
我build议你放弃你目前的devise思路，并看看其他人如何做这样的事情。 使用任何常用的wiki系统（我更喜欢MediaWiki）与常规的数据库系统（MySQL非常stream行），你不仅会节省大量的时间，而且你会得到一个更加可用的系统更强大，加上更便宜的实施。
总之，不要试图重新发明轮子，因为你现在的devise最终会变成一个大致中间有一个洞的方形。
如前所述，这个问题不在系统pipe理的范围之内。 也就是说，分布式数据库和分布式数据存储正在一些非常容易识别的地方使用。 虽然SQLite的优势通常不适用于这种types的应用程序，但这并不是闻所未闻的。 看，例如，在化石项目。 尽pipe这是一个基于SQLite的分布式源代码控制系统，但它也提供了一个分布式维基和一个博客应用程序，可能实际上也为你做了这个诀窍。 虽然你应该超越SQLite，但这并不意味着你需要放弃开源。 考虑在Apache CouchDB或基于Hadoop的数据存储中实现您的项目更新颖的方法是在Inferno等分布式用户空间虚拟环境中创build应用程序。
您的描述听起来很像POS（销售点）系统使用的。 一个主terminal在启动时被声明，进行数据库处理。 主站和所有从站terminal之间的数据库副本进行同步备份。
如果主人失败了，所有其他terminal都会popup一条消息，说“让我成为新主人？”。 你按是的，一切都在继续。 这可以继续，直到有一个terminal站立。
它的工作原理，是一种白痴certificate，但在一天结束时有一个损坏的数据库是常见的。 幸运的是，terminal只存储那些天的销售量，所以你的每日总数可能会有所下降，因为有些订单没有得到保存。 这比系统停下来几个小时而放弃销售更受欢迎。
在一个大的networking/电力中断中，清理结束是多余的，因为当前的销售可以分散到几个不同的terminal，所以你必须全部清理。 我很高兴我不再做这项工作。
坚持一个大的数据库服务器和良好的备份。
从你的问题来看，数据最终在哪里并不清楚？ 它居住在集中式文件服务器上吗？ 如果是这样，将数据库引擎移动到多个桌面上，同时使用集中式文件服务器作为磁盘存储可能不会给您带来太多的性能。 如果有的话，从发动机的磁盘的遥远可能会导致它运行更糟，如果有的话。
如果数据不是集中的，如果您有多个桌面都包含不同的数据位，则数据一致性将会成为问题。
数据库configuration和安全性方面也存在类似的问题，但都不是微不足道的。 最后，在服务于100多个活跃远程用户的台式机上运行数据库服务器将对该桌面的性能产生显着的影响。
你见过http://litereplica.io/吗？ 他们有一个nodejs的sqlite3驱动程序，它看起来相当好的架构。
我最近完成了SOA / ESB / RESTful中间件框架的分布式数据库层的开发，这个框架需要专有的数据库基础架构，而这些数据库基础架构是用C＃和SQLite的包装器构build的。
我的数据库层作为节点集群运行，包括见证节点（主节点和故障切换），数据写入/提交节点（又是主节点和故障切换）以及基本上存储复制数据的复制节点。
在写入操作上，所选的写入节点生成唯一的ID和外键，成功的数据写入节点的位置被索引。 这确保了复制的数据保持相同的ID和外键。 有线程/并行进程保持复制。 外键没有得到严格的执行，但是工作。
我也写了一个客户端包装这个数据层，提供证人之间的客户端连接string故障转移。
到目前为止，testing和基准似乎certificate了概念。 我已经testing了不同大小的数据，似乎处理得很好。 很明显，因为我的数据库层被devise成是Restful中间件，所以它的速度不如高可用性。 此外，数据结构的要求是这种方法是否起作用的主要因素。
我的下一个修订版本是查看是否可以在复制节点上分发大数据集的检索，因为数据集将stream式传输到客户端框架，这是一种带有json想法的数据网格。