partition

数据库Sharding的基本思想和切分策略 本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考我的另一篇博文： 数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 一、基本思想 Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分. 垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非 常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业 务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也 更小，拆分规则也会比较简单清晰。（这也就是所谓的”share nothing”）。

创建topic： [root@zookeep-kafka-node1 bin]# ./kafka-topics.sh --create --zookeeper 10.23.209.70:2181,10.23.209.71:2181,10.23.209.72:2181 --replication-factor 3 --partitions 3 --topic test Created topic test. 显示topic： [root@zookeep-kafka-node1 bin]# ./kafka-topics.sh --describe --zookeeper 10.23.209.70:2181,10.23.209.71:2181,10.23.209.72:2181 --topic test Topic:test PartitionCount:3 ReplicationFactor:3 Configs: Topic: test Partition: 0 Leader: 70 Replicas: 70,72,71 Isr: 70,72,71 Topic: test Partition: 1 Leader: 71 Replicas: 71,70,72 Isr: 71,70,72 Topic: test Partition: 2 Leader: 72 Replicas: 72,71

面试题 如何保证消息的顺序性？ 面试官心理分析 其实这个也是用 MQ 的时候必问的话题，第一看看你了不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这是生产系统中常见的问题。 面试题剖析 我举个例子，我们以前做过一个 mysql binlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（ mysql -> mysql ）。常见的一点在于说比如大数据 team ，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作。 你在 mysql 里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog 发送到 MQ 里面，再消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。 本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。 先看看顺序会错乱的俩场景： RabbitMQ ：一个 queue ，多个 consumer 。比如，生产者向 RabbitMQ 里发送了三条数据，顺序依次是 data1/data2/data3 ，压入的是 RabbitMQ 的一个内存队列。有三个消费者分别从 MQ

Kafka在0.8以前的版本中，并不提供High Availablity机制，一旦一个或多个Broker宕机，则宕机期间其上所有Partition都无法继续提供服务。若该Broker永远不能再恢复，亦或磁盘故障，则其上数据将丢失。而Kafka的设计目标之一即是提供数据持久化，同时对于分布式系统来说，尤其当集群规模上升到一定程度后，一台或者多台机器宕机的可能性大大提高，对Failover要求非常高。因此，Kafka从0.8开始提供High Availability机制。本文从Data Replication和Leader Election两方面介绍了Kafka的HA机制。 Kafka为何需要High Available 为何需要Replication 在Kafka在0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的Partition数据都不可被消费，这与Kafka数据持久性及Delivery Guarantee的设计目标相悖。同时Producer都不能再将数据存于这些Partition中。 如果Producer使用同步模式则Producer会在尝试重新发送 message.send.max.retries （默认值为3）次后抛出Exception，用户可以选择停止发送后续数据也可选择继续选择发送。而前者会造成数据的阻塞

什么是RDD RDD（Resilient Distributed Dataset）叫做分布式数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、弹性、里面的元素可并行计算的集合 RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度 RDD支持两种操作:转化操作和行动操作 Spark采用惰性计算模式，RDD只有第一次在一个行动操作中用到时，才会真正计算 属性: 一组分区（Partition） 一个计算每个分区的函数 RDD之间的依赖关系 一个Partitioner 一个列表 移动数据不如移动计算 每个节点可以起一个或多个Executor。 每个Executor由若干core组成，每个Executor的每个core一次只能执行一个Task。 每个Task执行的结果就是生成了下一个RDD的一个partiton。 特点: 分区:RDD逻辑上是分区的，每个分区的数据是抽象存在的 只读:RDD是只读的，要想改变RDD中的数据，只能在现有的RDD基础上创建新的RDD 依赖:RDDs通过操作算子进行转换，转换得到的新RDD包含了从其他RDDs衍生所必需的信息，RDDs之间维护着这种血缘关系，也称之为依赖 缓存:如果在应用程序中多次使用同一个RDD，可以将该RDD缓存起来，这样就加速后期的重用 checkPoint

WaitGroup kafka消费者 WaitGroup WaitGroup在go语言中，用于线程同步，单从字面意思理解，wait等待的意思，group组、团队的意思，WaitGroup就是指等待一组，等待一个系列执行完成后才会继续向下执行。 package main import ( "fmt" "sync" "time" ) func main() { wg := sync .WaitGroup {} for i := 0 ; i < 10; i++ { wg .Add ( 1 ) go calc(&wg, i) } wg .Wait () fmt .Println ( "all goroutine finish" ) } func calc(w *sync .WaitGroup , i int) { fmt .Println ( "calc:" , i) time .Sleep (time .Second ) w .Done () } 输出如下： PS E:\golang\go_pro\src\safly> go run waitGroup .go calc: 0 calc: 1 calc: 4 calc: 2 calc: 3 calc: 9 calc: 6 calc: 7 calc: 5 calc: 8 all goroutine finish PS E:\golang

APPLIES TO: Oracle Database - Enterprise Edition - Version 11.2.0.4 to 11.2.0.4 [Release 11.2] Information in this document applies to any platform. SYMPTOMS In this case, the issue is observed in three different RAC databases, each on 11.2.0.4, that were experiencing excessive PRTMV memory allocation during weekly partition maintenance operations. The PRTMV memory allocated by the instances reached 100G in some cases: Example: SQL> select name, bytes from v$sgastat where pool = 'shared pool' and (bytes > 999999 or name = 'free memory') order by bytes desc; NAME BYTES -------------------------

一、搭建iscsi存储服务 安装target [root@localhost wuqiong]# yum install -y scsi-target-utils [root@localhost wuqiong]# ls /etc/tgt/targets.conf /etc/tgt/targets.conf[root@localhost wuqiong]# /etc/init.d/tgtd start[root@localhost wuqiong]# systemctl start tgtd.service [root@localhost wuqiong]# systemctl status tgtd.service [root@localhost wuqiong]# systemctl restart tgtd.service 新建存储分区： sda4 [root@localhost wuqiong]# fdisk -l Disk /dev/sda: 107.4 GB, 107374182400bytes 255heads, 63sectors/track, 13054cylinders Units =cylinders of 16065* 512=8225280bytes Sector size (logical/physical): 512bytes / 512bytes I

分库分区分表概念 分区 　　就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的 分表 　　就是把一张数据量很大的表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。表名可以按照某种业务hash进行映射。单表数据量大于500万或者并发大于1200时考虑分表。 分库 　　一旦分表，一个库中的表会越来越多。当一个数据库的表数量到达一定的量时（>200），此时应该考虑分库。 一、分区 　　mysql数据库中的数据是以文件的形势存在磁盘上的，默认放在/mysql/data下面（可以通过my.cnf中的datadir来查看），一张表主要对应着三个文件，一个是frm存放表结构的，一个是myd存放表数据的，一个是myi存表索引的。如果一张表的数据量太大的话，那么myd,myi就会变的很大，查找数据就会变的很慢，这个时候我们可以利用mysql的分区功能，在物理上将这一张表对应的三个文件，分割成许多个小块，这样呢，我们查找一条数据时，就不用全部查找了，只要知道这条数据在哪一块，然后在那一块找就行了。如果表的数据太大，可能一个磁盘放不下，这个时候，我们可以把数据分配到不同的磁盘里面去。 分区的二种方式 a，横向分区 什么是横向分区呢？就是横着来分区了，举例来说明一下，假如有100W条数据，分成十份