第二种方法，把元数据和数据存储在一起。这种方法很可取，因为这样你就只需担心一个文件系统的数据完整性了。如果文件被移动，元数据也随之移动。你可以随时把元数据加入到文件中，因为它就和文件在一起。

理想的状态是，如果我们有好的工具来和文件一起复制，移动元数据，那我们就可以轻松地复制或移动数据文件。比如说，你把文件复制到某些活动状态存储中，元数据就要和其一起移动。这还意味着你可以升级这些文件的元数据，然后把它们复制回去，把升级后的元数据和文件放在一起。

我们可以借助扩展属性（扩展文件属性）来达到这一目的。许多文件系统都支持扩展属性，为用户提供多种选择，使用户可以通过扩展文件属性把元数据添加到文件中，当然，它们也提供多种文件读取方式。一些文件系统会对扩展属性强加限制，比如说加入数量的限制，但并不是所有的文件系统都这样。不管怎么说，把元数据和数据存储在一起是一个值得考虑的方法。

但是凡事有利就有弊，把元数据和数据存储在一起也有许多缺点。首先就是用户如何有效率地搜索元数据？

搜索的主要方式是扫描文件系统的树形结构，找到每个文件的元数据然后返回信息。但是这种方式要受到文件数量及文件树形结构的影响，搜索可能会花大量的时间，也许会浪费大量的时间做无用功。

如果你想寻找文件，那你就需要搜索所有文件的元数据。不幸的是，目前几乎没有令人满意的工具或技术把文件（包括元数据）复制到其它存储（或活动状态的存储设备）中。举个例子，NFS不支持扩展文件属性的传输，用户就不能通过它复制文件或从归档转移到活动位置。有复制文件和元数据的方式，但是你需要花大量的精力确保能达到你预期的效果。

更好的方法

我个人认为第二种方法会好一些，因为元数据总是和数据在一起，这样用户就可以随时访问元数据。在第一种把元数据集中起来的方法中，除了要保护数据之外，你不得不使用额外的资源来保护数据库，保证其精确性。考虑到那难以置信的数据量，再加上需要保护的新的归档，我现在觉得这两种方法都不够完美。

既然这样，那何不把这两种方法结合起来！

我仍然觉得元数据应该和数据存储在一起，最主要的原因就是元数据相对于数据而言，本身就是相同的东西，把它们分开没有多大的意义。

不过，扫描含有上亿个文件的树形结构也是不现实的。所以，我们需要专为搜索设计的框架，在其中建立一个集中元数据索引，不过所有元数据的功能仍在于文件本身。

如果我们创建了一个归档并把所有的数据都放入其中，那我们就可以抓取元数据并建立一个集中索引。当文件移动到归档中时，我们可以把元数据集中在一个文件中。

令人欣慰的是，归档本身的机制可以发现归档中文件的改变，获取元数据并升级集中索引。但是，若是归档有REST接口，那就没有好的方式去“升级”文件。如果你从一个归档中提取了一个文件并做了更改，大多数情况下，你都需要把整个文件再放回到归档中，因为对于归档来说，这是一个“新”文件。有一些归档允许用户升级文件，但是这种机制用起来并不容易，相比之下，提取文件，做更改，再放回去则是非常简单。在这种情况下，提取操作要获取元数据，这使得这一步骤变得简单。

对于所有元数据来说，发挥作用的是文件，元数据只是附加其上（我个人认为使用的是扩展文件属性）。如果集中索引因为某些原因失效了，你要花一些时间扫描文件系统来“重新收集”元数据，但是你并没有从根本上失去你的索引。

总结

人们曾经认为把元数据存储在什么地方这个问题非常简单，根本用不着进行长时间的讨论。直到有一天人们突然发现，如今的世界已经天翻地覆，大数据呈爆炸式增长，文件数量上亿，这时候考虑元数据放到哪里就变得非常重要，处理好这个问题，对于数据的实际使用有重大意义。

把所有元数据放到集中索引是不切实际的，因为这样你就必须进行大量的数据保护，不仅要保护数据，还要保护集中索引。仅仅移动文件位置而不升级索引会对搜索带来极大的影响。

同样的，借助扩展文件属性把元数据和数据放在一起也不可取，因为每次数据搜索都意味着元数据要通过树形结构被搜集起来再搜索。虽然把元数据和数据放在一起非常自然，但是这种存储方式往往会浪费大量的搜索时间。

我认为最好的解决方案是把这两种方式结合在一起。把元数据放在数据中，当数据被移动到归档中时，你就可以把元数据提取出来，同时建立一个集中索引，用这个索引来进行数据搜索。

借助一个简单的REST接口，就可以很轻松地升级索引。但是，如果索引丢失或崩溃了，那就需要再次扫描归档的树形结构来重新收集元数据了。

我写这篇文章的目的是能引发人们对元数据存储在何地以及如何搜索它们这个问题的思考，肯定会有人对我的观点提出质疑。如果有可能的话，请你们写下自己的解决方案，一定会有很多人从你们的分享中受益匪浅的！