精品国产亚洲一区二区三区|亚洲国产精彩中文乱码AV|久久久久亚洲AV综合波多野结衣|漂亮少妇各种调教玩弄在线

<blockquote id="ixlwe"><option id="ixlwe"></option></blockquote>
  • <span id="ixlwe"></span>

  • <abbr id="ixlwe"></abbr>

    影響數(shù)據(jù)檢索效率的幾個(gè)因素

    數(shù)據(jù)檢索有兩種主要形態(tài)。第一種是純數(shù)據(jù)庫(kù)型的。典型的結(jié)構(gòu)是一個(gè)關(guān)系型數(shù)據(jù),比如 mysql。用戶通過(guò) SQL 表達(dá)出所需要的數(shù)據(jù),mysql 把 SQL 翻譯成物理的數(shù)據(jù)檢索動(dòng)作返回結(jié)果。第二種形態(tài)是現(xiàn)在越來(lái)越流行的大數(shù)據(jù)玩家的玩法。典型的結(jié)構(gòu)是有一個(gè)分區(qū)的數(shù)據(jù)存儲(chǔ),最初這種存儲(chǔ)就是原始的 HDFS,后來(lái)開逐步有人在 HDFS 上加上索引的支持,或者干脆用 Elasticsearc 這樣的數(shù)據(jù)存儲(chǔ)。然后在存儲(chǔ)之上有一個(gè)分布式的實(shí)時(shí)計(jì)算層,比如 Hive 或者 Spark SQL。用戶用 Hive SQL 提交給計(jì)算層,計(jì)算層從存儲(chǔ)里拉取出數(shù)據(jù),進(jìn)行計(jì)算之后返回給用戶。這種大數(shù)據(jù)的玩法起初是因?yàn)?SQL 有很多 ad-hoc 查詢是滿足不了的,干脆讓用戶自己寫 map/reduce 想怎么算都可以了。但是后來(lái)玩大了之后,越來(lái)越多的人覺(jué)得這些 Hive 之類的方案查詢效率怎么那么低下啊。于是一個(gè)又一個(gè)項(xiàng)目開始去優(yōu)化這些大數(shù)據(jù)計(jì)算框架的查詢性能。這些優(yōu)化手段和經(jīng)典的數(shù)據(jù)庫(kù)優(yōu)化到今天的手段是沒(méi)有什么兩樣的,很多公司打著搞計(jì)算引擎的旗號(hào)干著重新發(fā)明數(shù)據(jù)庫(kù)的活。所以,回歸本質(zhì),影響數(shù)據(jù)檢索效率的就那么幾個(gè)因素。我們不妨來(lái)看一看。

    數(shù)據(jù)檢索干的是什么事情

    定位 => 加載 => 變換

    找到所需要的數(shù)據(jù),把數(shù)據(jù)從遠(yuǎn)程或者磁盤加載到內(nèi)存中。按照規(guī)則進(jìn)行變換,比如按某個(gè)字段group by,取另外一個(gè)字段的sum之類的計(jì)算。

    影響效率的四個(gè)因素

    • 讀取更少的數(shù)據(jù)
    • 數(shù)據(jù)本地化,充分遵循底層硬件的限制設(shè)計(jì)架構(gòu)
    • 更多的機(jī)器
    • 更高效率的計(jì)算和計(jì)算的物理實(shí)現(xiàn)

    原則上的四點(diǎn)描述是非常抽象的。我們具體來(lái)看這些點(diǎn)映射到實(shí)際的數(shù)據(jù)庫(kù)中都是一些什么樣的優(yōu)化措施。

    讀取更少的數(shù)據(jù)

    數(shù)據(jù)越少,檢索需要的時(shí)間當(dāng)然越少了。在考慮所有技術(shù)手段之前,最有效果的恐怕是從業(yè)務(wù)的角度審視一下我們是否需要從那么多的數(shù)據(jù)中檢索出結(jié)果來(lái)。有沒(méi)有可能用更少的數(shù)據(jù)達(dá)到同樣的效果。減少的數(shù)據(jù)量的兩個(gè)手段,聚合和抽樣。如果在入庫(kù)之前把數(shù)據(jù)就做了聚合或者抽樣,是不是可以極大地減少查詢所需要的時(shí)間,同時(shí)效果上并無(wú)多少差異呢?極端情況下,如果需要的是一天的總訪問(wèn)量,比如有1個(gè)億。查詢的時(shí)候去數(shù)1億行肯定快不了。但是如果統(tǒng)計(jì)好了一天的總訪問(wèn)量,查詢的時(shí)候只需要取得一條記錄就可以知道今天有1個(gè)億的人訪問(wèn)了。

    索引是一種非常常見(jiàn)的減少數(shù)據(jù)讀取量的策略了。一般的按行存儲(chǔ)的關(guān)系型數(shù)據(jù)庫(kù)都會(huì)有一個(gè)主鍵。用這個(gè)主鍵可以非??焖俚牟檎业綄?duì)應(yīng)的行。KV存儲(chǔ)也是這樣,按照Key可以快速地找到對(duì)應(yīng)的Value??梢岳斫鉃橐粋€(gè)Hashmap。但是一旦查詢的時(shí)候不是用主鍵,而是另外一個(gè)字段。那么最糟糕的情況就是進(jìn)行一次全表的掃描了,也就是把所有的數(shù)據(jù)都讀取出來(lái),然后看要的數(shù)據(jù)到底在哪里,這就不可能快了。減少數(shù)據(jù)讀取量的最佳方案就是,建立一個(gè)類似字典一樣的查找表,當(dāng)我們找 username=wentao 的時(shí)候,可以列舉出所有有 wentao 作為用戶名的行的主鍵。然后拿這些主鍵去行存儲(chǔ)(就是那個(gè)hashmap)里撈數(shù)據(jù),就一撈一個(gè)準(zhǔn)了。

    談到索引就不得不談一下一個(gè)查詢使用了兩個(gè)字段,如何使用兩個(gè)索引的問(wèn)題。mysql的行為可以代表大部分主流數(shù)據(jù)庫(kù)的處理方式:
    https://www.percona.com/blog/2012/12/14/the-optimization-that-often-is…
    https://www.percona.com/blog/2014/01/03/multiple-column-index-vs-multi…
    基本上來(lái)說(shuō),經(jīng)驗(yàn)表明有多個(gè)單字段的索引,最后數(shù)據(jù)庫(kù)會(huì)選一最優(yōu)的來(lái)使用。其余字段的過(guò)濾仍然是通過(guò)數(shù)據(jù)讀取到內(nèi)存之后,用predicate去判斷的。也就是無(wú)法減少數(shù)據(jù)的讀取量。

    在這個(gè)方面基于inverted index的數(shù)據(jù)就非常有特點(diǎn)。一個(gè)是Elasticsearch為代表的lucene系的數(shù)據(jù)庫(kù)。另外一個(gè)是新銳的druid數(shù)據(jù)庫(kù)。

    https://www.found.no/foundation/elasticsearch-from-the-bottom-up/
    http://druid.io/blog/2012/09/21/druid-bitmap-compression.html

    效果就是,這些數(shù)據(jù)庫(kù)可以把單字段的filter結(jié)果緩存起來(lái)。多個(gè)字段的查詢可以把之前緩存的結(jié)果直接拿過(guò)來(lái)做 AND 或者 OR 操作。

    索引存在的必要是因?yàn)橹鞔鎯?chǔ)沒(méi)有提供直接的快速定位的能力。如果訪問(wèn)的就是數(shù)據(jù)庫(kù)的主鍵,那么需要讀取的數(shù)據(jù)也就非常少了。另外一個(gè)變種就是支持遍歷的主鍵,比如hbase的rowkey。如果查詢的是一個(gè)基于rowkey的范圍,那么像hbase這樣的數(shù)據(jù)庫(kù)就可以支持只讀取到這個(gè)范圍內(nèi)的數(shù)據(jù),而不用讀取不再這個(gè)范圍內(nèi)的額外數(shù)據(jù),從而提高速度。這種加速的方式就是利用了主存儲(chǔ)自身的物理分布的特性。另外一個(gè)更常見(jiàn)的場(chǎng)景就是 partition。比如 mysql 或者 postgresql 都支持分區(qū)表的概念。當(dāng)我們建立了分區(qū)表之后,查找的條件如果可以過(guò)濾出分區(qū),那么可以大幅減少需要讀取的數(shù)據(jù)量。比 partition 更細(xì)粒度一些的是 clustered index。它其實(shí)不是一個(gè)索引(二級(jí)索引),它是改變了數(shù)據(jù)在主存儲(chǔ)內(nèi)的排列方式,讓相同clustered key的數(shù)據(jù)彼此緊挨著放在一起,從而在查詢的時(shí)候避免掃描到無(wú)關(guān)的數(shù)據(jù)。比 partition 更粗一些的是分庫(kù)分表分文件。比如我們可以一天建立一張表,查詢的時(shí)候先定位到表,再執(zhí)行 SQL。比如 graphite 給每個(gè) metric 創(chuàng)建一個(gè)文件存放采集來(lái)的 data point,查詢的時(shí)候給定metric 就可以定位到一個(gè)文件,然后只讀取這個(gè)文件的數(shù)據(jù)。

    另外還有一點(diǎn)就是按行存儲(chǔ)和按列存儲(chǔ)的區(qū)別。按列存儲(chǔ)的時(shí)候,每個(gè)列是一個(gè)獨(dú)立的文件。查詢用到了哪幾個(gè)列就打開哪幾個(gè)列的文件,沒(méi)有用到的列的數(shù)據(jù)碰都不會(huì)碰到。反觀按行存儲(chǔ),一張中的所有字段是彼此緊挨在磁盤上的。一個(gè)表如果有100個(gè)字段,哪怕只選取其中的一個(gè)字段,在掃描磁盤的時(shí)候其余99個(gè)字段的數(shù)據(jù)仍然會(huì)被掃描到的。

    考慮一個(gè)具體的案例,時(shí)間序列數(shù)據(jù)。如何使用讀取更少的數(shù)據(jù)的策略來(lái)提高檢索的效率呢?首先,我們可以保證入庫(kù)的時(shí)間粒度,維度粒度是正好是查詢所需要的。如果查詢需要的是5分鐘數(shù)據(jù),但是入庫(kù)的是1分鐘的,那么就可以先聚合成5分鐘的再存入數(shù)據(jù)庫(kù)。對(duì)于主存儲(chǔ)的物理布局選擇,如果查詢總是針對(duì)一個(gè)時(shí)間范圍的。那么把 timestamp 做為 hbase 的 rowkey,或者 mysql 的 clustered index 是合適。這樣我們按時(shí)間過(guò)濾的時(shí)候,選擇到的是一堆連續(xù)的數(shù)據(jù),不用讀取之后再過(guò)濾掉不符合條件的數(shù)據(jù)。但是如果在一個(gè)時(shí)間范圍內(nèi)有很多中數(shù)據(jù),比如1萬(wàn)個(gè)IP,那么即便是查1個(gè)IP的數(shù)據(jù)也需要把1萬(wàn)個(gè)IP的數(shù)據(jù)都讀取出來(lái)。所以可以把 IP 維度也編碼到 rowkey 或者 clustered index 中。但是假如另外還有一個(gè)維度是 OS,那么查詢的時(shí)候 IP 維度的 rowkey 是沒(méi)有幫助的,仍然是要把所有的數(shù)據(jù)都查出來(lái)。這就是僅依靠主存儲(chǔ)是無(wú)法滿足各種查詢條件下都能夠讀取更少的數(shù)據(jù)的原因。所以,二級(jí)索引是必要的。我們可以把時(shí)間序列中的所有維度都拿出來(lái)建立索引,然后查詢的時(shí)候如果指定了維度,就可以用二級(jí)索引把真正需要讀取的數(shù)據(jù)過(guò)濾出來(lái)。但是實(shí)踐中,很多數(shù)據(jù)庫(kù)并不因?yàn)槭褂昧怂饕沟貌樵冏兛炝耍械臅r(shí)候反而變得更慢了。對(duì)于 mysql 來(lái)說(shuō),存儲(chǔ)時(shí)間序列的最佳方式是按時(shí)間做 partition,不對(duì)維度建立任何索引。查詢的時(shí)候只過(guò)濾出對(duì)應(yīng)的 partition,然后進(jìn)行全 partition 掃描,這樣會(huì)快過(guò)于使用二級(jí)索引定位到行之后再去讀取主存儲(chǔ)的查詢方式。究其原因,就是數(shù)據(jù)本地化的問(wèn)題了。

    數(shù)據(jù)本地化

    數(shù)據(jù)本地化的實(shí)質(zhì)是軟件工程師們要充分尊重和理解底層硬件的限制,并且用各種手段規(guī)避問(wèn)題最大化利用手里的硬件資源。本地化有很多種形態(tài)

    • 最常見(jiàn)的最好理解的本地化問(wèn)題是網(wǎng)絡(luò)問(wèn)題。我們都知道網(wǎng)絡(luò)帶寬不是無(wú)限的,比本地磁盤慢多了。如果可能盡量不要通過(guò)網(wǎng)絡(luò)去訪問(wèn)數(shù)據(jù)。即便要訪問(wèn),也應(yīng)該一次抓取多一些數(shù)據(jù),而不是一次搞一點(diǎn),然后搞很多次。因?yàn)榫W(wǎng)絡(luò)連接和來(lái)回的開銷是非常高的。這就是 data locality 的問(wèn)題。我們要把計(jì)算盡可能的靠近數(shù)據(jù),減少網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量。
    • 這種帶寬引起的本地化問(wèn)題,還有很多。網(wǎng)絡(luò)比硬盤慢,硬盤比內(nèi)存慢,內(nèi)存比L2緩存慢。做到極致的數(shù)據(jù)庫(kù)可以讓計(jì)算完全發(fā)生在 L2 緩存內(nèi),盡可能地避免頻繁地在內(nèi)存和L2之間倒騰數(shù)據(jù)。
    • 另外一種形態(tài)的問(wèn)題化問(wèn)題是磁盤的順序讀和隨機(jī)讀的問(wèn)題。當(dāng)數(shù)據(jù)彼此靠近地物理存放在磁盤上的時(shí)候,順序讀取一批是非常快的。如果需要隨機(jī)讀取多個(gè)不連續(xù)的硬盤位置,磁頭就要來(lái)回移動(dòng)從而使得讀取速度快速下降。即便是 SSD 硬盤,順序讀也是要比隨機(jī)讀快的。

    基于盡可能讓數(shù)據(jù)讀取本地化的原則,檢索應(yīng)該盡可能地使用順序讀而不是隨機(jī)讀。如果可以的話,把主存儲(chǔ)的row key或者clustered index設(shè)計(jì)為和查詢提交一樣的。時(shí)間序列如果都是按時(shí)間查,那么按時(shí)間做的row key可以非常高效地以順序讀的方式把數(shù)據(jù)拉取出來(lái)。類似地,按列存儲(chǔ)的數(shù)據(jù)如果要把一個(gè)列的數(shù)據(jù)都取出來(lái)加和的話,可以非??斓赜庙樞蜃x的方式加載出來(lái)。

    二級(jí)索引的訪問(wèn)方式典型的隨機(jī)讀。當(dāng)查詢條件經(jīng)過(guò)了二級(jí)索引查找之后得到一堆的主存儲(chǔ)的 key,那么就需要對(duì)每個(gè) key 進(jìn)行一次隨機(jī)讀。即便彼此僅靠的key可以用順序讀做一些優(yōu)化,總體上來(lái)說(shuō)仍然是隨機(jī)讀的模式。這也就是為什么時(shí)間序列數(shù)據(jù)在 mysql 里建立了索引反而比沒(méi)有建索引還要慢的原因。

    為了盡可能的利用順序讀,人們就開始想各種辦法了。前面提到了 mysql 里的一行數(shù)據(jù)的多個(gè)列是彼此緊靠地物理存放的。那么如果我們把所需要的數(shù)據(jù)建成多個(gè)列,那么一次查詢就可以批量獲得更多的數(shù)據(jù),減少隨機(jī)讀取的次數(shù)。也就是把之前的一些行變?yōu)榱械姆绞絹?lái)存放,減少行的數(shù)量。這種做法的經(jīng)典案例就是時(shí)間序列數(shù)據(jù),比如可以一分鐘存一行數(shù)據(jù),每一秒的值變成一個(gè)列。那么行的數(shù)量可以變成之前的1/60。

    但是這種行變列的做法在按列存儲(chǔ)的數(shù)據(jù)庫(kù)里就不能直接照搬了,有些列式數(shù)據(jù)庫(kù)有column family的概念,不同的設(shè)置在物理上存放可能是在一起的也可能是分開的。對(duì)于 Elasticsearch 來(lái)說(shuō),要想減少行的數(shù)量,讓一行多pack一些數(shù)據(jù)進(jìn)去,一種做法就是利用 nested document。內(nèi)部 Elasticsearch 可以保證一個(gè) document 下的所有的 nested document是物理上靠在一起放在同一個(gè) lucene 的 segment 內(nèi)。

    網(wǎng)絡(luò)的data locality就比較為人熟知了。map reduce的大數(shù)據(jù)計(jì)算模式就是利用map在數(shù)據(jù)節(jié)點(diǎn)的本地把數(shù)據(jù)先做一次計(jì)算,往往計(jì)算的結(jié)果可以比原數(shù)據(jù)小很多。然后再通過(guò)網(wǎng)絡(luò)傳輸匯總后做 reduce 計(jì)算。這樣就節(jié)省了大量網(wǎng)絡(luò)傳輸數(shù)據(jù)的時(shí)間浪費(fèi)和資源消耗。現(xiàn)在 Elasticsearch 就支持在每個(gè) data node 上部署 spark。由 spark 在每個(gè) data node 上做計(jì)算。而不用把數(shù)據(jù)都查詢出來(lái),用網(wǎng)絡(luò)傳輸?shù)?spark 集群里再去計(jì)算。這種數(shù)據(jù)庫(kù)和計(jì)算集群的混合部署是高性能的關(guān)鍵。類似的還有 storm 和 kafka 之間的關(guān)系。

    網(wǎng)絡(luò)的data locality還有一個(gè)老大難問(wèn)題就是分布式大數(shù)據(jù)下的多表join問(wèn)題。如果只是查詢一個(gè)分布式表,那么把計(jì)算用 map reduce 表達(dá)就沒(méi)有多大問(wèn)題了。但是如果需要同時(shí)查詢兩個(gè)表,就意味著兩個(gè)表可能不是在物理上同樣均勻分布的。一種最簡(jiǎn)單的策略就是找出兩張表中最小的那張,然后把表的內(nèi)容廣播到每個(gè)節(jié)點(diǎn)上,再做join。復(fù)雜一些的是對(duì)兩個(gè)單表做 map reduce,然后按照相同的 key 把部分計(jì)算的結(jié)果匯集在一起。第三種策略是保證數(shù)據(jù)分布的方式,讓兩張表查詢的時(shí)候需要用到的數(shù)據(jù)總在一起。沒(méi)有完美的方案,也不大可能有完美的方案。除非有一天網(wǎng)絡(luò)帶寬可以大到忽略不計(jì)的地步。

    更多的機(jī)器

    這個(gè)就沒(méi)有什么好說(shuō)的了。多一倍的機(jī)器就多一倍的 CPU,可以同時(shí)計(jì)算更多的數(shù)據(jù)。多一倍的機(jī)器就多一倍的磁頭,可以同時(shí)掃描更多的字節(jié)數(shù)。很多大數(shù)據(jù)框架的故事就是講如何如何通過(guò) scale out 解決無(wú)限大的問(wèn)題。但是值得注意的是,集群可以無(wú)限大,數(shù)據(jù)可以無(wú)限多,但是口袋里的銀子不會(huì)無(wú)限多的。堆機(jī)器解決問(wèn)題比升級(jí)大型機(jī)是要便宜,但是機(jī)器堆多了也是非常昂貴的。特別是 Hive 這些從一開始就是分布式多機(jī)的檢索方案,剛開始的時(shí)候效率并不高。堆機(jī)器是一個(gè)乘數(shù),當(dāng)數(shù)據(jù)庫(kù)本來(lái)單機(jī)性能不高的時(shí)候,乘數(shù)大并不能起到?jīng)Q定性的作用。

    更高效的計(jì)算和計(jì)算實(shí)現(xiàn)

    檢索的過(guò)程不僅僅是磁盤掃描,它還包括一個(gè)可簡(jiǎn)單可復(fù)雜的變換過(guò)程。使用 hyperloglog,count min-sketch等有損算法可以極大地提高統(tǒng)計(jì)計(jì)算的性能。數(shù)據(jù)庫(kù)的join也是一個(gè)經(jīng)常有算法創(chuàng)新的地方。
    計(jì)算實(shí)現(xiàn)就是算法是用C++實(shí)現(xiàn)的還是用java,還是python實(shí)現(xiàn)的。用java是用大Integer實(shí)現(xiàn)的,還是小int實(shí)現(xiàn)的。不同的語(yǔ)言的實(shí)現(xiàn)方式會(huì)有一些固定的開銷。不是說(shuō)快就一定要C++,但是 python 寫 for 循環(huán)是顯然沒(méi)有指望的。任何數(shù)據(jù)檢索的環(huán)節(jié)只要包含 python/ruby 這些語(yǔ)言的逐條 for 循環(huán)就一定快不起來(lái)了。

    結(jié)論

    希望這四點(diǎn)可以被記住,成為一種指導(dǎo)性的優(yōu)化數(shù)據(jù)檢索效率的思維框架。無(wú)論你是設(shè)計(jì)一個(gè)mysql表結(jié)構(gòu),還是優(yōu)化一個(gè)spark sql的應(yīng)用。從這四個(gè)角度想想,都有哪些環(huán)節(jié)是在拖后腿的,手上的工具有什么樣的參數(shù)可以調(diào)整,讓隨機(jī)讀變成順序讀,表結(jié)構(gòu)怎么樣設(shè)計(jì)可以最小化數(shù)據(jù)讀取的量。要做到這一點(diǎn),你必須非常非常了解工具的底層實(shí)現(xiàn)。而不是盲目的相信,xx數(shù)據(jù)庫(kù)是最好的數(shù)據(jù)庫(kù),所以它一定很快之類的。如果你不了解你手上的數(shù)據(jù)庫(kù)或者計(jì)算引擎,當(dāng)它快的時(shí)候你不知道為何快,當(dāng)它慢的時(shí)候你就更加無(wú)從優(yōu)化了。

    原文出處: TaoWen

    End.

    極客網(wǎng)企業(yè)會(huì)員

    免責(zé)聲明:本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。

    2015-07-16
    影響數(shù)據(jù)檢索效率的幾個(gè)因素
    數(shù)據(jù)檢索有兩種主要形態(tài)。第一種是純數(shù)據(jù)庫(kù)型的。典型的結(jié)構(gòu)是一個(gè)關(guān)系型數(shù)據(jù),比如 mysql。用戶通過(guò) SQL 表達(dá)出所需要的數(shù)據(jù),mysql 把 SQL 翻譯成物理的數(shù)據(jù)檢索動(dòng)作返回結(jié)果。第二種形態(tài)是

    長(zhǎng)按掃碼 閱讀全文