MongoDB进入AWS红移

我们有一个相当大的MongoDB实例，包含碎片集合。现在，依赖MongoDB查询功能（包括聚合框架）来洞察数据变得过于昂贵

我四处寻找使数据可用且更易于使用的选项，并确定了两个有希望的选项：

自动气象站红移

Hadoop+Hive

我们希望能够使用类似SQL的语法来分析数据，并且希望接近实时地访问数据（几分钟的延迟是可以的，我们只是不想等待整个MongoDB一夜之间同步）

据我所知，对于选项2，可以使用它将数据从MongoDB移动到Hadoop集群

我看了很多东西，但我正在努力找到一个类似的解决方案，让MongoDB进入AWS红移。从亚马逊的文章来看，使用AWS Kinesis将数据转换成红移似乎是正确的方法。也就是说，我找不到任何类似的例子，也找不到任何库或连接器来将数据从MongoDB移动到Kinesis流中。至少没有什么看起来有希望的

---

有人做过类似的事情吗？

Redshift是一种数据仓库产品，Mongo DB是一种NoSQL DB。显然，它们不是彼此的替代品，可以共存并为不同的目的服务。现在了解如何在两个位置保存和更新记录。 您可以将所有Mongo DB数据作为一次性活动移动到红移。 红移不适合实时写入。为了接近实时同步到红移，您应该修改写入Mongo DB的程序。

---

让该程序也写入S3位置。S3位置到红移的移动可以定期进行。

Mongo DB作为一个文档存储引擎，Apache Solr，弹性搜索可以被视为可能的替代品。但它们不支持SQL类型查询功能，基本上使用不同的过滤机制。例如，对于Solr，您可能需要使用demax过滤器

---

在云上，亚马逊的云搜索/Azure搜索也将是令人信服的尝试选择。

我最终使用NodeJS编写了我们自己的migrator。 我对解释什么是红移和MongoDB的答案有点恼火，所以我决定花点时间来分享我最后要做的事情

时间戳数据

基本上，我们确保要迁移到红移表中的所有MongoDB集合都有时间戳，并根据该时间戳进行索引

返回游标的插件

然后，我们为从mongo集合到redshift表的每次迁移编写一个插件。每个插件都会返回一个游标，该游标会考虑上次迁移的日期（从migrator引擎传递给它），并且只返回自该插件上次成功迁移以来已更改的数据

如何使用光标

然后，migrator引擎使用该游标，并循环遍历每个记录。 它为每个记录调用插件，将文档转换为数组，然后migrator使用该数组创建分隔线，并将其流式传输到磁盘上的文件。我们使用制表符来分隔这个文件，因为我们的数据包含很多逗号和管道

用分隔符从S3导出到红移的表中

然后，迁移器将带分隔符的文件上载到S3，并运行redshift copy命令将文件从S3加载到临时表中，使用插件配置获取名称，并使用约定将其表示为临时表

例如，如果我有一个配置了表名为

employees

的插件，它将创建一个名为

temp\u employees

的临时表

现在我们在这个临时表中有了数据。这个临时表中的记录从原始MongoDB集合获取ID。这允许我们对目标表运行delete，在我们的示例中是employees表，其中id存在于temp表中如果任何表不存在，则根据插件提供的模式动态创建该表。因此，我们可以将temp表中的所有记录插入到目标表中。这既适用于新记录，也适用于更新记录。我们只对数据进行软删除，因此将使用红移中的

is\u deleted

标志更新数据

完成整个过程后，migrator引擎将插件的时间戳存储在红移表中，以便跟踪该插件上次成功运行的时间。然后，当引擎下次决定应该迁移数据时，该值会传递给插件，从而允许插件使用它需要提供给引擎的游标中的时间戳

总之，每个插件/迁移都为引擎提供了以下功能：

• 游标，可以选择使用传递给它的最后一个迁移日期 从发动机上拆下，以确保仅移动增量 对面
• 转换函数，引擎使用该函数将光标中的每个文档转换为带分隔符的字符串，并将其附加到导出文件中
• 模式文件，这是一个SQL文件，包含红移时表的模式