发表于 | 分类于 ， ，

TeXmacs

GNU TeXmacs 1.99.8 已发布，这是一个支持各种数学公式的所见即所得编辑器，可以用来编辑文本、图形、数学、交互内容，它的界面非常友好，并且内置高质量的排版引擎。

发表于 | 分类于 ， ，

术语

覆盖索引（索引覆盖）

  • 解释一： 就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。

  • 解释二： 索引是高效找到行的一个方法，当能通过检索索引就可以读取想要的数据，那就不需要再到数据表中读取行了。如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫做覆盖索引。

  • 解释三： 是非聚集组合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段，也即，索引包含了查询正在查找的所有数据）。

实战

背景

  • 表结构
1
2
3
4
5
6
7
CREATE TABLE `t_order` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `order_code` char(12) NOT NULL,
  `order_amount` decimal(12,2) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uni_order_code` (`order_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

在 order_code 上创建了唯一性索引 uni_order_code

  • 数据条数：32W条

  • SQL：select order_code, order_amount from t_order order by order_code limit 1000;

  • 执行计划

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t_order ALL NULL NULL NULL NULL 316350 Using filesort

全表扫描、文件排序，注定查询慢！

那为什么MySQL没有利用索引（uni_order_code）扫描完成查询呢？

因为MySQL认为这个场景利用索引扫描并非最优的结果。我们先来看下执行时间，然后再来分析为什么没有利用索引扫描。

  • 执行时间：260ms

如果表数据量继续增长下去，性能会越来越差。

分析

MySQL为什么使用全表扫描、文件排序，而没有使用索引扫描、利用索引顺序？

  • 全表扫描、文件排序

虽然是全表扫描，但是扫描是顺序的（不管机械硬盘还是 SSD 顺序读写性能都是高的），并且数据量不是特别大，所以这部分消耗的时间应该不是特别大，主要的消耗应该是在排序上。

  • 利用索引扫描、利用索引顺序

uni_order_code 是二级索引，索引上保存了（order_code,id），每扫描一条索引需要根据索引上的 id 定位（随机 IO）到数据行上读取order_amount，需要1000次随机IO才能完成查询，而机械硬盘随机 IO 的效率是极低的（机械硬盘每秒寻址几百次）。

既然我们已经知道是因为随机IO导致无法利用索引，那么有没有办法消除随机IO?

解决办法：覆盖索引。

优化方案

  • 创建索引
1
2
ALTER TABLE `t_order` 
ADD INDEX `idx_ordercode_orderamount` USING BTREE (`order_code` ASC, `order_amount` ASC);

创建了复合索引 idx_ordercode_orderamount(order_code,order_amount)，将 select 的列 order_amount 也放到索引中。

  • 执行计划

id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t_order index NULL idx_ordercode_orderamount 42 NULL 1000 Using index

  • 执行时间：13ms

从执行时间来看，SQL 的执行时间提升到原来的 1/20，已经达到我们的预期。

总结

覆盖索引是select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖。索引的字段不只包含查询列，还包含查询条件、排序等。

要写出性能很好的SQL不仅需要学习SQL，还要能看懂数据库执行计划，了解数据库执行过程、索引的数据结构等。

Refer to

聚集索引：https://www.cnblogs.com/chillsrc/archive/2012/09/04/2671092.html

发表于 | 分类于 ， ，

优化思路

思路一

  • 优化SQL和索引。考虑点：引擎类型，数据分布，索引情况，锁策略，业务特点。
  • 加缓存，比如Redis等等
  • 主从复制；主主复制；读写分离
  • MySQL自带分区表
  • 垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；
  • 水平拆分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding key，将数据定位到限定的表上去查，而不是扫描全部的表；

MySQL数据库一般都是按照这个步骤去演化的，成本也是由低到高。

思路二

对于一个存储设计，必须考虑业务特点，收集的信息如下：

  • 数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；
  • 数据项：是否有大字段，那些字段的值是否经常被更新；
  • 数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；
  • 数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；
  • SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？
  • 预计大表及相关联的SQL，每天总的执行量在何数量级？
  • 表中的数据：更新为主的业务，还是查询为主的业务
  • 打算采用什么数据库物理服务器，以及数据库服务器架构？
  • 并发如何？
  • 存储引擎选择InnoDB还是MyISAM？

大致明白以上10个问题，至于如何设计此类的大表，应该什么都清楚了！

