(1) 一定要区分业务类型,可能达到千万用户级别的应用业务场景,可归类描述为: SNS社交平台、SNS社交游戏、即时通信IM系统、电子商务、邮件系统、新闻门户网站等,这些不同类型的业务场景做法会不一样,主要是由他们业务性质决定,后续分析项中逐一描述;
(2) 应用业务的核心KPI数值,产品每天的日活跃用户量大概多少?若是网站类型应用,还需要加入其他参数PV,UV等数据辅助决策,即时通信IM的消息量,邮件系统的新增邮件数,SNS社交平台的Feeds量等核心数据;
(3) 系统中每个用户可能产生的数据量大概多大,分固定部分,以及动态部分的方式统计分析,对非固定部分以参考值和结合实践跨度(注释:1年为硬性指标,2年为预期,3年可选,再长的时间段不考虑)的方式进行分析,然后预测出整个系统的用户锁产生的数据条数和数据容量大概的估值;
首先要说的是创建索引会提高搜索速度
再就是 like 不会使用索引,结果就是你创建了索引但是找不到结果,这个和union没有关系
即使你单独一条查询也是遍历整个数据库,不会在索引中查询
对于这种情况一般都是通过分词创建文件索引的方式进行文字查询 如 lucene
现在的数据量,想要通过sql解决文字的like查询,通过数据库已经不够用的了~
以上就是关于如何构建千万用户级别 后台数据库架构设计的思路全部的内容,包括:如何构建千万用户级别 后台数据库架构设计的思路、mysql 千万级数据库如何进行多张结构相同的表联合查询如何优化或设置提高查询速度、等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)