您现在的位置:首页
--> Sky.Jian 朝阳的天空
在过往与很多人的交流过程中发现,在谈到基于硬件来进行数据库性能瓶颈分析的时候,常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备。个人觉得这其中可能存在一个非常大的误区。我们在谈论基于硬件进行优化的时候,不能仅仅将数据库使用的硬件划分为主机和存储两部分,而是需要进一步对硬件进行更细的分解,至少也应该分解到如下范畴: 主机 CPU:仅仅只能决定运算速度,及时是运算速度都还取决于与内存之间的总线带宽以及内存本身的速度内存:大小决定了所能缓存的数据量,主要决定了热点数据的访问速度磁盘: 大小:决定了你最终能存放多少数据量转速:决定了你每一次IO请求的延时时间,也就是决定了我们常说的IOPS和MBPS 数目:磁盘数目决定了类型
这篇文章是以 MySQL 为背景,很多内容同时适用于其他关系型数据库,需要有一些索引知识为基础 优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。降低 CPU 计算除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的
大家都知道索引对于数据访问的性能有非常关键的作用,都知道索引可以提高数据访问效率。为什么索引能提高数据访问性能?他会不会有“副作用”?是不是索引创建越多,性能就越好?到底该如何设计索引,才能最大限度的发挥其效能?这篇文章主要是带着上面这几个问题来做一个简要的分析,同时排除了业务...
在当前这个信息量飞速增长的时代,一个企业,尤其是电子商务企业的成功已经越来越多地与其海量数据处理能力相关联。高效、迅速地从海量数据中挖掘出潜在价值并转化为决策依据的能力,将成为企业的核心竞争力。数据的重要性毋庸置疑,但随着数据的产生速度越来越快,数据量越来越大,数据处理技术的挑战自然也越来越大。如何从海量数据中挖掘出价值所...
在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题,所以最近打算写一个MySQL数据库性能优化方面的系列文章,希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。这是本系列的第一篇文章:MySQL 数据库性能优化之缓存参数优化数据库属于 IO 密集型的应用程序,其主要职责就是数据的管理及存储工作。而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在...
这是 MySQL数据库性能优化专题 系列的第二篇文章:MySQL 数据库性能优化之表结构很多人都将 数据库设计范式 作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求。殊不知,在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优...
自上次 对 myperf 作了一个基本的介绍 之后,反响不错,就准备再针对 myperf 的 3 个模式分别说明一下。之前已经说明,myperf 有三个mode(功能模式),分别为: top, snap, report。第一个mode比较独立,后2个mode相辅相成。今天这里就先介绍一下 myperf 的第一个mode:“top” 。简单来说,“top” mode其实就是一个类似于我们 Linux/Unix 下最常使用的基本的性能查看程序 top 一样,实时刷新展示数据库当前的一些比较重要的性...
数据库 Sharding 目前已经是数据层架构的家常便饭了,随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力,Sharding 本身所带来的各种弊端也开始不断的显露出来了。最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流,记录之: 急于 Sharding,分区键考虑不充分,影响业务发展 Sharding 本身是一个需要慎重对待的事情,尤其是分区键的选择。好的分区键会让整个系统基本上对应用没有影响,但是如果选择了一...
随着数据存储技术的迅猛发展,随着各种 NoSQL 技术的产生,无论是我们同事之间还是整个互联网行业,都出现关于“分布式 数据 存储/处理 解决方案”方面的选择分歧。就我目前所了解到的主流意见主要有以下三种: 去关系型,NoSQL是王道 NoSQL靠边站,关系型才是王道以关系型为核心,NoSQL为补充 三种意见中前面两种观点较为极端,都是“非对即错”的选择,当然也有更为理性的第三种方案。如果作为开发人员,从我目前所了解的信...
最近一直在测试一款让我非常兴奋的存储介质: Fusion IO 的 ioDrive。他在随机小IO的方面的表现,实在是让我吃惊,可以轻松达到100k左右的单一读(或者写)(注意是写也可以达到这个数据) IOPS,读写混合也可以达到 50k~60k左右的IOPS,而且这个 IOPS 数据还是在响应时间低于5ms 的情况下的数据。而实际上,当 IOPS 达到50k 的时候,响应时间仍然低于1ms。注:测试工具为 orion/fio/iometer 100K 的 IOPS 是一个什么概念?假如...
关系型数据库60周年特刊随着信息量飞涨,信息的存储成为了这个时代至关重要的一项技术。如何来保证数据存储技术能够适应信息量的增长速度和我们对信息的高度依赖,成为一个非常重要的课题。本文将从数据库架构的层面,通过以开源的数据存储软件来构建分布式数据层的思路,期望实现一个低成本的高可用可扩展的数据层架构。传统数据库架构纵观各传统商业数据库软件,多以集中式架构为主,鲜有以分...
为了对核心技术拥有更多的自主控制能力,为了解决数据库的线性扩展问题,为了尽量减少对商业软件的依赖,为了摆脱对高端硬件的依赖,为了… 基于以上多种原因,2年前,我们计划将公司某核心应用平台进行大手术:数据库平台从软件到硬件全部重构。当然,这其中应用架构的改造也不可避免的进行了大换血。这个项目无论是从技术角度还是是业务角度来说,都对我们有着非常大的价值,也必定会带来非常深远的影响。项目历时2年多,...
最近经常有人问我 MySQL Query Cache 相关的问题,就整理一点 MySQL Query Cache 的内容,以供参考。顾名思义,MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说,Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲,就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。在大部分的 MySQL 分发版本中,Query Cache 功能默认都是打开的,我们...
[ 共13篇文章 ][ 第1页/共1页 ][ 1 ]
近3天十大热文
- [70] Twitter/微博客的学习摘要
- [67] IOS安全–浅谈关于IOS加固的几种方法
- [64] 如何拿下简短的域名
- [63] find命令的一点注意事项
- [63] android 开发入门
- [62] Go Reflect 性能
- [61] 流程管理与用户研究
- [59] Oracle MTS模式下 进程地址与会话信
- [58] 图书馆的世界纪录
- [57] 读书笔记-壹百度:百度十年千倍的29条法则
赞助商广告