数据库概览与选择

ls0398

1 数据库市场介绍
　　DB-Engines 发布的2017 年 2月份的数据库排名前10的数据库如下，其中商业数据库4个，开源6个，关系型数据库7个，非关系型3个

http://images2015.cnblogs.com/blog/713443/201703/713443-20170321192902190-317210504.png

2 如何选择数据库
　　A、看应用场景  —  OLTP/OLAP
　　　　OLTP（联机事务处理）
　　事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量 。
　　典型应用：电子商务系统、银行、证券等，如eBay的业务数据库，就是很典型的OLTP数据库
　　　　OLAP（联机分析处理）
　　有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
　　典型应用：大数据分析。
　　B、看应用场景  —  SQL / NoSQL
　　http://images2015.cnblogs.com/blog/713443/201703/713443-20170321193749111-1473871673.png
　　NoSQL与SQL的区别
　　优点：高并发读写、海量数据存储、高可扩展性、高可用性
　　缺点：缺乏事务一致性、缺乏读写实时性、不支持复杂查询
　　NoSQL数据库类型
　　Key-value:通常用hash table来实现
　　列式数据库：同一列数据存在一起
　　文档型数据库：Key-Value对应的键值对，Value为结构化数据产品：MongoDB
　　图结构数据库：以“图”为基本存储模型，产品：Neo4j，InfoGrid，InfiniteGraph
　　C、看数据模型
　　　　关系数据库
　　数据模型：各种关系
　　例子：Oracle、Mysql
　　优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好
　　
　　网格数据库（支持网格的数据库）
　　数据模型：基于空间的架构
　　例子：GigaSpaces, Coherence
　　优点：适于事务处理的高性能和高扩展性
　　　　对象数据库
　　数据模型：对象
　　例子：Objectivity, Gemstone
　　优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点
　　　　文档数据库
　　数据模型：包含了key-value的文档集合 ,
　　面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。
　　每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。
　　数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。
　　　　产品：MongoDB、CouchDB、RavenDB
　　　　有谁在使用：SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）
　　　　1. 适用的场景
　　　　1） 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
　　　　2） 分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
　　　　2. 不适用场景
　　　　在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
　　　　图数据库
　　数据模型：节点和关系，也可处理键值对
　　图形数据库是NoSQL数据库的一种类型，它应用图形理论存储实体之间的关系信息。
　　最常见的例子，就是社会网络中人与人之间的关系。关系型数据库用于存储关系型数据的效果并不好，
　　其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷。
　　　　产品：Neo4J、Infinite Graph、OrientDB
　　　　有谁在使用：Adobe （Neo4J）、Cisco （Neo4J）、T-Mobile （Neo4J）、Twitter（FlockDB）、美国国防部和中情局（InfiniteGraph）
　　　　1. 适用的场景
　　　　1） 在一些关系性强的数据中
　　　　2） 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定
　　　　2. 不适用场景
　　　　不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。
　　　　Key-Value数据库
　　数据模型：键值对
　　键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。
　　　　产品：Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort
　　　　有谁在使用：GitHub （Riak）、BestBuy （Riak）、Twitter （Redis和Memcached）、StackOverFlow （Redis）、 Instagram （Redis）、Youtube （Memcached）、Wikipedia（Memcached）
　　　　1. 适用的场景
　　　　储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。
　　　　2. 不适用场景
　　　　1） 取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。
　　　　2） 需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
　　　　3） 事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
　　　　BigTable类型数据库(列式数据库)
　　数据模型：列簇，每一行在理论上都是不同的  
　　列存储数据库将数据储存在列族（column family）中，一个列族存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，
　　我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另一个列族中。
　　　　产品：Cassandra、Hbase
　　　　有谁在使用：Ebay （Cassandra）、Instagram （Cassandra）、NASA （Cassandra）、Twitter （Cassandra and HBase）、Facebook （HBase）、Yahoo!（HBase）
　　　　1. 适用的场景
　　　　1） 日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。
　　　　2） 博客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。
　　　　2. 不适用场景
　　　　1） 如果我们需要ACID事务。Vassandra就不支持事务。
　　　　2） 原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。
    　　在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
