数据库分区

数据模型 Greenplum数据库是一种shared nothing的分析型MPP数据库。这种模型与高度规范化的/事务型的SMP数据库有显著区别。Greenplum数据库使用非规范化的模式设计会工作得最好，非规范化的模式适合于MPP分析型处理，例如带有大型事实表和较小维度表的星形模式或者雪花模式。 对表中用于连接的列使用相同的数据类型。 堆存储 vs. 追加优化存储 对将会接收迭代批量或者单一UPDATE、DELETE以及INSERT操作的表和分区使用堆存储。 对将会接收并发UPDATE、DELETE以及INSERT操作的表和分区使用堆存储。 对于在初始装载后很少更新并且只会在大型批处理操作中进行后续插入的表和分区，使用追加优化存储。 绝不在追加优化表上执行单个INSERT、UPDATE或者DELETE操作。 绝不在追加优化表上执行并发的批量UPDATE或DELETE操作。可以执行并发的批量INSERT操作。 行存 vs. 列存 如果负载中有要求更新并且频繁执行插入的迭代事务，则对这种负载使用行存。 在对宽表选择时使用行存。 为一般目的或混合负载使用行存。 选择面很窄（很少的列）和在少量列上计算数据聚集时使用列存。 如果表中有单个列定期被更新而不修改行中的其他列，则对这种表使用列存。 压缩 在大型追加优化和分区表上使用压缩以改进系统范围的I/O。 在数据位于的级别上设置列压缩设置。

原文出处： 阿里云RDS-数据库内核组 HybridDB for MySQL（原名petadata）是面向在线事务（OLTP）和在线分析（OLAP）混合场景的关系型数据库。HybridDB采用一份数据存储来进行OLTP和OLAP处理，解决了以往需要把一份数据多次复制来分别进行业务交易和数据分析的问题，极大地降低了数据存储的成本，缩短了数据分析的延迟，使得实时分析决策称为可能。 HybridDB for MySQL兼容MySQL的语法及函数，并且增加了对Oracle常用分析函数的支持，100%完全兼容TPC-H和TPC-DS测试标准，从而降低了用户的开发、迁移和维护成本。 TokuDB是TokuTek公司（已被 Percona收购）研发的新引擎，支持事务/MVCC，有着出色的数据压缩功能，支持异步写入数据功能。 TokuDB索引结构采用fractal tree数据结构，是buffer tree的变种，写入性能优异，适合写多读少的场景。除此之外，TokuDB还支持在线加减字段，在线创建索引，锁表时间很短。 Percona Server和Mariadb支持TokuDB作为大数据场景下的引擎，目前官方MySQL还不支持TokuDB。ApsaraDB for MySQL从2015年4月开始支持TokuDB，在大数据或者高并发写入场景下推荐使用。 TokuDB优势 数据压缩

mysql error code(备忘) 转1005：创建表失败 1006：创建数据库失败 1007：数据库已存在，创建数据库失败 1008：数据库不存在，删除数据库失败 1009：不能删除数据库文件导致删除数据库失败 1010：不能删除数据目录导致删除数据库失败 1011：删除数据库文件失败 1012：不能读取系统表中的记录 1020：记录已被其他用户修改 1021：硬盘剩余空间不足，请加大硬盘可用空间 1022：关键字重复，更改记录失败 1023：关闭时发生错误 1024：读文件错误 1025：更改名字时发生错误 1026：写文件错误 1032：记录不存在 1036：数据表是只读的，不能对它进行修改 1037：系统内存不足，请重启数据库或重启服务器 1038：用于排序的内存不足，请增大排序缓冲区 1040：已到达数据库的最大连接数，请加大数据库可用连接数 1041：系统内存不足 1042：无效的主机名 1043：无效连接 1044：当前用户没有访问数据库的权限 1045：不能连接数据库，用户名或密码错误 1048：字段不能为空 1049：数据库不存在 1050：数据表已存在 1051：数据表不存在 1054：字段不存在 1065：无效的SQL语句，SQL语句为空 1081：不能建立Socket连接 1114：数据表已满，不能容纳任何记录 1116：打开的数据表太多 1129

前言 数据为企业的发展提供动力。我们从数据中获取信息，对他们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据，包括日志消息，度量指标，用户活动记录，响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。例如我们在Amazon网站上浏览感兴趣的商品，浏览信息被转化成商品推荐，并在稍后展示给我们。 这个过程完成的越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就能越专注于核心业务。这就是为什么在一个以数据为驱动的企业里，数据管道会成立关键性组件。如何移动数据，几乎变得与数据本身一样重要。 发布与订阅消息系统 数据的发送者不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者订阅它们，以便接收特定类型的消息。 发布与定于系统一般会有一个broker，也就是发布消息的中心点。 Kafka Kafka是一款基于发布与订阅的消息系统，它一般被称为分布式提交日志或者分布式流平台。 文件系统或数据库提交日志用来提供所有事务的持久记录，通过重放这些日志可以重建系统的状态。同样地，Kafka的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。 消息和批次 Kafka的数据单元被称为消息。

转载地址：【 传送门 】 一、表的继承： 这个概念对于很多已经熟悉其他数据库编程的开发人员而言会多少有些陌生，然而它的实现方式和设计原理却是简单易懂，现在就让我们从一个简单的例子开始吧。 1. 第一个继承表： CREATE TABLE cities ( --父表 name text, population float, altitude int ); CREATE TABLE capitals ( --子表 state char(2) ) INHERITS (cities); capitals表继承自cities表的所有属性。在PostgreSQL里，一个表可以从零个或多个其它表中继承属性，而且一个查询既可以引用父表中的所有行，也可以引用父表的所有行加上其所有子表的行，其中后者是缺省行为。 MyTest=# INSERT INTO cities values('Las Vegas', 1.53, 2174); --插入父表 INSERT 0 1 MyTest=# INSERT INTO cities values('Mariposa',3.30,1953); --插入父表 INSERT 0 1 MyTest=# INSERT INTO capitals values('Madison',4.34,845,'WI');--插入子表 INSERT 0 1 MyTest=# SELECT

