partition

1、 consumer API kafka 提供了两套 consumer API： 1. The high-level Consumer API 2. The SimpleConsumer API 其中 high-level consumer API 提供了一个从 kafka 消费数据的高层抽象，而 SimpleConsumer API 则需要开发人员更多地关注细节。 1.1 The high-level consumer API high-level consumer API 提供了 consumer group 的语义，一个消息只能被 group 内的一个 consumer 所消费，且 consumer 消费消息时不关注 offset，最后一个 offset 由 zookeeper 保存。 使用 high-level consumer API 可以是多线程的应用，应当注意： 1. 如果消费线程大于 patition 数量，则有些线程将收不到消息 2. 如果 patition 数量大于线程数，则有些线程多收到多个 patition 的消息 3. 如果一个线程消费多个 patition，则无法保证你收到的消息的顺序，而一个 patition 内的消息是有序的 1.2 The SimpleConsumer API 如果你想要对 patition 有更多的控制权，那就应该使用

转载自：https://www.cnblogs.com/xifenglou/p/7251112.html 一、为什么需要消息系统 1.解耦：　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2.冗余： 　　消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 3.扩展性： 　　因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。 4.灵活性 & 峰值处理能力： 　　在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 5.可恢复性： 　　系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 6.顺序保证： 　　在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Partition 分区 MySql 5.6 手册： http://dev.mysql.com/doc/refman/5.6/en/partitioning.html 我理解的分区 举个例子， 操作系统中的分区，是将硬盘根据大小进行逻辑分区，就是我们看到的C、D、E、F盘，逻辑分区还是在同一个操作系统中。数据库产品的Partition分区也是一样的道理，将数据进行逻辑分区，对数据划分界限。 分区类型 MySql 支持Range，List，Hash，Key。最长用的是Range。 注意不同的版本对分区类型的支持有些不同！ Range：范围 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL ) PARTITION BY RANGE (store_id) ( PARTITION p0 VALUES LESS THAN (6), PARTITION

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> InnoDB逻辑存储结构 　　首先要先介绍一下InnoDB逻辑存储结构和区的概念， 它的所有数据都被逻辑地存放在表空间，表空间又由段，区，页组成。 段 段就是上图的segment区域，常见的段有数据段、索引段、回滚段等，在InnoDB存储引擎中，对段的管理都是由引擎自身所完成的。 区 　　区就是上图的extent区域， 区是由连续的页组成的空间，无论页的大小怎么变，区的大小默认总是为1MB。 为了保证区中的页的连续性，InnoDB存储引擎一次从磁盘申请4-5个区，InnoDB页的大小默认为16kb，即一个区一共有64（1MB/16kb=16）个连续的页。每 个段开始，先用32页（page）大小的碎片页来存放数据，在使用完这些页之后才是64个连续页的申请。这样做的目的是，对于一些小表或者是undo类的段，可以开始申请较小的空间，节约磁盘开销。 页 　　页就是上图的page区域，也可以叫块。 页是InnoDB磁盘管理的最小单位。 默认大小为16KB，可以通过参数innodb_page_size来设置。常见的页类型有：数据页，undo页，系统页，事务数据页，插入缓冲位图页，插入缓冲空闲列表页，未压缩的二进制大对象页，压缩的二进制大对象页等。 分区概述 分区 　　 这里讲的分区，此“区”非彼“区”

1. refresh refresh 用于刷新某个表或者某个分区的数据信息，它会重用之前的表元数据，仅仅执行文件刷新操作。 主要用于表中元数据未修改，数据的修改，例如insert into、load data、alter table add partition、llter table drop partition等，如果直接修改表的hdfs文件（增加、删除或者重命名）也需要指定refresh刷新数据信息。 # 刷新表 refresh [table] # 刷新分区 refresh [table] partition [partition] 2. invalidate metadata invalidate metadata 用于刷新全库或者某个表的元数据，包括表的元数据和表内的文件数据。 它会首先清除表的缓存，然后从metastore中重新加载全部数据并缓存，该操作代价比较重。 主要用于在hive中修改了表的元数据，需要同步到impalad，例如 create table / drop table / alter table add columns等 # 重新加载所有库中的所有表 invalidate metadata; # 重新加载指定的某个表 invalidate metadata [table] 来源： CSDN 作者： 南宫紫攸 链接： https://blog.csdn

分区表索引介绍 局部索引： 局部前缀索引 （local prefixed index）：在这些索引中，分区键在索引定义的前几列上。例如，一个表在名为LOAD_DATE 的列上进行区间分区， 该表上的局部前缀索引就是采用LOAD_DATE作为其索引列列表中的第一列。 局部非前缀索引 （local nonprefixed index）：这些索引不以分区键作为其列列表的前几列。索引可能包含分区键列，也可能不包含。 这两类索引都可以进行分区消除,前提是查询的条件中包含索引分区键，它们都支持惟一性（只要局部非前缀索引包含分区键列)。 局部索引与表的分区数一致，如果新增一个分区，新增加的分区局部索引也会自动创建。全局索引则不行（即需要重建全局索引）。 一、分区消除介绍： --下面通过实验来说明索引的分区消除 --创建一个分区表 CREATE TABLE partitioned_table ( a int, b int, data char(20)) PARTITION BY RANGE (a) ( PARTITION part_1 VALUES LESS THAN(2) tablespace gcomm, --以a字段进行分区，小于等于2的存在分区1，小于等于3的存在分区2 PARTITION part_2 VALUES LESS THAN(3) tablespace gmapdata ) -

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、 Kafka是一种分布式的，基于发布/订阅的消息系统。 2、 常用Message Queue对比 RabbitMQ RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。 Redis Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 ZeroMQ ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景