数据库概览与选择
1 数据库市场介绍
DB-Engines 发布的2017 年 2月份的数据库排名前10的数据库如下，其中商业数据库4个，开源6个，关系型数据库7个，非关系型3个
2 如何选择数据库
A、看应用场景 — OLTP/OLAP
OLTP（联机事务处理）
事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量 。
典型应用：电子商务系统、银行、证券等，如eBay的业务数据库，就是很典型的OLTP数据库
OLAP（联机分析处理）
有的时候也叫DSS决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
典型应用：大数据分析。
B、看应用场景 — SQL / NoSQL
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 开源）
商业数据库：付费使用，功能更强大一点，支持好，维护成本相对低一点
开源数据库：免费使用，功能有所牺牲，维护支持的成本相对高一点
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条浏览记录以便进行查阅。如下图所示 ：
随着LLOOGG.com的用户越来越多，LLOOGG为每个网站维护的浏览记录列表变得越来越多，执行的插入和弹出操作也越来越多，由于当时使用的数据库是MySQL，过度频繁的磁盘I/O操作严重影响着系统的性能，这使得Salvatore Sanfilippo萌生出开发一款列表结构的内存型数据库的想法。
优点：高速读写，拥有非常丰富的数据结构，且这些数据结构的常见操作均是原子性的
缺点：耗内存，持久化
适用场景：常用作缓存，配合其他数据库一起使用