CAP定理： 一个分布式系统 不可能 同时满足 一致性 （C:Consistency）、 可用性 （A:Availability）和 分区容错性 （P:Partition tolerance）这三个基本要求，最多只能满足 其中的两项 。 一致性 在分布式环境中，一致性是指数据在 多个副本之间 是否能够 保持强一致 的特性。 对于一个将数据副本分布在不同节点上的分布式系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是更新前的数据（称为 脏数据 ），这就是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有 强一致性 （或严格的一致性）。 可用性 可用性是指系统提供的服务必须 一直处于可用 的状态，对于用户的每一个操作请求总是能够在 有限的时间 内 返回结果 ，如果超过了这个时间范围，那么系统就被认为是不可用的。 『有限的时间内』是一个在系统设计之初就设定好的运行指标， 不同的系统会有很大的差别 。比如对于一个在线搜索引擎来说，通常在0.5秒内需要给出用户搜索关键词对应的检索结果。而对应Hive来说，一次正常的查询时间可能在20秒到30秒之间。 『返回结果

首先一个基本概念： ‍ 存储系统存储速度的快->慢： 内存->闪存->磁盘 因为内存的价格限制以及操作系统支持的限制，我们只能从磁盘这块来看，可见磁盘正是存储系统的最大瓶颈所在。 **下面具体提出我们的优化方案 优化方案1.缓存机制： 我们在磁盘里嵌入一小块高速的内存，用以保持常用的数据，我们称它为缓存。这样既可以使用磁盘，也能提高性能 缓存分为3类 Filestem cache、Diskcache、Disk controller cache。这里从磁盘部分来看，它包括了缓存数据。预读。回写。 缓存尝试用LRU算法、即近最少使用算法顾名思义。 写入缓存，即IO命令并不立刻的去执行，而是先在缓存中合并，相同的合为一个连续的合为一体，把随机写IO变成连续写。这样做的直接作用减少了寻址浪费时间从而有效提高效率 缓存的大小设置问题：不能太大了因为成本！！硬伤所在。。 小了呢他相对于大的存储系统就显的不够看，而且你要找一个东西他不在缓存里系统还要去缓存寻址一次。这样做的太多自然降低了效率。 [#1#root@localhost ~]#free -m Total// used free shared buffers cache 物理内存总量 已使用内存量 空闲内存 多个进程的共享内存 元数据缓存 块数据缓存 Mem: 490 132 357 0 7 38 -/+ buffers/cache:

hive表分区的概念 一个表可以拥有一个或者多个分区，每个分区以文件夹的形式单独存在表文件夹的目录下。 例如下图中xx.db(数据库），device_flow_report_data（表） month_id=201902：表示按月进行了分区 day_id=20190203：表示按天也进行了分区 分区是以字段的形式在表结构中存在，通过describe table命令可以查看到字段存在， 但是该字段不存放实际的数据内容，仅仅是分区的表示（伪列） 例如： describe device_flow_report_data ; id bigint NULL . . . . month_id string NULL day_id string NULL # Partition Information # col_name data_type comment month_id string NULL day_id string NULL Time taken: 0.173 seconds , Fetched 21 row ( s ) 小结：既然分区是以字段在表结构的中存在，那么就可以使用 where进行sql查询 解决检查hive表中是否存在某一分区 直接sql 查询表中是否存在该分区 # 查询日分区是否存在 show partitions device_flow_report_data

spark读取hive是最简单的，构造一个sparksession对象，直接执行SQL就得读取，然后直接insert就能写入。 因为spark客户端配置了你的hive数据库的信息，所以能够直接读取hive数据库。 spark = SparkSession .builder() .appName("Java Spark SQL basic example") .master(evm) .config("hive.exec.dynamic.partition", "true") // .config("hive.exec.max.dynamic.partitions.pernode", 10000) .config("hive.exec.max.dynamic.partitions", 100000) .config("hive.exec.dynamic.partition.mode", "nonstrict") .enableHiveSupport() // 启用HIVE数据源，必须参数 .getOrCreate(); // SQL ： select * from xxx public Dataset<Row> readFromHive(String sql) { if (StringUtils.isBlank(sql)) { throw new

前言 hive中操作hdfs上的数据可以像操作mysql数据库一样方便轻松，避免编写mapreduce程序，又提高了数据分析查询的速度和效率，下面就来总结一下自己前些天学的表的DDL 其实和mysql差不多 但是有一点需要注意，hive是读检查，写不检查，也就是是hive在你查询的时候才验证数据的有效性，加载数据时不检查，直接加载，这样的好处是加快了处理数据的速度，如果数据量很大，加载是检查会严重拖慢速度 Hive数据类型 string int double timestamp时间 struct map array 数据库 ： create database db1 location '/path' comment '描述' location代表指定数据库在dfs上的位置，其实就是创建了一个文件夹，不加也可以 用默认的位置 alert database db1 set xxx 更改数据库 drop database db1 CASCADE 删除数据库包括里面的表 show databases like 正则表达式 列出数据库 表 表分为内部表（受控表） 、外部表、临时表（创建时加TEMPORARY即可，退出客户端表即消失）。 外部表drop的时候只删除结构 不删除数据 并且可以指定表的目录（其实也就是数据的存放目录），可以用来备份数据用 create external t1(id