色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
电子发烧友
开通电子发烧友VIP会员 尊享10大特权
海量资料免费下载
精品直播免费看
优质内容免费畅学
课程9折专享价
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

基于Clickhouse構(gòu)建新一代日志存儲系統(tǒng)

Linux閱碼場 ? 來源:Linux閱碼場 ? 2024-03-12 14:06 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

ClickHouse 是2016年開源的用于實時數(shù)據(jù)分析的一款高性能列式分布式數(shù)據(jù)庫,支持向量化計算引擎、多核并行計算、高壓縮比等功能,在分析型數(shù)據(jù)庫中單表查詢速度是最快的。2020年開始在滴滴內(nèi)部大規(guī)模地推廣和應(yīng)用,服務(wù)網(wǎng)約車和日志檢索等核心平臺和業(yè)務(wù)。本文主要介紹滴滴日志檢索場景從 ES 遷移到 CK 的技術(shù)探索。

背景

此前,滴滴日志主要存儲于 ES 中。然而,ES 的分詞、倒排和正排等功能導(dǎo)致其寫入吞吐量存在明顯瓶頸。此外,ES 需要存儲原始文本、倒排索引和正排索引,這增加了存儲成本,并對內(nèi)存有較高要求。隨著滴滴數(shù)據(jù)量的不斷增長,ES 的性能已無法滿足當(dāng)前需求。

在追求降低成本和提高效率的背景下,我們開始尋求新的存儲解決方案。經(jīng)過研究,我們決定采用 CK 作為滴滴內(nèi)部日志的存儲支持。據(jù)了解,京東、攜程、B站等多家公司在業(yè)界的實踐中也在嘗試用 CK 構(gòu)建日志存儲系統(tǒng)。

挑戰(zhàn)

面臨的挑戰(zhàn)主要來自下面三個方面:

數(shù)據(jù)量大:每天會產(chǎn)生 PB 級別的日志數(shù)據(jù),存儲系統(tǒng)需要穩(wěn)定地支撐 PB 級數(shù)據(jù)的實時寫入和存儲。

查詢場景多:在一個時間段內(nèi)的等值查詢、模糊查詢及排序場景等,查詢需要掃描的數(shù)據(jù)量較大且查詢都需要在秒級返回。

QPS 高:在 PB 級的數(shù)據(jù)量下,對 Trace 查詢同時要滿足高 QPS 的要求。

為什么選 Clickhouse

大數(shù)據(jù)量:CK 的分布式架構(gòu)支持動態(tài)擴(kuò)縮容,可支撐海量數(shù)據(jù)存儲。

寫入性能:CK 的 MergeTree 表的寫入速度在200MB/s,具有很高吞吐,寫入基本沒有瓶頸。

查詢性能:CK 支持分區(qū)索引和排序索引,具有很高的檢索效率,單機(jī)每秒可掃描數(shù)百萬行的數(shù)據(jù)。

存儲成本:CK 基于列式存儲,數(shù)據(jù)壓縮比很高,同時基于HDFS做冷熱分離,能夠進(jìn)一步地降低存儲成本。

架構(gòu)升級

1eeb01ce-df56-11ee-a297-92fbcf53809c.png

舊的存儲架構(gòu)下需要將日志數(shù)據(jù)雙寫到 ES 和 HDFS 兩個存儲上,由ES提供實時的查詢,Spark 來分析 HDFS 上的數(shù)據(jù)。這種設(shè)計要求用戶維護(hù)兩條獨(dú)立的寫入鏈路,導(dǎo)致資源消耗翻倍,且操作復(fù)雜性增加。

在新升級的存儲架構(gòu)中,CK 取代了 ES 的角色,分別設(shè)有 Log 集群和 Trace 集群。Log 集群專門存儲明細(xì)日志數(shù)據(jù),而 Trace 集群則專注于存儲 trace 數(shù)據(jù)。這兩個集群在物理上相互隔離,有效避免了 log 的高消耗查詢(如 like 查詢)對 trace 的高 QPS 查詢產(chǎn)生干擾。此外,獨(dú)立的 Trace 集群有助于防止trace數(shù)據(jù)過度分散。

