关系型数据库 大数据分析中使用关系型数据库的关键点

大数据分析处理的原始数据有相当一部分来自关系数据库，处理结果也存储在关系数据库中。原因是超过99%的软件系统使用传统的关系数据库，大家都很熟悉，也很容易使用。

在我们正式的大数据团队中，几个仓库(data warehouse Hive+HBase)的数据采集也来自于Oracle或者MySql。虽然处理后的统计结果和明细保存在Hive中，但定期推送至Oracle/MySql供前台系统读取显示并生成各种报表。

在这种场景下，数据库的读写性能尤为重要！

一、数据库定位

有大神说，你给我足够的数据库硬件，一个GroupBy就能满足各种统计分析场景。

没错，我们数百万的金融级Oracle一体机证明了GroupBy可以很强大，也证明了它有一个上限，就是数据大了还是要趴下！

所以需要有设计原则和优化技巧。

核心原理:数据库只是数据存储的载体，在大数据中很难使用它的计算能力！

有了这个原则，就意味着数据库将被“纯粹地”使用:

数据表独立性很强，大表间很少join（这让我想起有同学在Hive里对两张大表做笛卡尔乘积产生270T数据）数据表很大，单表几十亿行很常见索引很少，一般按主键查单行或者按时间查一段 二、分区存储

在这里，数据库是存储数据的仓库，海量数据需要拆分存储，不可能全部压缩在一起。

根据业务不同，一般有两种拆分方式:

单表分区。常见于Oracle，每月做一个分区，数据连续方便业务处理，但要求单机性能强劲。分表分库。常见于MySql，分个128张表乃至4096张表也都是很平常的事情，可以用很多性能较差的机器组建集群，但因数据不连续不便于业务处理。

具体的拆分方法由使用场景决定。

如果以后要提取整个数据进行统计分析，比如原始数据和中间数据，那么分区优先。便于历史数据的连续提取和每月删除，对于海量数据删除是痛苦的。子分区和分区内索引也可以在分区内建立。

如果用于业务数据或最终统计结果，则考虑在数据库划分后再划分表，数据按照业务维度“统一”存储在不同的表上。比如对单个数取CRC，然后对数据表个数取模。

有很多数据，属于时间序列数据的性质，或者日志类型，都是只插入，很少或者根本没有Update，几乎没有Delete。

这类数据有一个关键时间字段来决定数据什么时候到达，比如input date/CreateTime/UpdateTime，可以通过触发器的方式填充当前时间。

基于时间维度提取时间序列数据进行分析时，必须保证所有数据都能按时间域升序找到，不会遗漏或重复搜索某些行。

第三，高效查询

对于海量数据查询，命中指数必须100%确定。code=xxx或updatetime >: =:start和updatetime<。:结束.

按主键查询命中单行或少量数据；

根据时间查询，一定要合理选择时间间隔(开始、结束)，最好将查询结果控制在10000~20000行左右。

比如考虑到高峰时段，我们一般以5秒的间隔进行查询，一般会得到10000 ~ 40000行。

使用数据时，可能会有很多查询条件，但最重要的是时间间隔。

由于数据量大，DBMS本身的统计信息收集可能非常不及时，导致执行计划中选择了错误的索引方案。在这种情况下，需要手动收集信息，甚至在查询语句中强制指定索引。

第四，批量写作

借助内存计算，我们经常可以在短时间内计算出几十万甚至上百万的数据，这些数据需要写入数据库。

一般数据库的Insert/Update性能只有3000 ~ 5000tps，很难在有索引负担的情况下快速将数据写入其中。

以甲骨文为例。它的OracleCommand有一个超级函数ArrayBindCount，可以为一个参数化的写操作绑定多个组(例如，5000组/行)。

这种方法可以使其获得最高的写入性能，实际服务使用量可以达到30000tps左右。

MySql和SQLite都有自己独特的批量写功能，支持netcore。

SqlServer也有批量写功能，但还不支持netcore。

MySql解决方案写在另一篇文章里。

动词 （verb的缩写）总结

关系数据库存储大数据的关键点是:简单存储、分区和表划分、高效索引和批量写入！

原地址:https://www.cnblogs.com/nnhy/p/DbForBigData.html