一个商品表需要销量这个字段吗?
根据表设计的范式 销量可以由订单记录得出(或者建一个商品每日效果表,记录每天的效率),但是这样在实际中却遇到了这样的问题?
怎么查询时怎么根据商品的销量排序呢,还有按点赞数排序呢,收藏数呢?想淘宝这样的怎么做呢?
一个商品表需要销量这个字段吗?
根据表设计的范式 销量可以由订单记录得出(或者建一个商品每日效果表,记录每天的效率),但是这样在实际中却遇到了这样的问题?
怎么查询时怎么根据商品的销量排序呢,还有按点赞数排序呢,收藏数呢?想淘宝这样的怎么做呢?
销量是必须的,但是这一列可以不是实时的,你应该记上统计出这个数据的时候的时间。
我的建议是,你先给订单时间加index,然后每过一小时(这个时间看你的售货速度)统计一下cache下当时的销量,然后把销量和时间这两个列存下来。你在前端显示真实的销量的时候,就可以把cache的数据,加上cache之后发生的订单的总和相加。这样你过一段时间就incrementally地做一下,问题就解决了。
订单时间加index的意思就是说,你知道你目前的cache是到譬如说半个小时前,那你这样就很容易query出半个小时内发生的订单,每一次处理的数据都会非常少。因此这个系统的负担不会随着你订单的增加而变慢,你也不需要因为每一次订单就频繁的更改“销量”这个列而产生性能问题。
如果一秒钟就有几个人挤进来,那可能会总是有一点误差,不过稍微做点变通就解决了。
对于如何给销量排序,我觉得需要在缓存这一层来解决,不需要在数据库维护这个index。如果按照这种方法维护销量的话,虽然直接按照这个列排序是不正确的,但是他“基本正确”。对于这样的属性的数据有特殊的排序方法。其中的一种方法是,你做一个qsort的变形,但是用户看到哪里你才排序到哪里。通常你在前端让用户按照销量排序的话,他只会看最前面的或者最后面的。平摊到每一次查阅,复杂度基本是log(n)的。
这种方法基本上可以用到你的数据规模明显比淘宝少的时候。你真有了淘宝那么大的数据,那所有的事情都得改成分布式的。最后要么上spark,要么上sqlazure,要么上scope,做起来就差很远了。
表的设计应该按照实际情况来,如果这个字段用得频繁,考虑到查询效率可以增加。
在你有排序的场景下,销量字段是必须的,并且由于是经常更新的字段,很有可能会按实际情况拆分到子表里,举个例子,goods存储商品信息,goods_counter一对一goods表,并存储各种统计信息,包括不限于销量,查看数,收藏数,点赞数,并根据需要建立索引
很多实际的一定规模(用户数或者数据量)的系统,未必还会使用MySQL做排序,会把数据放入搜索引擎,比如elasticsearch, solr, sphinx等等,然后利用搜索引擎做排序
都按销量排序了,那就加上呗。