今天的分享主要包含以下幾個(gè)方面的內(nèi)容：

• CrateDB介紹
• CrateDB在攜程的實(shí)踐
• CrateDB在攜程的優(yōu)化
• 總結(jié)

一、CrateDB介紹

1、CrateDB

CrateDB是一款基于ElasticSearch的分布式數(shù)據(jù)庫(kù)，它與ElasticSearch最大的區(qū)別是提供了ANSI SQL查詢(xún)?cè)L問(wèn)接口。ElasticSearch在6.X版本以后，也開(kāi)始提供SQL的查詢(xún)，但CrateDB與ElasticSearch相比，能夠支持多索引之間的關(guān)聯(lián)查詢(xún)，針對(duì)某些聚合函數(shù)，它返回的是精確的查詢(xún)結(jié)果，而ElasticSearch返回的是近似值。

2、CrateDB的特性

• 適用于海量時(shí)序數(shù)據(jù)存儲(chǔ)

CrateDB適用于海量時(shí)序數(shù)據(jù)存儲(chǔ)，需要頻繁更改的數(shù)據(jù)使用CrateDB存儲(chǔ)效果較差。因?yàn)镃rateDB基于ElasticSearch，頻繁的刪改操作會(huì)使它的性能大大受損。

• 高可靠水平可擴(kuò)

CrateDB繼承了ElasticSearch設(shè)計(jì)中高可靠的優(yōu)點(diǎn)，集群較方便實(shí)現(xiàn)擴(kuò)容，對(duì)于一些點(diǎn)查詢(xún)或復(fù)雜度中等的查詢(xún)均能夠較為實(shí)時(shí)地返回結(jié)果。

• 支持Dynamic Schema

CrateDB支持Dynamic Schema，其最新版本能夠支持json數(shù)據(jù)格式，寫(xiě)入數(shù)據(jù)更加方便。

我認(rèn)為CrateDB的初衷是用SQL的方式查詢(xún)?cè)L問(wèn)基于ElasticSearch存儲(chǔ)的數(shù)據(jù)。基于這一概念，我們可以看到它大概的分層（如上圖所示），從外部訪(fǎng)問(wèn)從下到上依次到達(dá)最終的存儲(chǔ)，其最外一層提供了PostgresSQL兼容的訪(fǎng)問(wèn)協(xié)議和REST API的訪(fǎng)問(wèn)協(xié)議，接下來(lái)對(duì)語(yǔ)句進(jìn)行解析，然后執(zhí)行，獲取存儲(chǔ)在各個(gè)節(jié)點(diǎn)上的數(shù)據(jù)。

3、海量數(shù)據(jù)存儲(chǔ)對(duì)比

因?yàn)轭?lèi)似技術(shù)較多，這里只對(duì)比幾個(gè)典型的技術(shù)，CrateDB、ElasticSearch以及MongoDB，這三者都可以歸類(lèi)于Nosql。下文將從7個(gè)維度對(duì)三者進(jìn)行對(duì)比。

1）Schema支持類(lèi)型

這三個(gè)數(shù)據(jù)庫(kù)均支持Dynamic Schema。但在現(xiàn)實(shí)的生產(chǎn)環(huán)境下，我們推薦采用Struct Schema，因?yàn)镈ynamic Schema可能會(huì)帶來(lái)種種問(wèn)題。

僅代表個(gè)人觀點(diǎn)，并非適用于所有場(chǎng)景。

2）是否支持SQL訪(fǎng)問(wèn)

SQL誕生四十多年，已成為非常成熟的語(yǔ)言，具有極強(qiáng)的表達(dá)能力。同時(shí)SQL具有通用性，被大家普遍接受。CrateDB基于SQL的通用性不斷發(fā)展，其支持ANSI SQL，并且采用了PostgreSQL協(xié)議。

ElasticSearch起初只支持類(lèi)json格式的查詢(xún)語(yǔ)法，之后開(kāi)始提供針對(duì)單索引的一些SQL語(yǔ)句支持函數(shù)，并不斷豐富。MongoDB據(jù)我所知并未直接支持SQL，如果寫(xiě)入SQL語(yǔ)句，需要通過(guò)第三方插件才能夠被MongoDB識(shí)別，這在一定程度上會(huì)影響查詢(xún)性能。

