我们需要收集，归档，研究的数据量是非常惊人的，但是如果我们能巧妙利用元数据，就能快速找到我们所需要的数据文件。不过，单独存储，研究元数据本身就是一个“大数据”问题，其中一个很重要的方面就是我们要把元数据存储到哪里？

目前，我们已经被“疯狂”的大数据包围了，整个世界都在适应大数据，我们要了解如何使用大数据，如何为大数据设计相应的处理系统，尽管如此，大数据仍然是一片深不可测的海洋。以我们的生活为例，在我们周围到处都有摄像头——商店外面，商店里面，十字路口，直升飞机上，银行，还有人们的手机上。还有大量的传感器——在街道上，在汽车里，在公园里，在桥上。还有一些特殊行业用的传感器，比如说电力行业，油气行业，医院，网络服务，网页，天气，海洋，军队，等等。它们无时无刻不在收集数据。而所有这些数据都有一个共同的地方——它们都需要元数据。

元数据是关于数据的数据。举个例子，元数据可以包括传感器位置信息（GPS坐标），特定时间的记录信息，传感器感应的方向，传感器的固件以及传感器的型号等等。

在对数据进行后期处理时，你可以用新得到的元数据信息给文件标上“标签“。比如说照相机，可以用时间来作为元数据标签，记录有趣的事情（或许会和事件本身一起被记录下来）。还有一些元数据标签可以是其它相关的信息资源，比如说其它的照相机型号或天气数据。

从中我们可以看出，元数据的使用依赖于其质量。如果元数据不精确，那使用相关的原始数据时就会出现问题，甚至会造成分析失败。有一些元数据是人为制造的，不能自动生成，所以会有一定的错误率。

认识到什么样的元数据对特定数据文件很重要，了解如何运用它们分析数据，这是非常重要的问题，而且这不仅仅涉及到技术解决方案，还有可能涉及到社会学和心理学的解决方案。

但是一个看起来很简单的问题却对元数据的使用造成重大影响，那就是——我们要把元数据存储在什么地方？

何处安放你的数据？

在遇到这个问题时，我曾想过两个方法。第一个是把元数据放到所有数据的中心位置。第二个方法是把元数据和它本身的数据放在一起。

许多研究和归档系统都采用第一种方法。它非常简单，就是收集特定文件的元数据并存储起来。这种方法广泛用于数据库中，你可以按照自己的需求搜索数据库，寻找含有你感兴趣信息的文件（在这里我们假设元数据是正确的，否则那就是另外一回事了）。

搜索的结果往往是找到文件的位置（文件全名以及文件访问路径），接着你就可以把文件复制到某些处于活动状态的存储设备中再进行进一步的分析。

集中元数据这种方法面临的问题是元数据和文件之间的映射。举个例子，当各种文件的元数据升级时，你就需要一种更新机制去升级集中元数据的服务器。理想状态是，升级速度非常快，否则，搜索数据就会过期。但是你怎么定义“快”呢？这取决于你的用户和用户模式。

这种更新机制有一个潜在的问题。如果数据库和文件不同步怎么办？比方说，当一个文件被移动，它在数据库中的全路径不再有效时怎么办？

答案很明显，数据库也会失效，至少包含那个文件的数据库会失效。不过令人感到欣慰的是，更新机制会告诉数据库文件已经移动，数据库会采取相应的措施，或者为新的位置创建元数据，或者升级现有的元数据对应文件新的位置。在一些案例中，升级窗口还会影响升级数据库。

还有一点需要注意，就是数据库本身的数据完整性。你需要利用备份，复制或其它相似的功能来进行数据保护。不要忘了数据库主要功能是从中读取数据，这就意味着你需要注意数据库的大小，注意读取错误。一些厂商会从消费级SATA硬盘中建立索引，当你读取100GB的数据时，你就有可能遇到读取错误。如果你借助RAID控制器建立存储，你就有可能重建，而在重建过程中，你还有可能遇到新的问题。