甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
目录
成都创新互联公司是一家专业提供海南州企业网站建设,专注与成都网站设计、成都网站建设、外贸网站建设、H5响应式网站、小程序制作等业务。10年已为海南州众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。
- 数据库分类维度：关系型/非关系型、交易型/分析型
- NoSQL数据库的进一步分类
- OLTP市场规模：关系型数据库仍占营收大头
- 数据库市场份额：云服务和新兴厂商主导NoSQL
- 开源数据库 vs. 商业数据库
- 数据库三大阵营：传统厂商和云服务提供商
最近由于时间原因我写东西少了，在公众号上也转载过几篇搞数据库朋友的大作。按说我算是外行，没资格在这个领域品头论足，而当我看到下面这份报告时立即产生了学习的兴趣，同时也想就能看懂的部分写点心得体会分享给大家。
可能本文比较适合普及性阅读，让数据库领域资深的朋友见笑了：）
数据库分类维度：关系型/非关系型、交易型/分析型
首先是分类维度，上图中的纵轴分类为Relational Database（关系型数据库，RDBMS）和Nonrelational Database （非关系型数据库，NoSQL），横轴的分类为Operational（交易型，即OLTP）和Analytical（分析型，即OLAP）。
按照习惯我们先看关系型数据库，左上角的交易型类别中包括大家熟悉的商业数据库Oracle、MS SQL Server、DB2、Infomix，也包括开源领域流行的MySQL（MariaDB是它的一个分支）、PostgreSQL，还有云上面比较常见的SQL Azure和Amazon Aurora等。
比较有意思的是，SAP HANA正好位于交易型和分析型的中间分界处，不要忘了SAP还收购了Sybase，尽管后者今天不够风光了，而早年微软的SQL Server都是来源于Sybase。Sybase的ASE数据库和分析型Sybase IQ还是存在的。
右上角的分析型产品中包括几款知名的列式数据仓库Pivotal Greenplum、Teradata和IBM Netezza（已宣布停止支持），来自互联网巨头的Google Big Query和Amazon RedShift。至于Oracle Exadata一体机，它上面运行的也是Oracle数据库，其最初设计用途是OLAP，而在后来发展中也可以良好兼顾OLTP，算是一个跨界产品吧。
再来看非关系型数据库，左下角的交易型产品中，有几个我看着熟悉的MongoDB、Redis、Amazon DynamoDB和DocumentDB等；右下角的分析型产品包括著名的Hadoop分支Cloudera、Hortonworks（这2家已并购），Bigtable（来自Google，Hadoop中的HBase是它的开源实现）、Elasticsearch等。
显然非关系型数据库的分类要更加复杂，产品在应用中的差异化也比传统关系型数据库更大。Willian Blair很负责任地对它们给出了进一步的分类。
NoSQL数据库的进一步分类
上面这个图表应该说很清晰了。非关系型数据库可以分为Document-based Store（基于文档的存储）、Key-Value Store（键值存储）、Graph-based（图数据库）、Time Series（时序数据库），以及Wide Cloumn-based Store（宽列式存储）。
我们再来看下每个细分类别中的产品：
文档存储 ：MongoDB、Amazon DocumentDB、Azure Cosmos DB等
Key-Value存储 ：Redis Labs、Oracle Berkeley DB、Amazon DynamoDB、Aerospike等
图数据库 ：Neo4j等
时序数据库 ：InfluxDB等
WideCloumn ：DataStax、Cassandra、Apache HBase和Bigtable等
多模型数据库 ：支持上面不只一种类别特性的NoSQL，比如MongoDB、Redis Labs、Amazon DynamoDB和Azure Cosmos DB等。
OLTP市场规模：关系型数据库仍占营收大头
上面这个基于IDC数据的交易型数据库市场份额共有3个分类，其中深蓝色部分的关系型数据库（RDBMS，在这里不统计数据挖掘/分析型数据库）占据80%以上的市场。
Dynamic Database（DDMS，动态数据库管理系统，同样不统计Hadoop）就是我们前面聊的非关系型数据库。这部分市场显得小（但发展势头看好），我觉得与互联网等大公司多采用开源+自研，而不买商业产品有关。
而遵循IDC的统计分类，在上图灰色部分的“非关系型数据库市场”其实另有定义，参见下面这段文字：
数据库市场份额：云服务和新兴厂商主导NoSQL
请注意，这里的关系型数据库统计又包含了分析型产品。Oracle营收份额42%仍居第一，随后排名依次为微软、IBM、SAP和Teradata。
代表非关系型数据库的DDMS分类中（这里同样加入Hadoop等），云服务和新兴厂商成为了主导，微软应该是因为云SQL Server的基础而小幅领先于AWS，这2家一共占据超过50%的市场，接下来的排名是Google、Cloudera和Hortonworks（二者加起来13%）。
上面是IDC传统分类中的“非关系型数据库”，在这里IBM和CA等应该主要是针对大型机的产品，InterSystems有一款在国内医疗HIS系统中应用的Caché数据库（以前也是运行在Power小机上比较多）。我就知道这些，余下的就不瞎写了。
开源数据库 vs. 商业数据库
按照流行度来看，开源数据库从2013年到现在一直呈现增长，已经快要追上商业数据库了。
商业产品在关系型数据库的占比仍然高达60.5%，而上表中从这列往左的分类都是开源占优：
Wide Cloumn：开源占比81.8%；
时序数据库：开源占比80.7%；
文档存储：开源占比80.0%；
Key-Value存储：开源占比72.2%；
图数据库：开源占比68.4%；
搜索引擎：开源占比65.3%
按照开源License的授权模式，上面这个三角形越往下管的越宽松。比如MySQL属于GPL，在互联网行业用户较多；而PostgreSQL属于BSD授权，国内有不少数据库公司的产品就是基于Postgre哦。
数据库三大阵营：传统厂商和云服务提供商
前面在讨论市场份额时，我提到过交易型数据库的4个巨头仍然是Oracle、微软、IBM和SAP，在这里William Blair将他们归为第一阵营。
随着云平台的不断兴起，AWS、Azure和GCP（Google Cloud Platform）组成了另一个阵营，在国外分析师的眼里还没有BAT，就像有的朋友所说，国内互联网巨头更多是自身业务导向的，在本土发展公有云还有些优势，短时间内将技术输出到国外的难度应该还比较大。（当然我并不认为国内缺优秀的DBA和研发人才）
第三个阵容就是规模小一些，但比较专注的数据库玩家。
接下来我再带大家简单过一下这前两个阵容，看看具体的数据库产品都有哪些。
甲骨文的产品，我相对熟悉一些的有Oracle Database、MySQL以及Exadata一体机。
IBM DB2也是一个庞大的家族，除了传统针对小型机、x86（好像用的人不多）、z/OS大型机和for i的版本之外，如今也有了针对云和数据挖掘的产品。记得抱枕大师对Informix的技术比较推崇，可惜这个产品发展似乎不太理想。
微软除了看家的SQL Server之外，在Azure云上还能提供MySQL、PostgreSQL和MariaDB开源数据库。应该说他们是传统软件License+PaaS服务两条腿走路的。
如今人们一提起SAP的数据库就想起HANA，之前从Sybase收购来的ASE（Adaptive Server Enterprise）和IQ似乎没有之前发展好了。
在云服务提供商数据库的3巨头中，微软有SQL Server的先天优势，甚至把它移植到了Linux拥抱开源平台。关系型数据库的创新方面值得一提的是Amazon Aurora和Google Spanner（也有非关系型特性），至于它们具体好在哪里我就不装内行了：）
非关系型数据库则是Amazon全面开花，这与其云计算业务发展早并且占据优势有关。Google当年的三篇经典论文对业界影响深远，Yahoo基于此开源的Hadoop有一段时间几乎是大数据的代名词。HBase和Hive如今已不再是人们讨论的热点，而Bigtable和BigQuery似乎仍然以服务Google自身业务为主，毕竟GCP的规模比AWS要小多了。
最后这张DB-Engines的排行榜，相信许多朋友都不陌生，今年3月已经不是最新的数据，在这里列出只是给大家一个参考。该排行榜几乎在每次更新时，都会有国内数据库专家撰写点评。
以上是我周末的学习笔记，班门弄斧，希望对大家有帮助。
参考资料《Database Software Market:The Long-Awaited Shake-up》
扩展阅读：《 数据库存储：互相最想知道的事 》
尊重知识，转载时请保留全文。感谢您的阅读和支持！
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，
泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 关系型数据库与NoSQL的区别？
3.1 RDBMS
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
ACID
关系型数据库遵循ACID规则
事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：
A (Atomicity) 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C (Consistency) 一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
I (Isolation) 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
3.2 NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
分布式数据库中的CAP原理(了解)
CAP定理：
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性), 好的响应性能
Partition tolerance(分区容错性) 可靠性
P: 系统中任意信息的丢失或失败不会影响系统的继续运作。
定理：任何分布式系统只可同时满足二点，没法三者兼顾。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
说明：C：强一致性 A：高可用性 P：分布式容忍性
举例：
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向。
4. 当下NoSQL的经典应用
当下的应用是 SQL 与 NoSQL 一起使用的。
代表项目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。
难点：
数据类型多样性。
数据源多样性和变化重构。
数据源改造而服务平台不需要大面积重构。
NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的
SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数
据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
从这一新兴技术中选择一款正确的NoSQL数据库是非常具有挑战性的。比一下网建议在选择时考虑以下因素：
并发控制
并
发控制指的是当多个用户同时更新运行时，用于保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。并发控制的目的是保
证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下，这些措施保证了当用户和其他用户一起操作时，所得的结果和她单独操作时的结果是
一样的。在另一些情况下，这表示用户的工作按预定的方式受其他用户的影响。
封锁
就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。
封锁是一次只允许一个用户读取或修改的一种机制，是实现并发控制的一个非常重要的技术。
MVCC
Multi-Version Concurrency Control多版本并发控制，维持一个数据的多个版本使读写操作没有冲突。MVCC优化了数据库并发系统，使系统在有大量并发用户时得到最高的性能，并且可以不用关闭服务器就直接进行热备份。
ACID
指
数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久
性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction
processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。
None
一些系统不提供原子性。
镜像
数据库镜像是DBMS根据DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS会自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。
镜像分为同步和异步。
数据存储
指的是数据的物理特性怎样被存储在数据库中。
磁盘 数据被存储在硬盘驱动器里；
GFS或谷歌文件系统是一个由谷歌开发的专有的分布式文件系统；
Hadoop是Apache软件框架，免费许可下支持数据密集型分布式应用程序；
RAM随机存储器；
插件 可以添加外部插件；
Amazon S3通过Web服务接口提供存储；
BDB：BDB
全称是 “Berkeley DB”，它是MySQL具有事务能力的表类型，由Sleepycat
Software开发。BDB表类型提供了MySQL用户长久期盼的功能，即事务控制能力。在任何RDBMS中，事务控制能力都是一种极其重要和宝贵的功
能。事务控制能力使得我们能够确保一组命令确实已经全部执行成功，或者确保当任何一个命令出现错误时所有命令的执行结果均被退回。
实现语言
实现语言会影响数据库的发展速度。典型的NoSQL数据库是用低级语言如C / C + +编写的。另一方面，那些更高层次的语言如Java，使自定义更容易。
实现语言有：C, C++, Erlang, Java, Python
特性
考虑下列哪一个特点对你的数据库是最重要的：
持久性
可用性
一致性
分区容忍性
证书类型
下面这些许可证是一个不同的开放源码许可的形式：
GPL：通用公共许可证
BSD：伯克利软件分发
MPL：Mozilla公共许可证
EPL：Eclipse公共许可证
IDPL：最初的开发者的公共许可证
LGPL：较宽松通用公共许可证
存储类型
存储类型是NoSQL数据库最大的不同，是决定使用哪款数据库的一个首要指标。
关键字：支持get、put和删除操作
按列存储：相对于传统的按行存储，数据集成容易多了
面向文件系统：存储像是JSON或XML这样的结构化文件，很容易就能从面向对象软件中获取数据。
NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。