我们正在经历一场不可思议的复兴。长期以来被嘲笑为过时的数据库突然成为行业的宠儿。在权威人士宣布数据库几乎已死的数年之后，一种新型的初创公司引起了华尔街的注意。然而，IT 领导者仍然难以有效地将他们现有的工作负载迁移到这些系统。
对数据库的供应商锁定是传奇。没有其他部门对其用户产生如此大的影响。自然地，供应商锁定使客户对现有技术心存感激。然而，它也让竞争和新贵们望而却步。Snowflake 的 CEO 曾感叹打入这个市场有多么困难，他说：“Teradata 已经 [使得] 很难离开他们的平台。”
随着数据库虚拟化(DBV)(而非数据虚拟化)的出现，一种新的方法已进入舞台。DBV 声称打破了供应商对数据仓库技术的锁定。它的适用性如何?IT 领导者如何评估该技术?以下是关于 DBV 的五件事。
1) DBV 是如何工作的?
DBV 平台位于数据库和应用程序之间。它使为一个数据库编写的应用程序能够在另一个数据库上本地运行。所有查询和通信都是实时翻译的。例如，为 Teradata 编写的应用程序可以直接在 Microsoft Azure Synapse 上运行，甚至不会“知道”它们不再在 Teradata 上运行。
DBV 是完全透明的，目的是应用程序不需要任何调整或只需要很少的调整。这不仅包括标准 SQL，还包括专有扩展。为了在实践中取得成功，还必须支持加载程序、驱动程序和实用程序。
由于 DBV 系统实现了查询和数据的转换，因此它们可以以相当低的开销运行。实际的数据处理始终在数据仓库本身上执行，并利用该系统的大规模并行处理 (MPP) 功能。
2) 何时使用 DBV 而非传统迁移?
在传统迁移中，所有现有的 SQL 代码、驱动程序、工具和实用程序都被替换为新目标系统的对应项。对于具有少量应用程序的紧凑型数据仓库系统，这可能是首选方法。只有有限数量的用户的数据集市可能有资格这样做。
但是，在复杂的企业数据仓库 (EDW) 的情况下，DBV 可以显着优于传统迁移。DBV 以极少的时间、成本和风险完成工作负载的迁移。
3) DBV 可以覆盖我的工作量吗?
一些工作负载广泛使用专门的功能。还有一些使用早于标准化工作的功能。换句话说，没有两个数据仓库工作负载是相同的。这会使评估 DBV 系统的覆盖范围变得困难。
支持功能的完整文档似乎是可取的，但实际上并不是很有帮助。大多数客户无法简洁地描述他们的工作负载当前正在使用哪些功能。更复杂的是，查询或函数的原始作者通常不再在公司工作。
然而，这不一定是采用 DBV 的障碍。由于 DBV 的采用风险较低，因此它可以实现非常有效的概念验证 (POC) 实施。客户无需更改其应用程序即可使用 DBV。他们可以直接在 POC 中测试他们的实际应用程序。
然后，POC 可以快速识别任何缺失的覆盖范围。重要的是要理解，虽然 100% 的覆盖率似乎是可取的，但 90 的高频率通常就足够了。处理剩下的问题通常只需要微不足道的努力。
4) DBV 与数据虚拟化有何不同?
数据虚拟化是一种有些相关但又完全不同的方法。要使数据虚拟化成功，首先需要重写所有应用程序并采用抽象的SQL方言。然后，只有这样，它才能防止未来的供应商锁定。主要应用领域是不需要考虑现有应用的“绿地”场景。
相比之下，DBV 打破了现有的供应商锁定。它使应用程序保持原样。随着时间的推移，这可能会导致各种各样的不同应用技术。然而，这可能不是什么大问题，并且被新数据技术的采用很好地抵消了。
5) DBV 能否将 EDW 重新平台化为任何技术?
每隔几年，一项新技术就会挑战企业数据仓库系统的霸主地位。新来者通常在一个显着维度上优于现有堆栈。例如，新技术可能更具可扩展性。另一个可能会简化数据的共享。还有一些更吸引开源开发者。
通常，专家团队可以构建定制解决方案，将工作负载从 EDW 转移到大多数新技术。然而，功能上的差距越大，运行这些系统所需的软件工程就越多。例如，将 EDW 迁移到NoSQL系统在技术上可能是可行的，但在经济上并不总是可取的。
要使 DBV 成功，源和目标必须有意义地相似。但是，这不需要等效功能。DBV 可以弥补大多数高级功能的不足，例如存储过程、宏，甚至是不受支持的数据类型。目前，云原生PaaS 解决方案在 DBV 环境中最为成功。
选择正确的迁移方法
在为现有 EDW 选择新的目标系统时，需要考虑许多因素。一个经常被忽视的是迁移方法。DBV 在打破供应商对遗留数据仓库的锁定方面非常有效。
通过将迁移方法考虑到他们对目标系统的选择中，IT 领导者可以优化快速采用，同时控制风险和成本。
标签：
版权声明：本文由用户上传，如有侵权请联系删除！