大并发大数量中的MYSQL瓶颈与NOSQL介绍

NoSQL在2010年风生水起,大大小小的Web站点在追求高性能高可靠性方面,不由自主都选择了NoSQL技术作为优先考虑的方面。今年伊始,InfoQ中文站有幸邀请到凤凰网的孙立先生,为大家分享他之于NoSQL方面的经验和体会。



非 常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏,InfoQ是我非常尊重的一家技术媒体,同时我也希望借助InfoQ,在国内推动NoSQL 的发展,希望跟我一样有兴趣的朋友加入进来。这次的NoSQL专栏系列将先整体介绍NoSQL,然后介绍如何把NoSQL运用到自己的项目中合适的场景 中,还会适当地分析一些成功案例,希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念

随着web2.0的快速发展,非关系型、分布式数据存储得到了快速的发展,它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”,“Not Only SQL”也被很多人接受。(“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。)

NoSQL被我们用得最多的当数key-value存储,当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前,这些数据库就被用于各种系统当中,但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能,高稳定型,久经历史考验,而且使用简单,功能强大,同时也积累了大量的成功案例。在互联网领域,MySQL成为了绝对靠前的王者,毫不夸张的说,MySQL为互联网的发展做出了卓越的贡献。

在90年代,一个网站的访问量一般都不大,用单个数据库完全可以轻松应付。在那个时候,更多的都是静态网页,动态交互类型的网站不多。

到了最近10年,网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期,论坛的流量其实也不大,如果你接触网络比较早,你可能还记得那个时候还有文本型存储的论坛程序,可以想象一般的论坛的流量有多大。

Memcached+MySQL

后 来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能。程序员 们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多 台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力。在这个时候,Memcached就自然的成为一个非常时尚的技术产品。

Memcached 作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行 多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时,如果你 去面试,你说你有Memcached经验,肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库

随 着web2.0的继续高速发展,在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这时MySQL主库的写压力开始出现瓶颈, 而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。 同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就 在这个时候,MySQL推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群,但是由于在互联网几乎没有成功案例,性能也不能满足互联网的要求,只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在 互联网,大部分的MySQL都应该是IO密集型的,事实上,如果你的MySQL是个CPU密集型的话,那么很可能你的MySQL设计得有性能问题,需要优 化了。大数据量高并发环境下的MySQL应用开发越来越复杂,也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大 的公司开发了透明的中间件层来屏蔽开发者的复杂性,但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更,可能又 需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小,如果能把这些数据从MySQL省去,MySQL将变得非常的小。

关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现),大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势

易扩展

NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。

大数据量,高性能

NoSQL 数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的 Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用

NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。

总结

NoSQL数据库的出现,弥补了关系数据(比如MySQL)在某些方面的不足,在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上,NoSQL关注在存储上。

大并发大数量中的MYSQL瓶颈与NOSQL介绍

时间: 2024-08-05 07:08:40

大并发大数量中的MYSQL瓶颈与NOSQL介绍的相关文章

大并发大数据量请求的处理方法

大并发大数据量请求一般会分为几种情况: 1.大量的用户同时对系统的不同功能页面进行查找,更新操作 2.大量的用户同时对系统的同一个页面,同一个表的大数据量进行查询操作 3.大量的用户同时对系统的同一个页面,同一个表进行更新操作 对于第一种情况一般处理方法如下: 一.对服务器层面的处理 1. 调整IIS 7应用程序池队列长度 由原来的默认1000改为65535. IIS Manager > ApplicationPools > Advanced Settings Queue Length : 6

php 处理 大并发

小谈php处理 大并发 大流量 大存储 一.判断大型网站的标准: 1.pv(page views)网页的浏览量: 概念:一个网站所有的页面,在24小时内被访问的总的次数.千万级别,百万级别 2. uv值(unique visitor)独立访客 概念:一个网站,在24小时内,有多少个用户来访问我们的网站,达到10万 3. 独立ip 重点内容 概念:一个网站,在24小时内,有多少个ip来访问我们的网站. uv值约等于独立ip如果要考虑局域网,uv值略大于独立ip 二 大型网站带来的一些问题 1 大的

Slave延迟很大的优化方法总结(MySQL优化)

