Jas*_*rue 4 couchdb mongodb entity-attribute-value
假设我有一个遗留应用程序,由于各种原因,以前的开发人员决定必须具有任意灵活的模式,并且他们再次重新创建了实体 - 属性 - 值模型.他们实际上正在尝试构建一个文档存储库,对于像Mongo或Couch这样的工具现在更适合当今世界,但以前的团队不可用或不知道.
为了保持竞争力,假设我们需要构建更强大的方法来查询和分析系统中的信息.基于纯粹的数量和属性的多样性,似乎map/reduce更适合我们的问题,而不是逐渐将系统重构为更多的关系模式.
原始源数据库有数百万个文档,但只有少量不同的文档类型.不同文档类型之间存在一些共性.
从MySql中的大规模EAV实施迁移到像Mongo或Couch这样的面向文档的商店,有什么有效的策略？
我当然可以想象一种攻击方法,但是我真的希望看到一个教程或战争故事,向已经攻击过这类问题的人学习.
做这种转换的策略是什么？你学到了什么教训？我应该避免哪些陷阱？您是如何处理仍希望能够与现有数据库交互的遗留应用程序的？
我第一次使用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应用程序,我很快就开始在我的所有项目中使用它,并最终与两个创建者一起创建了一个围绕该技术的公司.
| 归档时间： |
|
| 查看次数： |
1909 次 |
| 最近记录： |