84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
假设一个论坛帖子按板块分为N个表
thread_bbs1 thread_bbs2 thread_bbs3 .... thread_bbsN
那一个用户发布的帖子就会散落在N个表里,如果有个业务需要查看用户的所有帖子总数并按时间排序用户的所有发帖,就要join所有的表?
应该怎么样合理的分表呢?
这个问题不在于如何分表和查询,而在于如何做 数据冗余。
你需要将用户发帖的基本信息用另一些表来存储,比如叫做 thread_user*,这些表按照用户 id 分表,内容包括用户 id、帖子 id、发帖时间等你需要的信息。
每次创建帖子的时候需要同时写两份,thread_bbs* 和 thread_user*,读的时候按需读取对应的表就可以。
按照用户的唯一ID去路由分表。
分表只是为了分散存储压力,查询的话可以借鉴@Han Du 的方法,建个索引表,存储基本信息,通过索引表去统计和排列,需要具体数据的时候再join 很多开源的系统,尤其是国外的优秀商城产品,看下数据库设计会发现他们很擅长使用索引表
http://blog.csdn.net/hguisu/article/details/8836819
可以考虑使用中间层,例如阿里的 otter 或者 360的 atlas,不建议用 mysqlproxy
这个问题不在于如何分表和查询,而在于如何做 数据冗余。
你需要将用户发帖的基本信息用另一些表来存储,比如叫做 thread_user*,这些表按照用户 id 分表,内容包括用户 id、帖子 id、发帖时间等你需要的信息。
每次创建帖子的时候需要同时写两份,thread_bbs* 和 thread_user*,读的时候按需读取对应的表就可以。
按照用户的唯一ID去路由分表。
分表只是为了分散存储压力,查询的话可以借鉴@Han Du 的方法,建个索引表,存储基本信息,通过索引表去统计和排列,需要具体数据的时候再join
很多开源的系统,尤其是国外的优秀商城产品,看下数据库设计会发现他们很擅长使用索引表
http://blog.csdn.net/hguisu/article/details/8836819
可以考虑使用中间层,例如阿里的 otter 或者 360的 atlas,不建议用 mysqlproxy