数据库分区

前言 应大部分的小伙伴的要求，在Yarn之前先来一个kafka的小插曲，轻松愉快。 一、Kafka基础 消息系统的作用 应该大部份小伙伴都清楚，用机油装箱举个例子 所以消息系统就是如上图我们所说的仓库，能在中间过程作为缓存，并且实现解耦合的作用。 引入一个场景，我们知道中国移动，中国联通，中国电信的日志处理，是交给外包去做大数据分析的，假设现在它们的日志都交给了你做的系统去做用户画像分析。 按照刚刚前面提到的消息系统的作用，我们知道了消息系统其实就是一个模拟缓存，且仅仅是起到了缓存的作用而并不是真正的缓存，数据仍然是存储在磁盘上面而不是内存。 1.Topic 主题 kafka学习了数据库里面的设计，在里面设计了topic（主题），这个东西类似于关系型数据库的表 此时我需要获取中国移动的数据，那就直接监听TopicA即可 2.Partition 分区 kafka还有一个概念叫Partition（分区），分区具体在服务器上面表现起初就是一个目录，一个主题下面有多个分区，这些分区会存储到不同的服务器上面，或者说，其实就是在不同的主机上建了不同的目录。这些分区主要的信息就存在了.log文件里面。跟数据库里面的分区差不多，是为了提高性能。 至于为什么提高了性能，很简单，多个分区多个线程，多个线程并行处理肯定会比单线程好得多

一、资料文档 Kafka：中。有kafka作者自己写的书，网上资料也有一些。rabbitmq：多。有一些不错的书，网上资料多。zeromq：少。没有专门写zeromq的书，网上的资料多是一些代码的实现和简单介绍。rocketmq：少。没有专门写rocketmq的书，网上的资料良莠不齐，官方文档很简洁，但是对技术细节没有过多的描述。activemq：多。没有专门写activemq的书，网上资料多。 二、开发语言 Kafka：Scala rabbitmq：Erlang zeromq：c rocketmq：java activemq：java 三、支持的协议 Kafka：自己定义的一套…（基于TCP） rabbitmq：AMQP zeromq：TCP、UDP rocketmq：自己定义的一套… activemq：OpenWire、STOMP、REST、XMPP、AMQP 四、消息存储 Kafka：内存、磁盘、数据库。支持大量堆积。 kafka的最小存储单元是分区，一个topic包含多个分区，kafka创建主题时，这些分区会被分配在多个服务器上，通常一个broker一台服务器。分区首领会均匀地分布在不同的服务器上，分区副本也会均匀的分布在不同的服务器上，确保负载均衡和高可用性，当新的broker加入集群的时候，部分副本会被移动到新的broker上。根据配置文件中的目录清单

Fetch抓取（Hive可以避免进行MapReduce） Hive中对某些情况的查询可以不必使用MapReduce计算。例如：SELECT * FROM employees;在这种情况下，Hive可以简单地读取employee对应的存储目录下的文件，然后输出查询结果到控制台。 在hive-default.xml.template文件中hive.fetch.task.conversion默认是more，老版本hive默认是minimal，该属性修改为more以后，在全局查找、字段查找、limit查找等都不走mapreduce。 < property > < name > hive.fetch.task.conversion </ name > < value > more </ value > < description > Expects one of [none, minimal, more]. Some select queries can be converted to single FETCH task minimizing latency. Currently the query should be single sourced not having any subquery and should not have any aggregations or

用来衡量分布式系统架构是否符合要求的重要指导方式.通过一致性,可用性,分区容忍性三个维度,来去衡量一个软件架构. CAP原理 C:一致性 ---多节点数据一致 A:可用性 ---保持服务可用:多节点 P:分区容忍性 ---是否可以将数据存到多个地方 不能同时满足C,A,P AC :放弃分区容忍,物理数据库 AP:可以短暂允许数据不一致 ,nosql数据库 CP:放弃可用性 来源： CSDN 作者： level_Tiller 链接： https://blog.csdn.net/level_Tiller/article/details/103470019

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> OLTP与OLAP的介绍 数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支 持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作； OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。 OLTP与OLAP之间的比较 ： OLTP，也叫联机事务处理（Online Transaction Processing） ，表示事务性非 常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 数据处理大致可以分成两大类： 联机事务处理 OLTP （ on-line transaction processing ）、 联机分析处理 OLAP （ On-Line Analytical Processing ）。 OLTP 是传统的关系型数据库的主要应用 ，主要是基本的、日常的事务处理，例如银行交易。 OLAP 是数据仓库系统的主要应用 ，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作； OLAP 系统则强调数据分析，强调 SQL 执行市场，强调磁盘 I/O ，强调分区等。 OLTP 与 OLAP 之间的比较 ： 什么是 OLTP OLTP ，也叫联机事务处理（ Online Transaction Processing ），表示事务性非常高的系统 ，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的 Transaction 以及 Execute SQL 的数量。在这样的系统中，单个数据库每秒处理的 Transaction 往往超过几百个，或者是几千个， Select 语句的执行量每秒几千甚至几万个。典型的 OLTP 系统有电子商务系统、银行、证券等，如美国