[http://www.cstor.cn/textdetail_9146.html] 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发.简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master ORACLE MySQL 5.6版本开始支持多线程复制,配置选项 slave_parallel_wor

大并发服务器框架设计

简单谈一谈大并发服务器框架设计的基本思路 基本的服务器框架都是C/S结构的,请求和相应流程是这样的: 这样的框架存在一个很严重的问题,当客户端大并发请求到来,服务器需要进行大量的数据库操作,假设数据库最大连接数为 1000个,此时有10000个请求访问应用服务器,那么应用服务器只能处理1000个请求,剩下99000个等待1000个请求处理好后 再进行访问数据库处理.可以在应用服务器和数据库服务器中间增加中间层DAL,DAL采用缓冲队列和连接池设计. DAL设计缓冲队列,存储等待的请求,并且DAL

大并发server架构 && 大型站点架构演变

server的三条要求: 高性能:对于大量请求,及时高速的响应 高可用:7*24 不间断,出现问题自己主动转移.这叫fail over(故障转移) 伸缩性:使用跨机器的通信(TCP) 另外不论什么网络系统结构都能够抽象成C/S架构.我们常说的B/S模式本质上也是C/S架构(浏览器看作client). 一个典型的server架构: 注: epoll是linux下最高效的网络I/O 因为server须要高效处理大并发连接.因此多个位置均可能出现性能瓶颈,以下我们分析不同位置产生瓶颈的原因及其处理方法

高性能大并发server的基础

一.背景 进入多核时代已经很久了,大数据概念也吵得沸沸扬扬,不管你喜欢不喜欢,不管你遇到没遇到,big-data或bigger-data都必须正视. 处理大数据,基本都离不开分布式计算和分布式存储,这其中以hadoop最为使用广泛和经典. 分布式系统,就离不开计算系统.网络系统.文件系统和数据库系统. 这么多系统,之间又是如何协作的呢? 通讯过程又是如何保障高性能的呢? 1.单处理器 在以前的单核心cpu下,我们要实现文件I/O.网络I/O,可以妥妥的使用单线程循环处理任务. 但是如果想"同时&

常规问题总结之大并发

大并发写入案例:抢红包,微博.高并发,大数量写数据,会把数据先写到内存,积累一定的量后,然后再定时或定量的写到磁盘(减少磁盘IO<Ioput/Output>)最终还是会把数据加载到内存中再对外提供访问.特点:优:写数据到内存,性能搞.速度快(微博,NS,秒杀)却:可能会丢失一部分在内存中还没有来得及存入磁盘的数据解决数据不丢失的方法:1.服务器主板上安装蓄电池,在断电瞬间把内存数据写到磁盘2.安装UPS(一组蓄电池),不间断供电(持续10min,IDC数据UPS 1h)3.选择双电路机房.使用

论 大并发 下的 乐观锁定 Redis锁定 和 新时代事务

在 <企业应用架构模式> 中 提到了 乐观锁定, 用 时间戳 来 判定 交易 是否有效, 避免 传统事务 的 表锁定 造成 的 瓶颈 . 在 现在的 大并发 的 大环境下, 传统事务 及其 表锁定 以及 事务带来 的 性能消耗, 确实 不能适应 当今 的 大并发 的 场景 了 . 感觉 传统事务 也就只能用在 办公系统 了,   哈哈哈哈 . 但是 传统事务 的 表锁定 是 合理的, 表锁定 使得 事务中 其它 线程 不能 读写 表 . 不能 写, 这个容易理解, 不能 读 是怎么回事 ? 因

处理大并发量订单处理的 KafKa部署总结

处理大并发量订单处理的 KafKa部署总结 今天要介绍的是消息中间件KafKa,应该说是一个很牛的中间件吧,背靠Apache 与很多有名的中间件搭配起来用效果更好哦 ,为什么不用RabbitMQ,因为公司需要它. 网上已经有很多怎么用和用到哪的内容,但结果很多人都倒在了入门第一步 环境都搭不起来,可谓是从了解到放弃,所以在此特记录如何在linux环境搭建,windows中配置一样,只是启动运行bat文件. 想要用它就先必须了解它能做什么及能做到什么程度,先看看它是什么吧. 当今社会各种应用系统诸