寫在前面：如果對(duì)分庫分表還不是很熟悉的，可以參考筆者之前的文章《分庫分表技術(shù)演進(jìn)暨最佳實(shí)踐》。
在這篇文章中提到了一個(gè)場(chǎng)景，即電商的訂單讹语。我們都知道訂單表有三大主要查詢：基于訂單ID查詢，基于商戶編號(hào)查詢蜂科，基于用戶ID查詢顽决。且那篇文章給出的方案是基于訂單ID、商戶編號(hào)导匣、用戶ID都有一份分庫分表的數(shù)據(jù)才菠。那么為什么要這么做？能否只基于某一列例如用戶ID分庫分表贡定，答案肯定是不能赋访。
筆者基于sharding-sphere（GitHub地址：https://github.com/apache/incubator-shardingsphere）進(jìn)行了一個(gè)簡(jiǎn)單的測(cè)試，測(cè)試環(huán)境如下：
- 128個(gè)分表：image_${0..127}缓待；
- 數(shù)據(jù)庫服務(wù)器：32C64G蚓耽；
- 數(shù)據(jù)庫版本：MySQL-5.7.23；
- 操作系統(tǒng)：CentOS 6.9 Final旋炒；
- 連接池：druid 1.1.6步悠；
- mysql-connector-java：6.0.5；
- mybatis：3.4.5国葬；
- mybatis-spring：1.3.1贤徒；
- springboot：1.5.9.RELEASE芹壕；
- sharding-sphere-3.1.0汇四；
- JVM參數(shù)：-Xmx2g -Xms2g -Xmn1g -Xss256k -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+AlwaysPreTouch；
- druid配置：默認(rèn)參數(shù)踢涌；
表信息如下：
-- id是分片鍵通孽。備注，DDL是偽SQL
CREATE TABLE `image_${0..127}` (
`id` varchar(32) NOT NULL,
`image_no` varchar(50) NOT NULL,
`file_name` varchar(200) NOT NULL COMMENT '影像文件名稱',
`source` varchar(32) DEFAULT NULL COMMENT '影像來源',
`create_date` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '影像文件創(chuàng)建時(shí)間',
PRIMARY KEY (`id`),
KEY `idx_image_no` (`image_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
第1個(gè)測(cè)試場(chǎng)景如下：
- 每個(gè)分表大概160w數(shù)據(jù)睁壁；
- 累計(jì)1w次跨分片(imageNo)查詢 PK. 帶分片(id)查詢背苦；
測(cè)試結(jié)果如下：
結(jié)論：由測(cè)試結(jié)果可知，跨分片查詢相比帶分片鍵查詢的性能衰減了很多潘明。
第2個(gè)測(cè)試場(chǎng)景如下：
- 每個(gè)分表大概160w數(shù)據(jù)行剂；
- 累計(jì)1w次分別測(cè)試跨1個(gè)分表，8個(gè)分表钳降、16個(gè)分表厚宰、32個(gè)分表、64個(gè)分表、128個(gè)分表铲觉，結(jié)果如下：
結(jié)論：跨的分表數(shù)量越大澈蝙，跨分表查詢的性能越差；
- 為什么慢
我們要弄明白跨分片查詢?yōu)槭裁催@么慢之前撵幽，首先要掌握跨分片查詢?cè)淼朴Ｒ詓harding-sphere為例，其跨分片查詢的原理是：通過線程池并發(fā)請(qǐng)求到所有符合路由規(guī)則的目標(biāo)分表盐杂，然后對(duì)所有結(jié)果進(jìn)行歸并逗载。需要說明的是，當(dāng)路由結(jié)果只有1個(gè)链烈，即不跨分片操作時(shí)sharding-sphere不會(huì)通過線程池異步執(zhí)行撕贞，而是直接同步執(zhí)行，這么做的原因是為了減少線程開銷测垛，核心源碼在ShardingExecuteEngine.java中）捏膨。
既然是這個(gè)執(zhí)行原理，為什么跨分片查詢食侮，隨著跨分片數(shù)量越多号涯，性能會(huì)越來越差？我們?cè)倏匆幌碌?個(gè)測(cè)試場(chǎng)景锯七，當(dāng)測(cè)試跨1個(gè)分表時(shí)链快，1w次查詢只需要5889ms，即平均1次查詢不到1ms眉尸。所以性能瓶頸不應(yīng)該在SQL執(zhí)行階段域蜗，而應(yīng)該在結(jié)果歸并階段。為了驗(yàn)證這個(gè)猜想噪猾，筆者空跑sharding-sphere依賴的并發(fā)執(zhí)行組件google-guava的MoreExecutors霉祸。其結(jié)果如下：
結(jié)論：由這個(gè)測(cè)試結(jié)果可知，當(dāng)并發(fā)執(zhí)行越來越多袱蜡，其結(jié)果歸并的代價(jià)越來越大丝蹭。
附--空跑sharding-sphere依賴的并發(fā)執(zhí)行組件google-guava的MoreExecutors的部分源碼如下：
public class ConcurrentExecutorTest {
private static final ListeningExecutorService executorService;
public static final int CONCURRENT_COUNT = 64;
public static final int batchSize = CONCURRENT_COUNT;
public static final int EXECUTOR_SIZE = 8;
static {
executorService = MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(EXECUTOR_SIZE));
MoreExecutors.addDelayedShutdownHook(executorService, 60, TimeUnit.SECONDS);
}
private static <I, O> List<O> execute(final Collection<I> inputs) {
if (inputs.isEmpty()) {
return Collections.emptyList();
}
// 并發(fā)執(zhí)行
Collection<ListenableFuture<O>> allFutures = asyncExecute(inputs);
// 結(jié)果歸并
return getResults(allFutures);
}
private static <I, O> Collection<ListenableFuture<O>> asyncExecute(final Collection<I> inputs) {
Collection<ListenableFuture<O>> result = new ArrayList<>(inputs.size());
for (final I each : inputs) {
// 異步執(zhí)行時(shí)直接返回結(jié)果
result.add(executorService.submit(() -> (O) each));
}
return result;
}
private static <O> List<O> getResults(final Collection<ListenableFuture<O>> allFutures) {
List<O> result = new LinkedList<>();
for (ListenableFuture<O> each : allFutures) {
result.add(each.get());
}
return result;
}
}
-- 最后總結(jié)
跨分片查詢的性能這么差，為什么sharding-sphere還要去做呢坪蚁？筆者認(rèn)為首先sharding-sphere是一個(gè)通用的分庫分表中間件奔穿，而不是在某些特定條件才能使用的中間件，所以應(yīng)該要盡可能的兼容所有SQL敏晤。其次贱田，即使跨分片查詢性能這么差，這個(gè)主要是在OLTP系統(tǒng)中使用時(shí)要小心嘴脾，在一些OLAP或者后臺(tái)管理系統(tǒng)等一些低頻次操作的系統(tǒng)中男摧，還是可以使用的。
比如，賬戶表已經(jīng)根據(jù)賬戶ID分表彩倚，但是在運(yùn)營(yíng)操作的后臺(tái)管理系統(tǒng)中維護(hù)賬戶信息時(shí)筹我，肯定有一些操作的SQL是不會(huì)帶有分片鍵賬戶ID的，比如查詢賬戶余額最多的88個(gè)土豪用戶帆离。這個(gè)時(shí)候蔬蕊，我們可以通過sharding-sphere中間件直接執(zhí)行這條低頻次SQL。而不需要為了這些操作引入es或者其他組件來解決這種低頻次的問題（當(dāng)然哥谷，隨著系統(tǒng)的演進(jìn)岸夯，最后可能還是需要引入es等一些中間件來解決這些問題）。所以们妥，分庫分表中間件的跨分片查詢?cè)陧?xiàng)目特定階段能夠大大減少開發(fā)成本猜扮，從而以最短的時(shí)間上線業(yè)務(wù)需求。
