我们需要收集，归档，研究的数据量是非常惊人的，但是如果我们能巧妙利用元数据，就能快速找到我们所需要的数据文件。不过，单独存储，研究元数据本身就是一个“大数据”问题，其中一个很重要的方面就是我们要把元数据存储到哪里？
目前，我们已经被“疯狂”的大数据包围了，整个世界都在适应大数据，我们要了解如何使用大数据，如何为大数据设计相应的处理系统，尽管如此，大数据仍然是一片深不可测的海洋。以我们的生活为例，在我们周围到处都有摄像头——商店外面，商店里面，十字路口，直升飞机上，银行，还有人们的手机上。还有大量的传感器——在街道上，在汽车里，在公园里，在桥上。还有一些特殊行业用的传感器，比如说电力行业，油气行业，医院，网络服务，网页，天气，海洋，军队，等等。它们无时无刻不在收集数据。而所有这些数据都有一个共同的地方——它们都需要元数据。
元数据是关于数据的数据。举个例子，元数据可以包括传感器位置信息（GPS坐标），特定时间的记录信息，传感器感应的方向，传感器的固件以及传感器的型号等等。
在对数据进行后期处理时，你可以用新得到的元数据信息给文件标上“标签“。比如说照相机，可以用时间来作为元数据标签，记录有趣的事情（或许会和事件本身一起被记录下来）。还有一些元数据标签可以是其它相关的信息资源，比如说其它的照相机型号或天气数据。
从中我们可以看出，元数据的使用依赖于其质量。如果元数据不精确，那使用相关的原始数据时就会出现问题，甚至会造成分析失败。有一些元数据是人为制造的，不能自动生成，所以会有一定的错误率。
认识到什么样的元数据对特定数据文件很重要，了解如何运用它们分析数据，这是非常重要的问题，而且这不仅仅涉及到技术解决方案，还有可能涉及到社会学和心理学的解决方案。
但是一个看起来很简单的问题却对元数据的使用造成重大影响，那就是——我们要把元数据存储在什么地方？
何处安放你的数据？
在遇到这个问题时，我曾想过两个方法。第一个是把元数据放到所有数据的中心位置。第二个方法是把元数据和它本身的数据放在一起。
许多研究和归档系统都采用第一种方法。它非常简单，就是收集特定文件的元数据并存储起来。这种方法广泛用于数据库中，你可以按照自己的需求搜索数据库，寻找含有你感兴趣信息的文件（在这里我们假设元数据是正确的，否则那就是另外一回事了）。
搜索的结果往往是找到文件的位置（文件全名以及文件访问路径），接着你就可以把文件复制到某些处于活动状态的存储设备中再进行进一步的分析。
集中元数据这种方法面临的问题是元数据和文件之间的映射。举个例子，当各种文件的元数据升级时，你就需要一种更新机制去升级集中元数据的服务器。理想状态是，升级速度非常快，否则，搜索数据就会过期。但是你怎么定义“快”呢？这取决于你的用户和用户模式。
这种更新机制有一个潜在的问题。如果数据库和文件不同步怎么办？比方说，当一个文件被移动，它在数据库中的全路径不再有效时怎么办？
答案很明显，数据库也会失效，至少包含那个文件的数据库会失效。不过令人感到欣慰的是，更新机制会告诉数据库文件已经移动，数据库会采取相应的措施，或者为新的位置创建元数据，或者升级现有的元数据对应文件新的位置。在一些案例中，升级窗口还会影响升级数据库。
还有一点需要注意，就是数据库本身的数据完整性。你需要利用备份，复制或其它相似的功能来进行数据保护。不要忘了数据库主要功能是从中读取数据，这就意味着你需要注意数据库的大小，注意读取错误。一些厂商会从消费级SATA硬盘中建立索引，当你读取100GB的数据时，你就有可能遇到读取错误。如果你借助RAID控制器建立存储，你就有可能重建，而在重建过程中，你还有可能遇到新的问题。
第二种方法，把元数据和数据存储在一起。这种方法很可取，因为这样你就只需担心一个文件系统的数据完整性了。如果文件被移动，元数据也随之移动。你可以随时把元数据加入到文件中，因为它就和文件在一起。
理想的状态是，如果我们有好的工具来和文件一起复制，移动元数据，那我们就可以轻松地复制或移动数据文件。比如说，你把文件复制到某些活动状态存储中，元数据就要和其一起移动。这还意味着你可以升级这些文件的元数据，然后把它们复制回去，把升级后的元数据和文件放在一起。
我们可以借助扩展属性（扩展文件属性）来达到这一目的。许多文件系统都支持扩展属性，为用户提供多种选择，使用户可以通过扩展文件属性把元数据添加到文件中，当然，它们也提供多种文件读取方式。一些文件系统会对扩展属性强加限制，比如说加入数量的限制，但并不是所有的文件系统都这样。不管怎么说，把元数据和数据存储在一起是一个值得考虑的方法。
但是凡事有利就有弊，把元数据和数据存储在一起也有许多缺点。首先就是用户如何有效率地搜索元数据？
搜索的主要方式是扫描文件系统的树形结构，找到每个文件的元数据然后返回信息。但是这种方式要受到文件数量及文件树形结构的影响，搜索可能会花大量的时间，也许会浪费大量的时间做无用功。
如果你想寻找文件，那你就需要搜索所有文件的元数据。不幸的是，目前几乎没有令人满意的工具或技术把文件（包括元数据）复制到其它存储（或活动状态的存储设备）中。举个例子，NFS不支持扩展文件属性的传输，用户就不能通过它复制文件或从归档转移到活动位置。有复制文件和元数据的方式，但是你需要花大量的精力确保能达到你预期的效果。
更好的方法
我个人认为第二种方法会好一些，因为元数据总是和数据在一起，这样用户就可以随时访问元数据。在第一种把元数据集中起来的方法中，除了要保护数据之外，你不得不使用额外的资源来保护数据库，保证其精确性。考虑到那难以置信的数据量，再加上需要保护的新的归档，我现在觉得这两种方法都不够完美。
既然这样，那何不把这两种方法结合起来！
我仍然觉得元数据应该和数据存储在一起，最主要的原因就是元数据相对于数据而言，本身就是相同的东西，把它们分开没有多大的意义。
不过，扫描含有上亿个文件的树形结构也是不现实的。所以，我们需要专为搜索设计的框架，在其中建立一个集中元数据索引，不过所有元数据的功能仍在于文件本身。
如果我们创建了一个归档并把所有的数据都放入其中，那我们就可以抓取元数据并建立一个集中索引。当文件移动到归档中时，我们可以把元数据集中在一个文件中。
令人欣慰的是，归档本身的机制可以发现归档中文件的改变，获取元数据并升级集中索引。但是，若是归档有REST接口，那就没有好的方式去“升级”文件。如果你从一个归档中提取了一个文件并做了更改，大多数情况下，你都需要把整个文件再放回到归档中，因为对于归档来说，这是一个“新”文件。有一些归档允许用户升级文件，但是这种机制用起来并不容易，相比之下，提取文件，做更改，再放回去则是非常简单。在这种情况下，提取操作要获取元数据，这使得这一步骤变得简单。
对于所有元数据来说，发挥作用的是文件，元数据只是附加其上（我个人认为使用的是扩展文件属性）。如果集中索引因为某些原因失效了，你要花一些时间扫描文件系统来“重新收集”元数据，但是你并没有从根本上失去你的索引。
总结
人们曾经认为把元数据存储在什么地方这个问题非常简单，根本用不着进行长时间的讨论。直到有一天人们突然发现，如今的世界已经天翻地覆，大数据呈爆炸式增长，文件数量上亿，这时候考虑元数据放到哪里就变得非常重要，处理好这个问题，对于数据的实际使用有重大意义。
把所有元数据放到集中索引是不切实际的，因为这样你就必须进行大量的数据保护，不仅要保护数据，还要保护集中索引。仅仅移动文件位置而不升级索引会对搜索带来极大的影响。
同样的，借助扩展文件属性把元数据和数据放在一起也不可取，因为每次数据搜索都意味着元数据要通过树形结构被搜集起来再搜索。虽然把元数据和数据放在一起非常自然，但是这种存储方式往往会浪费大量的搜索时间。
我认为最好的解决方案是把这两种方式结合在一起。把元数据放在数据中，当数据被移动到归档中时，你就可以把元数据提取出来，同时建立一个集中索引，用这个索引来进行数据搜索。
借助一个简单的REST接口，就可以很轻松地升级索引。但是，如果索引丢失或崩溃了，那就需要再次扫描归档的树形结构来重新收集元数据了。
我写这篇文章的目的是能引发人们对元数据存储在何地以及如何搜索它们这个问题的思考，肯定会有人对我的观点提出质疑。如果有可能的话，请你们写下自己的解决方案，一定会有很多人从你们的分享中受益匪浅的！
