将 Windows 上的文件共享用于数据库时，其可靠性如何？
我们有一个在磁盘上生成数据库的应用程序。 该数据库由数千个文件组成。
该应用程序可以同时打开 500 到 3000 个文件的句柄。 这些句柄保持打开状态，数据不断写入。
到目前为止，它在本地硬盘上运行得很好，但是当尝试将数据库放在共享磁盘上时，我们遇到了很多问题。
这只是一个坏主意还是如果我们改变数据库引擎的设计以按需打开/关闭文件句柄它可以工作？
编辑
此时，我们只有一个客户端“连接”到数据库。
We have an application that produces a database on disk. The database is made of thousand of files.
The application can have from 500 to 3000 file's handle opened at the same time. These handle are kept opened and data is continuously written to.
Up until now, it worked really well on local hard drive, but when trying to put the database on a shared disk, we encountered a lot of problems.
Is it simply a bad idea or it can work if we change the design of the database engine to open/close file handle on demand?
EDIT
At this time, we only have one client "connected" to the database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
共享到网盘了吗？
如果是这样，那么无论网络延迟如何以及网络磁盘上的负载如何，性能显然都会受到通过 SMB 协议进行转换的影响。
Does the share go to a network disk?
If so then the performance is obviously going to be affected by translation through the SMB protocol, whatever network delay you have and the load on the network disk.
我想您遇到的问题来自“资源访问”家族：某些记录/表/文件必须/应该由多个用户在重叠的时间访问。 打开和关闭文件时的网络延迟也可能是一个问题，请检查您是否没有使用 NETbios 服务来处理此问题。
这种资源共享问题是一个经典问题，尽管只有当多个用户开始使用该应用程序时才变得真正明显......而这通常“为时已晚”。
您应该重新设计以使用数据库引擎，或者至少让所有请求都通过处理来自客户端的请求的服务器应用程序。 哦，等等，这相当于专门为此编写一个数据库引擎……我真笨，重新发明轮子。
除非您正在管理实时视频流（或者更复杂的东西），否则我建议重新设计以包含适当的数据库引擎。
I guess the problems you've encountered is from the "resource-access" family one: some records/tables/file must/should be accessed by multiple users at overlapping times. Network lags when opening and closing files could also be an issue, check that you are NOT using NETbios service to handle this.
This resource-sharing problem is a classical, although only becomes truly apparent when multiple users start using the app... and that's usually "too late".
You should either redesign to use a DB engine, or at least make all requests go through a server application that handles the requests from clients. oh, wait, that would be equivalent of writing a DB engine just for this... dumb of me, to reinvent the wheel.
Unless you're managing real-time video streams (or something even further complicated) I recommend a redesign to include a proper DB engine.
根据“共享文件”数据库（dBase、Paradox 等）的经验，这不能很好地扩展。 它还对网络错误和不良硬件非常敏感。
Based on experience with "shared file" databases (dBase, Paradox and the like) this doesn't scale well. It can also be very sensitive to network errors and bad hardware.
是的，这只是一个坏主意。 如果您想共享数据库，我建议重构为标准数据库，旨在良好地扩展并支持多用户访问。
Yes it is simply a bad idea. If you want to share your database I would suggest refactoring to a standard database designed to scale well and work with multi-user access.