假设我有一个遗留应用程序，由于各种原因，以前的开发人员决定必须有一个任意灵活的模式，他们再次重新发明了实体-属性-值模型。他们实际上是在尝试构建一个文档存储库，为此，Mongo 或 Couch 等工具现在更适合当今世界，但以前的团队不可用或不知道。
为了保持竞争力，假设我们需要构建更强大的方法来查询和分析系统中的信息。基于属性的绝对数量和多样性，似乎 map/reduce 比逐步将系统重构为更具关系的模式更适合我们的问题集。
原始源数据库有数百万个文档，但只有少数不同的文档类型。不同的文档类型有一些共性。
从大型 EAV 实现(例如 MySql)迁移到面向文档的存储(如 Mongo 或 Couch)的有效策略是什么？
我当然可以想象一种解决这个问题的方法，但我真的很想看一个教程或 war 故事，从已经解决过这类问题的人那里学习。
进行这种有效转换的策略有哪些？你学到了什么教训？我应该避免哪些陷阱？您如何处理仍希望能够与现有数据库交互的旧应用程序？
最佳答案
我第一次使用 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 应用程序，我很快就开始在我的所有项目中使用它，并最终与两位创建者围绕该技术成立了一家公司。
关于mongodb - 将传统 EAV 模式转换为 Mongo 或 Couch，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5682279/