日志數(shù)據(jù)通過 Flink 直接寫入 Log 集群,并通過 Trace 物化視圖從 log 中提取 trace 數(shù)據(jù),然后利用分布式表的異步寫入功能同步至 Trace 集群。這一過程不僅實現(xiàn)了 log 與 trace 數(shù)據(jù)的分離,還允許 Log 集群的后臺線程定期將冷數(shù)據(jù)同步到 HDFS 中。

新架構(gòu)僅涉及單一寫入鏈路,所有關(guān)于 log 數(shù)據(jù)冷存儲至 HDFS 以及 log 與 trace 分離的處理均由 CK 完成,從而為用戶屏蔽了底層細(xì)節(jié),簡化了操作流程。

考慮到成本和日志數(shù)據(jù)特點(diǎn),Log 集群和 Trace 集群均采用單副本部署模式。其中,最大的 Log 集群有300多個節(jié)點(diǎn),Trace 集群有40多個節(jié)點(diǎn)。

存儲設(shè)計

存儲設(shè)計是提升性能最關(guān)鍵的部分,只有經(jīng)過優(yōu)化的存儲設(shè)計才能充分發(fā)揮 CK 強(qiáng)大的檢索性能。借鑒時序數(shù)據(jù)庫的理念,我們將 logTime 調(diào)整為以小時為單位進(jìn)行取整,并在存儲過程中按照小時順序排列數(shù)據(jù)。這樣,在進(jìn)行其他排序鍵查詢時,可以快速定位到所需的數(shù)據(jù)塊。例如,查詢一個小時內(nèi)數(shù)據(jù)時,最多只需讀取兩個索引塊,這對于處理海量日志檢索至關(guān)重要。

以下是我們根據(jù)日志查詢特性和 CK 執(zhí)行邏輯制定的存儲設(shè)計方案,包括 Log 表、Trace 表和 Trace 索引表:

Log 表

Log 表旨在為明細(xì)日志提供存儲和查詢服務(wù),它位于 Log 集群中,并由 Flink 直接從 Pulsar 消費(fèi)數(shù)據(jù)后寫入。每個日志服務(wù)都對應(yīng)一張 Log 表,因此整個 Log 集群可能包含數(shù)千張 Log 表。其中,最大的表每天可能會生成 PB 級別的數(shù)據(jù)。鑒于 Log 集群面臨表數(shù)量眾多、單表數(shù)據(jù)量大以及需要進(jìn)行冷熱數(shù)據(jù)分離等挑戰(zhàn),以下是針對 Log 表的設(shè)計思路:

CREATE TABLE ck_bamai_stream.cn_bmauto_local
(
    `logTime` Int64 DEFAULT 0, -- log打印的時間
    `logTimeHour` DateTime MATERIALIZED toStartOfHour(toDateTime(logTime / 1000)), -- 將logTime向小時取整
    `odinLeaf` String DEFAULT '',
    `uri` LowCardinality(String) DEFAULT '',
    `traceid` String DEFAULT '',
    `cspanid` String DEFAULT '',
    `dltag` String DEFAULT '',
    `spanid` String DEFAULT '',
    `message` String DEFAULT '',
    `otherColumn` Map,
    `_sys_insert_time` DateTime MATERIALIZED now()
)
ENGINE = MergeTree
PARTITION BY toYYYYMMDD(logTimeHour)
ORDER BY (logTimeHour,odinLeaf,uri,traceid)
TTL _sys_insert_time + toIntervalDay(7),_sys_insert_time + toIntervalDay(3) TO VOLUME 'hdfs'
SETTINGSindex_granularity=8192,min_bytes_for_wide_part=31457280

分區(qū)鍵:根據(jù)查詢特點(diǎn),幾乎所有的 sql 都只會查1小時的數(shù)據(jù),但這里只能按天分區(qū),小時分區(qū)導(dǎo)致 Part 過多及 HDFS 小文件過多的問題。

