NoSQL基本原理及常用开源实现

NoSQL基本原理及常用开源实现培训PPT周凯二〇一四年一月二十七日课程内容•NoSQL介绍•NoSQL在系统架构中的应用•NoSQL产品介绍及对比•NoSQL安装应用演示课程内容•NoSQL介绍•NoSQL在系统架构中的应用•NoSQL产品介绍及对比•NoSQL安装应用演示NoSQL介绍NoSQL基本概念NoSQL数据库分类NoSQL是什么？•NoSQL概念在2009年被提了出来–NoSQL最常见的解释是“non-relational”，“NotOnlySQL”也被很多人接受•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推出了MySQLCluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。MySQL的扩展性瓶颈•在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。•MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。•关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。NoSQL诞生的原因•关系型数据库面临的问题–扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难；–读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重；–成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升；–有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储；•数据库访问的新需求–低延迟的读写速度：应用快速地反应能极大地提升用户的满意度；–支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量；–大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理；–庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低；NoSQL数据库的共有原则•假设失效是必然发生的–NOSQL实现都建立在硬盘、机器和网络都会失效这些假设之上。–我们不能彻底阻止这些时效，我们需要让我们的系统能够在即使非常极端的条件下也能应付这些失效。•对数据进行分区–最小化了失效带来的影响，也将读写操作的负载分布到了不同的机器上。•保存同一数据的多个副本–大部分NOSQL实现都基于数据副本的热备份来保证连续的高可用性。–一些实现提供了API，可以控制副本的复制，也就是说，当你存储一个对象的时候，你可以在对象级指定你希望保存的副本数。•查询支持–在这个方面，不同的实现有相当本质的区别。不同实现的一个共性在于哈希表中的key/value匹配。关系数据库VSNoSQL•关系数据库–表都是存储一些格式化的数据结构–每个元组字段的组成都一样–即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段–这样的结构可以便于表与表之间进行连接等操作•NoSQL–以键值对存储，它的结构不固定–每一个元组可以有不一样的字段–每个元组可以根据需要增加一些自己的键值对–不会局限于固定的结构，可以减少一些时间和空间的开销关系数据库VSNoSQL•关系数据库–分布式关系型数据库中强调的ACID分别是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。–ACID的目的就是通过事务支持，保证数据的完整性和正确性•NoSQL–对于许多互联网应用来说，对于一致性要求可以降低，而可用性(Availability)的要求则更为明显，从而产生了弱一致性的理论BASE。–BASE分别是英文：Basically，Available，Soft-state，EventualConsistency的缩写，这个模型是反ACID模型。NoSQL和关系数据库•NoSQL数据库仅仅是关系数据库在某些方面（性能、扩展）的一个弥补–单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足。–一般会把NoSQL和关系数据库进行结合使用，各取所长，各得其所。•在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等–用NoSQL完全可以替代关系数据库(如：MySQL)存储。不但具有更高的性能，而且开发也更加方便NoSQL的优缺点•优点–简单的扩展典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群；–快速的读写主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作；–低廉的成本这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本；•不足–不提供对SQL的支持如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本；–支持的特性不够丰富现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MSSQLServer和Oracle那样能提供各种附加功能，比如BI和报表等；–现有产品的不够成熟大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语；总结•NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。•MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。NoSQL介绍NoSQL基本概念NoSQL数据库分类按CAP分类•一致性（Consistency）–任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的；•可用性（Availability）–每一个操作总是能够在确定的时间内返回，也就是系统随时都是可用的。•分区容忍性（PartitionTolerance）–在出现网络分区（比如断网）的情况下，分离的系统也能正常运行。一个分布式系统不能同时满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。CAP理论标题关注一致性和可用性的(CA)•这些数据库对于分区容忍性方面比较不感冒，主要采用复制（Replication）这种方式来保证数据的安全性，常见的CA系统有：–传统关系型数据库，比如Postgres和MySQL等(Relational)–Vertica(Column-oriented)–AsterData(Relational)–Greenplum(Relational)按CAP分类关注一致性和分区容忍性的(CP)•这种系统将数据分布在多个网络分区的节点上，并保证这些数据的一致性，但是对于可用性的支持方面有问题，比如当集群出现问题的话，节点有可能因无法确保数据是一致性的而拒绝提供服务，主要的CP系统有：–BigTable(Column-oriented)–Hypertable(Column-oriented)–HBase(Column-oriented)–MongoDB(Document)–Terrastore(Document)–Redis(Key-value)–Scalaris(Key-value)–MemcacheDB(Key-value)–BerkeleyDB(Key-value)按CAP分类关于可用性和分区容忍性的(AP)•这类系统主要以实现“最终一致性（EventualConsistency）”来确保可用性和分区容忍性，AP的系统有：–Dynamo(Key-value)–Voldemort(Key-value)–TokyoCabinet(Key-value)–KAI(Key-value)–Cassandra(Column-oriented)–CouchDB(Document-oriented)–SimpleDB(Document-oriented)–Riak(Document-oriented)按CAP分类按数据模型分类NoSQL-三种主流的数据模型•Column-oriented（列式）–主要围绕着“列（Column）”，而非“行（Row）”进行数据存储–属于同一列的数据会尽可能地存储在硬盘同一个页（Page）中–大多数列式数据库都支持