search 2013 adfgs

在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题,所以最近打算写一个MySQL数据库性能优化方面的系列文章,希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。 这是 MySQL数据库性能优化专题 系列的第一篇文章:MySQL 数据库性能优化之缓存参数优化 数据库属于 IO 密集型的应用程序,其主要职责就是数据的管理及存储工作。而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级。所以,要优化数据库,首先第一步需要优化的就是 IO,尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化: query_cache_size/query_cache_type (global) Query cache 作用于整个 MySQL Instance,主要用来缓存 MySQL 中的 ResultSet,也就是一条SQL语句执行的结果集,所以仅仅只能针对select语句。当我们打开了 Query Cache 功能,MySQL在接受到一条select语句的请求后,如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cache,或者已经显式申明需要使用Query Cache),MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash,然后到Query Cache 中直接查找是否已经缓存。也就是说,如果已经在缓存中,该select请求就会直接将数据返回,从而省略了后面所有的步骤(如 SQL语句的解析,优化器优化以及向存储引擎请求数据等),极大的提高性能。 当然,Query Cache 也有一个致命的缺陷,那就是当某个表的数据有任何任何变化,都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以,当我们的数据变化非常频繁的情况下,使用Query Cache 可能会得不偿失。 Query Cache的使用需要多个参数配合,其中最为关键的是 query_cache_size 和 query_cache_type ,前者设置用于缓存 ResultSet 的内存大小,后者设置在何场景下使用 Query Cache。在以往的经验来看,如果不是用来缓存基本不变的数据的MySQL数据库,query_cache_size 一般 […]

, ,

上周受邀于 IT168,在 2012年度的 DTCC 大会上做了一个小的主题分享,内容主要是最近几年在 MySQL 数据库的性能调优过程中积累的一点点经验总结,希望能对大家有用。 其中部分内容在之前的 第二届华东地区数据库大会 上已经有过分享,这次是在当时分享内容的基础上增加了硬件和系统层面的内容,同时根据听众反馈对原有内容进行了部分优化改进。 以下就是这次分享的 PPT 内容(有更新): MySQL性能调优最佳实践 View more presentations from Sky Jian

, ,

这个月11号应 蝎子 同学和 ThinkInLamp 的邀请,在上海光大会展中心参加了由 ThinkInLamp 社区组织的 第二届华东地区数据库大会,并做了一个题为“浅谈MySQL数据库优化”的主题分享交流。 考虑到参会人员大多是一线的技术工程师,而且还有很多是开发人员,所以内容更偏重于一些指导性的原则,会后将 PPT 格式稍作了调整,这里再发出来希望对感兴趣的朋友有所帮助。 浅谈 MySQL 性能调优 View more presentations from Sky Jian

,

