云数据迁移中的一些注意事项

　　人们在云迁移中看到的最常见的错误是将数据迁移到云存储中而未考虑如何使用这些数据。人们典型的思考过程是，“我想把文档和数据库放在云中，是因为对象存储成本很低。”但是文件、对象和数据库的行为非常不同，将其数据放到错误的位置会削弱企业的云计划。

　　文件由路径层次结构组成，即目录树。每个文件都可以快速访问，延迟最短，并且快速(数据开始流动时的每秒位数)。单个文件可以很容易地移动、重命名并更改。企业可能有许多小文件，少量大文件或任意大小和数据类型的组合。传统的应用程序可以像在本地一样访问云中的文件，而不需要特别的云感知。

　　所有这些特点使基于文件的存储成为最为昂贵的选择，但将文件存储在云中还有其他一些缺点。为了实现更高的性能，大多数基于云服务器的文件系统一次只能由一个基于云服务器的虚拟机访问，这意味着所有需要该数据的应用程序必须运行在单个云虚拟机上。要为多个虚拟机提供服务，需要使用像SMB这样的NAS(网络连接存储)协议来存储，这会严重限制性能。文件系统是快速、灵活和兼容的，但是它们很昂贵，仅适用于运行在云中的应用程序，并且不能很好地扩展。

　　对象不是文件。请记住，因为它很容易遗忘。对象位于一个平面的命名空间中，就像一个巨大的目录。其延迟时间很长，有时甚至达到数百或数千毫秒，吞吐量也很低，除非使用了巧妙的技巧，否则通常每秒钟可以达到150兆比特左右。关于访问对象的大部分内容涉及到多部分上传、字节范围访问和密钥名称优化等巧妙技巧。对象可以同时从云服务器内外进行读取，但传统应用程序需要性能低下的解决方法。大多数用于访问对象存储的接口使对象看起来像文件：键名称按前缀过滤，以看起来像文件夹，自定义元数据附加到对象，以显示为文件元数据。以及某些系统(如虚拟机文件系统上的FUSE缓存对象)，以允许访问通过传统应用。但是这样的解决方法很脆弱并且表现不佳。云存储价格低廉，可扩展，云原生化，但速度慢，并且难以访问。

　　数据库具有自己的复杂结构，并且可以通过查询语言(如SQL)访问它们。传统数据库可能由文件存储来支持，但它们需要实时数据库进程来提供查询。通过将数据库文件和应用程序复制到虚拟机上，或者通过将数据迁移到云托管的数据库服务中，可以将其提升到云端。但将数据库文件复制到对象存储中仅作为脱机备份，这很有用。数据库可以作为云托管服务的一部分进行扩展，但确保依赖于数据库的应用程序和进程完全兼容，并且基于云原生非常重要。数据库存储是高度专业化和专用的。

　　对象存储的明显成本节省与文件和数据库功能的平衡需要仔细考虑需要哪些功能。例如，如果要存储和分发成千上万的小文件，请将它们存储为ZIP文件，并将其作为单个对象存储，而不是将每个单独的文件存储为单独的对象。错误的存储选择可能会导致复杂的依赖关系，这些依赖关系在以后更改很困难，并且代价较高。

　　当数据转换格式和应用程序时，即使字节相同，意义和功能也会丢失。软件版本之间的简单不兼容可能导致PB级的“正确”数据无用。使用可扩展的流程来验证企业的数据是否正确可用，这可能是一项艰巨的任务。在最糟糕的情况下，它可能会转变为劳动密集型和不精确的“看起来没问题”的人工处理过程。但即使这样做，也比没有验证要好。最重要的是确保企业能够在遗留系统退役之前识别问题!