3）可擴(kuò)展性

從可擴(kuò)展性角度出發(fā)，CrateDB和ElasticSearch采用gossip協(xié)議組建集群，簡(jiǎn)單來(lái)說(shuō)節(jié)點(diǎn)之間相應(yīng)對(duì)等。在一個(gè)ElasticSearch集群中，節(jié)點(diǎn)可分Master、Coordinator，以及承載數(shù)據(jù)的Data，一個(gè)節(jié)點(diǎn)可以同時(shí)扮演三個(gè)不同的角色，因此它們是對(duì)等的。

MongoDB則不同，如果用它來(lái)構(gòu)建一個(gè)分布式集群，最起碼有三個(gè)不同的Host，分別是Config Server、Mongos以及Data，為了實(shí)現(xiàn)高可靠，一個(gè)分片還需要分成相應(yīng)的Master或Slave。

綜上所述，從可擴(kuò)展角度來(lái)看，ElasticSearch和CrateDB更好。

4）對(duì)于關(guān)聯(lián)分析的支持程度

CrateDB支持跨索引之間的關(guān)聯(lián)分析，而ElasticSearch則使用一些變通的方式支持此類(lèi)關(guān)聯(lián)查詢(xún)，這意味著在寫(xiě)入數(shù)據(jù)時(shí)需要做相應(yīng)變更。MongoDB在4.X版本時(shí)不支持關(guān)聯(lián)查詢(xún)，之后的版本未及時(shí)關(guān)注，如描述有誤，歡迎大家指正。

5）聚合準(zhǔn)確度

CrateDB和MongoDB返回精確值，ElasticSearch則是返回近似值，雖然返回近似值執(zhí)行速度快，但其計(jì)算的準(zhǔn)確度會(huì)受到一定影響。

6）性能

在查詢(xún)性能方面， CrateDB和ElasticSearch都能夠較好地返回查詢(xún)結(jié)果，上圖中列出的耗時(shí)為100毫秒。對(duì)于較為簡(jiǎn)單的查詢(xún)，100毫秒算是較高的消耗，事實(shí)上可以在更短的時(shí)間內(nèi)返回結(jié)果。后文中會(huì)提到我們自己質(zhì)量環(huán)境下的實(shí)際耗時(shí)。

7）運(yùn)維

引入一項(xiàng)新技術(shù)后，其帶來(lái)的運(yùn)維復(fù)雜度十分關(guān)鍵。CrateDB和ElasticSearch相較于MongoDB運(yùn)維復(fù)雜度更低。

4、CrateDB系統(tǒng)架構(gòu)及節(jié)點(diǎn)類(lèi)型

上文中提到在CrateDB和ElasticSearch中節(jié)點(diǎn)之間相互對(duì)等。以ElasticSearch舉例，由5個(gè)節(jié)點(diǎn)構(gòu)成的ElasticSearch集群中起碼有兩個(gè)不同的角色。

• Master

該角色需要負(fù)責(zé)兩個(gè)方面的工作，分別是管理節(jié)點(diǎn)和管理索引。節(jié)點(diǎn)加入集群，在集群中創(chuàng)建了多少個(gè)不同的索引，這些索引的分片分布在哪些機(jī)器上，這些信息都由 Master來(lái)管理。

• 數(shù)據(jù)節(jié)點(diǎn)

我們創(chuàng)建好的索引，數(shù)據(jù)最終要落到一個(gè)具體的ElasticSearch節(jié)點(diǎn)上，這些最終承載數(shù)據(jù)的就是數(shù)據(jù)節(jié)點(diǎn)。