1.1Hazelcast概述 Hazelcast是基于内存的数据网格开源项目，同时也是该公司的名称。Hazelcast提供弹性可扩展的分布式内存计算，Hazelcast被公认是提高应用程序性能和扩展性最好的方案。Hazelcast通过开放源码的方式提供以上服务。更重要的是，Hazelcast通过提供对开发者友好的Map、Queue、ExecutorService、Lock和JCache接口使分布式计算变得更加简单。例如，Map接口提供了内存中的键值存储，这在开发人员友好性和开发人员生产力方面提供了NoSQL的许多优点。 除了在内存中存储数据外，Hazelcast还提供了一组方便的api来访问集群中的cpu，以获得最大的处理速度。轻量化和简单易用是Hazelcast的设计目标。Hazelcast以Jar包的方式发布，因此除Java语言外Hazelcast没有任何依赖。Hazelcast可以轻松地内嵌已有的项目或应用中，并提供分布式数据结构和分布式计算工具。 Hazelcast 具有高可扩展性和高可用性（100%可用，从不失败）。分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。Hazelcast基于Java实现，并提供C/C++，.NET，REST，Python、Go和Node.js客户端。Hazelcast遵守内存缓存协议

在WEB网站的规模从小到大不断扩展的过程中，数据库的访问压力也不断的增加，数据库的架构也需要动态扩展，在数据库的扩展过程基本上包含如下几步，每一个扩展都可以比上一步骤的部署方式的性能得到数量级的提升。 1、WEB应用和数据库部署在同一台服务器上 一般的小规模的网站采用这种方式，用户量、数据量、并发访问量都比较小，否则单台服务器无法承受，并且在遇到性能瓶颈的时候升级硬件所需要的费用非常高昂，在访问量增加的时候，应用程序和数据库都来抢占有限的系统资源，很快就又会遇到性能问题。 2、WEB应用和数据库部署在各自独立的服务器上 web应用和数据库分开部署，WEB应用服务器和数据库服务器各司其职，在系统访问量增加的时候可以分别升级应用服务器和数据库服务器，这种部署方式是一般小规模网站的典型部署方式。在将应用程序进行性能优化并且使用数据库对象缓存策略的情况下，可以承载较大的访问量，比如2000用户，200个并发，百万级别的数据量。 3、数据库服务器采用集群方式部署（比如Oracle的一个数据库多个实例的情况） 数据库集群方式能承担的负载是比较大的，数据库物理介质为一个磁盘阵列，多个数据库实例以虚拟IP方式向外部应用服务器提供数据库连接服务。这种部署方式基本上可以满足绝大多数的常见WEB应用，但是还是不能满足大用户量、高负载、数据库读写访问非常频繁的应用。 4、数据库采用主从部署方式

Outline 1.ACID 2.CAP 3.BASE 4.一致性协议 一直都对数据库事务不甚清楚，趁着前段时间对数据库事务级别进行了总结，一起对分布式事务进行总结梳理 ACID 1234 start transaction;update account set money = money-100 where userId = 1;update account set money = money+100 where userId = 2;commit; A（Atomicity），原子性 ，一个事务内的操作，要么全成功执行，要么全部不执行。 C（Consistency），一致性 ，事务执行的结果必须使将数据库从一种一致的状态变为另一种一致的状态，不可能出现中间状态，只有事务提交前状态和提交后状态，不存在提交中的状态。 I（Isolation），隔离性 ，每个读写事务的对象对其他事务的操作对象相互独立，即该事务提交前对其他事务都不可见。 D（Durability），持久性 ，一个事务一旦提交，它对数据库中对应数据的状态变更就是永久性的。 CAP 单机事务很容易实现支持ACID特性的事务处理系统，但是在分布式环境中问题就变得困难许多。 CAP理论告诉我们，一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)、分区容错性(P

调优 Hive提供三种可以改变环境变量的方法，分别是： （1） 修改${HIVE_HOME}/conf/hive-site.xml配置文件； 所有的默认配置都在 ${HIVE_HOME}/conf/hive-default.xml 文件中，如果需要对默认的配置进行修改，可以创建一个hive-site.xml文件，放在${HIVE_HOME}/conf目录下。里面可以对一些配置进行个性化设定。 这里做的配置都全局用户都生效，而且是永久的 。 （2）命令行参数； 在启动Hive cli的时候进行配置，可以在命令行添加-hiveconf param=value来设定参数； 这一设定对本次启动的会话有效，下次启动需要重新配置。 （3）在已经进入cli时进行参数声明。 可以在HQL中使用SET关键字设定参数， 这种配置也是对本次启动的会话有效，下次启动需要重新配置 。在HQL中使用SET关键字还可以查看配置的值。 　　set后面什么都不添加，这样可以查到Hive的所有属性配置。 上述三种设定方式的优先级依次递增。即参数声明覆盖命令行参数，命令行参数覆盖配置文件设定。 服务器和客户端中都要进行配置； https://www.cnblogs.com/ITtangtang/p/7683028.html 1 Fetch抓取 Fetch抓取是指