排序鍵:為了快速定位到某一個小時的數(shù)據(jù),基于 logTime 向小時取整物化了一個新的字段 logTimeHour,將 logTimeHour 作為第一排序鍵,這樣就能將數(shù)據(jù)范圍鎖定在小時級別,由于大部分查詢都會指定上 odinLeaf、uri、traceid,依據(jù)基數(shù)從小到大分別將其作為第二、三、四排序鍵,這樣查詢某個 traceid 的數(shù)據(jù)只需要讀取少量的索引塊,經(jīng)過上述的設(shè)計所有的等值查詢都能達(dá)到毫秒級。

Map 列:引入了 Map 類型,實現(xiàn)動態(tài)的 Scheme,將不需要用來過濾的列統(tǒng)統(tǒng)放入 Map 中,這樣能有效減少 Part 的文件數(shù),避免 HDFS 上出現(xiàn)大量小文件。

Trace 表

Trace 表是用來提供 trace 相關(guān)的查詢,這類查詢對 QPS 要求很高,創(chuàng)建在 Trace 集群。數(shù)據(jù)來源于從 Log 表中提取的 trace 記錄。Trace 表只會有一張,所有的 Log 表都會將 trace 記錄提取到這張 Trace 表,實現(xiàn)的方式是 Log 表通過物化視圖觸發(fā)器跨集群將數(shù)據(jù)寫到 Trace 表中。

Trace 表的難點(diǎn)在于查詢速度快且 QPS 高,以下是 Trace 表的設(shè)計思路:

CREATE TABLE ck_bamai_stream.trace_view
(
    `traceid` String,
    `spanid` String,
    `clientHost` String,
    `logTimeHour` DateTime,
    `cspanid` AggregateFunction(groupUniqArray, String),
    `appName` SimpleAggregateFunction(any, String),
    `logTimeMin` SimpleAggregateFunction(min, Int64),
    `logTimeMax` SimpleAggregateFunction(max, Int64),
    `dltag` AggregateFunction(groupUniqArray, String),
    `uri` AggregateFunction(groupUniqArray, String),
    `errno` AggregateFunction(groupUniqArray, String),
    `odinLeaf` SimpleAggregateFunction(any, String),
    `extractLevel` SimpleAggregateFunction(any, String)
)
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMMDD(logTimeHour)
ORDER BY (logTimeHour, traceid, spanid, clientHost)
TTL logTimeHour + toIntervalDay(7)
SETTINGS index_granularity = 1024

AggregatingMergeTree:Trace 表采用了聚合表引擎,會按 traceid 進(jìn)行聚合,能很大程度的聚合 trace 數(shù)據(jù),壓縮比在5:1,能極大地提升 Trace 表的檢索速度。

分區(qū)鍵和排序鍵:與 Log 的設(shè)計類似。

index_granularity:這個參數(shù)是用來控制稀疏索引的粒度,默認(rèn)是8192,減小這個參數(shù)是為了減少數(shù)據(jù)塊中無效的數(shù)據(jù)掃描,加快 traceid 的檢索速度。

Trace 索引表

Trace 索引表的主要作用是加快 order_id、driver_id、driver_phone 等字段查詢 traceid 的速度。為此,我們給需要加速的字段創(chuàng)建了一個聚合物化視圖,以提高查詢速度。數(shù)據(jù)則是通過為 Log 表創(chuàng)建相應(yīng)的物化視圖觸發(fā)器,將數(shù)據(jù)提取到 Trace 索引表中。

以下是建立 Trace 索引表的語句:

CREATE TABLE orderid_traceid_index_view
(
    `order_id` String,
    `traceid` String,
    `logTimeHour` DateTime
)
ENGINE = AggregatingMergeTree
PARTITION BY logTimeHour
ORDER BY (order_id, traceid)
TTL logTimeHour + toIntervalDay(7)
SETTINGS index_granularity = 1024

存儲設(shè)計的核心目標(biāo)是提升查詢性能。接下來,我將介紹從 ES 遷移至 CK 過程中,在這一架構(gòu)下所面臨的穩(wěn)定性問題及其解決方法。

穩(wěn)定性之路

