作为一名数据架构师，我们早期就应该考虑到业务数据分布的特殊性，如果没有考虑到，将会是致命的。那么我们该如何发现并能够早期解决这样的问题呢？下面我们以具体的案例来介绍说明。
案例一：select * from user where email like 'a%' order by create_time limit 1,20。
在很多的web2.0应用中，UI通常要求能够提供智能的用户搜索功能，功能翻译成SQL语句，类似于上面显示的SQL，而这非常简单的SQL语句带来的疼苦远比我们写这行代码的快感要多。针对这样的需求，前期的数据架构该如何进行呢？
首先，我们的脑海中，需要有这样的一个概念，这样的查询数据量是巨大的，它占到了用户注册量的3.8%，如果用户数达到2500千万，那么查询的数据就是接近100万数据，而UI设计之时要求的页面反应时间需要在几秒内，技术上如何实现这样的数据架构呢？
其次，面对这样的问题，我们该如何去做呢？通用的方法是将数据拆小，单个表的数据量不是有2500万嘛，如果有250个表，那么单表的数据量不就只有10万了嘛，如果我们最大并发数可以达到250，那么这样最长查询的时间将在100毫秒内，加上web层的合并数据和排序的时间，将不会超过1秒，这样的数据架构将能够满足我们的业务需求，但如何拆分呢？将庞大的用户表进行拆分，通常是将用户ID进行hash和取模，那么这样的拆分也不能说此不好，而是再以上SQL查询时，需要访问的表将很多，那么查询性能上将大大降低。我们是否可以换一种方法呢？我们按照email的首字母进行拆分，那么我们可以拆分成26份表(可以加上数字和一些英文符号，这样分表的粒度将更大），然后我们再按照email的hash值进行取模10份，最后我们的表的数量为10*26=260个，而这样的拆分不但满足通用的case，而且满足后期的可扩展。
第三，260份表最大可支持的物理机器为260台，因此单表最大全表扫描的100万的话，可以支撑的用户数为2亿6千万或者更多。
最后，应用层可以根据切片规则进行最大260个线程的并发查询，并发度的大小，需要根据物理机器的容量和能力，设置并发度和数据库连接非常关键。
在案例一中，简单说明了下数据分布对数据架构的影响，但不足以说明此决定了后期的数据架构，下面举一个真实的案例来说明。
在设计消费记录初始时(支撑每年数据为35亿条），大家都认为已经将消费记录按照用户ID（USERID）取模，分成了100份，然后将按照消费记录的产生的月份在进行一次拆分，100*12=1200张表分布到10-20台的物理的MYSQL数据库中，绝对能够满足所有前台查询。业务数据的拆分规则如下图所示：
大家都认为此时查询应该非常快了，用户怎么爽怎们用；这样的架构设计，不但能够满足后期的业务增长而带来的技术服务能力不匹配问题，而且架构设计也相对简单，已经堪称完美了。但是这样的架构真的是这样吗？
其实不然，由于消费记录中存在大量非商户的卖家用户，当不限制用户查询的时候，普通用户没有问题，当遇到大的卖家用户时，问题出现了：一个大的卖家可能每天产生的消费记录达2万条，一旦这样的用户查询6个月的数据时（2*30*6=120万条数据的获取），无论如何在几秒内是无法完成的，而这样的用户如果取模较多的分布在同一台物理机器上时，并发查询带来的后果，就是运维人员的恐慌和无眠之夜；那么这样的问题，早期是如何规避的呢？
设计一张简单的统计信息表，将这样人群用户前期筛选出来，然后放置到统计信息表中，再将此放置在前端的cache中，这样的表一定是一个小于百万数据的表，当用户查询时，首先访问的是cache中的数据，当发现查询的用户存在于该表中，路由到大卖家系统中，而这个大卖家系统就是根据单个用户最大使用单台物理机器的方法，进行服务的（当然也可根据配置规则路由到不同的物理机器上），这样普通用户的消费记录是一套通用的架构，而特殊大卖家使用的是专用服务器的定制架构。
总结：由于不同的应用系统有此特殊性和共性，作为一名数据架构师，我们不但要找到他们的共性，关键的是我们要找到他们的特殊性，将业务数据的分布特性理清楚，然后再合理规划；一但数据分布问题得以解决，后端使用什么样的数据库以及文件存储对此影响将有限，而你也会享受它们给你带来的成就感。
No comments:
Post a Comment