es 索引規(guī)范？您必須手動指定切片數(shù)量。碎片的數(shù)量會影響查詢效率。有兩種情況:數(shù)據(jù)量大，碎片數(shù)少。會影響單個片段的查詢效率。導致最終查詢時間緩慢。數(shù)據(jù)量不大，但切片太多。碎片太多會影響聚合效率，也會導

es 索引規(guī)范？

您必須手動指定切片數(shù)量。

碎片的數(shù)量會影響查詢效率。

有兩種情況:

數(shù)據(jù)量大，碎片數(shù)少。會影響單個片段的查詢效率。導致最終查詢時間緩慢。

數(shù)據(jù)量不大，但切片太多。碎片太多會影響聚合效率，也會導致最終查詢變慢。

不建議使用

redis集群如何解決key不均勻？

對于分布式存儲系統(tǒng)的架構(gòu)和運行管理來說，保證每個節(jié)點的數(shù)據(jù)存儲容量和請求數(shù)量盡可能均衡是非常重要的。本文介紹了導致 "傾斜 "Redis大型集群運行維護中的數(shù)據(jù)請求及規(guī)避措施。嚴重的影響 "傾斜 "Redis的數(shù)據(jù)容量或請求量是從運維的角度來解釋的。當數(shù)據(jù)容量和請求量傾斜時，Redis中幾十個節(jié)點的集群存在一些痛點:

來自幾個或單個節(jié)點的請求數(shù)量是 "過熱 "，導致Redis分布式系統(tǒng)失去了可擴展性和集群的意義，類似于MongoDB_id字段作為切片鍵；導致運維能力規(guī)劃，擴容困難；增加了自動配置管理的難度；單個集群節(jié)點應盡可能統(tǒng)一參數(shù)配置；監(jiān)控報警很復雜(容量、QPS、連接數(shù)閾值等。).那么讓我們 讓我們看看那些經(jīng)常導致嚴重后果的場景傾斜 "生產(chǎn)環(huán)境中的Redis集群。

普通的 "傾斜 "Redis集群場景一般是由于DBA規(guī)劃不當和業(yè)務密鑰空間設計不合理造成的。

DBA規(guī)劃集群時或者擴展后，數(shù)據(jù)槽(hash bucket)的位分布不均勻，造成內(nèi)存容量、鍵數(shù)和請求QPS傾斜；服務的關(guān)鍵空間設計不合理，所謂 "熱鍵 "導致少量鍵的大QPS操作；這種節(jié)點的QPS過載；程序中使用了大量的Keys hash標簽，可能導致一些數(shù)據(jù)槽中有大量的key；程序有一個很大的簇鍵(hash，set，l。Ist等。)，導致大密鑰所在節(jié)點的容量和QPS很高；工人和教師執(zhí)行Monitor等命令，導致當前節(jié)點客戶端的輸出緩沖區(qū)增加，used_memory_rss擴大，導致節(jié)點內(nèi)存容量增加。接下來，當集群內(nèi)存容量、鍵數(shù)或QPS請求數(shù)嚴重傾斜時，就要調(diào)查定位問題了。

Redis集群的故障排除傾斜 "檢查集群每個段的數(shù)據(jù)槽是否均勻分布。

讓 s以Redis Cluster集群為例，確定集群中每個節(jié)點負責的數(shù)據(jù)槽和鍵的數(shù)量。以下演示的一些例子并不輕微傾斜 "，但不嚴重，可以考慮再平衡。

檢查節(jié)點熱點鍵并確定頂部命令。

使用redis-faina，最好有一個實時分析平臺。從下面的例子可以看出，兩個前綴鍵的QPS比基本都是各50%，明顯是熱點鍵；您還可以看到auth命令的頂部命令。

程序是否大量使用了密鑰散列標簽？

這可能導致數(shù)據(jù)存儲量和QPS不一致的問題。scan可以用來掃描keyspace中是否有hash標簽，或者monitor，可以用vc-redis-sniffer。

該程序是否使用大型設置密鑰？

例如，一個1kw字段的哈希鍵占用幾GB的內(nèi)存。這種set key一次操作幾個字段，所以很難從proxy或者sdk找到key的大小?？赏ㄟ^redis-cli -bigk:和業(yè)務確認音)。在實際生產(chǎn)業(yè)務場景中，大規(guī)模集群很難做到集群的完全平衡，只要盡量保證不出現(xiàn)嚴重的傾斜問題即可。

那個 這是我的看法。你怎么看待這個問題？歡迎在下方評論區(qū)交流~我是科技領(lǐng)域的創(chuàng)作者，有十年互聯(lián)網(wǎng)行業(yè)經(jīng)驗。歡迎關(guān)注我了解更多科技知識！