假设我有一个遗留应用程序，由于各种原因，以前的开发人员决定必须有一个任意灵活的架构，他们再次重新发明了实体-属性-值模型。他们实际上是在尝试构建一个文档存储库，Mongo 或 Couch 等工具现在更适合当今世界，但以前的团队不可用或不知道。
为了保持竞争力，假设我们需要构建更强大的方法来查询和分析我们系统中的信息。基于属性的绝对数量和多样性，map/reduce 似乎更适合我们的问题集，而不是逐渐将系统重构为关系性更强的模式。
原始源数据库有数百万文档，但只有少量不同的文档类型。不同文档类型之间存在一些共性。
从 MySql 等大型 EAV 实现迁移到 Mongo 或 Couch 等面向文档的存储的有效策略是什么？
我当然可以想象一种解决这个问题的方法，但我真的很想看到一个教程或 war 故事，以向已经解决过此类问题的人学习。
进行这种效果很好的转换有哪些策略？你学到了什么教训？我应该避免哪些陷阱？您如何处理仍希望能够与现有数据库交互的遗留应用程序？
最佳答案
我第一次使用 Couch 是在我编写了 Ruby 和 Postgres 网络爬虫(定向爬取 mp3 博客以构建推荐引擎)之后。
当我尝试记录 ID3 元数据、音频签名等时，关系模式变得非常粗糙，检测重叠并以其他方式进行重复数据删除。它有效但速度很慢。太慢了，我开始将我的 JSON API 行作为 blob 字段缓存到相应的主要 ActiveRecord 对象上。
我有一个选择:深入学习 Postgres 性能调优，或者转向横向方法。因此，我使用 Nutch 和 Hadoop 来抓取网络，并使用 PipeMapper 来使用 Ruby/Hpricot 解析页面。所以我能够重用我所有的解析器代码，并将其从保存为规范化数据库更改为保存为 JSON。我编写了一个名为 CouchRest 的小库来处理 JSON 和 REST URL 端点，我用它来将 Hpricot 结果保存到 CouchDB 中。
对于那个项目，我只是在单个 EC2 节点上运行 Couch，其中填充了一个小型 6 节点 Hadoop 集群。只有当我着手构建爬取数据的浏览界面时，我才真正对查询功能有了良好的感觉。
事实证明，我很灵活，特别适合 OLTP 应用程序，我很快就开始在我的所有项目中使用它，并最终与两位创始人一起围绕该技术创立了一家公司。
关于mongodb - 将遗留 EAV 模式转换为 Mongo 或 Couch，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5682279/