面向文档的dbms作为主数据库,RDBMS数据库作为辅助数据库？

Question

由于它的规范化,我在MySQL数据库方面遇到了一些性能问题.

我使用数据库的大多数应用程序都需要执行一些重型嵌套查询,在我的情况下需要花费大量时间.使用索引运行查询可能需要2秒钟.没有索引约45秒.

几个月前我遇到的一个解决方案就是使用更快,更线性的基于文档的数据库,在我的案例中,Solr作为主数据库.一旦MySQL数据库中的某些内容发生了变化,就会通知Solr.

这非常有用.使用Solr数据库的所有查询只需要大约3 毫秒.

数字看起来不错,但我遇到了一些问题.

• 庞大的数据库

MySQL数据库大约200mb,Solr db包含大约1.4Gb的数据.每次我需要更改表/列时,数据库都需要重新编制索引,在此示例中需要花费12个小时.

• 难以渲染Solr对象和Active Record(MySQL)对象而不会弄湿.

视图依赖于某个对象.它不关心它自身的对象是Active Record对象还是Solr对象,只要它可以在它上面调用一组属性.

像这样.

# Controller
@song = Song.first

# View
@song.artist.urls.first.service.name

在我的情况下,问题是从Solr返回的数据是这样的平坦.

{
  id: 123,
  song: "Waterloo",
  artist: "ABBA",
  service_name: "Groveshark",
  urls: ["url1", "url2", "url3"]
}

这迫使我构建一个可以传递给视图的活动记录对象.

我的问题

有没有更好的方法来解决这个问题？某种可以快速处理复杂查询的超级快速主要只读数据库会很好.

Answer 1

Solr个别字段更新

关于对模式更改的所有重建索引:Solr 不支持更新单个字段,但有一个关于此的JIRA问题仍未解决.但是,您有多少次更改架构？

MongoDB的

如果你可以在没有RDBMS的情况下生活(没有连接,模式,事务,外键约束),那么像MongoDB或CouchDB这样的基于文档的数据库将是一个完美的选择.(这是他们之间的一个很好的比较)

为什么要使用MongoBD:

• 数据采用原生格式(您可以 直接在视图中使用类似Mongoid的ORM映射器,因此您不需要像使用Solr一样调整记录)
• 动态查询
• 在非全文搜索查询上表现非常出色
• 无架构(不需要迁移)
• 内置,易于设置复制

为何使用SOLR:

• 先进的,高性能的全文搜索

为什么要使用MySQL

• 加入,约束,交易

解决方案

那么,解决方案(组合)将是:

1. 使用MongoDB + Solr

   • 但是您仍然需要重新索引所有架构更改

2. 仅使用MongoDB

   • 但放弃了对高级全文搜索的支持

3. 在主从配置中使用MySQL,并平衡从slave的读取(使用像octupus这样的插件)+ Solr

   • 设置复杂性

4. 保持当前设置,在MySQL中对数据进行非规范化

   • 乱

Solr重新索引缓慢

MySQL数据库大约200mb,Solr db包含大约1.4Gb的数据.每次我需要更改表/列时,数据库都需要重新编制索引,在此示例中需要花费12个小时.

在Solr中重新索引200MB DB 不应该花费12个小时!最有可能你还有其他问题,如:

MySQL的:

• n + 1期
• 索引

SOLR:

• 在每个请求之后提交 - 这是默认设置,你使用像太阳黑子这样的插件,但它是生产的一个杀手杀手

来自http://outoftime.github.com/pivotal-sunspot-presentation.html:

• 默认情况下,Sunspot :: Rails在每个更新Solr索引的请求结束时提交.把它关掉.
  
  • 使用Solr的autoCommit功能.这是在solr/conf/solrconfig.xml中配置的
  • 很高兴假设不一致.不要在结果需要最新的情况下使用搜索.

• 其他设置问题(http://wiki.apache.org/solr/SolrPerformanceFactors#Indexing_Performance)

查看日志以获取更多详细信息