我们有一个GDBM键值数据库作为负载均衡的面向Web的应用程序的后端，该应用程序是用C ++实现的。应用程序提供的数据已经变得非常大，因此我们的管理员已将GDBM文件从“本地”存储（在Web服务器上，或非常接近）移动到大型，共享，远程，NFS挂载的文件系统。
这影响了性能。我们的性能测试（在测试环境中）显示页面加载时间从数百毫秒（对于本地磁盘）跳跃到几秒（通过NFS，本地网络），有时甚至高达30秒。我相信问题的很大一部分是应用程序从GDBM文件中进行大量随机读取，并且这些在NFS上比较慢，而且在生产中会更糟糕（前端和后端都有甚至更差）它们之间的网络硬件更多）和我们的数据库变得更大。
虽然这不是一个关键应用程序，但我希望提高性能，并提供一些资源，包括应用程序开发人员时间和Unix管理员。我的主要约束是时间只有几周的资源。
我认为，我的选择是：
通过调整参数来提高NFS性能。我的直觉是我们不会从中得到很多，但之前我错了，而且我对NFS调整并不是很了解。
转到其他键值数据库，例如memcachedb或Tokyo Cabinet。
用其他协议替换NFS（已经提到过iSCSI，但我不熟悉它）。
我该如何解决这个问题？
答案 0 :(得分：10)
不要过于依赖“关系与非关系”比较。这似乎与这个问题无关。
您的应用程序划过的行是另一行：从本地快速文件存储上的小型数据库到通过网络访问的大型数据库。跨越该行意味着您现在可以通过专用的网络服务数据库管理系统获得更好的服务。管理服务器是否管理关系数据库与该方面无关。
为了快速启动和运行，MariaDB（MySQL的继任者）可能是你最好的选择。如果你预见它会比现在增长得多，你也可以把它放在PostgreSQL中，因为无论如何它最终还是要去的地方： - ）
答案 1 :(得分：2)
这似乎不是你想听到的，但老实说，如果我是你，我会把它扔进一个mysql表。这并不是说使用起来更有意义，而且你可以从中获得很多好处，尤其是实际上适用于你的情况的远程访问协议，与GDBM-over-NFS不同。
答案 2 :(得分：1)
如果您想坚持使用非关系数据库，可以尝试BDB或DJB CDB。到目前为止，我已经使用了两者，我认为当它取决于性能时，它们的性能优于GDBM。
但请记住bignose的答案，因为我也认为你的瓶颈可能不是你正在使用的数据结构（GDBM），而是你的基础设施。
答案 3 :(得分：0)
通过网络使用平面文件的文件系统i / o不是一个好主意，但你应该考虑编写一个多线程tcp服务器来进行i / o，查询等。在那台机器上，然后返回结果。传输小块数据而不是整个db文件..
我正在设计缓存持久性机制来克服高可用性问题。我将在python中对其进行编码。