所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
关于这个话题,这里有一份有趣的白皮书。
是否使用BLOB:数据库或文件系统中的大型对象存储
答案是“视情况而定。”当然,这取决于数据库服务器及其blob存储方法。它还取决于存储在blob中的数据类型,以及如何访问这些数据。
使用数据库作为存储机制,可以有效地存储和传递较小的文件。较大的文件可能最好使用文件系统存储,特别是如果它们将经常被修改/更新。(blob碎片在性能方面成为一个问题。)
Here's an additional point to keep in mind. One of the reasons supporting the use of a database to store the blobs is ACID compliance. However, the approach that the testers used in the white paper, (Bulk Logged option of SQL Server,) which doubled SQL Server throughput, effectively changed the 'D' in ACID to a 'd,' as the blob data was not logged with the initial writes for the transaction. Therefore, if full ACID compliance is an important requirement for your system, halve the SQL Server throughput figures for database writes when comparing file I/O to database blob I/O.
其他回答
关于这个话题,这里有一份有趣的白皮书。
是否使用BLOB:数据库或文件系统中的大型对象存储
答案是“视情况而定。”当然,这取决于数据库服务器及其blob存储方法。它还取决于存储在blob中的数据类型,以及如何访问这些数据。
使用数据库作为存储机制,可以有效地存储和传递较小的文件。较大的文件可能最好使用文件系统存储,特别是如果它们将经常被修改/更新。(blob碎片在性能方面成为一个问题。)
Here's an additional point to keep in mind. One of the reasons supporting the use of a database to store the blobs is ACID compliance. However, the approach that the testers used in the white paper, (Bulk Logged option of SQL Server,) which doubled SQL Server throughput, effectively changed the 'D' in ACID to a 'd,' as the blob data was not logged with the initial writes for the transaction. Therefore, if full ACID compliance is an important requirement for your system, halve the SQL Server throughput figures for database writes when comparing file I/O to database blob I/O.
我将使用文件系统方法,主要是因为它具有更好的灵活性。考虑一下,如果图像的数量变得很大,一个数据库可能无法处理它。对于文件系统,您可以简单地添加更多的文件服务器,假设您正在使用NFS或kind。
文件系统方法的另一个优点是能够做一些奇特的事情,例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断,则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。
如果你正在计划一个面向公众的网站,那么你不应该选择任何一个选项。您应该使用内容分发网络(CDN)。在互联网上传递大量静态内容时,CDN具有价格、可扩展性和速度优势。
如果您没有使用SQL Server 2008,并且有充分的理由将特定的映像文件放在数据库中,那么您可以采用“两者兼备”的方法,将文件系统用作临时缓存,并将数据库用作主存储库。
例如,您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上,并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。
正如有人已经提到的,“视情况而定”。如果数据库中的存储被认为是文件系统的1对1替代方案,那么它可能不是最佳选择。
但是,如果数据库后端将提供额外的值,而不仅仅是blob的序列化和存储,那么它可能是真正有意义的。
You may take a look at WKT Raster which is a project aiming at developing raster support in PostGIS which in turn serves as a geospatial extension for PostgreSQL database system. Idea behind the WKT Raster is not only to define a format for raster serialization and storage (using PostgreSQL system), but, what's much more important than storage, is to specify database-side efficient image processing accessible from SQL. Long story short, the idea is to move the operational weight from client to database backend, so it take places as close to storage itself as possible. The WKT Raster, as PostGIS, is dedicate to applications of specific domain, GIS.
要获得更完整的概述,请查看该系统的网站和演示文稿(PDF)。