50/50 插入和选择。创建两张表或一张表

Question

现在建议的表结构是：-

data_table
->impressions
->clicks
->ctr

或

data_table_1
->ctr

data_table_2
->impressions
->clicks

执行了哪些查询？ 展示次数每秒大约有 500 次更新。每秒大约有 1 次点击更新。 ctr 每秒大约有 500 次更新。

现在我的应用程序使用 ctr 对数据进行排序。 ctr 是ctr = clicks/impressions 计算的点击率。现在我意识到，除非有点击更新，否则 ctr 不需要更新，因为文章的所有印象都在增加，这会降低相同关系中的 ctr，所以除非有点击，否则 ctr 不需要更新。

目前更新查询类似于“UPDATE data_table SET 展示次数 = 展示次数 + 1，ctr = 点击次数 / 展示次数 WHERE something = something

这意味着虽然一次更新了 2 个字段，但只执行了 1 个查询。

现在的瓶颈是这 500 次更新导致此表上的选择变慢。每秒大约有 20 次选择。所以我想把桌子分开。新的表格样式建议更新发生在单独的表格上，选择发生在单独的表格上。包含展示次数的数据表更新非常频繁，因此对其执行的展示次数进行更新确实加快了该表的性能。这意味着 data_table_2 上的选择也会更快，并且每次有人点击时都可以更新 ctr。

所以，我只是想知道是否应该使用新的表结构。你有什么建议？我的建议的利弊！

Answer 1

首先，我假设该表已被良好索引，因此something = something 谓词将很快导致相应的行，对吧？

进一步假设您的瓶颈是由于高更新率而导致的磁盘吞吐量，那么根本不存储 ctr 值怎么样，因为它可以很容易地即时计算？由于您似乎受到更新的限制，因此仅更新一个字段应该大约是必须将数据写入磁盘的影响的一半。在这种情况下，CPU 可能相对空闲，计算每个结果的点击/展示应该不是问题。您的方法会得到回报（再次假设磁盘是限制因素，假设它是并且可以通过查看 CPU 利用率轻松发现），那么您的方法将带来相当大的好处，iff 表格或在两个不同的磁盘上。

如果 CPU 被证明是限制因素，那么可能是因为 something = something 谓词的评估相当复杂，在这种情况下简化这应该是主要关注点，而不是拆分表。

Answer 2

也许这不是对您问题的直接回答，但我认为需要注意这一点很重要。

我认为您应该考虑使用 Nosql 数据库，例如 Redis、MemcacheDB、MongDB、CouchDB。关系型 DBMS 不太适合这种用途。例如，每次更新任何列 (UPDATE data_table SET impressions = impressions + 1) 时，缓存都会被擦除，数据库必须命中磁盘。

其他人认为您可以考虑使用 Memcache 并在一段时间后将该数据批量存储到磁盘。

例如，如果您可以承受一些印象数（记住 memcache 不会持久化数据），您可以在 memcache 中执行印象数++，并每 5 分钟更新一次数据库中的数据。它会显着减少您的负载。

希望对你有帮助。

编辑：

存储 CTR 是一个好主意，它被称为“非规范化”，如果它是一个经常需要的值，它可能会在您的应用程序中起作用。