1

这是我第一次接近一个非常高容量的情况。这是一个基于 MySQL 的广告服务器。但是，使用的查询包含很多 JOIN 并且通常很慢。（这是 Rails ActiveRecord，顺便说一句）

sel = Ads.find(:all, :select => '*', :joins => "在 ads.campaign_id =campaign.id 上加入活动campaign.id LEFT JOIN 关键字 ON keywords.campaign_id = campaign.id", :conditions => [flashstr + "keywords.word = ? AND ads.format = ? AND campaign.cenabled = 1 AND (countries.country IS NULL OR countries .country = ?) AND ads.enabled = 1 AND campaign.dailyenabled = 1 AND users.uenabled = 1", kw, format, viewer['country'][0]], :order => order, :limit =>限制）

我的问题：

  1. 有没有像 MySQL 这样支持 JOIN 但速度更快的替代数据库？（我知道有 Postgre，仍在评估它。）

  2. 否则，启动 MySQL 实例，将本地数据库加载到内存中并每 5 分钟重新加载一次会有帮助吗？

  3. 否则，有什么方法可以将整个操作切换到 Redis 或 Cassandra，并以某种方式更改 JOIN 行为以匹配 NoSQL 的（不可加入）性质？

谢谢！

编辑：这里有更多细节：

使用扁平化选择（上面截断）的完整执行 SQL：

选择活动.id、活动.guid、活动.user_id、活动.dailylimit、活动.impressions、活动.cenabled、活动.dayspent、活动.dailyenabled、活动.fr、ads.id、ads.guid、ads.user_id、广告.campaign_id, ads.format, ads.enabled, ads.datafile, ads.data1, ads.data2, ads.originalfilename, ads.aid, ads.impressions, countries.id, countries.guid, countries.campaign_id, countries.country ，keywords.id，keywords.campaign_id，keywords.word，keywords.bid FROMads在 ads.campaign_id =campaign.id 上加入广告系列 在campaigns.user_id = users.id 上加入用户 在国家/地区.campaign_id =campaigns.id 上左加入国家/地区在keywords.campaign_id =campaigns.id 上加入关键字' AND ads.format = 10 AND campaign.cenabled = 1 AND (countries.country IS NULL OR countries.country = 82) AND ads.enabled = 1 AND campaign.dailyenabled = 1 AND users.uenabled = 1 AND ads.datafile ！ = '') ORDER BY keywords.bid DESC LIMIT 1,1

解释/执行计划：

+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+
| id | select_type | table     | type   | possible_keys    | key         | key_len | ref                                | rows | Extra                                        |
+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+
|  1 | SIMPLE      | keywords  | ref    | campaign_id,word | word        | 257     | const                              |    9 | Using where; Using temporary; Using filesort | 
|  1 | SIMPLE      | ads       | ref    | campaign_id      | campaign_id | 4       | e_development.keywords.campaign_id |    8 | Using where                                  | 
|  1 | SIMPLE      | campaigns | eq_ref | PRIMARY          | PRIMARY     | 4       | e_development.keywords.campaign_id |    1 | Using where                                  | 
|  1 | SIMPLE      | users     | eq_ref | PRIMARY          | PRIMARY     | 4       | e_development.campaigns.user_id    |    1 | Using where                                  | 
|  1 | SIMPLE      | countries | ALL    | campaign_id      | NULL        | NULL    | NULL                               |    4 | Using where                                  | 
+----+-------------+-----------+--------+------------------+-------------+---------+------------------------------------+------+----------------------------------------------+

（这是在一个开发数据库上，它的行数几乎没有生产版本那么多。）

定义的指数：

ads -> id (primary, autoinc) + aid (unique) + campaign_id (index) + user_id (index)
campaigns -> id (primary, autoinc) + user_id (index)
countries -> id (primary, autoinc) + campaign_id (index) + country (index) + user_id (index)
keywords -> id (primary, autoinc) + campaign_id (index) + word (index) + user_id (index)
user -> id (primary, autoinc)
4

2 回答 2

3

数据库理论和名义实践的存在为大多数情况提供了一个框架。并非每个数据库使用模式都适合第三范式。因此，NoSQL 的出现。这些数据库在大多数情况下效果不佳，但在特定情况下效果很好。它们运行良好的一个原因是它们不像普通的 RDBMS 那样运行。Cassandra 确实有一些“加入”的功能，但我不记得确切的细节。如果您想快速了解，我推荐 Digg 开发人员博客。有一个很好的简单描述。

问题是我敢打赌，加入 4 个表会比 mySQL 慢。唯一确定的方法是学习一个新的 DBMS，安装它，调整安装，以及调整 MySQL 和设置所有数据......你会喜欢发现 MySQL 做得非常好.

尝试用不同的引擎以完全相同的方式解决完全相同的问题不会解决问题……您必须像 NoSQL 开发人员一样思考，而不是使用 NoSQL 的 RDBMS 开发人员。

但是你可以按照Frustrated 的建议来思考这个问题。

为什么我们有第三范式？主要是易于更新。我更新一行而不是几十行。它还有助于约束数据，如果我仔细控制国家表中国家的添加，我将永远不会在活动表中得到一个坏的。在那之后，3NF 并没有让查询变得更快，这就是我们发明报告数据库、OLAP、多维数据集、星型模式的原因。

关键是报告与编辑/捕获的结构不同。

正如Frustrated 所说，确定基础数据的变化速度。如果你真的每 5 分钟添加一次国家，我会惊呆的。竞选活动？可能偶尔？广告？一天几次。构建一个完全扁平化的表并为其编制索引需要多长时间？这会产生多少行？如果该周期时间比您的更新频率短得多...构建并查看。测试查询速度。这比购买一个全新的数据库便宜。

于 2010-06-14T22:07:34.240 回答
1

你分析过你的执行计划吗？你分析过你的指数吗？

我的第一个猜测是你需要一个索引campaignsfor user_id， index on countriesfor campaign_id， on keywordson campaign_id...也许还有其他人。您需要获得一个执行计划以查看您的查询在做什么。

另一个选项：此结果集中的数据多久更改一次？分分钟？小时？天？如果它是每天或每小时（嗯，几个小时），最好有一个包含此结果集的所有列（或只是不太可能经常更改的列）并由此查询填充的辅助表每n小时。然后您的应用程序将只查询辅助表（或者可能与一个具有频繁更改数据的表连接），这样可能会更快。

于 2010-06-14T20:15:39.420 回答