至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈。

另外对优化索引结构去解决性能问题的话，建议优先考虑修改类SQL语句，使他们更快些，不得已只靠索引组织结构的方式，当然此话前提是，
索引已经创建的非常好，若是读为主，可以考虑打开query_cache，以及调整一些参数值：sort_buffer_size，read_buffer_size，read_rnd_buffer_size，join_buffer_size

思路三

MySQL 数据库设计总结：https://cloud.tencent.com/developer/article/1004367

  • 联合索引的建立原则(以下均假设在数据库表的字段a,b,c上建立联合索引(a,b,c))

    • 联合索引中的字段应尽量满足过滤数据从多到少的顺序，也就是说差异最大的字段应该房子第一个字段
    • 建立索引尽量与SQL语句的条件顺序一致，使SQL语句尽量以整个索引为条件，尽量避免以索引的一部分(特别是首个条件与索引的首个字段不一致时)作为查询的条件
    • Where a=1；where a>=12 and a<15；where a=1 and b<5 ；where a="1" and b="7" c>=40为条件可以用到此联合索引；而这些语句where b=10；where c=221；where b>=12 and c=2则无法用到这个联合索引。
    • 当需要查询的数据库字段全部在索引中体现时，数据库可以直接查询索引得到查询信息无须对整个表进行扫描(这就是所谓的key-only)，能大大的提高查询效率。特别注意，当a，ab，abc与其他表字段关联查询时可以用到索引。

  • 合理构造Query语句

    • Insert语句中，根据测试，批量一次插入1000条时效率最高，多于1000条时，要拆分，多次进行同样的插入，应该合并批量进行。注意query语句的长度要小于mysqld的参数 max_allowed_packet
    • 查询条件中各种逻辑操作符性能顺序是and > or > in，因此在查询条件中应该尽量避免使用在大集合中使用in

思路四

背景：有三张表，是5亿的数据，每天张表每天的增量是100w，每张表大概在10个columns左右

当前使用mysiam，没有做分区。在只读情况下，比innodb的效率要高13％左右。

在做了partition之后，读一下mysql的官方文档，其实对于partition，专门是对myisam做的优化，对于innodb，所有的数据是存在ibdata里面的，所以即使你可以看到schema变了，其实没有本质的变化。在分区出于同一个physical disk下面的情况下，提升大概只有1％

在分区在不同的physical disk下，分到了三个不同的disks下，提升大概在3％，其实所谓的吞吐量，由很多因素决定的，比如你的explain parition时候可以看到，record在那一个分区，如果每个分区都有，其实本质上没有解决读的问题，这样只会提升写的效率。

另外一个问题在于，分区，你怎么分，如果一张表，有三个column都是经常被用于做查询条件的，其实是一件很悲惨的事情，因为你没有办法对所有的sql做针对性的分区，如果你只是如mysql官方文档上说的，只对时间做一个分区，而且你也只用时间查询的话，恭喜你。

参考链接

https://www.zhihu.com/question/19719997

发表于 | 分类于 ， ，

资源利用特点

CPU

  • 5.1可以利用4个核；5.5可以利用到24个核；5.6可以利用到64个核
  • 每个连接一个是一个线程(非thread pool)，每个query只能使用到一个核，随着连接数增加，性能下降
  • 无执行计划缓存(无SQL执行计划预编译)
  • 有Result缓存，但比较鸡肋

内存

  • 64位系统可利用内存（2的64次方）GB
  • 在高速并发环境，基本是靠内存缓存来减少对磁盘的IO冲击
  • 通常内存按实际数据的15%-20%规划，如果特别热的数据，需要考虑更大的比例来缓存数据
  • 可以根据Query响应时间来做指导分配
  • query cache建议关闭或设置很小

磁盘

  • Binlog，redo log，undo log顺序IO
  • Datafile 随机IO和顺序IO相结合
  • OLTP业务更多的需要随机IO（可以利用内存做缓存，从而减少随机IO）
  • OLAP业务更多需要顺序IO（内存缓存作用不大）

性能特性

HOT（堆表）和IOT（索引组织表）的区别

  • 起源