上圖右半部分所示為在生產(chǎn)上部署一個(gè)CrateDB或ElasticSearch集群。最上方的負(fù)載均衡部分可有可無(wú)。除上文提到的兩種節(jié)點(diǎn)類(lèi)型外，還有一種叫做Coordinator的節(jié)點(diǎn)類(lèi)型，它既不承載具體的數(shù)據(jù)，也不扮演Master的角色，只接受外部的請(qǐng)求，并將外部請(qǐng)求路由到數(shù)據(jù)節(jié)點(diǎn)上做具體查詢(xún)，然后在Coordinator節(jié)點(diǎn)做一些匯總，最后返回給應(yīng)用程序。除此之外，ElasticSearch中可能還會(huì)有一個(gè)叫Ingest的節(jié)點(diǎn)類(lèi)型，這里不進(jìn)行過(guò)多闡述。

綜上所述，一個(gè)CrateDB的表類(lèi)似于一個(gè)ElasticSearch的索引，ElasticSearch中索引由多個(gè)不同的分片組成，每一個(gè)分片可能會(huì)落到某一個(gè)數(shù)據(jù)節(jié)點(diǎn)上。為了實(shí)現(xiàn)高可靠，一個(gè)分片又分成主分片和副本分片，即圖中列出的Primary和Secondary。

5、CrateDB具體操作

1）表創(chuàng)建

這個(gè)操作和我們平時(shí)用PostgreSQL或MySQL創(chuàng)建一張表并無(wú)很大差別。

創(chuàng)建一張職工的表（如上圖所示），其中包括姓名、年齡、性別以及住址。這張表根據(jù)姓名來(lái)進(jìn)行哈希，哈希的結(jié)果分到4個(gè)不同的分片中，with后面跟著一些針對(duì)索引層面的配置，它的配置項(xiàng)多達(dá)幾十項(xiàng)。我們最主要關(guān)注以下幾點(diǎn)：

• 分片的副本數(shù)

如果只有主分片，replica數(shù)為0。如果在主分片之外，還有別的副本分片，增加相應(yīng)的replica數(shù)即可。

• refresh_interval

ElasticSearch進(jìn)行刷新數(shù)據(jù)會(huì)從內(nèi)存刷新到磁盤(pán)，不斷刷新會(huì)降低性能。為了保證更多數(shù)據(jù)留在內(nèi)存中，減少刷新的次數(shù)，我們可以調(diào)節(jié)刷新間隔，具體調(diào)整根據(jù)對(duì)數(shù)據(jù)的新鮮度要求而定。數(shù)據(jù)只有被刷新后才能被搜索到。

• translog.sync_interval

ElasticSearch采用的是write ahead log的方式，這意味著有大量的translog。translog同樣將數(shù)據(jù)從內(nèi)存寫(xiě)到磁盤(pán)，這當(dāng)中有一個(gè)sync的間隔，如果調(diào)高這一間隔，可能會(huì)加快寫(xiě)入速度，但也有可能帶來(lái)容錯(cuò)方面的問(wèn)題。

2）樂(lè)觀并發(fā)控制

CrateDB是基于ElasticSearch的數(shù)據(jù)庫(kù)，其在ElasticSearch基礎(chǔ)上進(jìn)行了叫做樂(lè)觀并發(fā)控制的演變。我們將數(shù)據(jù)寫(xiě)入到某一張表時(shí)，有兩個(gè)隱藏的列，一個(gè)是sequence_number，即這一列的版本號(hào)，另一個(gè)為primary_term，二者聯(lián)合使用可以實(shí)現(xiàn)某一版本的數(shù)據(jù)只更新一次，避免頻繁更新。

以上圖中的語(yǔ)句為例，對(duì)sequence_number等于0進(jìn)行更新，當(dāng)這條語(yǔ)句執(zhí)行成功后，它的sequence_number會(huì)自動(dòng)跳到1，每更新一次，這個(gè)值就會(huì)遞增。如果有兩個(gè)不同的進(jìn)程或兩個(gè)不同的外部訪(fǎng)問(wèn)，試圖來(lái)更新同一條語(yǔ)句，那么只有一條會(huì)被執(zhí)行成功，這就做到了樂(lè)觀并發(fā)控制。

3）Partitioned Table

CrateDB與ElasticSearch不同，它引入了Partitioned Table的概念，即所謂的分區(qū)表。

