本文正在参加「金石计划 . 瓜分6万现金大奖」
数据库的特性和使用技巧以及架构说明文章比较多，这些都是纵深方向来说，从横宽方向来说还是比价少，笔者主要介绍下一些主流数据库技术和数据存储技术，以及其趋势方向和场景。
五个典型数据库：mysql、oracle 、db2、hbase、neo4j
1.SQL 和 NoSQL 角度
SQL（关系型数据库）：MySQL、Oracle、DB2
NoSQL（非关系型数据库）：Hbase、neo4j
2.点线面体
mysql 等关系型数据库存储的数据更加线性和某一点关系的聚合，像 Hbase 等可存储的数据偏向线性往面靠拢，neo4j 等图数据库存储的数据更加立体。
我们可以通过各种方案和实现让 mysql 中的数据有立体关联或者具备面特征，但是这种情况下，数据库操作的性能就难以维持、难以保证，尤其是复杂立体关系下，比如人际关系数据，和账户转账流转记录数据，前者可以用来做可能认识的人，后者可以用来做金融行为分析，来做风控等。
对于这种复杂关系数据，我们便需要有更加立体的数据存储服务来存储，比如图数据库 neo4j。
随着现在对数据的挖掘和使用认知越来越清晰和看重，有很多立体关系查询需求，这再用 mysql 等关系型数据库去通过 sql 或者代码层面来实现的话，性能无疑是个很大的问题。
举一个位置定位的需求场景：
mysql 数据库表中存了上千万条地理位置信息（辩证看待，不要考虑分库分表），现在需要去获取某个位置的方圆 500 米的地理位置信息，这种情况下，结合库表设计和字段的关联性，很难去写一个高性能的 sql 或者使用一些方案高效率的获取相关数据。
类似这样的需求场景，现在也是比较多的，这时候其实可以考虑，对类似数据使用图数据库存储，通过操作图数据库去获取。
有人说图数据库将取代关系型数据库，成为新一代的数据库，这个还真不好说，但是关系型数据库领域应用场景还是比较突出，最多是两者互补结合，一个完全取代另一个应该很难。
除了这些常规的数据库，可能我们还有听说过数据仓库和数据湖，这些其实是数据存储设计模式，主要用来支撑 OLAP（现在也有同时支持 OLTP 和 OLAP 的数据库），即联机分析处理，而且它对于数据的存储可能是多个数据库和存储方案的组合，并不是我们狭义上说的数据库。
简单的说，传统的文件系统由于数据冗余、不一致…等问题，发展出了关系型数据库，期间伴随着各种需求场景，也出现了各种非关系型数据库，包括 redis，mongodb 等。
随着互联网的越发发达，动辄上亿的数据已很常见，公司发展到一定地步做决策也需要统合所有数据来进行，这时候的数据量就已经很大了。而且除了这些场景，也有一些功能场景，比如商品推荐，机器学习等人工智能模型，也需要海量的数据来跑，这些单纯的依托关系型数据库或者说传统数据库是很难实现的。
后面就出现了我们众所周知的谷歌三篇论文，发展出了以开源 hdfs 为基础的 hadoop 生态，用来存储大量的数据，来做对实时性要求不高的分析，对数据挖掘进行支撑，在这期间对这种数据的存储又出现了一些设计模型。比如现在我们基本上都认可的数据仓库，它不是一个单纯的技术，是对数据存储的一种设计方案，采用了分层存储，有 ODS 层（数据运营），DW（数据仓库，其中又细分为 DWD-详细，DWM-中间，DWS-服务 等）层等，我们所知道的数据集市也就是在 DW 中，数据集市一般是对部门或者业务数据的集中，它是一个主题，其中的数据存在于 DW 中的多张表或者说宽表（很多列）中。
数据仓库有个很显著的特点就是它需要在写入之前就设计好对应的模型，所以它是 write-operate，即写前、或者说入仓前操作数据，对数据进行 ETL 清洗转换后进入仓库，分发到不同的集市等，这些都是基于对数据使用有一个明确的需求和认识才能去做。
随着算力和机器学习、AI 的发展，有些数据是很有价值的，但是现阶段并不能发掘出来它的使用或者说价值，对于这些数据我们应该保存，以供未来发掘使用，这就是属于数据湖的应用场景了，它相当于是 read-operate，即在使用时才对数据进行操作，在入库时基本上就是保存的原始数据。
随着业务的发展，有些公司只有数据仓库，有些公司只有数据湖，也有些既有数据湖也有数据仓库，甚至于打通了数据湖和数据仓库，再到现阶段说的比较多的湖仓一体。
数据仓库，数据湖等是对不同需求场景的数据存储设计模式，或者说是对彼此的补充。
像是 Hadoop 生态的一些技术，例如 hdfs、yarn、hive、spark、flink、hbase、mysql…等等可以认为是用来实现数据仓库和数据湖的一些技术，当然还有其他技术用来实现数据仓库和数据湖。
本文正在参加「技术专题19期 漫谈数据库技术」活动