堆组织表的存储速度因为不用考虑排序，所以存储速度会比较快。但是要查找符合某个条件的记录，就必须得读取全部的记录以便筛选。而这个时候为了加快查询速度，索引就出现了，索引是针对少量特定字段的值拿出来进行排序存储，并记录在表中的位置，而因为索引是有序的，所以就会很容易通过索引查询到具体的记录位置（普遍使用二分查找法），然后再根据记录位置直接从表中读取该记录。同时因为索引的字段较少，所以索引通常会比其基表小得多。

从上面通过索引访问表记录的方式可以看出，当要访问的数据量较大时，通过每一条记录的位置去访问原始记录，每一条符合条件的记录都需要经过索引访问后再访问基表这样一个复杂的过程，这会花费很多时间。同样，如果不经过索引而直接查询表，也可能因为表字段太多，记录较大的情况下把全部的数据读取进来，这也会花费很多时间。

那怎么办呢？这个时候就会想到，如果表中数据本身就是有序的，这样查询表的时候就可以快速的找到符合条件的记录位置，而很容易判断符合条件记录的位置，这样只需要读取一小部分数据出来就可以了，不需要全表记录都读取出来进行判断。索引组织表就这样产生了，当然索引表中插入，更新的时候可能会因为需要排序而将数据重组，这时候数据插入或更新速度会比堆组织表慢一些。如果堆组织表上有索引，那么对堆组织表的插入也会因为要修改索引而变慢。

  • 堆表

堆表（heap table）数据插入时时存储位置是随机的，主要是数据库内部块的空闲情况决定，获取数据是按照命中率计算，全表扫表时不见得先插入的数据先查到。

堆表的特点就是索引和数据分开，所有索引都是二级索引，或叫辅助索引。所以主键索引也是二级索引，没有完整记录，区别只有唯一或非唯一。索引中存储的是key与指针，指针指向具体数据记录。当然，查找key的算法都是一样的，使用二分查找，也叫书签查找。

两者的查找方式都一样，通过先找到key，然后定位到数据。不论是通过主键还是二级索引，两者的开销都是一样的。

  • 索引表

索引表（IOT）数据存储是把表按照索引的方式存储的，数据是有序的，数据的位置是预先定好的，与插入的顺序没有关系。

索引表的查询效率逼堆表高（相当于查询索引的效率），插入数据的速度比堆表慢。

索引组织表必须要有主键，如果非显式创建，InnoDB存储引擎会默认创建一个ROWID当做主键；而堆表则无强制要求。

这就是经常有文章说MyISAM比InnoDB快的原因吧，但这个说法并不完全正确，索引组织表由于索引项和数据存储在一起，且InnoDB聚集索引各个叶子节点之间都是同过双向链表组织，且都是根据主键逻辑顺序存放，所以无论是基于主键的等值查询还是范围查询都能大大节省磁盘访问时间。

特别对于范围查询，只需要定位到开始key的位置，就可以顺着这个位置扫描到结束key。如下SQL语句：

1
select * from table where id between 1000 and 2000

超大单表问题

常见的水平切分方式：分库分表；分区表

  • 什么是分库分表？

把一个很大的库（表）的数据分到几个库（表）中，每个库（表）的结构都相同，但他们可能分布在不同的mysql实例，甚至不同的物理机器上，以达到降低单库（表）数据量，提高访问性能的目的。分库分表往往是业务层实施的，分库分表后，为了满足某些特定业务功能，往往需要rd修改代码。

  • 什么是分区表？

所有数据还在一个表中，但物理存储根据一定的规则放在不同的文件中。这个是mysql支持的功能，业务rd代码无需改动。

看上去分区表很帅气，为什么大部分互联网还是更多的选择自己分库分表来水平扩展咧？

    • 分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁
    • 旦数据量并发量上来，如果在分区表实施关联，就是一个灾难
    • 自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定mysql是怎么玩的，不太可控

水平拆分设计与约束

缺点

  • 数据分散，group by ,order by , sum, count等排序，聚 集函数不能支持，如果一定需要，需要某一个地方存全量
  • 分片过多，会造成维护难度增加，比较定位(要求分区尽可能的简单)
  • 后期迁移较复杂

优点

  • 同一个功能内的关连，事务操作都可以进行
  • 不会存在超大规模的表
  • 应用程序端改动比较小
  • 拆分规则设计的好的情况，较难触到性能瓶颈，也比较 易扩展

Reference

发表于 | 分类于 ，

java.lang.OutOfMemoryError: Requested array size exceeds VM limit