上文中講到一個(gè)表存在多個(gè)分片承載數(shù)據(jù)，即ElasticSearch的一個(gè)索引有多個(gè)不同的分片，對(duì)應(yīng)到CrateDB中是分區(qū)，CrateDB中的分區(qū)可以與ElasticSearch中的別名相對(duì)應(yīng)。

如果我們要查詢(xún)或?qū)懭氡淼臄?shù)據(jù)量達(dá)幾十億或上百億，將這些表都放到同樣一個(gè)索引當(dāng)中，可能會(huì)導(dǎo)致查詢(xún)與寫(xiě)入的速度變慢，我們其實(shí)可以把這些數(shù)據(jù)分成多個(gè)不同的分區(qū)。

在我們實(shí)際的生產(chǎn)中有這樣一種情況，一些坐過(guò)飛機(jī)的用戶(hù)可能希望查看自己的飛行足跡，如果將所有用戶(hù)的歷史數(shù)據(jù)都放在同一個(gè)索引中，經(jīng)過(guò)查詢(xún)最后在前端展現(xiàn)的話(huà)，速度可能會(huì)較慢，因?yàn)檫@一操作對(duì)接口的要求較高。

例如要求在50毫秒內(nèi)返回結(jié)果，如果不把這些數(shù)據(jù)做分區(qū)的話(huà)，查詢(xún)會(huì)很慢。此處的慢是99%line的情況，在此情況下，我們要達(dá)到滿(mǎn)足性能指標(biāo)，其中一個(gè)變通方法就是把它拆成多個(gè)不同的分區(qū)，每個(gè)uid進(jìn)入后只需要到對(duì)應(yīng)的分區(qū)表查詢(xún)即可。

在做分區(qū)的時(shí)候有一點(diǎn)需要注意，如果表已經(jīng)創(chuàng)建了組件，分區(qū)的字段必須都屬于組件字段的列表，因?yàn)檫@個(gè)組件可以由一個(gè)列或多個(gè)列組成，也可能是一種復(fù)合的組件，分區(qū)的字段必須在組件的字段列表當(dāng)中。

二、CrateDB在攜程的實(shí)踐

1、實(shí)時(shí)聚合分析

上圖是我們使用CrateDB之后進(jìn)行的比較，圖中只比較了CrateDB和Presto，我們當(dāng)時(shí)的場(chǎng)景如下。

我們有不少的表，每張表的數(shù)據(jù)量都有幾千萬(wàn)條，有的甚至上億條，需要對(duì)數(shù)據(jù)做比較復(fù)雜的聚合。原來(lái)是用Presto查詢(xún)，因?yàn)樗且粋€(gè)看板，每次刷新的間隔延遲較大，為了解決這個(gè)問(wèn)題，我們嘗試了一些方法，后來(lái)發(fā)現(xiàn)用CrateDB效果較好，右側(cè)是性能對(duì)比，收益十分明顯。

1）具體分析場(chǎng)景

• 國(guó)內(nèi)產(chǎn)品/業(yè)務(wù)/收益數(shù)據(jù)分析；
• 主要對(duì)常用產(chǎn)量收益(多維度)進(jìn)行監(jiān)控；
• 進(jìn)行拆分下鉆分析；
• 進(jìn)行了sum、between、groupby、case when、left join、union all等操作。

在性能對(duì)比方面，采用CrateDB后，我們基本上能夠在1~2秒之內(nèi)返回結(jié)果。

2、海量數(shù)據(jù)存儲(chǔ)以及實(shí)時(shí)查詢(xún)

在我們實(shí)際的生產(chǎn)中有不少實(shí)時(shí)數(shù)據(jù)聚合分析的調(diào)用。

起初，我們是將數(shù)據(jù)放入Redis中，每收到一次取數(shù)請(qǐng)求，我們都會(huì)進(jìn)行相應(yīng)的代碼開(kāi)發(fā)，把取出的數(shù)據(jù)進(jìn)行相應(yīng)解析，處理之后返回給調(diào)用方。這個(gè)需求雖然不復(fù)雜，但是因?yàn)槲覀儧](méi)有辦法注入數(shù)據(jù)分析的邏輯，所以不得不進(jìn)行代碼工作。

