druid相關的時間序列資料庫——也用到了倒排相關的優化技術

桃子紅了吶發表於2017-11-15
UI資料庫優化
Cattell [6] maintains a great summary about existing Scalable SQL and NoSQL data stores. Hu [18] contributed another great summary for streaming databases. Druid feature-wise sits some-
where between Google’s Dremel [28] and PowerDrill [17]. Druid has most of the features implemented in Dremel (Dremel handles arbitrary nested data structures while Druid only allows for a single
level of array-based nesting) and many of the interesting compression algorithms mentioned in PowerDrill. Although Druid builds on many of the same principles as other distributed columnar data stores [15], many of these data stores are  
designed to be more generic key-value stores [23] and do not sup

 

port computation directly in the storage layer. There are also other 

 

data stores designed for some of the same data warehousing issues 

 

that Druid is meant to solve. These systems include in-memory 
databases such as SAP’s HANA [14] and VoltDB [43]. These data 

 

stores lack Druid’slowlatency ingestion characteristics. Druidalso 

 

has native analytical features baked in, similar to ParAccel [34], 

 

however, Druid allows system wide rolling software updates with 

 

no downtime. 

 

Druid is similiar to C-Store [38] and LazyBase [8] in that it has 
twosubsystems,aread-optimizedsubsysteminthehistoricalnodes 

 

andawrite-optimizedsubsysteminreal-timenodes. Real-timenodes 

 

are designed to ingest a high volume of append heavy data, and do 

 

not support data updates. Unlike the two aforementioned systems, 

 

Druid is meant for OLAP transactions and not OLTP transactions. 

 

Druid’s low latency data ingestion features share some similar-

 

ities with Trident/Storm [27] and Spark Streaming [45], however,

 

both systems are focused on stream processing whereas Druid is 

 

focused on ingestion and aggregation. Stream processors are great 

 

complements to Druid as a means of pre-processing the data before 

 

the data enters Druid. 

 

There are a class of systems that specialize in queries on top of
cluster computing frameworks. Shark [13] is such a system for  
queriesontopofSpark,andCloudera’sImpala[9]isanothersystem 

 

focused on optimizing query performance on top of HDFS. Druid
historical nodes download data locally and only work with native  
Druid indexes. We believe this setup allows for faster query laten

 

cies. 

 

Druid leverages a unique combination of algorithms in its archi-
tecture. Although we believe no other data store has the same set  
of functionality as Druid, some of Druid’s optimization techniques 

 

suchas using inverted indices to perform fast filter sarealsousedin
other data stores [26].
 
druid白皮書：http://static.druid.io/docs/druid.pdf
本文轉自張昺華-sky部落格園部落格，原文連結：http://www.cnblogs.com/bonelee/p/6433333.html，如需轉載請自行聯絡原作者


相關文章