云数据迁移中的6 个潜在瓶颈.docxVIP

云数据迁移中的6个潜在瓶颈作者：暂无来源：《计算机世界》2019年第1期 云数据迁移中的6个潜在瓶颈 从云存储导航选项到数据传送后的验证，按照如下的步骤可以有效避免云数据迁移中的风险。 作者？SethNoble 编译?MonkeyKing 将TB甚至PB级的数据转移到云端确实是一项非常有挑战性的工作。但是更重要的是你需要看到比这些字节更深远的地方。你可能知道当在云端访问这些应用程序时，它们的运行行为可能会表现得不一样，它们的成本结构将会有所不同（希望是更好），并且转移所有的数据需要花费大量的时间。 因为我的公司，DataExpedition，从事的生意是高性能数据传输，当客户预期的网络速度成为问题时他们就会来找我们。但是在帮助客户企业解决这些问题的过程中，我们看到了许多其他容易被忽略的因素，有可能威胁到整个过程并导致云数据迁移脱轨。 收集、组织、格式化，以及验证你的数据要远比转移数据的挑战更大。我会列举出云数据迁移计划阶段的一些普遍问题，可以帮助你在接下来的工作中避免浪费更多的时间和财力。 云数据迁移瓶颈#1:数据存储 我们看到的云迁移中最常见的错误是将数据堆入云存储而不考虑将会如何使用这些数据。典型的思考过程是“我想把我的文档和数据库放到云中，对象存储很便宜，所以我会把文档和数据库文件放在那里。”但是文件、对象以及数据库的行为模式是完全不同的。如果字节放错了位置会破坏你的整个云计划。 文件由层次结构的路径、目录树来组织。每个文件可以快速访问，以最小的等待时间（到首字节的时间）以及很高的速度（数据流开始后每秒比特数）。可以轻松地将单个文件移动、重命名和更改到字节级别。可以有许多小文件、少量大文件，或者大小和数据类型的任意组合。传统应用程序可以像在房子里一样在云中访问文件，而不需要任何特殊的云意识。 所有这些优点使得基于文件的存储成为最昂贵的选择，但是将文件存储在云中还有一些其他缺点。为了实现高性能，大多数基于云的文件系统（比如AmazonEBS）一次只能由一个基于云的虚拟机访问，这意味着所有需要该数据的应用程序必须在单个云VM上运行。如果要服务多个VM（比如AzureFiles），就需要像中小企业那样将NAS存储前置，但这又会使得性能严重受限。文件系统是快速、灵活和向后兼容的，但是它们很昂贵，只对在云中运行的应用程序有用，并且不能很好地扩展。 对象不是文件。请牢牢记住，因为很容易忘记。对象位于平面命名空间中，就像一个巨型目录一样。延迟很高，有时几百或几千毫秒，并且吞吐量很低，除非使用巧妙的技巧，否则通常达到每秒150兆比特。访问对象的很多技巧都可以归结为聪明的技巧，比如多部分上传、字节范围访问和键名优化。对象可以同时被许多云本地和基于web的应用程序从云内外读取，但传统的应用程序则需要一些变通的方法。访问对象存储的大多数接口使得对象看起来像文件：键名通过前缀过滤，使其看起来像文件夹，将自定义元数据附加到对象上，使其看起来像文件元数据或是一些系统，比如VM文件系统上的FUSE缓存对象，以允许传统应用程序访问。但是这些方法是易碎的且破坏性能的。云存储是廉价的、可扩展的、云原生的，但是它也很慢，并且很难访问。 数据库有它们自己的复杂结构，它们可以由查询语言（如SQL）访问。传统的数据库可能由文件存储支持，但它们需要一个实时数据库进程来提供查询。这可以通过将数据库文件和应用程序复制到VM中或者通过将数据迁移到云托管的数据库服务来提升到云中。但是将数据库文件复制到对象存储中仅作为脱机备份有用。数据库作为云托管服务的一部分可扩展，但是确保依赖于数据库的应用程序和流程完全兼容并且是云原生同样至关重要。数据库存储是高度专业化和特定于应用程序的。 如何在可明显节省成本的对象存储与文件和数据库的功能性之间做出平衡，就需要仔细考虑你到底需要什么功能。举个例子，如果你想存储和分发成千上万的小文件，那么与其将它们存档到单一的ZIP文件中，并作为单个对象来存储，反倒不如将每个单独的文件作为单独的对象来存储更好。不正确的存储选择可能会导致复杂的依赖关系，这些依赖关系在后续更改时既困难又昂贵。 云数据迁移瓶颈#2:数据准备 将数据移动到云并不像将字节复制到指定的存储类型那样简单。在复制任何东西之前，需要进行大量准备，而这段时间需要仔细编制预算。概念验证这个项目环节常常被忽略，这会导致之后的成本代价大大超支。 过滤掉不必要的数据可以节省大量的时间和存储成本。举个例子，数据集可以包含不需要成为云工作流一部分的备份、早期版本或草稿文件。也许过滤过程中最重要的部分就是优先确定哪些数据需要首先转移。正在频繁使用的数据不能容忍在完成整个迁移过程所需的周、月或年之间失去同步。这里的关键是提出一种自动选择要发送哪些数据以及何时发送数据的方法，然后仔细记录所有已完成和未完成的