作者：Stuart Lauchlan
原文出处：https://diginomica.com/databases-meatballs-ikeas-migration-flatpack-data-model-open-source-postgres
宜家以其著名的蓝色大盒子店面设计遍布全球30个国家/地区，是全球最知名的品牌之一，数百万顾客都在寻找用时尚的家具和配件来装饰自己的家。在幕后，这家瑞典零售商已经进行了自己的现代化改造，其数据中心迁移到开源的PostgreSQL数据库。
宜家零售基础设施经理Dinesh Adhikari说，这一转变是由零售市场更广泛的趋势和不断变化的客户需求推动的，特别是随着人们通过公司网站或宜家应用程序在线访问，销售机会随之增加。在线购物的普及增加了公司的覆盖面，但也增加了对支持零售商日常运营的系统需求的复杂性。Adhikari说：
这背后是供应链系统、财务系统、客户解决方案、合作者解决方案来共同运营的如此庞大的业务。大多数 [运营] 信息存储在数据库中，并发送到不同的系统，从不同的系统接收，发送给我们在供应链和其他领域的外部合作伙伴。
他补充说，运维这些数据库是宜家基础设施团队的工作，例如，为电子商务的兴起提供动力和支持。但他回忆道，管理数据库组合正成为一个更大的要求：
我们使用数据库已经很长时间了。多年来，我们建立了不同的数据库版本。运行我们的数据库操作有点像我们在公司内部所做的“老任务”。因为有这么多的实体店已经成长起来，商业运作也在成长，我们看到了很多挑战。多年来，我们在如何使用数据库或数据库能提供什么方面创造了相当多的复杂性。
在我们的产品组合中，我们使用的大多是专有数据库，因此每当需要[用户]访问数据库时，我们都会说，‘好吧，您将有且仅能使用此数据库’，到目前为止，这对我们是有效的。这做得很好，但我们看到有差距、有缺点。我们已经收到了很多反馈，认为我们的行动，到目前为止，可能会面临[更多]挑战。我们不够快，做得也不够，无法满足我们在如何改变我们周围的应用程序环境方面的要求。
这种反馈的结果是启动对数据库战略的评估，以确定哪些更改最有益。Adhikari解释说：
这是一个复杂的评估过程以确定我们的规划。我们尝试了很多，基本上把每一种可能都试过。在我们做出任何’这是我们想要做的’决定之前，我们想知道我们有什么，我们是如何运行的。因此，在本次评估中，我们查看了已部署的数据库，了解我们有多少个数据库，这些数据库在哪里运行？数据中心吗？我们的实体店都有一些数据库的解决方案 - 我们有什么数据库，[那里]？我们的政策是什么？在部署、删除、修改这些数据库时，我们当前的流程是什么？如何满足我们的需求？在满足未来需求方面，它们又能做些什么？
评估还包括对数据库运营工作的审视，如检查宜家内部 DBA 团队的工作量：
他们面临什么样的挑战？他们具有怎样的任务分类？数据库实际上做了什么？什么样的逻辑，我们有什么代码？然后，我们还对应用程序做了一点映射，以查看我们拥有什么样的应用程序。但主要用法部分更多的是从 DBA 角度、从数据库运维角度、从数据库功能角度获得见解。但与此同时，我们也看到，我们需要什么样的能力？因此，我们与架构师进行了一些讨论，还与一些应用程序所有者进行了交谈。我们只是在调查我们错过了什么？我们还需要什么？我们如何制作更好的服务或应用程序来使用？
不可避免的是，评估的最后一个要素是围绕总拥有成本（TCO）：
这不仅仅是关于我们的数据库许可成本或计算中的一个特定成本。运行数据库的总成本是多少？建立一个数据库要花多少钱？做生命周期管理要花多少钱？这些是我们实际上从不同的方面来了解我们的整体成本。
成果目录
Adhikari说，整个评估进行了两个多月，并抛出了一些有趣的结果，这些结果将决定未来的策略：
有很多事实，如果我们继续从整体的角度来看，我们可能会忽略这些事实。我们发现，与实际生产阶段相比，我们有更多的开发测试数据库。我记不清这个比例到底是多少，但与生产数据库的数量相比，这个数字相当高。因此，这告诉我们，我们做了很多测试——这是一件好事，但随后我们启动了很多实例，可能比我们需要的更多。我们还了解到，我们的规划相当缓慢，这背后有个繁复的流程牵绊。我们就是这样在不同团队之间进行很多沟通的，因此协调过程非常缓慢。
取消规划甚至更慢：
要建立数据库需要付出很多努力，但需要付出更多努力才能使数据库替换。仅仅因为这种进行规划和取消规划的复杂性，取消规划的速度就相当低，这意味着我们规划更多，但随后我们取消的速度不够。这给我们的操作增加了复杂性，也增加了运行这些数据库所需的总拥有成本。在这些数据库处于大型测试环境中的一段时间内，它们开始有自己的生命周期，所以状态变得非常混乱，以至于即使是测试和开发数据库，它们也不能使用，因为它们需要创建、更新、删除。从实践的角度来看，这是一个非常有趣的发现。
其他的经验教训包括：数据库操作有点平凡
DBA基本上从事于创建存储、创建数据或表空间、扩展表空间。他们参与创建数据刷新周期、备份、监视备份作业，因此运行这项操作变得相当平常。我们还了解到，我们的计算利用率非常低，所以无论我们提供什么计算容量，我们都没有使用那么多。所以我们创建数据库，创建计算基础设施，分配存储，分配CPU和内存来保护很多东西，但最终我们并没有利用这么多。
他补充说，基础数据库技术本身的性质也抛出了一些意想不到的问题：
一旦我们查看数据库内部，我们发现其中许多数据库的数据结构是扁平的。一些应用程序只是使用数据库在表和列中存储数据。因为没有或者很少有[关系元素]，所以里面的代码很少。那是一个非常有趣的发现。我们通常不会进入数据库查看我们正在运行的内容。我们还发现，大量的数据库都在30GB左右，我们称之为相当小的大小。我们有运行数TB的大型数据库，但大量的数据库相当小。
计划改头换面
基于所有这些信息，宜家下一步要考虑的是更广泛的数据库行业发生了什么，以及如何将其映射到零售商不断变化的需求上：
我们买的东西（以前）对我们有用，在过去效果很好，但现在正是变化迅速发生的时候。我们通过网络渠道的销售额增加了46%。这意味着，在电子商务开始复苏的地方，我们需要更快地进行部署更改，我们需要有更好的测试能力。拥有这么长的交付周期或者拥有一个受污染的测试数据库，可能并不是一个很大的帮助。
决定采用数据库服务提供方法，而不是推出基于数据库的标准部署。Adhikari解释说，这一举动背后有几个驱动力：
我们想整合我们的数据库。我们希望以一种更轻松的方式利用我们正在提供的资源，这样我们就拥有了足够的一切——不太多，也不太少。我们还想创建一个基本的API和数据库平台服务，在那里我们可以动态地进行资源调配。当人们能够按需创建数据库时，他们应该能够根据需要删除这些数据库或克隆数据库。我们希望在数据库上运行大量的人力资源操作，我们希望能够在有需要时扩大规模，或者如果不再需要，可以缩小规模。因此，创建基本上可以在我们的数据库平台中创建灵活性和敏捷性的模型。
我们还想创建适合用途的数据库。正如我之前所说，我们使用的是专有数据库。我们多年来一直在使用关系数据库，但是考虑到我们在评估中发现的事实，其中一些企业级数据库只是用来存储表和列。那么，这说明了什么？这说明也许我们没有正确地使用我们的数据库技术。因此，我们需要一个更好的数据库产品，它基本上满足了这一需求，并且在成本和性能、可用性和可伸缩性之间保持平衡。
自动化和成本降低也是新思维的关键因素：
我们还希望创建一个具有高效操作的数据库平台，这意味着[我们可以创建]任务，创建自动化，创建一个环境，通过机器学习，通过创建触发某些响应的功能，并以更好的方式修复那些平凡的工作。我们还研究了我们需要的新能力。我们应该如何更好地处理中断？我们应该如何更好地处理数据应用程序？我们应该如何处理我们的测试数据？我们应该如何备份？我们应该如何恢复？我们如何在这个目标结果中使用这些新功能？当然，这是TCO的降低。如果我们能够实现许多自动化，那么它对我们的总体拥有成本有何影响？如果我们没有像部署专有的企业级数据库那样使用计算机，那么我们希望降低TCO。
引入PostgreSQL
Adhikari 回忆道，与基础设施架构师关于如何将这些需求转化为现实的对话包括关于选择关系数据库提供商解决方案的辩论，但重点转移到了 PostgreSQL 上：
在讨论中，我们基本上谈到了某些数据库名称，以及为什么要选择它们，我们应该去哪里？但最后，我们基本上说，让我们围绕 PostgreSQL 做一个测试和学习；PostgreSQL 能为我们做什么，PostgreSQL 是什么？让我们深入研究一下。所以我们花了几个星期学习 PostgreSQL，安装了PostgreSQL。我们创建了一些用例，并围绕这些用例测试了 PostgreSQL，然后围绕这些用例进行了大量的活动，以便与之合作的技术团队看到它是一个非常好的产品，我们现在就可以使用它。
得出这一结论有很多关键原因，他说：
它基本上是一个开源关系数据库。从经验的角度来看，产品简单。我们的应用团队和技术团队对开始使用 Postgres 充满信心。我从同事那里得到的一个反馈是 ，[Postgres] 社区。是强大的。社区做出了很多贡献，社区周围也有很多发展，也有很多知识共享。因此， 社区是另一个原因， 我们走向波斯特格雷斯。它还具有基本满足可伸缩性需求的体系结构 - 我们如何创建群集？我们如何能够创建和高度可用的环境，高度可扩展的环境？我们如何将任务关键型应用程序引入 Postgres？- 因此，体系结构本身以及 Postgres 即将推出的所有扩展或框架绝对是一个很大的优势。
它是一个开源的关系型数据库。从体验的角度来看，产品简单易用。我们的应用团队和技术团队对开始使用 PostgreSQL 非常有信心。我从同事那里得到的一个反馈是，PostgreSQL的社区很强大。社区有很多贡献，有很多知识分享。社区是我们选择 PostgreSQL 的另一个原因。它还有一个架构，基本上满足了我们的可伸缩性需求——我们如何能够创建集群？我们如何能够创建高可用性、高可扩展性的环境？我们如何将关键任务应用程序引入 PostgreSQL？因此，体系结构本身以及 PostgreSQL 附带的所有扩展或框架无疑是一大优势。
但是，尽管产品具有吸引人的简单性，PostgreSQL 将不得不经历 Adhikari 所说的"企业升级"，这需要一些额外的支持需求：
我们基本上需要一些能力。我们如何创建这种基础设施？我们如何监控它？我们如何在背后运作？我们如何保护我们在这个平台上带来的任何数据？当我们开始这次尝试时，我们得出一些经验。我们确实进行了测试和学习，但我们并没有将 PostgreSQL 作为一种企业服务来创建，而这正是我们在宜家零售中可以使用的。因此，我们联系了[服务提供商]EDB[以前是enterpriseedb]，这就是我们在创建 PostgreSQL 作为企业级服务方面得到了相当好的支持。我们和他们坐来下聊了很多时间，讨论如何使用EDB提供的不同工具来帮助我们创建 PostgreSQL 数据库服务。
宜家现在使用 PostgreSQL 社区版之一，也有一个企业版 PostgreSQL 高级服务器。Adhikari说，到目前为止，迁移已经取得了成功，但还有许多工作要做：
这基本上是一次旅行。这是我们要继续做的…… PostgreSQL 绝对是一个加分，也是一个很好的补充，但我们的旅程不会就此结束。现在，我们正在进行大量的规划，看看我们如何能够为宜家创造更好的服务。我想我们要花相当长的时间才能到达那里，但我们绝对走在正确的道路上。
