对数据的思考

RDBMS

引用：复杂查询带来可能不单单是性能问题，其背后隐藏的还有多是不恰当的架构和设计

若是有人问你数据库的原理，叫他看这篇文章

RDBMS，Relational Database Management System，关系型数据库管理系统。

什么是关系型数据库，行和列组成表，表的集合就是关系型数据库，关系数据库是以数据（单元格）、关系（一对多...）、数据的约束（外键）组成的数据模型，这已经有将近50年的历史了。

关系型数据库的管理系统，其实就是管理软件，MySQL、Oracle这类的，数据是存放在操做系统的文件系统中的。

基本的sql流程是，解释 -> 优化 -> 执行

数据库主要面向的是，事务。

当复杂sql赶上当大数据量的时候，那就是Cpu和磁盘IO的挑战了。

比较深入的是索引，能够用二叉搜索树（或者B+树）来实现，而搜索行的时候，可使用hash桶。

可是建立太多的索引，有时反而会加剧数据库的负担，由于索引是有序的，每次增删改都会致使一次排序，而最好的排序算法，只是O(Log(N)*N)。

HDFS

5分钟深刻浅出 HDFS

HDFS，Hadoop Distributed File System，Hadoop分布式文件系统。

这个东西就比较复杂了，它是用Java写的分布式文件系统，与Map-Reduce是Hadoop框架的一部分，是大数据处理的基础架构。

Hive

有Mysql数据库的状况下为何要用Hive？

Hadoop使用Map-Reduce来计算数据，而Hive提供了类Sql的查询方式，虽然不能使用索引，致使每次查询都是暴力的全扫描，可是大数据量的并行查询，会表现的好。

它能够将metadata放在mysql，而后经过SQL引擎去HDFS中查询数据。

固然，还有Hbase，SparkSQL，后者具备更强大的一栈式处理数据能力。

数据仓库

数据库 与 数据仓库的本质区别是什么？

有了以上的知识，很是清楚了一点，最须要的是一个数据仓库，由于系统运行时超过99%的数据是历史数据，不容许修改，只须要查询，而将这些数据和生产数据放在一块儿，势必会加大系统和数据库的负担。 火了几年的大数据，利用这些成熟的框架，能够搭建一个更强大，面向将来的架构。

理想的架构是

• online web服务使用MySql，只保存活跃的记录和系统数据，如用户信息，当前订单

• Data Warehouse 数据仓库，提供报表和数据分析服务，搭建好以后交给专业的数据分析师，存放不变的数据，如历史订单

所以，只须要一个Hadoop集群 + 一个Hive/SparkSQL应用。