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