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

Question

由于 MySQL 数据库的规范化，我遇到了一些性能问题。

我的大多数使用数据库的应用程序都需要执行一些繁重的嵌套查询，在我的情况下这需要很多时间。查询可能需要 2 秒才能运行，有索引。没有索引大约 45 秒。

几个月前我遇到的一个解决方案是使用更快、更线性的基于文档的数据库，在我的例子中是 Solr，作为主数据库。一旦 MySQL 数据库发生变化，Solr 就会收到通知。

这真的很棒。使用 Solr 数据库的所有查询只用了大约 3ms。

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

• 庞大的数据库

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

• 很难在不获取 wet 的情况下同时呈现 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 does not support updating individual fields，但有一个 JIRA issue 对此仍未解决。但是，您更改了多少次架构？

MongoDB

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

为什么使用 MongoBD：

• 数据为原生格式（您可以直接在视图中使用像 Mongoid 这样的 ORM 映射器，因此您无需像使用 Solr 那样调整您的记录）
• dynamic queries
• 在非全文搜索查询中表现非常出色
• 无模式（无需迁移）
• 内置，易于设置replication

为什么使用 SOLR：

• 高级、高性能的全文搜索

为什么要使用 MySQL

• 联接、约束、事务

解决方案

因此，解决方案（组合）将是：

1. 使用 MongoDB + Solr

   • 但您仍需要在架构更改时重新索引所有内容

2. 仅使用 MongoDB

   • 但不再支持高级全文搜索

3. 在主从配置中使用 MySQL，并平衡来自从属的读取（使用像 octupus 这样的插件）+ Solr

   • 设置复杂度

4. 保持当前设置，非规范化 MySQL 中的数据

   • 凌乱

Solr 重新索引缓慢

MySQL 数据库大约 200mb，Solr db 包含大约 1.4Gb 数据。每次我需要更改数据库需要的表/列时 重新索引，在本例中需要 12 多个小时。

在 Solr 中重新索引 200MB 数据库不应该需要 12 个小时！很可能您还有其他问题，例如：

MySQL：

• n+1 issue
• 索引

SOLR：

• 在每次请求后提交 - 这是默认设置，您使用像 sunspot 这样的插件，但它是 perf killer for production

来自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)

查看日志了解更多详情

Answer 2

与其将数据推送到 Solr 以展平记录，不如直接在 MySQL 数据库中创建一个单独的表，该表已针对只读访问进行了优化。

你似乎也自相矛盾

视图依赖于某个对象。它不关心自己的对象是 Active Record 对象还是 Solr 对象，只要它可以调用其上的一组属性即可。

我的问题是从 Solr 返回的数据是扁平的...这迫使我构建一个可以由视图呈现的假活动记录对象。