引入CrateDB后，我們可以將分析工作采用SQL的方式來(lái)實(shí)現(xiàn)，對(duì)于那些用SQL分析不能完全解決掉的剩余部分，則聯(lián)合一些Groovy腳本完成。

基于這樣的理念，我們開(kāi)發(fā)了一個(gè)模板，我們將SQL寫(xiě)入模板中，指定從哪個(gè)表中取數(shù)，如何分析，決定取完數(shù)后是否需要進(jìn)行定制的后續(xù)處理，如果需要，則執(zhí)行相應(yīng)的Groovy的腳本，最后返回結(jié)果。這一套流程大大節(jié)省了開(kāi)發(fā)的周期，提升了開(kāi)發(fā)的效率。

除開(kāi)發(fā)周期對(duì)比外，存儲(chǔ)方面的對(duì)比也十分顯著。例如數(shù)據(jù)放入到Redis中，需要200g內(nèi)存，用CrateDB來(lái)存，可能只需要50g，這不僅是數(shù)據(jù)量上的減少，同時(shí)意味著成本的大大縮減。在攜程，有基于RocksDB的存儲(chǔ)，它開(kāi)發(fā)有Redis兼容協(xié)議，可以做到把數(shù)據(jù)存儲(chǔ)到磁盤(pán)上，同時(shí)可以用Redis的接口訪(fǎng)問(wèn)。

我們將數(shù)據(jù)存入了磁盤(pán)，分別從均線(xiàn)、95%line、99%line三方面對(duì)比性能。均線(xiàn)方面還在可以忍受的范圍內(nèi)，當(dāng)然CrateDB不可能比Redis更快。從上圖中可以看出，除99.9%line的時(shí)候差距大一點(diǎn)，其他均在可接受的范圍內(nèi)。在數(shù)據(jù)導(dǎo)入耗時(shí)方面，我們運(yùn)用Spark將數(shù)據(jù)導(dǎo)入CrateDB，兩者差距不是特別大。

三、CrateDB在攜程的優(yōu)化

1、落地時(shí)的調(diào)優(yōu)

當(dāng)我們將CrateDB引入整體的技術(shù)方案中時(shí)，還需要進(jìn)行一些調(diào)優(yōu)。

1）磁盤(pán)空間調(diào)優(yōu)

為了避免大量磁盤(pán)空間的消耗，需要對(duì)索引層面進(jìn)行優(yōu)化。除此之外，還可以進(jìn)行聚合優(yōu)化，關(guān)閉列存儲(chǔ)。

2）update操作優(yōu)化

為了提升 update操作的性能，我們建議先insert，然后再刪除已有的數(shù)據(jù)。為了達(dá)到目的，可以加上相應(yīng)的版本號(hào)，每次只取最新版本的數(shù)據(jù)。對(duì)于在線(xiàn)更新的需求需要做轉(zhuǎn)換，這也意味著采用CrateDB所能夠支持的場(chǎng)景是有受限的,對(duì)于嚴(yán)格要求一致，或更新頻繁的場(chǎng)景，CrateDB不是很好的選擇。

3）查詢(xún)優(yōu)化

上文中提到采用分區(qū)加多個(gè)分片的方式優(yōu)化表結(jié)構(gòu)的存儲(chǔ)，使得每一次查詢(xún)只需要去查盡可能少的分區(qū)或分片，查的數(shù)據(jù)越少、越精準(zhǔn)，時(shí)間消耗就越短。

4）過(guò)期數(shù)據(jù)刪除優(yōu)化

2、Spark數(shù)據(jù)導(dǎo)入

在數(shù)據(jù)導(dǎo)入CrateDB時(shí)，我們可能會(huì)用 Spark進(jìn)行操作，此處向大家分享這一過(guò)程中的一個(gè)細(xì)節(jié)點(diǎn)。

