海量日志分析系统实践,新浪DBA.ppt

基于MySql的日志分析系统设计 ?? ??? ??? ??? ??? ??? ??? ? 有些选项是每个线程分配的，需要注意不能设置太大 innodb log buffer size不宜设置过大，如果事务量相对较大可以考虑稍微大点 mysql自身的query cache效率一般，可以采用memcached来补充 * 有些选项是每个线程分配的，需要注意不能设置太大 innodb log buffer size不宜设置过大，如果事务量相对较大可以考虑稍微大点 mysql自身的query cache效率一般，可以采用memcached来补充 * MySQL相关设置 1.增大tmp_table_size 2.增大table_cache及thread_cache的值，避免频繁建立和断开链接 3.用mysql_unbuffered_query取代mysql_query, 4.用mysql_pconnect取代mysql_connect 5.使用SQL_BIG_RESULT来提示mysql优化引擎更好的处理大数据量sql 6.使用MyISAM表可使用索引数据的预加载功能 数据节点的优化—多D点的架构 展现层向Proxy发起Query请求，Proxy将请求分发到多个DB，然后将结果合并后返回 当单个Proxy负载过高的时候，可以启用多个Proxy，展现层通过简单的取模来连接不同的Proxy 数据节点的优化—多D点的设计 启用多个D点(比如分静态池和动态池)，单独产品线的从某个D点取数据，跨产品线的时候从多个D点取数据并进行合并。测试了如下方案: 1.基于php5.3的Mysqlnd 2.Ameoba 多D点方案测试:mysqlnd 如图:mysqlnd少了从mysql驱动中复制数据到php扩展这一步。 更亮的特点是:异步获取数据的能力 多D点方案测试:mysqlnd 吸引力:除了性能上的提升,mysqlnd支持异步获取数据 困难:需要改动应用层的取数据函数，因为之前这部分代码不统一，所以需要改动不少 从测试来看，异步取多个数据库的结果时，可能会出现返回数据不正确，以及执行顺序错误等状况 (怀疑是和Apache在一起使用的问题，CLI下正常) 多D点方案测试:Amoeba Amoeba测试结果: 支持高可用性，负载均衡。 对多数据库读取的结果只是分别执行然后直接拼接 ? 高并发情况下，有时会出现到Amoeba的连接无响应 高版本下高并发的性能表现已经改善不少 数据节点的优化—结果 通过上面几个方案的测试, 架构调整选择Amoeba Proxy是目前比较合适的方案，数据切分可以通过XML灵活配置，对应用层的改动比较小，也相对比较稳定. 由于磁盘做radio0，对数据的保护不够，所以要加入备份的考虑及产品线增多后数据缓存的利用率 数据节点的优化—缓存 Memcache 客户端缓存数据 页面静态化 Php级opcode缓存 xCache 数据节点的优化—Memcache 数据点的优化—Memacahe应用 memcache有1m限制。如果列表太大,采取拆分数据，用key+特殊标识来保存整个序列。在获取的时候批量get来一次性得到这个列表。 预处理:提前生成需求数据到cache中 写库:进行数据的预处理,写入到memcache服务器中 读库 :根据时间选择应该已在cache中的数据+最近生成的数据 拼成最新数据展现 缺点:维护多个存储操作增加了应用层逻辑复杂度 优点:减少从数据库读取海量数据的问题及避免重复计算 数据节点的优化—Memache应用优化 Memcache自重启 deamon tools监控程序，让其在挂掉时重启 开启数据压缩功能 $memcachesetCompressThreshold 根据数据量大小修改slab及factor的值提高内存利用率 使用类似get_multi方法发送请求 减少客户端和服务端的通信 使用到的工具 Gearman 用于分布式节点的管理 Memcached 缓存数据 Amoeba 展示层数据库代理 Php 5.3 FACEBOOK的HIPHOP INFOBRIGHT的ICE版 对业务需求了解透彻是技术架构的基础 标准化，减少错误的发生 根据业务形态、网络情况选择适合的技术架构方案 用合适的数据库做适合的事情 以组分布,各组之间架构一致，便于横向扩展及管理 最大化减少客户端到网络端的网络延时 为系统中不同应用选择适合的硬件 根据情况选择开发环境、开发语言及工具等 总结 谢谢 优化是一项长期而艰巨的任务，不是一天两天，三言两语，一次讲座就能解决得了的。需要长期关注整个系统的表现和趋势而决定。 * * * * * 优