MIG|Suite 是 adesso Insurance Solutions GmbH 为保险环境中的迁移项目提供的解决方案。在 MIG|Suite 的帮助下，保险公司可以将其数据（保险合同）从“旧系统”（通常是基于主机的系统或关系数据库）迁移到新系统。
MongoDB 充当 MIG|Suite 中从旧系统导入的保险合同的数据存储。 MIG|Suite 利用 MongoDB 的架构自由性。这使得从旧系统一对一传输数据成为可能。 MIG|Tools 组件可以帮助实现这一点，将遗留系统的结构转换为可持久的 Java 类。然后在导入数据时指定 MongoDB 中的结构。下图提供了 MIG|Suite 的粗略概述：
这也确保了遗留系统中的专家能够继续理解数据并可以使用它 验光师准确的电子邮件列表 而无需重新思考。当 MIG|Transform 组件将旧系统映射到新系统时，这是一个决定性的优势。
MongoDB 3.2 – WiredTiger 取代 MMAPv1
存储引擎是数据库的一部分，负责在文件系统上存储数据。在 2.8 版本之前，MMAPv1 是 MongoDB 中唯一的存储引擎。随后，在收购同名公司后，WiredTiger 也作为 MMAPv1 的替代品推出。随着 12 月发布的 3.2 版本（当前为 3.2.1），WiredTiger 首次作为标准存储引擎提供。启动数据库实例时必须显式指定使用 MMAPv1，否则将使用 WiredTiger。除了 WiredTiger 和 MMAPv1 之外，MongoDB 还提供了另外两种存储引擎，一种是内存存储引擎，另一种是提供加密功能。然而，两者都只是企业版的一部分。此外，存储引擎 API 还提供开发您自己的存储引擎的选项。例如，Facebook 开发了 RocksDB。
MIG|Suite 中的 MMAPv1 和 WiredTiger
MMAPv1 和 WiredTiger 之间最大的区别是数据的压缩。 MMAPv1 将数据写入文件系统时不进行压缩，而 WiredTiger 可以选择不同的压缩级别。在使用 MongoDB 的项目中，会出现这样的问题：应使用哪种存储引擎，采用旧标准还是新标准。
作为 MIG|Suite 项目的一部分，我更详细地研究了这个问题。测试基于 1,000 份匿名保险合同，其中包含来自主机系统的总共 6,743 种合同状态。使用 MIG|Import 组件将其作为 205MB 文本文件导入 MongoDB。一次使用 MMAPv1 作为存储引擎，再次使用 WiredTiger。
该图显示了使用两个存储引擎进行导入的平均测试结果：
结果令人惊讶，因为即使数据量很小，存储引擎的简单更换所产生的深远影响也是显而易见的。 WiredTiger 清楚地展示了 MongoDB 对默认存储引擎进行更改的原因。除了使用的存储空间显着减少之外，导入速度也得到了提高。我没想到会出现这种情况，因为 WiredTiger 在压缩时的资源消耗较高，但这是有助于存储引擎选择的另一个见解。
最后，可以说，即使对于以文本形式提供的少量数据，使用 WiredTiger 也是值得的。应始终根据要持久保存的数据来决定存储引擎。还必须考虑读取这些数据。存储引擎 API 还提供了一个接口，使您可以开发自己的存储引擎。
如果您在评论中分享您自己使用不同存储引擎的经验，我将非常高兴。我也很乐意回答您有关 NoSQL、MongoDB 和 MIG|Suite 的任何问题。