　　D、看成本（商业 VS 开源）
　　商业数据库：付费使用，功能更强大一点，支持好，维护成本相对低一点
开源数据库：免费使用，功能有所牺牲，维护支持的成本相对高一点
　　数据库参数对比
　　http://images2015.cnblogs.com/blog/713443/201703/713443-20170321195143080-2083210911.png
3 常见的数据库
　　A、Oracle
　　　　基本情况：Oracle前身叫SDL，由Larry Ellison和另两个编程人员在1977年创办，Oracle公司是最早开发关系型数据库的厂商之一，目前是数据库市场占有率第一的厂商。
　　优点：牛逼公司的牛逼产品，几十年技术积累，可靠、安全、性能高 ……
　　缺点：对硬件的要求很高，价格比较昂贵，管理维护麻烦，操作复杂，需要技术含量较高
　　适用场景：各行各业都有应用，全球500强中有三分之二的企业使用Oracle
　　B、Mysql
　　　　基本情况：开源、传统关系型数据库、快速的、多线程、多用户和健壮的SQL数据库服务器，瑞典的MYSQL AB公司开发，2008年被Sun公司收购，2010年Oracle公司以74亿美元收购了Sun公司
　　特点：优秀的开源产品，成熟，门槛低，有丰富的资料可以查阅，体积小，开放源码，可运行在Windows平台和大多数的Linux平台上，快速，轻量级，易于扩展，免费，跨平台
　　适用场景：广泛的应用在Internet上的中小型网站中
     LAMP（Linux+Apache+Mysql+Php）
　　C、Microsoft SQL Server
　　　　基本情况：微软开发的大型关系型数据库，1987年，微软与IBM合作开发完成OS/2，IBM在其销售的OS/2 Extended Edition系统中绑定了OS/2 Database Manager,而微软产品线尚缺数据库产品，于是，微软将目光投向Sybase，同Sybase签订了合作协议，使用Sybase技术开发基于OS/2系统的关系型数据库，1989年年，微软发不了SQL Server 1.0版。后来，微软与Sybase分道扬镳后，在其6.05和7.0版本中重写了核心数据库系统。
　　优点：牛逼公司的产品，安全性和可用性高，性能快……
　　缺点：只能在微软的Windows平台运行，开放性差……
　　适用场景：主机操作系统为Windows，主要用于web网站的建设，承载中小型web后台数据
　　D、MongoDB
　　　　基本情况：MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的 。2007年10月，MongoDB由10gen团队发展，2009年首度推出；2012年5月，MongoDB 2.1开发分支发布，该版本采用了全新架构；目前，已经发展到3.4版了。
　　优点：NoSQL数据库的优点，高扩展性等…
　　缺点：NoSQL数据库的缺点，不支持复杂查询
　　适用场景：适合存大尺寸、低价值的数据，高伸缩性的场景，不适合高度事务性的系统，如银行或会计系统等
　　E、Redis
　　　　基本情况：2008年，意大利一家创业公司Merzia推出一款基于MySQL的网站实时统计系统LLOOGG，然而产品上线没多久，该公司的创始人Salvatore Sanfilippo就对MySQL的性能非常不满意，于是亲自操刀开发一款为LLOOGG量身定制的数据库，也就是Redis的雏形。LLOOGG.com是一个访客信息追踪网站，网站可以通过 JavaScript 脚本，将访客的 IP 地址，所属国家，浏览器信息，被访问页面的地址等数据传送给LLOOGG.com。然后LLOOGG.com会将这些浏览数据通过web页面实时地展示给用户，并储存起最新的5至10000条浏览记录以便进行查阅。如下图所示 ：
　　                             http://images2015.cnblogs.com/blog/713443/201703/713443-20170321195831346-1422341682.png
随着LLOOGG.com的用户越来越多，LLOOGG为每个网站维护的浏览记录列表变得越来越多，执行的插入和弹出操作也越来越多，由于当时使用的数据库是MySQL，过度频繁的磁盘I/O操作严重影响着系统的性能，这使得Salvatore Sanfilippo萌生出开发一款列表结构的内存型数据库的想法。
　　优点：高速读写，拥有非常丰富的数据结构，且这些数据结构的常见操作均是原子性的
　　缺点：耗内存，持久化
　　适用场景：常用作缓存，配合其他数据库一起使用