将传统的EAV模式转换为Mongo或Couch

如何解决将传统的EAV模式转换为Mongo或Couch

| 假设我有一个遗留应用程序，由于各种原因，以前的开发人员决定必须具有任意灵活的架构，然后他们又重新发明了Entity-Attribute-Value模型。他们实际上是在尝试建立文档存储库，Mongo或Couch之类的工具现在更适合当今世界，但以前的团队并不知道或不知道。 为了保持竞争力，我们需要建立更强大的方法来查询和分析系统中的信息。基于大量的属性和各种属性，与逐步将系统重构为更具关系的架构相比，map / reduce似乎更适合我们的问题。 原始源数据库具有数百万个文档，但是只有少量不同的文档类型。不同文档类型之间存在一些共性。 从大规模的EAV实现（例如MysqL）迁移到面向文档的商店（如Mongo或Couch）的有效策略是什么？ 我当然可以想像出一种解决此问题的方法，但是我真的很想看看一个教程或战争故事，以向已经解决了此类问题的人学习。 有什么策略可以很好地进行这种转换？你学了什么课？我应该避免什么陷阱？您如何处理仍希望能够与现有数据库交互的旧版应用程序？     

解决方法

Couch的首次使用是在我编写了Ruby和Postgres Web搜寻器之后（定向mp3博客的搜寻以构建推荐引擎）。 当我尝试记录ID3元数据，音频签名等时，关系模式变得非常粗糙，检测重叠并且进行重复数据删除。它起作用了，但是很慢。太慢了，我开始将JSON API行作为blob字段缓存到相应的主要ActiveRecord对象上。 我有一个选择：深入学习Postgres性能调整，或者转向横向方法。因此，我使用Nutch和Hadoop扩展了网络，并使用PipeMapper使用Ruby / Hpricot解析页面。因此，我能够重用我所有的解析器代码，并将其从保存为规范化数据库更改为保存为JSON。我编写了一个小库来处理JSON和REST URL终结点，称为CouchRest，用于将Hpricot结果保存到CouchDB中。 对于该项目，我只是在单个EC2节点上运行了Couch，并在其中填充了一个小的6节点Hadoop集群。只有当我开始构建爬虫数据的浏览界面时，我才真正对查询功能感到满意。 事实证明，我非常灵活，特别适合OLTP应用程序，我很快就在我的所有项目中开始使用它，并最终与两名创建者围绕该技术成立了一家公司。