支撐日志場景對 CK 來說是非常大的挑戰(zhàn),面臨龐大的寫入流量及超大集群規(guī)模,經(jīng)過一年的建設(shè),我們能夠穩(wěn)定的支撐重點(diǎn)節(jié)假日的流量高峰,下面的篇幅主要是介紹了在支撐日志場景過程中,遇到的一些問題。

大集群小表數(shù)據(jù)碎片化問題

在 Log 集群中,90%的 Log 表流量低于10MB/s。若將所有表的數(shù)據(jù)都寫入數(shù)百個節(jié)點(diǎn),會導(dǎo)致大量小表數(shù)據(jù)碎片化問題。這不僅影響查詢性能,還會對整個集群性能產(chǎn)生負(fù)面影響,并為冷數(shù)據(jù)存儲到 HDFS 帶來大量小文件問題。

為解決大規(guī)模集群帶來的問題,我們根據(jù)表的流量大小動態(tài)分配寫入節(jié)點(diǎn)。每個表分配的寫入節(jié)點(diǎn)數(shù)量介于2到集群最大節(jié)點(diǎn)數(shù)之間,均勻分布在整個集群中。Flink 通過接口獲取表的寫入節(jié)點(diǎn)列表,并將數(shù)據(jù)寫入相應(yīng)的 CK 節(jié)點(diǎn),有效解決了大規(guī)模集群數(shù)據(jù)分散的問題。

寫入限流及寫入性能提升

在滴滴日志場景中,晚高峰和節(jié)假日的流量往往會大幅增加。為避免高峰期流量過大導(dǎo)致集群崩潰,我們在 Flink 上實現(xiàn)了寫入限流功能。該功能可動態(tài)調(diào)整每張表寫入集群的流量大小。當(dāng)流量超過集群上限時,我們可以迅速降低非關(guān)鍵表的寫入流量,減輕集群壓力,確保重保表的寫入和查詢不受影響。

同時為了提升把脈的寫入性能,我們基于 CK 原生 TCP 協(xié)議開發(fā)了 Native-connector。相比于 HTTP 協(xié)議,Native-connector 的網(wǎng)絡(luò)開銷更小。此外,我們還自定義了數(shù)據(jù)類型的序列化機(jī)制,使其比之前的 Parquet 類型更高效。啟用 Native-connector 后,寫入延遲率從之前的20%降至5%,整體寫入性能提升了1.2倍。

HDFS 冷熱分離的性能問題

用 HDFS 來存儲冷數(shù)據(jù),在使用的過程中出現(xiàn)以下問題:

服務(wù)重啟變得特別慢且 Sys cpu 被打滿,原因是在服務(wù)重啟的過程中需要并發(fā)的加載 HDFS 上 Part 的元數(shù)據(jù),而 libhdfs3 庫并發(fā)讀 HDFS 的性能非常差,每當(dāng)讀到文件末尾都會拋出異常打印堆棧,產(chǎn)生了大量的系統(tǒng)調(diào)用。

當(dāng)寫入歷史分區(qū)的數(shù)據(jù)時,數(shù)據(jù)不會落盤,而是直接往 HDFS 上寫,寫入性能很差,并且直接寫到 HDFS 的數(shù)據(jù)還需要拉回本地 merge,進(jìn)一步降低了 merge 的性能。

本地的 Part 路徑和 HDFS 的路徑是通過 uuid 來映射的,所有表的數(shù)據(jù)都是存儲在 HDFS 的同一路徑下,導(dǎo)致達(dá)到了 HDFS 目錄文件數(shù) 100w 的限制。

HDFS 上的 Part 文件路徑映射關(guān)系是存儲在本地的,如果出現(xiàn)節(jié)點(diǎn)故障,那么文件路徑映射關(guān)系將會丟失,HDFS 上的數(shù)據(jù)丟失且無法被刪除。

為此我們對 HDFS 冷熱分離功能進(jìn)行了比較大的改造來解決上面的問題,解決 libhdfs3 庫并發(fā)讀 HDFS 的問題并在本地緩存 HDFS 的 Part 元數(shù)據(jù)文件,服務(wù)的啟動速度由原來的1小時到1分鐘。

