将旧版 EAV 模式转换为 Mongo 或 Couch

Question

假设我有一个遗留应用程序，由于各种原因，以前的开发人员决定必须有一个任意灵活的模式，他们再次重新发明了实体-属性-值模型。他们实际上是在尝试构建一个文档存储库，Mongo 或 Couch 等工具现在更适合当今世界，但以前的团队不可用或不知道。

为了保持竞争力，假设我们需要构建更强大的方法来查询和分析系统中的信息。从属性的数量和种类来看，似乎 map/reduce 更适合我们的问题，而不是逐渐将系统重构为更具关系的模式。

原始源数据库有数百万个文档，但只有少数不同的文档类型。不同的文档类型有一些共同点。

从 MySql 中的大规模 EAV 实施迁移到像 Mongo 或 Couch 这样的面向文档的存储的有效策略是什么？

我当然可以想出一种方法来解决这个问题，但我真的很想看到一个教程或战争故事，向已经解决过这类问题的人学习。

有哪些策略可以很好地进行这种转换？你学到了什么？我应该避免哪些陷阱？您如何处理仍希望能够与现有数据库交互的旧版应用程序？

Answer 1

我第一次使用 Couch 是在我编写了一个 Ruby 和 Postgres 网络爬虫（直接爬取 mp3 博客以构建推荐引擎）之后。

当我尝试记录 ID3 元数据、音频签名等时，关系模式变得非常粗糙，并且检测重叠并进行重复数据删除。它有效，但速度很慢。太慢了，我开始将我的 JSON API 行作为 blob 字段缓存到相应的主要 ActiveRecord 对象上。

我有一个选择：深入学习 Postgres 性能调优，或者转向横向方法。所以我用 Nutch 和 Hadoop 来爬网，用 PipeMapper 用 Ruby / Hpricot 解析页面。所以我能够重用我的所有解析器代码，只需将其从保存为规范化数据库更改为保存为 JSON。我编写了一个小库来处理 JSON 和 REST URL 端点，称为 CouchRest，我用它来将 Hpricot 结果保存到 CouchDB 中。

对于那个项目，我只是在单个 EC2 节点上运行 Couch，并在其中填充了一个小型 6 节点 Hadoop 集群。直到我开始为爬取的数据构建浏览界面时，我才真正对查询能力有了很好的感觉。

事实证明，我很灵活，特别适合 OLTP 应用程序，我很快就开始在我的所有项目中使用它，并最终与两位创建者一起围绕该技术成立了一家公司。