服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

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

我经常使用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,意味着文件服务器上的工作负载将大大降低。 这又应该改善用户体验。 你真的认为我还有这个想法吗?