我正在开发一个网上商店类型的应用程序.我经常在其他网站上看到的一个功能是过滤选项的细分,之后总共过滤选项会有多少结果.您经常在计算机网站(例如Newegg)或二手车网站上看到此信息.例:
CPU:
* AMD (315)
* Intel (455)
Video card:
* ATI (378)
* Nvidia (402)
我怎样才能有效地计算这些总数？我正在研究的网站将有许多不同的产品(10.000+),有许多不同的选择.更糟糕的是,产品在不断变化.
试图预先计算所有不同的过滤组合总数似乎是不可行的.如果我有5个不同的过滤器,每个过滤器有4个选项,那么选项的可能性就是多少20 * 16 * 12 * 8 * 4 = 122880.计算它需要很长时间.
另一种选择是按需查询并缓存结果(例如在Redis中).但是,如果不断添加和删除产品,我怎么能有效地管理缓存呢？缓存通常是陈旧的.我担心我必须以微观方式管理缓存失效,从而导致一个非常复杂和脆弱的实现.另一种方法是使广泛的缓存部分无效.但是,在无效之后,我的数据库会被需要重新计算这些总数的活跃用户的查询匆匆忙忙.
有一个漂亮而优雅的方式来处理这个问题吗？
我认为显示您的案例的实时数据没有问题。无论如何，我无意劝阻您，但就性能而言，10K 产品并不多。另一方面，有数百万人是这样。
您是否真的尝试以这种方式实现它并发现它执行缓慢，或者您只是过于关注其理论性能？我建议您按原样对系统进行一些压力测试，看看是否值得改进。不过，这里有一些让它更快的想法：
仅当展开/单击特定类别时，才不要一次填充所有计数。因此，您总是会得到一个SELECT cat_name, COUNT(*) GROUP BY cat_name查询，这不会占用太多时间。像这样的每次用户点击的单一且相对较轻的查询对我来说听起来很合理。
让数据库引擎为您管理缓存。如果您经常执行类似的查询，您的数据库引擎应该自动优化底层存储（即将整个表移动到内存或类似的地方）。您只需确保实例有足够的内存即可。
如果需要，升级服务器硬件。如果数据量增加，您可能没有足够的内存来存储所有内容。不要惊慌，您仍然可以在服务器中放入 SSD，或者在服务器中安装 12 核 Xeon 处理器，具体取决于瓶颈在哪里。