此處用分區(qū)舉例，如果有一個(gè)十幾億或幾億的用戶(hù)ID，還有一些關(guān)聯(lián)數(shù)據(jù)，要把它均勻地落到每個(gè)分區(qū)上，有一種比較簡(jiǎn)單的方法。我們把 uid（一串字符）進(jìn)行相應(yīng)的MD5，MD5之后，取前兩位或后兩位，就可以得到256個(gè)分片。256分片顯然太多了，可以再除以一個(gè)系數(shù)，減少分片數(shù)，就可以讓這些數(shù)據(jù)均勻分布，這樣可以做到分片上承載的數(shù)據(jù)量是差不多的。

這樣做的挑戰(zhàn)是在寫(xiě)Spark程序時(shí)，怎樣讓每一個(gè)partition當(dāng)中的數(shù)據(jù)都是落入同一個(gè)分片的內(nèi)容，大家可能會(huì)想到repartition函數(shù)，但repetition是對(duì)某個(gè)字段進(jìn)行哈希，并不能保證落到同一個(gè) partition的數(shù)據(jù)，這時(shí)我們就需要去制定 partition。上圖右側(cè)寫(xiě)出了一些偽碼，我們?cè)趕park中定義一個(gè)repartition，然后重載，顯示這里可能會(huì)有多少個(gè)不同的分片。

假設(shè)我們剛才取前兩位或取后兩位，然后除以4得到64個(gè)分片的話(huà)，那么我們把傳進(jìn)來(lái)的數(shù)字跟64取模就對(duì)應(yīng)到某一個(gè)具體的partition的位置。在Spark中有partitionBy，partitionBy只支持rdd算子，DataFrame中沒(méi)有partitionBy的算子，所以我們需要先把DataFrame或者DataSet轉(zhuǎn)成rdd，通過(guò)組成一個(gè) key鍵值對(duì)的方式進(jìn)行partitionBy操作。之后還需要將相應(yīng)的rdd轉(zhuǎn)換回DataFrame，這樣就可以得到一個(gè)分布很均勻的 DataFrame，再將其寫(xiě)入CrateDB中，就能達(dá)到很快的寫(xiě)入速度。

3、運(yùn)維自動(dòng)化嘗試

我當(dāng)時(shí)是用 Rancher、OpenEBS，以及Nginx Ingress實(shí)現(xiàn)了一個(gè)在K8S上的CrateDB集群，這使得我們?cè)谠骗h(huán)境去部署CrateDB成為一種可能，部署到云上，即便是私有云上，也可以提高硬件使用率，這也是我的初衷。

4、CrateDB admin UI

CrateDB安裝完成后，會(huì)打開(kāi)上圖所示的操作界面，我們能夠直接寫(xiě)入查詢(xún)語(yǔ)句，也可以方便地觀測(cè)到整個(gè)集群的狀況。

四、總結(jié)

1、CrateDB的適用場(chǎng)景

• 單點(diǎn)查詢(xún)
• 寫(xiě)入少，查詢(xún)多
• 時(shí)序數(shù)據(jù)存儲(chǔ)
• 全文本查詢(xún)

2、CrateDB的不足

• Upsert性能較低
• 僅支持NRT查詢(xún)
• 高階SQL函數(shù)有待實(shí)現(xiàn)
• 不支持事務(wù)

Q&A

Q1：CrateDB有解決ES字段類(lèi)型無(wú)法修改、寫(xiě)入性能較低和高硬件資源消耗等痛點(diǎn)嗎？

A1：首先，CrateDB支持修改字段類(lèi)型，這個(gè)字段類(lèi)型的修改和PostgreSQL中相同，可以將varchar改成text，但將varchar類(lèi)型直接改成time stamp可能就會(huì)有問(wèn)題，這時(shí)就不得不從重寫(xiě)或者是進(jìn)行轉(zhuǎn)換。其次，寫(xiě)入性能高低分場(chǎng)景，如果只是單獨(dú)insert的話(huà)，它的性能還是很高的，如果是upsert，或delete與insert摻雜在一起的話(huà)，這種混雜這種模式的話(huà)，寫(xiě)入性能就會(huì)有一些問(wèn)題，需要進(jìn)行相應(yīng)的變通。變通的方式有兩種，第一種是先把新數(shù)據(jù)insert，再把老數(shù)據(jù)delete。第二種方式是新數(shù)據(jù)較小的話(huà)，可以寫(xiě)入一張另外的臨時(shí)表中，臨時(shí)表和新的表進(jìn)行關(guān)聯(lián)，再做相應(yīng)的update。