1f007dd8-df56-11ee-a297-92fbcf53809c.png

同時禁止歷史數(shù)據(jù)直接寫 HDFS ,必須先寫本地,merge 之后再上傳到 HDFS ,最后對 HDFS 的存儲路徑進(jìn)行改造。由原來數(shù)據(jù)只存儲在一個目錄下改為按cluster/shard/database/table/ 進(jìn)行劃分,并按表級別備份本地的路徑映射關(guān)系到 HDFS。這樣一來,當(dāng)節(jié)點(diǎn)故障時,可以通過該備份恢復(fù) HDFS 的數(shù)據(jù)。

收益

在日志場景中,我們已經(jīng)成功完成了從 ES 到 CK 的遷移。目前,CK 的日志集群規(guī)模已超過400個物理節(jié)點(diǎn),寫入峰值流量達(dá)到40+GB/s,每日查詢量約為1500萬次,支持的 QPS 峰值約為200。相較于 ES,CK 的機(jī)器成本降低了30%。

1f140c2c-df56-11ee-a297-92fbcf53809c.png

查詢速度相比 ES 提高了約4倍。下圖展示了 bamailog 集群和 bamaitrace 集群的 P99 查詢耗時情況,基本都在1秒以內(nèi)。

1f240ae6-df56-11ee-a297-92fbcf53809c.png

總結(jié)

將日志從 ES 遷移至 CK 不僅可以顯著降低存儲成本,還能提供更快的查詢體驗。經(jīng)過一年多的建設(shè)和優(yōu)化,系統(tǒng)的穩(wěn)定性和性能都有了顯著提升。然而,在處理模糊查詢時,集群的資源消耗仍然較大。未來,我們將繼續(xù)探索二級索引、zstd 壓縮以及存算分離等技術(shù)手段,以進(jìn)一步提升日志檢索性能。

審核編輯:黃飛

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • TCP
    TCP
    +關(guān)注

    關(guān)注

    8

    文章

    1402

    瀏覽量

    80954
  • 存儲系統(tǒng)
    +關(guān)注

    關(guān)注

    2

    文章

    423

    瀏覽量

    41346
  • HDFS
    +關(guān)注

    關(guān)注

    1

    文章

    31

    瀏覽量

    9879
  • 大數(shù)據(jù)
    +關(guān)注

    關(guān)注

    64

    文章

    8959

    瀏覽量

    140078