原因分析：这个错误是由JVM中的本地代码抛出的. 在真正为数组分配内存之前, JVM会执行一项检查: 要分配的数据结构在该平台是否可以寻址(addressable)。

一般很少看到这个错误, 因为Java使用 int 类型作为数组的下标(index, 索引)。在Java中, int类型的最大值为 2^31 – 1 = 2,147,483,647。大多数平台的限制都约等于这个值，例如在 64位的 MB Pro 上, Java 1.7 平台可以分配长度为 2,147,483,645, 以及 Integer.MAX_VALUE-2) 的数组。

参考链接

https://blog.csdn.net/renfufei/article/details/78170188

发表于 | 分类于

基础知识

一个对象池需要完成哪些功能：

  • 如果有可用的对象，对象池应当能返回给客户端。
  • 客户端把对象放回池里后，可以对这些对象进行重用。
  • 对象池能够创建新的对象来满足客户端不断增长的需求。
  • 需要有一个正确关闭池的机制来确保关闭后不会发生内存泄露。

参考链接

http://ifeve.com/generic-concurrent-object-pool/

发表于 | 分类于

UUID

  1. 什么是UUID？
    UUID是通用唯一标识符（Universally Unique Identifier）。由128bit组成，如果用16进制表示，那么就是32个字符。表示形式如下：03e1c09e-4967-469c-85f5-764c5b286d47（8-4-4-4-12）。
  1. UUID的作用？
    让分布式系统中的所有元素都能有唯一的辨识资讯，而不需要通过中央控制端来作辨别资讯的指定。
  1. UUID由哪些元素组成才能让其成为唯一？
    UUID指在一台机器上生成的数字，他保证对在同一时空内的所有机器都是唯一的。说得明白一点就是它能保证无论在某时某地某台机器上它都能生成一个唯一字符串。

组成部分：

  • 当前日期及时间
  • 时钟序列
  • 全局唯一的IEEE机器识别号。

生成算法

基于随机数的UUID

1
UUID.randomUUID().toString()

发表于 | 分类于 ，

如何解决前置Handler批处理造成后置Handler阻塞问题

举例，生产消费链条： P -> C1 -> C2

假如P生产者一次性生产了1000万条数据，在默认情况下，C1必须消费完这1000万条数据后，C2才能继续接着处理这1000万条数据，在实际情况中，这是不合理的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
private void processEvents() {
    T event = null;
    long nextSequence = sequence.get() + 1L;

    while (true) {
        try {
            final long availableSequence = sequenceBarrier.waitFor(nextSequence);
            if (batchStartAware != null && availableSequence >= nextSequence) {
                batchStartAware.onBatchStart(availableSequence - nextSequence + 1);
            }

            while (nextSequence <= availableSequence) {
                event = dataProvider.get(nextSequence);
                eventHandler.onEvent(event, nextSequence, nextSequence == availableSequence);
                nextSequence++;
            }

            sequence.set(availableSequence);
        } catch (final TimeoutException e) {
            notifyTimeout(sequence.get());
        } catch (final AlertException ex) {
            if (running.get() != RUNNING) {
                break;
            }
        } catch (final Throwable ex) {
            exceptionHandler.handleEventException(ex, nextSequence, event);
            sequence.set(nextSequence);
            nextSequence++;
        }
    }
}

在这段代码中，只有当前一个消费者调用了 sequence.set(availableSequence) 后，下一个消费者才能接着消费数据。

The call to sequence.set() is placed at the end of the callback to provide the maximum possible throughput.

The call to Sequence.set() is reasonably cheap but not as fast as a standard variable assignment as it requires atomicity and enforces ordering. However the use case that you mention is a common one therefore we have a specific type of event handler for it.

If you want to have an event handler that updates the sequence more frequently that the default, then you should use the SequenceReportingEventHandler.

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MyHandler implements SequenceReportingEventHandler<Data> {
    private final Buffer buffer = new Buffer();
    private Sequence sequence;

    @Override // The Sequence is passed in by the batch event processor
    public void setSequenceCallback(Sequence sequence) {
        this.sequence = sequence;
    }

    public void onEvent(Data data, long sequence, boolean endOfBatch) {
        this.sequence.set(sequence);  
    }
}

https://groups.google.com/forum/#!searchin/lmax-disruptor/batch$20processor|sort:date/lmax-disruptor/_2m1WKrcXUo/cMTSMq6SAwAJ