建立30米图像数据库的策略

时间:2015-12-16 18:53:08

标签: database

摘要

我正面临着建立一个可搜索数据库的任务,该数据库包含与其元数据相关的大约3000万张图像(不同大小)。到目前为止,我没有真正的数据库经验。

要求

只有少数用户,数据库几乎是只读的(如果事情是通过受控的自动过程编写的话),维护的停机时间应该不是大问题。我们可能会对元数据执行或多或少的复杂查询。

我的想法

我目前的想法是将图像保存在文件夹结构中,并在包含元数据的一侧以及图像本身的链接上构建关系数据库。我读过有关基于文档的数据库。我确信它们是可靠的,但可能只能通过数据库查询访问图像,这是真的吗?在这种情况下,我担心未来的数据用户可能会面临在实际完成任务之前学习如何查询数据库的问题。

问题

我可以/应该使用哪种数据库?

2 个答案:

答案 0 :(得分:1)

对于某些数据库系统,建议在“查找表”之外存储未在查询中使用的大字段,因此将30米图像存储在文件系统中似乎并不罕见。

对于“哪个数据库”,这取决于您打算使用的框架,查询通常有多复杂,以及您可以使用哪些资源。

我在MySQL上运行了几分钟的复杂查询,这些查询在PostgreSQL上在几秒钟内完成,反之亦然。没有使用SQL Server进行测试,SQL Server是我现有的第三个RDBMS。

我可以告诉你一件事:无论你在数据库中做什么,都可以在数据库中完成。如果从数据库中提取所有数据然后在框架代码中进行匹配,则几乎不会获得相同的性能。

我可以告诉你的第二件事:索引,索引,索引!

答案 1 :(得分:1)

这听起来并不像数据是非常关系的,所以像MongoDB这样的非关系型DBMS可能就是这样。使用任何DBMS,您都必须使用查询从中获取信息。但是,如果您担心未来的用户,可以在用户和数据库之间放置一个软件层,使查询更容易。

将文件系统中的图像和数据库中的元数据存储在比将数据库(IMHO)中存储大Blob更好的想法。我还要注意,如果你有一个文件夹和子文件夹而不是一个大文件夹中的30M图像(需要引用)

,文件系统性能会更好