文件存储库
我想开发一个开源库,用于快速高效的文件存储(在一个大文件和索引文件下),例如 NFileStorage。我为什么要这样做?
答:在我的工作范围内,需要类似的东西。
B.我们的DBA说在DB下存储文件效率不高。
C. 这对我来说是一个很好的练习。
我正在寻找一篇有关文件索引的好文章 你能推荐一个吗?
你的总体想法是什么?
I want to develop an open source library, for a fast efficient file storage (under one large file, and index file) like NFileStorage. why i want to do this ?
A. under my line of work something like that waS needed.
B. our DBA said its not efficient to store files under the DB.
C. Its a good practice for me.
I am looking for a good article for file indexes
can you recommend one ?
what is your general idea ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在数据库中存储文件可能效率不高,但是像 SQL Server 这样的数据库具有 FileStreams 的概念,它实际上将文件存储在本地文件系统上,而不是将其放置在数据库文件本身中。
在我看来,这对于一个项目来说是一个坏主意。
您将遇到与数据库将所有上传的文件存储在同一个文件中完全相同的问题......这就是为什么其中一些数据库已经不再使用二进制/大型对象,而是支持替代方法。
您必须处理的一些问题包括:
第 1 项和第 2 项会导致将“文件”写入数据存储所需的时间增加。网络文件系统已经支持第 3、4 和 5 项,因此您只需重新创建轮子即可。
简而言之,您必须编写自己的文件系统或编写自己的 DBMS。对于 99% 的现实世界应用程序,我都不认为这两者是“良好实践”。如果您的目标是为 Seagate 工作,这可能是值得的。但即便如此,他们也可能会用滑稽的眼神看着您。
如果您确实对最有效的文件存储方法感兴趣,那么购买 SAN 阵列并将文件推送到其中,同时保留指向数据库中的文件/位置的指针非常简单。易于备份,快速存储文件,比开发人员花时间尝试弄清楚如何编写自己的文件系统要便宜得多,而且未来的开发人员肯定会 100% 支持和理解。
It may not be efficient to store files inside a database, however databases like SQL Server have the concept of FileStreams where it actually stores it on the local file system instead of placing it in the database file itself.
In my opinion this is a bad idea for a project.
You are going to run into exactly the same problem that databases have with storing all of the uploaded files inside the same single file... which is why some of them have moved away from this for binary / large objects and instead support alternative methods.
Some of the problems you will have to deal with include:
Items 1 and 2 cause an increase in the amount of time it takes to write a "file" to your data store. Items 3, 4 and 5 are already supported by network file systems so you're just recreating the wheel.
In short you're going to have to either write your own file system or write your own DBMS. Neither of which I would consider "good practice" for 99% of real world applications. It might be worthwhile if your goal is to work for Seagate.. But even then they'd probably look at you funny.
If you are truly interested in the most efficient method of file storage, it is quite simply to purchase a SAN array and push your files to it while keeping a pointer to the file/location in your database. Easy to back up, fast to store files, much cheaper than spending developer time trying to figure out how to write your own file system and certainly 100% supported and understandable by future devs.
这种产品已经存在。您应该阅读有关 Mongo Db 的内容 (http://www.mongodb.org/display/DOCS/Home)
This kind of product already exist. You should read about Mongo Db (http://www.mongodb.org/display/DOCS/Home)