原文標(biāo)題:滴滴基于 Clickhouse 構(gòu)建新一代日志存儲系統(tǒng)

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 0人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    網(wǎng)絡(luò)存儲系統(tǒng)可生存性量化評估

    【作者】:張益;霍珊珊;【來源】:《清華大學(xué)學(xué)報(自然科學(xué)版)》2009年S2期【摘要】:針對當(dāng)前網(wǎng)絡(luò)存儲系統(tǒng)可生存性評估缺乏系統(tǒng)的評估指標(biāo)和量化評估方法的現(xiàn)狀,提出了量化評估指標(biāo)體系和基于多指標(biāo)
    發(fā)表于 04-24 09:43

    Centos7下如何搭建ClickHouse列式存儲數(shù)據(jù)庫

    ,主要適合于批量數(shù)據(jù)處理和即時查詢。(2)數(shù)據(jù)壓縮在些列式數(shù)據(jù)庫管理系統(tǒng)中不是用數(shù)據(jù)壓縮。但是, 數(shù)據(jù)壓縮在實現(xiàn)優(yōu)異的存儲系統(tǒng)中確實起著關(guān)鍵的作用。(3)數(shù)據(jù)的磁盤存儲許多的列式數(shù)據(jù)
    發(fā)表于 01-05 18:03

    新一代軍用通信系統(tǒng)的挑戰(zhàn)

    新一代軍用通信系統(tǒng)挑戰(zhàn)
    發(fā)表于 03-02 06:21

    如何構(gòu)建個PCI-E架構(gòu)的實時海量存儲系統(tǒng)

    如何設(shè)計個基于PC主機(jī)北橋的長時間不間斷高速采集和存儲系統(tǒng)。本文最后介紹了利用PC主機(jī)、PCI-E接口芯片PEX8311、Switch芯片PEX8616和RAID磁盤陣列卡,構(gòu)建
    發(fā)表于 04-15 06:32

    什么是云存儲?云存儲系統(tǒng)的結(jié)構(gòu)是如何構(gòu)成的?

    到底什么是云存儲?云存儲系統(tǒng)的結(jié)構(gòu)是如何構(gòu)成的?云存儲有哪些技術(shù)前提?
    發(fā)表于 06-02 06:27

    存儲系統(tǒng)的層次結(jié)構(gòu)

    文章目錄存儲系統(tǒng)的層次結(jié)構(gòu)技術(shù)指標(biāo)層次結(jié)構(gòu)局部性原理主存儲器讀寫存儲器只讀存儲存儲器地址譯碼主存空間分配高速緩沖
    發(fā)表于 07-29 09:47

    存儲系統(tǒng)的層次結(jié)構(gòu)是怎樣的?

    存儲系統(tǒng)的層次結(jié)構(gòu)是怎樣的?怎么解決容量/速度和價格矛盾的問題?
    發(fā)表于 11-02 09:22

    基于FPGA的微型數(shù)字存儲系統(tǒng)設(shè)計

    基于FPGA的微型數(shù)字存儲系統(tǒng)設(shè)計 1 引言    針對航天測試系統(tǒng)的應(yīng)用需求,提出種基于FPGA的微型數(shù)字存儲系統(tǒng)設(shè)計方案。該
    發(fā)表于 11-04 10:46 ?989次閱讀
    基于FPGA的微型數(shù)字<b class='flag-5'>存儲系統(tǒng)</b>設(shè)計

    公有云存儲系統(tǒng)性能評測方法研究

    存儲系統(tǒng);測試環(huán)境構(gòu)建復(fù)雜,測試時間長,準(zhǔn)備測試環(huán)境成本高;受網(wǎng)絡(luò)因素及外界其他因素影響,評測結(jié)果不穩(wěn)定。針對以上所述云存儲系統(tǒng)性能評測的重點(diǎn)和難點(diǎn),提出種云測試云的公有云
    發(fā)表于 12-03 11:48 ?0次下載
    公有云<b class='flag-5'>存儲系統(tǒng)</b>性能評測方法研究

    富士通推出全新企業(yè)級全閃存儲系統(tǒng)系列產(chǎn)品:性能較上一代提升了30%以上

    富士通面向中國市場推出了全新的企業(yè)級全閃存存儲系統(tǒng)ETERNUS AF S2系列,官方稱新一代產(chǎn)品高度優(yōu)化了算法、提升了緩存的容量、更換了更快速的處理器和光纖接口,新一代ETERNUS AF S2的性能較上
    發(fā)表于 07-24 15:27 ?980次閱讀

    如何使用iSCSI技術(shù)構(gòu)建IP SAN網(wǎng)絡(luò)存儲系統(tǒng)的方法概述

    本文簡要介紹了主要存儲技術(shù)DAS、NAS及SAN的組成結(jié)構(gòu)、原理、優(yōu)點(diǎn)和缺陷。詳細(xì)分析了iSCSI技術(shù)標(biāo)準(zhǔn)的主要內(nèi)容,闡述了用iSCSI技術(shù)構(gòu)建IP SAN網(wǎng)絡(luò)存儲系統(tǒng)的解決方案。
    發(fā)表于 12-10 16:47 ?8次下載
    如何使用iSCSI技術(shù)<b class='flag-5'>構(gòu)建</b>IP SAN網(wǎng)絡(luò)<b class='flag-5'>存儲系統(tǒng)</b>的方法概述

    新華三推出全新一代存儲系統(tǒng)

    據(jù)了解,全新的Primera存儲系統(tǒng)實現(xiàn)了存儲介質(zhì)從HDD到SSD的質(zhì)變,并做到了前所未有的100% SLA。而通過存儲協(xié)議、互聯(lián)架構(gòu)、控制器、OS和應(yīng)用層面的創(chuàng)新,Primera也實現(xiàn)了在性能、體驗和感知層面的全面超越。
    發(fā)表于 08-09 10:28 ?690次閱讀

    新華三推出全新一代數(shù)據(jù)存儲系統(tǒng)Primera

    紫光集團(tuán)旗下新華三集團(tuán)(以下簡稱新華三)以“天生極智·閃耀未來”為主題在天津正式發(fā)布全新一代關(guān)鍵業(yè)務(wù)智能存儲系統(tǒng)Primera。
    發(fā)表于 08-15 11:04 ?1036次閱讀

    浪潮信息以新一代存儲核心構(gòu)建新一代集中式和分布式存儲平臺

    隨著數(shù)字化轉(zhuǎn)型的持續(xù)深入,各行業(yè)用戶面臨的數(shù)據(jù)存儲挑戰(zhàn)也與日俱增。在此背景下,浪潮信息基于“存儲即平臺”戰(zhàn)略,以新一代G6存儲為核心,構(gòu)建
    的頭像 發(fā)表于 12-06 12:22 ?3495次閱讀
    浪潮信息以<b class='flag-5'>新一代</b><b class='flag-5'>存儲</b>核心<b class='flag-5'>構(gòu)建</b><b class='flag-5'>新一代</b>集中式和分布式<b class='flag-5'>存儲</b>平臺

    日志結(jié)構(gòu)存儲下數(shù)據(jù)放置的方法淺析

    日志結(jié)構(gòu)存儲在當(dāng)今存儲系統(tǒng)中被廣泛使用,然而其中的垃圾回收會將有效數(shù)據(jù)重新寫入導(dǎo)致寫放大現(xiàn)象。
    發(fā)表于 07-28 10:31 ?554次閱讀
    <b class='flag-5'>日志</b>結(jié)構(gòu)<b class='flag-5'>存儲</b>下數(shù)據(jù)放置的方法淺析
    主站蜘蛛池模板: 歪歪爽蜜臀AV久久精品人人槡 | 囯产精品一品二区三区 | 先锋资源久久 | 9797在线看片亚洲精品 | 日韩吃奶摸下AA片免费观看 | 亚洲区视频| 亚洲天堂999| 永久久久免费人妻精品 | 扒开黑女人p大荫蒂老女人 扒开粉嫩的小缝末成年小美女 | www.青青草| 91热久久免费频精品99欧美 | 一道精品视频一区二区三区 | 国产午夜伦伦伦午夜伦 | 国产又粗又猛又爽又黄的免费视频 | 男男高H啪肉Np文多攻多一受 | 渔夫床满艳史bd高清在线直播 | 古代荡女丫鬟高H辣文纯肉 姑娘视频日本在线播放 | 睡觉被偷偷进入magnet | 日韩在线 无码 精品 | 国内精品久久 | 亚洲AV无码专区国产精品99 | 亚洲精品一二三区-久久 | 玖玖在线精品 | 2017最新伦理伦理片67 | 99re这里只有精品国产 | 99热这里只有 精品 99热这里只就有精品22 | 小舞被爆操 | 国产亚洲中文字幕视频 | 精品一产品大全 | 久久亚洲午夜牛牛影视 | 欧美人与动牲交ZOOZ特 | 日本阿v直播在线 | 牲高潮99爽久久久久777 | 成人影片下载网站 | 欧美日韩午夜群交多人轮换 | 欧式午夜理伦三级在线观看 | 午夜神器老司机高清无码 | 国产亚洲欧洲日韩在线观看 | 亚洲 欧美 日韩 国产 视频 | 两个吃奶一个添下面视频 | 啊好大好厉害好爽真骚 |

    電子發(fā)燒友

    中國電子工程師最喜歡的網(wǎng)站

    • 2931785位工程師會員交流學(xué)習(xí)
    • 獲取您個性化的科技前沿技術(shù)信息
    • 參加活動獲取豐厚的禮品