架构设计 - 大数据 - 性能优化篇

前言

什么是大数据？

大数据(big data)，或称巨量资料，指的是所涉及的资料量规模巨大到无法透过主流软件工具，在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。

在日常生活中，大数据的提现为
单表构成业务数据库，且数据量很大，导致查询速度很慢。
多表或跨库表的数据结合构成业务数据库，业务使用时，需要去多表或跨库表中多次查询或是查询后要做二次算法处理才可使用的数据，导致查询速度慢。

基于单表构成的业务数据库，本文不做讨论，优化方案无外乎分库分表，加查询缓存，或将数据备份至es进行查询，达到性能优化的目的。

本文讨论内容：多表或跨库表的数据结合构成业务数据库，业务使用时，需要去多表或跨库表中多次查询或是查询后要做二次算法处理才可使用的数据，如何优化起使用体验。

讨论内容

1、对用户C端，怎样才是一个好的体验？
这个命题对不同的客户有不同的结果。但至少要满足的点有：

响应速度要快
不能让用户打开一个网页耗时30s或是更久的时间才能打开吧，这样给用户的感受不好，一般来说，响应时间越短越好，如果能在1s内响应就更好了。

使用流畅
让用户使用起来感觉很舒服。牵涉的内容主要在 功能设计 和 界面展现 上。
好的 功能设计 一进入页面就能让用户知道我在这个页面上可以做什么，我想做的内容该如何去做。
好的 页面设计 在用户使用时感受特别的丝滑，如ios系统在使用时应用的切换和使用就特别的丝滑。

基于以上两点，我们来说说优化方案
增强响应速度
一次业务查询牵涉多个表甚至跨库查询，有想法的同学可能会想到left join 和 子查询。 跨库查询是根据一个表的结果集计算结果作为另一个库的查询条件。 看着比较复杂，实际使用中对数据库的压力也很大。

以left join 为例，关联了n个表(n>=2)，n个表中n越大，查询效率越低。
以跨库表为例，第一次查询结果集越大，那么后端程序就需要开辟相应的内存大小来存储结果，还要包含后面的计算要消耗的cpu，以及第二次在跨库表中的查询，两次数据库的连接资源消耗等。

其实如上，本质就是业务复杂度较高的业务，有效数据的获取要通过一系列的表去获取，且中途可能需要二次计算。

那么如何来优化呢？

分析业务点，我们的业务是否一定要实时从业务数据库（多表或跨库查询或可能的二次计算的数据集）中获取，能否做缓存？如果不能做缓存，那么怎么样来优化？特殊情况，既不做缓存，也不做队列？

1、根据业务分析，可以做缓存操作。
后台启动一个守护进程，此进程永不结束，进程的工作内容位，一直实时统计业务数据库的数据，将产生的有效数据放入缓存或是一个设计好的新表里面。 然后业务上就直接从缓存中获取或是从新表里面获取数据。

有朋友会问：如果守护进程之前统计了某条数据，但之后这条数据发生了变化，那么如果使更新的这条数据重新走一次统计呢？
答案：热更新技术 + 事件机制，当某个数据发生变化时，抛出数据变更事件，由守护进程所属服务来处理这条更新的数据（建议任务处理采用队列消息，因为有的数据统计比较耗时，当数据更新发生变化时，为了更好的体验，我们直接给用户反馈操作成功，而数据统计更新则在后台交给队列处理）。不明白事件机制的原理的朋友 参考这篇文章 事件机制

2、如果不能做缓存，那么怎么样来优化？
队列消息机制处理，将用户的查询操作封装成一个任务（队列任务），这个任务含有的属性有：进度（0%~100%）便于用户实时查看统计进度。状态（未开始，进行中，已完成，已失败）、sql操作日志，查询结果集等（还有其它属性设计，这里只列举关键的四个）。我们将查询步骤拆开，每完成一次查询，更新一次进度，便于用户查看任务进度。当完成任务后，会触发消息机制，给用户推送一条消息（微信公众号、短信、邮箱、站内信息均可）告知用户已处理完成，可随时检阅。

3、特殊情况，既不做缓存，也不做队列
某些特定场景下，既不能做缓存，也没有做队列。必须要给用户C实时反馈。怎么办？以下解决方案可同时兼容1，2。 请参阅
给数据库表加字段索引，如联合索引，hash索引，fulltext索引等。 如果表只做简单的CURD 操作，未涉及需要事务支持的操作，建议使用存储引擎 myisam 。关于数据库的优化，参见文章，数据库优化

以上，就是自己整理归纳的关于大数据性能优化篇的方案，欢迎大家反馈讨论。