<del id="nnjnj"></del><track id="nnjnj"></track>

<p id="nnjnj"></p>

<address id="nnjnj"></address>

    <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

      <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>

      • 自動秒收錄
      • 軟件:1973
      • 資訊:57811|
      • 收錄網站:279872|

      IT精英團

      一萬字長文講解HBase讀寫性能優化

      一萬字長文講解HBase讀寫性能優化

      瀏覽次數:
      評論次數:
      編輯: 澤洋
      信息來源: ITPUB
      更新日期: 2022-05-07 18:32:51
      摘要

      一、HBase讀優化1.HBase客戶端優化和大多數系統一樣,客戶端作為業務讀寫的入口,姿勢使用不正確通常會導致本業務讀延遲較高實際上存在一些使用姿勢的推薦用法,這里一般需要關注四個問題:1)s

      • 正文開始
      • 相關閱讀
      • 推薦作品

      1.HBase讀取優化

      1.HBase客戶端優化

      和大多數系統一樣,客戶端是讀寫服務的入口,不正確的姿勢使用通常會導致該服務的高讀取延遲。其實姿勢用法是有一些推薦用法的,這里一般有四個問題需要注意:

      1)掃描緩存設置是否合理?

      優化原理:在解釋這個問題之前,我們應該先解釋一下什么是掃描緩存。一般來說,掃描會返回大量數據。因此,當客戶端發起掃描請求時,所有數據不會一次加載到本地,而是在多個RPC請求中加載。這種設計是基于一方面大量的數據請求可能導致網絡帶寬的嚴重消耗,從而影響其他服務,另一方面本地客戶端也可能因為數據太多而出現OOM。在這樣的設計體系下,用戶會先加載一部分數據到本地,然后遍歷處理,再加載下一部分數據到本地進行處理,以此類推,直到加載完所有數據。在本地加載數據時,數據將存儲在掃描緩存中,默認大小為100條數據。

      通常,默認掃描緩存設置可以正常工作。但是在一些大型的掃描中(一次掃描可能需要查詢幾萬甚至幾十萬行數據),每100個數據的請求就意味著一次掃描需要幾百甚至幾千個RPC請求,這種交互的代價無疑是非常高的。所以可以考慮增加掃描緩存設置,比如500或者1000,可能更合適。我以前做過一個實驗。在一次掃描10w條數據的情況下,將掃描緩存從100增加到1000可以有效降低掃描請求的整體延遲,延遲基本降低25%左右。

      優化建議:在大掃描場景中,將掃描緩存從100增加到500或1000以減少RPC的數量。

      2)可以對GET請求使用批處理請求嗎?

      優化原理: h base分別為單次獲取和批量獲取提供API接口。使用batch get接口可以減少客戶端與RegionServer之間的RPC連接數,提高讀取性能。還應該注意,批處理get請求要么成功返回所有請求的數據,要么拋出異常。

      優化建議:使用batch get發出讀請求。

      3)請求能否顯示指定的列族或列?

      優化原理: h base是典型的列族數據庫,也就是說同一列族的數據存儲在一起,不同列族的數據分別存儲在不同的目錄中。如果一個表有多個列族,不指定列族,只需要根據Rowkey獨立檢索不同列族的數據,性能勢必比指定列族的查詢差很多,很多時候性能損失甚至會是2-3倍。

      優化建議:可以為精確搜索指定列族或列。嘗試指定搜索。

      4)離線批量讀取請求是否設置為禁止緩存?

      優化原理:通常,離線批量讀取的數據會被掃描一次。一方面數據量大,另一方面請求只會執行一次。在這種情況下,如果使用默認的掃描設置,數據將從HDFS加載,然后放入緩存??上攵?,當大量數據進入緩存時,其他實時熱數據將被擠出,其他服務將不得不從HDFS加載,這將造成明顯的讀取延遲毛刺。

      優化建議:脫機批量讀取請求設置禁用緩存,scan.setBlockCache(false)

      2.HBase服務器端優化

      一般而言,一旦服務端到端問題導致服務讀取請求延遲較大,通常是在集群層面,即整個集群服務都會體現出較大的讀取延遲??梢詮乃膫€方面入手:

      1)讀取請求是否平衡?

      優化原理:在極端情況下,如果所有的讀請求都落在一個RegionServer的某個區域,一方面整個集群的并發處理能力無法發揮,另一方面這個RegionServer的資源會被嚴重消耗(比如IO耗盡、handler耗盡等。),落在這個RegionServer上的其他服務都會受到很大影響??梢钥闯?,不均衡的讀取請求不僅會造成服務性能不佳,還會嚴重影響其他服務。當然,不均衡的寫請求也會造成類似的問題,所以可以看出不均衡負載是HBase。

      大忌。

      觀察確認:觀察所有RegionServer的讀請求QPS曲線,確認是否存在讀請求不均衡現象

      優化建議:RowKey必須進行散列化處理(比如MD5散列),同時建表必須進行預分區處理

      2) BlockCache是否設置合理?

      優化原理:BlockCache作為讀緩存,對于讀性能來說至關重要。默認情況下BlockCache和Memstore的配置相對比較均衡(各占40%),可以根據集群業務進行修正,比如讀多寫少業務可以將BlockCache占比調大。另一方面,BlockCache的策略選擇也很重要,不同策略對讀性能來說影響并不是很大,但是對GC的影響卻相當顯著,尤其BucketCache的offheap模式下GC表現很優越。另外,HBase 2.0對offheap的改造(HBASE-11425)將會使HBase的讀性能得到2~4倍的提升,同時GC表現會更好!

      觀察確認:觀察所有RegionServer的緩存未命中率、配置文件相關配置項一級GC日志,確認BlockCache是否可以優化

      優化建議:JVM內存配置量 < 20G,BlockCache策略選擇LRUBlockCache;否則選擇BucketCache策略的offheap模式;期待HBase 2.0的到來!

      3) HFile文件是否太多?

      優化原理:HBase讀取數據通常首先會到Memstore和BlockCache中檢索(讀取最近寫入數據&熱點數據),如果查找不到就會到文件中檢索。HBase的類LSM結構會導致每個store包含多數HFile文件,文件越多,檢索所需的IO次數必然越多,讀取延遲也就越高。文件數量通常取決于Compaction的執行策略,一般和兩個配置參數有關:

      hbase.hstore.compactionThreshold

      hbase.hstore.compaction.max.size

      前者表示一個store中的文件數超過多少就應該進行合并,后者表示參數合并的文件大小最大是多少,超過此大小的文件不能參與合并。這兩個參數不能設置太’松’(前者不能設置太大,后者不能設置太?。?,導致Compaction合并文件的實際效果不明顯,進而很多文件得不到合并。這樣就會導致HFile文件數變多。

      觀察確認:觀察RegionServer級別以及Region級別的storefile數,確認HFile文件是否過多

      優化建議hbase.hstore.compactionThreshold設置不能太大,默認是3個;設置需要根據Region大小確定,通??梢院唵蔚恼J為 hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

      4) Compaction是否消耗系統資源過多?

      優化原理:Compaction是將小文件合并為大文件,提高后續業務隨機讀性能,但是也會帶來IO放大以及帶寬消耗問題(數據遠程讀取以及三副本寫入都會消耗系統帶寬)。正常配置情況下Minor Compaction并不會帶來很大的系統資源消耗,除非因為配置不合理導致Minor Compaction太過頻繁,或者Region設置太大情況下發生Major Compaction。

      觀察確認:觀察系統IO資源以及帶寬資源使用情況,再觀察Compaction隊列長度,確認是否由于Compaction導致系統資源消耗過多

      優化建議

      1. Minor Compaction設置:hbase.hstore.compactionThreshold設置不能太小,又不能設置太大,因此建議設置為5~6;hbase.hstore.compaction.max.size = RegionSize / hbase.hstore.compactionThreshold

      2. Major Compaction設置:大Region讀延遲敏感業務( 100G以上)通常不建議開啟自動Major Compaction,手動低峰期觸發。小Region或者延遲不敏感業務可以開啟Major Compaction,但建議限制流量;

      3. 期待更多的優秀Compaction策略,類似于stripe-compaction盡早提供穩定服務

      3. HBase列族設計優化

      HBase列族設計對讀性能影響也至關重要,其特點是只影響單個業務,并不會對整個集群產生太大影響。列族設計主要從以下方面檢查:

      1) Bloomfilter是否設置?是否設置合理?

      優化原理:Bloomfilter主要用來過濾不存在待檢索RowKey或者Row-Col的HFile文件,避免無用的IO操作。它會告訴你在這個HFile文件中是否可能存在待檢索的KV,如果不存在,就可以不用消耗IO打開文件進行seek。很顯然,通過設置Bloomfilter可以提升隨機讀寫的性能。

      Bloomfilter取值有兩個,row以及rowcol,需要根據業務來確定具體使用哪種。如果業務大多數隨機查詢僅僅使用row作為查詢條件,Bloomfilter一定要設置為row,否則如果大多數隨機查詢使用row+cf作為查詢條件,Bloomfilter需要設置為rowcol。如果不確定業務查詢類型,設置為row。

      優化建議:任何業務都應該設置Bloomfilter,通常設置為row就可以,除非確認業務隨機查詢類型為row+cf,可以設置為rowcol

      4. HDFS相關優化

      HDFS作為HBase最終數據存儲系統,通常會使用三副本策略存儲HBase數據文件以及日志文件。從HDFS的角度望上層看,HBase即是它的客戶端,HBase通過調用它的客戶端進行數據讀寫操作,因此HDFS的相關優化也會影響HBase的讀寫性能。這里主要關注如下三個方面:

      1) Short-Circuit Local Read功能是否開啟?

      優化原理:當前HDFS讀取數據都需要經過DataNode,客戶端會向DataNode發送讀取數據的請求,DataNode接受到請求之后從硬盤中將文件讀出來,再通過TPC發送給客戶端。Short Circuit策略允許客戶端繞過DataNode直接讀取本地數據。(具體原理參考此處)

      優化建議:開啟Short Circuit Local Read功能,具體配置戳這里

      2) Hedged Read功能是否開啟?

      優化原理:HBase數據在HDFS中一般都會存儲三份,而且優先會通過Short-Circuit Local Read功能嘗試本地讀。但是在某些特殊情況下,有可能會出現因為磁盤問題或者網絡問題引起的短時間本地讀取失敗,為了應對這類問題,社區開發者提出了補償重試機制 – Hedged Read。該機制基本工作原理為:客戶端發起一個本地讀,一旦一段時間之后還沒有返回,客戶端將會向其他DataNode發送相同數據的請求。哪一個請求先返回,另一個就會被丟棄。

      優化建議:開啟Hedged Read功能,具體配置參考這里

      3) 數據本地率是否太低?

      數據本地率:HDFS數據通常存儲三份,假如當前RegionA處于Node1上,數據a寫入的時候三副本為(Node1,Node2,Node3),數據b寫入三副本是(Node1,Node4,Node5),數據c寫入三副本(Node1,Node3,Node5),可以看出來所有數據寫入本地Node1肯定會寫一份,數據都在本地可以讀到,因此數據本地率是100%?,F在假設RegionA被遷移到了Node2上,只有數據a在該節點上,其他數據(b和c)讀取只能遠程跨節點讀,本地率就為33%(假設a,b和c的數據大小相同)。

      優化原理:數據本地率太低很顯然會產生大量的跨網絡IO請求,必然會導致讀請求延遲較高,因此提高數據本地率可以有效優化隨機讀性能。數據本地率低的原因一般是因為Region遷移(自動balance開啟、RegionServer宕機遷移、手動遷移等),因此一方面可以通過避免Region無故遷移來保持數據本地率,另一方面如果數據本地率很低,也可以通過執行major_compact提升數據本地率到100%。

      優化建議:避免Region無故遷移,比如關閉自動balance、RS宕機及時拉起并遷回飄走的Region等;在業務低峰期執行major_compact提升數據本地率

      5. HBase讀性能優化歸納

      在本文開始的時候提到讀延遲較大無非三種常見的表象,單個業務慢、集群隨機讀慢以及某個業務隨機讀之后其他業務受到影響導致隨機讀延遲很大。了解完常見的可能導致讀延遲較大的一些問題之后,我們將這些問題進行如下歸類,讀者可以在看到現象之后在對應的問題列表中進行具體定位:

      二、HBase 寫優化

      和讀相比,HBase寫數據流程倒是顯得很簡單:數據先順序寫入HLog,再寫入對應的緩存Memstore,當Memstore中數據大小達到一定閾值(128M)之后,系統會異步將Memstore中數據flush到HDFS形成小文件。

      HBase數據寫入通常會遇到兩類問題,一類是寫性能較差,另一類是數據根本寫不進去。這兩類問題的切入點也不盡相同,如下圖所示:

      1. 寫性能優化切入點

      1) 是否需要寫WAL?WAL是否需要同步寫入?

      優化原理:數據寫入流程可以理解為一次順序寫WAL+一次寫緩存,通常情況下寫緩存延遲很低,因此提升寫性能就只能從WAL入手。WAL機制一方面是為了確保數據即使寫入緩存丟失也可以恢復,另一方面是為了集群之間異步復制。默認WAL機制開啟且使用同步機制寫入WAL。首先考慮業務是否需要寫WAL,通常情況下大多數業務都會開啟WAL機制(默認),但是對于部分業務可能并不特別關心異常情況下部分數據的丟失,而更關心數據寫入吞吐量,比如某些推薦業務,這類業務即使丟失一部分用戶行為數據可能對推薦結果并不構成很大影響,但是對于寫入吞吐量要求很高,不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入,寫入吞吐量可以提升2x~3x。退而求其次,有些業務不能接受不寫WAL,但可以接受WAL異步寫入,也是可以考慮優化的,通常也會帶來1x~2x的性能提升。

      優化推薦:根據業務關注點在WAL機制與寫入吞吐量之間做出選擇

      其他注意點:對于使用Increment操作的業務,WAL可以設置關閉,也可以設置異步寫入,方法同Put類似。相信大多數Increment操作業務對WAL可能都不是那么敏感~

      2) Put是否可以同步批量提交?

      優化原理:HBase分別提供了單條put以及批量put的API接口,使用批量put接口可以減少客戶端到RegionServer之間的RPC連接數,提高寫入性能。另外需要注意的是,批量put請求要么全部成功返回,要么拋出異常。

      優化建議:使用批量put進行寫入請求

      3) Put是否可以異步批量提交?

      優化原理:業務如果可以接受異常情況下少量數據丟失的話,還可以使用異步批量提交的方式提交請求。提交分為兩階段執行:用戶提交寫請求之后,數據會寫入客戶端緩存,并返回用戶寫入成功;當客戶端緩存達到閾值(默認2M)之后批量提交給RegionServer。需要注意的是,在某些情況下客戶端異常的情況下緩存數據有可能丟失。

      優化建議:在業務可以接受的情況下開啟異步批量提交

      使用方式:setAutoFlush(false)

      4) Region是否太少?

      優化原理:當前集群中表的Region個數如果小于RegionServer個數,即Num(Region of Table) < Num(RegionServer),可以考慮切分Region并盡可能分布到不同RegionServer來提高系統請求并發度,如果Num(Region of Table) > Num(RegionServer),再增加Region個數效果并不明顯。

      優化建議:在Num(Region of Table) < Num(RegionServer)的場景下切分部分請求負載高的Region并遷移到其他RegionServer;

      5) 寫入請求是否不均衡?

      優化原理:另一個需要考慮的問題是寫入請求是否均衡,如果不均衡,一方面會導致系統并發度較低,另一方面也有可能造成部分節點負載很高,進而影響其他業務。分布式系統中特別害怕一個節點負載很高的情況,一個節點負載很高可能會拖慢整個集群,這是因為很多業務會使用Mutli批量提交讀寫請求,一旦其中一部分請求落到該節點無法得到及時響應,就會導致整個批量請求超時。因此不怕節點宕掉,就怕節點奄奄一息!

      優化建議:檢查RowKey設計以及預分區策略,保證寫入請求均衡。

      6) 寫入KeyValue數據是否太大?

      KeyValue大小對寫入性能的影響巨大,一旦遇到寫入性能比較差的情況,需要考慮是否由于寫入KeyValue數據太大導致。KeyValue大小對寫入性能影響曲線圖如下:

      圖中橫坐標是寫入的一行數據(每行數據10列)大小,左縱坐標是寫入吞吐量,右坐標是寫入平均延遲(ms)??梢钥闯鲭S著單行數據大小不斷變大,寫入吞吐量急劇下降,寫入延遲在100K之后急劇增大。

      說到這里,有必要和大家分享兩起在生產線環境因為業務KeyValue較大導致的嚴重問題,一起是因為大字段業務寫入導致其他業務吞吐量急劇下降,另一起是因為大字段業務scan導致RegionServer宕機。

      案件一:大字段寫入導致其他業務吞吐量急劇下降

      部分業務反饋集群寫入忽然變慢、數據開始堆積的情況,查看集群表級別的數據讀寫QPS監控,發現問題的第一個關鍵點:業務A開始寫入之后整個集群其他部分業務寫入QPS都幾乎斷崖式下跌,初步懷疑黑手就是業務A。

      下圖是當時業務A的寫入QPS(事后發現腦殘忘了截取其他表QPS斷崖式下跌的慘象),但是第一感覺是QPS并不高啊,憑什么去影響別人!

      于是就繼續查看其他監控信息,首先確認系統資源(主要是IO)并沒有到達瓶頸,其次確認了寫入的均衡性,直至看到下圖,才追蹤到影響其他業務寫入的第二個關鍵點:RegionServer的handler(配置150)被殘暴耗盡:

      對比上面兩張圖,是不是發現出奇的一致,那就可以基本確認是由于該業務寫入導致這臺RegionServer的handler被耗盡,進而其他業務拿不到handler,自然寫不進去。那問題來了,為什么會這樣?正常情況下handler在處理完客戶端請求之后會立馬釋放,唯一的解釋是這些請求的延遲實在太大。

      試想,我們去漢堡店排隊買漢堡,有150個窗口服務,正常情況下大家買一個很快,這樣150個窗口可能只需要50個服務。假設忽然來了一批大漢,要定制超大漢堡,好了,所有的窗口都工作起來,而且因為大漢堡不好制作導致服務很慢,這樣必然會導致其他排隊的用戶長時間等待,直至超時。

      可回頭一想這可是寫請求啊,怎么會有這么大的請求延遲!和業務方溝通之后確認該表主要存儲語料庫文檔信息,都是平均100K左右的數據,是不是已經猜到了結果,沒錯,就是因為這個業務KeyValue太大導致。KeyValue太大會導致HLog文件寫入頻繁切換、flush以及compaction頻繁觸發,寫入性能急劇下降。

      目前針對這種較大KeyValue寫入性能較差的問題還沒有直接的解決方案,好在社區已經意識到這個問題,在接下來即將發布的下一個大版本HBase 2.0.0版本會針對該問題進行深入優化,詳見HBase MOB,優化后用戶使用HBase存儲文檔、圖片等二進制數據都會有極佳的性能體驗。

      案件二:大字段scan導致RegionServer宕機

      案件現場:有段時間有個0.98集群的RegionServer經常頻繁宕機,查看日志是由于”java.lang.OutOfMemoryError: Requested array size exceeds VM limit”,如下圖所示:

      原因分析:通過查看源碼以及相關文檔,確認該異常發生在scan結果數據回傳給客戶端時由于數據量太大導致申請的array大小超過JVM規定的最大值( Interge.Max_Value-2)。造成該異常的兩種最常見原因分別是:

      • 表列太寬(幾十萬列或者上百萬列),并且scan返回沒有對列數量做任何限制,導致一行數據就可能因為包含大量列而數據超過array大小閾值

      • KeyValue太大,并且scan返回沒有對返回結果大小做任何限制,導致返回數據結果大小超過array大小閾值

      有的童鞋就要提問啦,說如果已經對返回結果大小做了限制,在表列太寬的情況下是不是就可以不對列數量做限制呢。這里需要澄清一下,如果不對列數據做限制,數據總是一行一行返回的,即使一行數據大小大于設置的返回結果限制大小,也會返回完整的一行數據。在這種情況下,如果這一行數據已經超過array大小閾值,也會觸發OOM異常。

      解決方案:目前針對該異常有兩種解決方案,其一是升級集群到1.0,問題都解決了。其二是要求客戶端訪問的時候對返回結果大小做限制(scan.setMaxResultSize(210241024))、并且對列數量做限制(scan.setBatch(100)),當然,0.98.13版本以后也可以對返回結果大小在服務器端進行限制,設置參數hbase.server.scanner.max.result.size即可

      2. 寫異常問題檢查點

      上述幾點主要針對寫性能優化進行了介紹,除此之外,在一些情況下還會出現寫異常,一旦發生需要考慮下面兩種情況(GC引起的不做介紹):

      Memstore設置是否會觸發Region級別或者RegionServer級別flush操作?

      問題解析:以RegionServer級別flush進行解析,HBase設定一旦整個RegionServer上所有Memstore占用內存大小總和大于配置文件中upperlimit時,系統就會執行RegionServer級別flush,flush算法會首先按照Region大小進行排序,再按照該順序依次進行flush,直至總Memstore大小低至lowerlimit。這種flush通常會block較長時間,在日志中會發現“Memstore is above high water mark and block 7452 ms”,表示這次flush將會阻塞7s左右。

      問題檢查點:

      • Region規模與Memstore總大小設置是否合理?如果RegionServer上Region較多,而Memstore總大小設置的很?。↗VM設置較小或者upper.limit設置較?。?,就會觸發RegionServer級別flush。集群規劃相關內容可以參考文章《HBase最佳實踐-集群規劃》

      • 列族是否設置過多,通常情況下表列族建議設置在1~3個之間,最好一個。如果設置過多,會導致一個Region中包含很多Memstore,導致更容易觸到高水位upperlimit

      Store中HFile數量是否大于配置參數blockingStoreFile?

      問題解析:對于數據寫入很快的集群,還需要特別關注一個參數:hbase.hstore.blockingStoreFiles,此參數表示如果當前hstore中文件數大于該值,系統將會強制執行compaction操作進行文件合并,合并的過程會阻塞整個hstore的寫入。通常情況下該場景發生在數據寫入很快的情況下,在日志中可以發現”Waited 3722ms on a compaction to clean up ‘too many store  files“

      問題檢查點:

      • 參數設置是否合理?hbase.hstore.compactionThreshold表示啟動compaction的最低閾值,該值不能太大,否則會積累太多文件,一般建議設置為5~8左右。hbase.hstore.blockingStoreFiles默認設置為7,可以適當調大一些。

      本文轉自:http://hbasefly.com/2016/12/10/hbase-parctice-write/

      標簽:數據 業務 緩存
      服務器端高并發分布式架構的演進之路
      ? 上一篇 2022-05-07
      Linux中的交互式進程查看命令htop
      下一篇 ? 2022-05-09
      • 如何在Ubuntu中保留文件系統并備份當前開發板鏡像
        0閱讀 0條評論 個贊
        在Ubuntu保留文件系統或者說備份當前開發板鏡像的需求在不斷增加。比如Ubuntu文件系統需要安裝庫文件的話直接使用apt-get工具就可以下載,但由于需要下載的核心板較多,比較費時間,這時需要將安……
      • 國產核心板全志T507助力消防系統升級
        0閱讀 0條評論 個贊
        9月16日下午,位于湖南長沙市區內的中國電信大樓發生火災,建筑高度218米,現場濃煙滾滾,數十層樓體燃燒劇烈。消防救援人員趕到現場后很快將火勢控制住,目前大樓火勢已被撲滅,所幸未發現人員傷亡。湖南電信……
      • 教大家如何處理Spring Boot易流中的用戶和群體!
        0閱讀 0條評論 個贊
        1.準備工作2.用戶操作2.1添加用戶2.2修改用戶2.3刪除用戶2.4查詢用戶3.組操作3.1添加組3.2修改組3.3刪除組3.4查詢組4.查看表詳情雖然說我們在實際開發中,……
      • 從PG15開始WAL壓縮優化
        0閱讀 0條評論 個贊
        PG15傳聞中的超級令人激動的功能大多數跳票了,年初我也寫過一個關于PG15新功能跳票的文章。PG15BETA已經發出幾個月了,似乎PG15里令人激動人心的功能不多,不過從長長的新功能列表里,……
      • 深入了解美團葉子發射器開源方案
        0閱讀 0條評論 個贊
        大家好,我是樹哥。之前我們有聊過「如何設計一個分布式ID發號器」,其中有講過4種解決方案,分別是:UUID類雪花算法數據庫自增主鍵Redis原子自增美團以第2、3種解決方案為基礎,開發出……
      發表評論 共有條評論
      用戶名: 密碼:
      驗證碼: 匿名發表
      • 大促銷活動如何抵御高流量DDoS攻擊?
        0閱讀 0條評論 個贊
        大促活動如何抵御大流量DDoS攻擊?每一次活動大促帶來的迅猛流量,對技術人而言都是一次嚴峻考驗。如果在活動期間遭受黑產惡意DDoS攻擊,無疑是雪上加霜。電商的特性是業務常態下通常不會遭受大流量DD……
      • web端pdf編輯能力的設計與實踐
        0閱讀 0條評論 個贊
        本期作者顧伊凡嗶哩嗶哩資深開發工程師2021年加入B站,負責UP主創作激勵、收益中心、電子簽約平臺前端建設。本文將從業務場景與技術實現等角度對“web端pdf編輯能力”進行基本的介紹。01背景B站電……
      • Hadoop JMX監控和預警
        0閱讀 0條評論 個贊
        .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
      • SQL Server復制:事務發布
        0閱讀 0條評論 個贊
        一、背景在復制的運用場景中,事務發布是使用最為廣泛的,我遇到這樣一個場景:在Task數據庫中有Basic與Group兩個表,需要提供這兩個表的部分字段給其它程序讀取放入緩存,程序需要比較及時的獲取……
      • 教你如何構建JAVA分布式爬蟲
        0閱讀 0條評論 個贊
        在工作中,我們經常需要去獲取一些數據,但是這些數據可能需要從第三方平臺才可以獲取到。這個時候,爬蟲系統就可以幫助我們來完成這些事情。提到爬蟲系統,很多人都會想到使用python。但實際上,語言只……
      • [設計模式] Java設計模式-橋模式
        0閱讀 0條評論 個贊
        目錄【設計模式】Java設計模式-橋接模式簡介橋接模式實例代碼示例①、品牌接口②、汽車品牌③、抽象汽車類④、汽車類型子類⑤、橋接模式測試1|1簡介橋接(Bridge)是用于把抽象化與實現化解耦,使……
      • 從PG15開始WAL壓縮優化
        0閱讀 0條評論 個贊
        PG15傳聞中的超級令人激動的功能大多數跳票了,年初我也寫過一個關于PG15新功能跳票的文章。PG15BETA已經發出幾個月了,似乎PG15里令人激動人心的功能不多,不過從長長的新功能列表里,……
      • SQL Server聯接方式
        0閱讀 0條評論 個贊
        0.參考文獻MicrosoftSQLServer企業級平臺管理實踐看懂SqlServer查詢計劃1.測試數據準備參考:SqlServer中的表訪問方式TableScan,IndexScan……
      • 基于ASP.NET核心6.0的簡潔架構
        0閱讀 0條評論 個贊
        背景最近嘗試錄制了一個系列視頻:《ASP.NETCore6.0+Vue.js3實戰開發》,本節是視頻內部整潔架構的理論和實戰的文字稿。因為在錄制之前,我通常會編寫完整的文字內容作為視頻文案,這……
      • 談談動態線程池的9個場景(改進版)
        0閱讀 0條評論 個贊
        大家好,我是小馬哥。線程池是一種基于池化思想管理線程的工具,使用線程池可以減少創建銷毀線程的開銷,避免線程過多導致系統資源耗盡。在高并發以及大批量的任務處理場景,線程池的使用是必不可少的?!?/div>
      • 全志A40i核心板全國產化 照亮動力設備國產化之路
        1閱讀 0條評論 個贊
        國產化三個字近幾年來在電力行業內很火,新的設備、新的項目都開始有國產化的趨勢,要求自主可控,然而很多人只是泛泛地去看待“國產化”這三個字而沒有去深究它的重要性。自主可控有多重要?今天,我們就來認真地聊……
      • Go語言知識|基本數據類型
        0閱讀 0條評論 個贊
        前言學習Go半年之后,我決定重新開始閱讀《TheGoProgramingLanguage》,對書中涉及重點進行全面講解,這是Go語言知識查漏補缺系列的文章第二篇,前一篇文章則對應書中一二兩章。我……
      • 如何獲取Yarn和Spark UI的界面索引信息
        1閱讀 0條評論 個贊
        .css-1yuhvjn{margin-top:16px;}.css-3jt6os.FileLinkCard{-webkit-align-items:center;-webkit-box-align……
      • 基于Flyway的數據庫版本控制實踐
        0閱讀 0條評論 個贊
        背景大家平時在開發過程中,會用Git來進行我們的代碼管理。如Git這些,使用這些版本控制系統能輕松的幫我們解決不同開發人員之間的代碼沖突處理版本回退實現軟件代碼的CI/CD等那大家考慮過么,針對數據庫……
      • smile——Java機器學習引擎
        2閱讀 0條評論 個贊
        資源https://haifengl.github.io/https://github.com/haifengl/smile介紹Smile(統計機器智能和學習引擎)是一個基于Java和Scala的快速……
      • SQLServer自動化運維系列監控磁盤剩余空間和SQLServer錯誤日志(PowerShell)
        0閱讀 0條評論 個贊
        需求描述在我們的生產環境中,大部分情況下需要有自己的運維體制,包括自己健康狀態的檢測等。如果發生異常,需要提前預警的,通知形式一般為發郵件告知。在所有的自檢流程中最基礎的一個就是磁盤剩余空間檢測。作為……
      • SQL Server 2005分區模板和實例
        0閱讀 0條評論 個贊
        一、場景這一段時間使用SQLServer2005對幾個系統進行表分區,這幾個系統都有一些特點,比如數據庫某張表持續增長,給數據庫帶來了很大的壓力?,F在假如提供一臺新的服務器,那么我們應該如何規劃……
      • 記錄一次數據庫滿CPU的故障排除過程
        0閱讀 0條評論 個贊
        1前言近期隨著數據量的增長,數據庫CPU使用率100%報警頻繁起來。第一個想到的就是慢Sql,我們對未合理運用索引的表加入索引后,問題依然沒有得到解決,深入排查時,發現在orderbyida……
      • 深入了解春季交易:介紹 使用 原則
        8閱讀 0條評論 個贊
        大家好,我是樹哥。Spring事務是復雜一致性業務必備的知識點,掌握好Spring事務可以讓我們寫出更好地代碼。這篇文章我們將介紹Spring事務的誕生背景,從而讓我們可以更清晰地了解Sp……
      • 面試官:談談你對mysql事務的認識?
        0閱讀 0條評論 個贊
        引言今天回頭繼續講講數據庫系列的文章。這篇文章屬于mysql數據庫系列,我們來談談事務方面的常見面試題。那么,具體題目有下面這些:1、講講為什么用事務?事務的四大特性?事務的隔離級別知道吧,你們生產……
      最近發布資訊
      更多
      警花高潮嗷嗷叫
      <del id="nnjnj"></del><track id="nnjnj"></track>

      <p id="nnjnj"></p>

      <address id="nnjnj"></address>

        <pre id="nnjnj"><pre id="nnjnj"></pre></pre>

          <noframes id="nnjnj"><ruby id="nnjnj"><ruby id="nnjnj"></ruby></ruby>