Q2：CrateDB 相比于 Elasticsearch 和 MongoDB ，備份和恢復(fù)能力如何？

A2：CrateDB和Elasticsearch在備份和恢復(fù)能力層面一樣，但是和MongoDB相比，可能更加直觀和容易，這是我個(gè)人的理解?；謴?fù)方面，如果你要求寫(xiě)入時(shí)所有數(shù)據(jù)都吐到磁盤(pán)之后才返回，那么所有數(shù)據(jù)應(yīng)該都是全部無(wú)丟失的。

Q3：CrateDB運(yùn)行一段時(shí)間性能會(huì)明顯降低，除了重啟還有什么方案？

A3：CrateDB在實(shí)際運(yùn)維中確實(shí)會(huì)碰到一些問(wèn)題，但是我沒(méi)有碰到性能明顯下降的情況。如果有的話(huà)，你可以進(jìn)行索引級(jí)別的重建，而不是整個(gè)集群的重啟，因?yàn)榧褐貑?lái)的成本較高。

Q4：CrateDB日志分析能力如何，有繼承ES的ELK能力嗎？

A4：在與Logstash和Kibana搭配這一層面，還是ES能力更強(qiáng)。從整個(gè)生態(tài)圈的角度來(lái)看，CrateDB還是不能和Elasticsearch相比的，因?yàn)镋lasticsearch的發(fā)展時(shí)間久，然后有Logstash和Kibana的加持，在數(shù)據(jù)的可視化還有分析展現(xiàn)層面確實(shí)很強(qiáng)，但是CrateDB可以和另外幾個(gè)開(kāi)源的產(chǎn)品搭配使用，比如說(shuō)Apache Superset但是肯定沒(méi)有Kibana那種原生定制的強(qiáng)大。

Q5：如果把CrateDB部署在k8s上，數(shù)據(jù)存儲(chǔ)應(yīng)該怎么存放，是分布存儲(chǔ)，本地存儲(chǔ)，還是集中存儲(chǔ)？

A5：上文中提到需要和OpenEBS或Rancher結(jié)合，它是分布式處理的，你的節(jié)點(diǎn)要附著于相應(yīng)的存儲(chǔ)機(jī)器上面，即使Docker掛了，數(shù)據(jù)是不會(huì)丟失掉的。

Q6：CrateDB貴司用在TP場(chǎng)景多還是AP場(chǎng)景多？

A6：我們用到的是 AP場(chǎng)景，實(shí)時(shí)數(shù)據(jù)的聚合返回結(jié)果的，當(dāng)然每一次查詢(xún)所命中的數(shù)據(jù)集并不是特別大，我們要查詢(xún)的數(shù)據(jù)集可能是很大的，但是真正被查詢(xún)條件所命中的還是比較少的，可能是幾十萬(wàn)。

Q7：CrateDB 的對(duì)標(biāo)競(jìng)品是什么，和大數(shù)據(jù)生態(tài)圈比如hadoop有互補(bǔ)嗎 ？

A7：CrateDB不是跟Hadoop相競(jìng)爭(zhēng)，它們兩個(gè)應(yīng)該在不同的層面，因?yàn)镠adoop是進(jìn)行離線(xiàn)數(shù)據(jù)存儲(chǔ)的，而CrateDB是做數(shù)據(jù)分析的。如果要尋找對(duì)標(biāo)競(jìng)品的話(huà)，我個(gè)人認(rèn)為T(mén)imescaleDB是一個(gè)很強(qiáng)的競(jìng)品，因?yàn)樗鼈兌继?hào)稱(chēng)是時(shí)序數(shù)據(jù)庫(kù)，同時(shí)也提供ANSI SQL的查詢(xún)標(biāo)準(zhǔn)。從現(xiàn)在的態(tài)勢(shì)來(lái)看，可能TimescaleDB獲得的用戶(hù)群更多一點(diǎn)。