这是之前发布于《程序员》杂志2011年08期的一篇文章,这里再在Blog上发布一下。 在当前这个信息量飞速增长的时代,一个企业,尤其是电子商务企业的成功已经越来越多地与其海量数据处理能力相关联。高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力,将成为企业的核心竞争力。 数据的重要性毋庸置疑,但随着数据的产生速度越来越快,数据量越来越大,数据处理技术的挑战自然也越来越大。如何从海量数据中挖掘出价值所在,分析出深层含义,进而转化为可操作的信息,已经成为各互联网企业尤其是电子商务公司不得不研究的课题。本文将介绍国内箱包行业电子商务领军者麦包包如何利用海量数据的分析处理(个性化推荐引擎)来协助用户更好地完成购买体验。 图1 数据层基础架构 数据层基础架构 如图1所示,麦包包的数据层基础架构与其他很多互联网公司相比,可能会有一点儿差异,那就是有一个用于实时分析处理的在线分析数据层,用来处理一些对实时性要求较高的分析任务。 总的来说,麦包包的数据层分为下面三个部分。 在线交易数据层 用于存放网站对外访问数据,如交易相关、产品相关、用户相关等数据。 离线分析数据层 用于分析各种报表、数据挖掘,如购买行为、销售分析、浏览跟踪等。 在线分析数据层 用于处理一些对实时性要求较高的分析,如在线交易分析、用户浏览推荐等。在线交易数据层和离线分析数据层对于大家来说都已经比较熟悉了,二者的数据特点和访问特点都很清晰明确,架构方向也相对明确。只有在线分析系统比较特别,既有高并发的用户访问,同时又兼具了分析型复杂查询及海量的基础数据,构建起来相对要复杂一些。所以下面简单介绍一下麦包包如何构建在线分析系统的应用之一——“个性化推荐引擎”。 个性化推荐引擎 我们首先分析一下这个推荐引擎的需求。 关联个性化 根据用户的喜好倾向以及访问历史记录,不同用户浏览同一个产品时,将给出不同的关联推荐结果。 页面个性化 不同用户访问同一个页面,我们将会根据用户的以往购买历史及浏览行为而展示个性化的内容。 搜索个性化 随着用户的多次搜索及结果点击行为,我们会对搜索结果进行过滤重组,尽可能展示更符合用户需求的搜索结果。也就是说,在完全相同的基础数据中,不同用户在同一时间搜索同一个关键词,可能会给出不一样的结果;或者同一个用户重复多次搜索同一个关键词,也可能会有不一样的结果。 我们再来看一看推荐引擎的数据特点。 海量 超过500万会员,5位数的SKU,7位数的访问量。将这些数据与会员及SKU的各类属性相互关联,数据量之庞大可想而知。 多维度 从性能优化角度来说,数据量大并不可怕,只要访问方式简单,很容易通过索引等手段进行优化。可偏偏不幸的是,由于将用户和产品进行多维度关联,既需要根据用户去分析,又需要根据产品去关联,再辅以运行时的各类属性;既可能各个维度同时存在,也可能只有任何一个维度;多维度就多维度吧,可还有很多访问是分析型,比较难以优化扩展。 访问高并发 当然,数据量大也并不一定就可怕,如果并发访问较小,响应时间要求不是太高,那也容易解决,可以用Hadoop之类的分布式系统来分析计算。可恰恰不巧的就是这个系统面对的是网站上的访问客户,对并发及响应时间的要求和OLTP系统一样。 需求已经确定,数据特点也已了解,下一步就是根据数据的特点,设计一个切实可行的架构来实现这些应用需求了。 在如此海量数据中进行高并发的复杂分析查询,还要能够快速响应,看上去就像是一个不可能的任务。但仔细分析之后,我们不难发现,推荐引擎结果主要由以下几个因素决定。 用户固定属性:年龄、性别、职业类型、地域、价格承受范围、色彩喜好、品牌喜好等。 产品固定属性:品牌、类别、材质、价格、色系等。 用户以往行为:浏览历史、购买历史等。 用户当前行为:当前点击、浏览等。 以上四个因素实际上对应了四种数据,在分析每一种数据的特点之后,可以发现前面三个因素所对应的数据都是相对静态的,只有用户当前行为才是一个在不断变化的动态数据。也就是说,在海量数据中,只有少部分数据是动态的,其他大部分都是静态。 当然,用户属性中的各种喜好,也需要我们通过用户以往的历史购买以及浏览行为进行各种分析挖掘才能获得,但这都是由历史积淀数据分析得来,而不是由当前的运行时动态数据决定。价格承受范围以及地域特性也同样如此。 数据的这一特性对我们的架构设计起到了一个非常关键的作用,因为我们可以使用完全不同的方式来将静态数据和动态数据分开处理,再合并分析。静态数据的变化较小,实时性要求较低,我们将进行离线分析;动态数据相对较少,但实时性要求较高,我们在线实时处理。动、静数据在线合并分析。这样一来,我们就可以很轻松地绕过海量数据的高并发在线分析的问题,将这一动作交由离线分析系统定时作业批量完成,既不会有高并发问题,又不存在响应时间的压力。至于在线实时数据的处理,由于数据量的大幅缩减,以及访问方式的简化,比在线交易的OLTP系统复杂度高不了太多,自然也就容易优化了。 图2 推荐引擎基本架构 架构设计 简单来说,推荐引擎系统本身的基础架构就如图2所展现的一样,一部分数据进行离线计算,另一部分数据在线计算合并,最终通过推荐引擎API将数据处理后返回给前端应用。 看上去简单,但有几个问题并没有展现出来,那就是离线计算和在线计算这两部分具体是如何构建的?数据如何进入离线计算系统?又如何将离线运算结果回送至在线计算系统中?最终数据又如何交由前端应用使用?让我们再来看看图3。 离线分析层完全可以通过成熟的产品来构建,如Greenplum、Hadoop等,目前我们已经使用了Greeplum,后续很快还会引入Hadoop,通过HBase + Hive来对处理我们的用户与各SKU的关系数据,帮助进一步完善我们的协同过滤算法,进而优化推荐引擎。在线合并分析层我们选择MySQL数据库。可能有些人会问,为什么不使用当前如此流行的NoSQL产品呢?主要原因有以下两点。 MySQL更便于维护与备份等运维需求。 NoSQL不满足我们的一些分析型查询需求。 NoSQL产品虽然流行,但每种产品都还只适于某些特定的应用场景,很多听上去完美的理论目前暂时还仅仅只是听上去完美,实际用起来仍然存在各种各样的问题。所以我们选择了更适合于我们的MySQL作为在线合并分析层的数据库。 图3 推荐引擎整体架构 整个架构的数据流,如图3所示。 前端应用产生用户的浏览日志、购买日志、搜索日志以及用户及产品属性数据进入。 通过文件日志收集程序以及基于MySQL开放复制协议所定制的数据同步工具(注:在我的个人网站上有介绍:http://isky000.com/database/mysql-replication-extend)将数据同步至离线分析系统中。 通过离线任务的统计分析,得出会员的各种喜好属性,并将之与产品属性进行关联分析,得出一个用户产品倾向性关联结果,然后再通过应用程序定期从离线分析系统将上述分析结果写入在线合并分析数据库中。 […]

, ,

最近看到一个比较全面的MySQL优化的PPT,不敢独享,特放上来与大家分享。 注:版权所有: Yoshinori Matsunobu Linux and H/W optimizations for MySQL View more presentations from Yoshinori Matsunobu

, ,