360海量數據存儲 zeppelin設計與實現

2020-12-16 IT168

  本文編輯整理自【微學堂】第二十八期活動實錄。

  嘉賓介紹

  360 web平臺部基礎架構組技術經理, 主要負責360內部的資料庫和存儲系統 bada, pika, zeppelin, ceph 等開發和維護. 目前bada, pika, zeppelin, ceph已經幾乎使用在360 各個系統中, 每天承擔百億級別的訪問. 並且已經將pika, zeppelin 開源. 開源項目 pika, zeppelin, floyd, pink, nemo 作者. 對存儲, 資料庫, 內核, 分布式系統有一定的了解.

  直播實錄:

  大家好, 我是來自360基礎架構組技術經理陳宗志. 主要負責360 存儲, 中間件, 推送相關技術的實現

  本次分享主要向大家介紹我們這一年多做的另外一個存儲項目 zeppelin. 各位可能知道我們團隊有bada, Pika. Pika (https://github.com/Qihoo360/pika) 已經開源, 目前應該也有各個大公司使用到他們的線上環境中, 在線上我們有800+ 實例在線上穩定運行. 為什麼我們還要開發另一套存儲系統呢?

  我一直覺得不同的場景需要有不同的存儲系統去解決, 有在線存儲的需求, 有離線存儲的需求. 因此肯定不是一套存儲系統能夠通吃所有的場景(不過貌似spanner 在做這個事情)

  本次分享將闡述 Zeppelin 系統產生的背景,重點介紹 Zeppelin 系統的整個設計過程,並分享在分布式系統開發中的一些經驗。通過帶領大家重走 Zeppelin 的設計之路,讓大家了解如何設計一個分布式存儲系統,會遇到哪些問題,有哪些可能的解決思路。

  我們公司的github 地址

  https://github.com/Qihoo360

  我們團隊開發的 pika, pink, zeppelin, floyd 等等代碼都在上面

  我們先來談談在線存儲和離線存儲的區別

  離線存儲的需求很統一, 就是離線數據分析, 產生報表等等. 也因為這統一的需求, 所以目前hdfs 為首的離線存儲基本統一了離線存儲這個平臺. 離線存儲最重要的就是吞吐, 以及資源的利用率. 對性能, 可靠性的要求其實並不多. (所以這也是為什麼java系在離線存儲這塊基本一統的原因, java提供的大量的基礎庫, 包等等. 而離線存儲又對性能, 可靠性沒有比較高的要求, 因此java GC等問題也不明顯)

  所以我們可以看到雖然現在離線的分析工具一直在變, 有hadoop, spark, storm 等等, 但是離線的存儲基本都沒有變化. 還是hdfs 一統這一套. 所以我認為未來離線存儲這塊不會有太大的變化。

  在線存儲

  指的是直接面向用戶請求的存儲類型. 由於用戶請求的多樣性, 因此在線存儲通常需要滿足各種不同場景的需求.

  比如用戶系統存儲是提供對象的服務, 能夠直接通過HTTP接口來訪問, 那麼自然就誕生了對象存儲s3這樣的服務

  比如用戶希望所存儲的數據是關係性資料庫的模型, 能夠以SQL 的形式來訪問, 那麼其實就是mysql, 或者現在比較火熱的NewSql

  比如用戶只希望訪問key, value的形式, 那麼我們就可以用最簡單的kv接口, 那麼就有Nosql, bada, cassandra, zeppelin 等等就提供這樣的服務

  當然也有多數據結構的請求, hash, list 等等就有了redis, 有POSIX文件系統接口了請求, 那麼就有了cephfs. 有了希望提供跟磁碟一樣的iSCSI 這樣接口的塊設備的需求, 就有了塊存儲, 就是ceph.

  從上面可以看到和離線存儲對比, 在線存儲的需求更加的複雜, 從接口類型, 從對訪問延期的需求, 比如對於kv的接口, 我們一般希望是2ms左右, 那麼對於對象存儲的接口我們一般在10ms~20ms. 對於SQL, 我們的容忍度可能更高一些, 可以允許有100 ms. 處理延遲的需求, 我們還會有數據可靠性的不同, 比如一般在SQL 裡面我們一般需要做到強一致. 但是在kv接口裡面我們一般只需要做到最終一致性即可. 同樣對於資源的利用也是不一樣, 如果存儲的是稍微偏冷的數據, 一定是EC編碼, 然後存在大的機械盤. 對於線上比較熱的數據, 延遲要求比較高. 一定是3副本, 存在SSD盤上

  從上面可以看到在線存儲的需求多樣性, 並且對服務的可靠性要求各種不一樣, 因此我們很難看到有一個在線存儲能夠統一滿足所有的需求. 這也是為什麼現在沒有一個開源的在線存儲服務能夠像hdfs 那樣的使用率. 因此一定是在不同的場景下面有不同的存儲的解決方案

  總結一下在線存儲的要求

  可以看到Facebook infrastructure stack 裡面就包含的各種的在線存儲需求. 裡面包含了熱的大對象存儲Haystack, 一般熱的大對象存儲f4, 圖資料庫Tao. key-value 存儲memcached 集群等等

  對應於google 也會有不同的在線存儲產品. 對應於Google 有MegaStore, Spanner 用於線上的SQL 類型的在線存儲, BigTable 用於類似稀疏map 的key-value存儲等等。

  個人認為對於在線存儲還是比較適合C++來做這一套東西, 因為比較在線存儲一般對性能, 可靠性, 延遲的要求比較高.

  那麼這些不同的存儲一般都怎麼實現呢?, 很多在線存儲比如對象存儲的實現一般都是基於底下的key-value進行封裝來實現對象存儲的接口. ceph 就是這方面這個做法的極致.

  ceph 底下的rados 本質是一個對象存儲, 這裡的對象存儲跟s3 的對象存儲還不一樣, 只是提供了存儲以為key 對應的value 是對象的形式. 然後基於上層基於librados 封裝了librbd 就實現了塊設備的協議, 那麼就是一個塊存儲. 基於librados 實現了Rados Gateway 提供了s3 的對象存儲的協議就封裝成s3對象存儲. 基於librados 實現了POSIX 文件系統的接口, 就封裝成了分布式文件系統Ceph FS. (不過我認為ceph 底下的rados實現的還不夠純粹, 因為rados對應的value 是類似於一個對象文件. 比如在基於librados 實現librbd的時候很多對象屬性的一些方法是用不上的)

  同樣google 的F1 是基於spanner 的key-value 接口實現了SQL了接口. 就封裝成了NewSql

  因此其實我們也可以這麼說對於這麼多接口的實現, 其實後續都會轉換成基於key-value 接口實現另一種接口的形式, 因為key-value 接口足夠簡單, 有了穩定的key-value 存儲, 只需要在上層提供不同接口轉換成key-value 接口的實現即可. 當然不同的接口實現難度還是不太一樣, 比如實現SQL接口, POSIX文件系統接口, 圖資料庫肯定要比實現一個對象存儲的接口要容易很多

  所以**zeppelin 定位的是高可用, 高性能, 可定製一致性的key-value 服務**, 上層可以對接各個協議的實現, 目前zeppelin 已經實現支持key-value 接口, 用於線上搜索系統中. 標準的S3 接口實現, 並且用於公司內部存儲docker 鏡像, 代碼發布系統等等

  這個是目前360 的存儲體系

  講了這麼多我對存儲的了解, 我們對zeppelin 的定位. 那麼接下來聊聊zeppelin 具體的實現

  CAP 理論指的是 CAP 並不能同時滿足, 而P 是基本都需要滿足的, 所以基本都是AP, CP. 但是這裡並不是說只能選AP 就沒有C, 而是Consistency 的級別不一樣, 同樣CP 也值得並不是A, 只是A的級別不一樣而已

  數據分布

  * 均勻性(uniformity)

  * 穩定性(consistency)

  所有的分片策略都是在均勻性和穩定性之間的折衷

  常見策略

  * 一致性Hash

  * 固定Hash 分片

  * Range Hash

  * crush

  zeppelin 的選擇

  固定Hash 分片

  1. 實現簡單

  2. Partition Number > Server Number 可以解決擴展性問題

  3. 固定Hash 分片便於運維管理

  4. 通過合理設置Hash 函數已經Server 對應的Partition數, 解決均勻性問題

  有中心節點的設計.

  * 為什麼這麼做?

  * 目前主流的設計一般是兩種

  * Bigtable 為代表的, 有MetaServer, DataServer的設計, MetaServer存儲元數據信息, DataServer存儲實際的數據. 包括 百度的Mola, bigtable, Hbase等等

  * Dynamo 為代表的, 對等結構設計. 每一個節點都是一樣的結構, 每一個節點都保存了數據的元信息以及數據. 包括 cassandra, Riak 等等

  zeppelin 的選擇

  有中心節點優點是簡單, 清晰, 更新及時, 可擴展性強. 缺點是存在單點故障

  無中心節點優點是無單點故障, 水平擴展能力強. 缺點是消息傳播慢, 限制集群規模等等

  因為後續我們會考慮支持zeppelin 到千個節點的規模, 因此無中心節點的設計不一定能夠滿足我們後期的擴展性, 所以zeppelin 是有中心節點的設計, 那麼我們就需要做大量的事情去減少對Meta Server 的壓力

  zeppelin 選擇有中心節點的設計, 但是我們操作大量的優化去儘可能避免中心節點的壓力, 同時通過一致性協議來保證元數據更新的強一致

  1. Client 緩存大量元信息, 只有Client 出錯是才有訪問Meta Server

  2. 以節點為維度的心跳設計

  副本策略

  1. Master - Slave

  以MongoDB, redis-cluster, bada 為主的, 有主從結構的設計, 那麼讀寫的時候, 客戶端訪問的都是主副本, 通過binlog/oplog 來將數據同步給從副本

  2. Quorum(W+R>N)

  以cassandra, dynamo 為主的, 沒有主從結構的設計, 讀寫的時候滿足quorum W + R > N, 因此寫入的時候寫入2個副本成功才能返回. 讀的時候需要讀副本然後返回最新的. 這裡的最新可以是時間戳或者邏輯時間

  3. EC (erasure code)

  EC 其實是一個CPU 換存儲的策略, ec 編碼主要用於保存偏冷數據, 可以以減少的副本數實現和3副本一樣的可用性. ec編碼遇到的問題是如果某一個副本掛掉以後, 想要恢復副本的過程必須與其他多個節點進行通信來恢復數據, 會照成大量的網絡開銷.

  zeppelin 的選擇

  目前zeppelin 只實現的Master-Slave 策略, 後續會根據業務場景, 存儲成本的需求實現EC, Quorum.

  存儲引擎

  Manos Athanassoulis [**Designing Access Methods: The RUM Conjecture**](http://101.96.8.165/stratos.seas.harvard.edu/files/stratos/files/rum.pdf)

  RUM 是 寫放大, 讀放大, 空間放大 之前的權衡

  寫放大: 寫入引擎的數據和實際存儲的數據大小比

  讀放大: 讀放大是一次讀取需要的IO 次數大小比

  空間放大: 實際的數據總量和引擎中存儲的數據總量關係大小比

  當然這裡主要根據DAM 模型(disk access model), 得出結論

  當然這裡並沒有考慮 LSM Tree 裡面場景的 bloom filter 等等

  這裡B+ tree 主要用在 資料庫相關, 支持範圍查找的操作, 因為B+ Tree 在底下有序數據是連續的

  zeppelin 的選擇

  zeppelin 目前使用的是改過的rocksdb, nemo-rocksdb. nemo-rocksdb 支持TTL, 支持後臺定期compaction 等等功能

  https://github.com/Qihoo360/nemo-rocksdb

  一致性協議

  floyd 是c++ 實現的raft 協議, 元信息模塊的管理主要通過floyd 來維護.

  1. 關於paxos, multi-paxos 的關係

  其實paxos 是關於對某一個問題達成一致的一個協議. paxos make simple 花大部分的時間解釋的就是這個一個提案的問題, 然後在結尾的Implementing a State Machine 的章節介紹了我們大部分的應用場景是對一堆連續的問題達成一致, 所以最簡單的方法就是實現每一個問題獨立運行一個Paxos 的過程, 但是這樣每一個問題都需要Prepare, Accept 兩個階段才能夠完成. 所以我們能不能把這個過程給減少. 那麼可以想到的解決方案就是把Prepare 減少, 那麼就引入了leader, 引入了leader 就必然有選leader 的過程. 才有了後續的事情, 這裡可以看出其實lamport 對multi-paxos 的具體實現其實是並沒有細節的指定的, 只是簡單提了一下. 所以才有各種不同的multi-paxos 的實現

  那麼paxos make live 這個文章裡面主要講的是如何使用multi paxos 實現chubby 的過程, 以及實現過程中需要解決的問題, 比如需要解決磁碟衝突, 如何優化讀請求, 引入了Epoch number等, 可以看成是對實現multi-paxos 的實踐

  2. 關於 multi-paxos 和 raft 的關係

  從上面可以看出其實我們對比的時候不應該拿paxos 和 raft 對比, 因為paxos 是對於一個問題達成一致的協議, 而raft 本身是對一堆連續的問題達成一致的協議. 所以應該比較的是multi-paxos 和raft

  那麼multi-paxos 和 raft 的關係是什麼呢?

  raft 是基於對multi paxos 的兩個限制形成的

  * 發送的請求的是連續的, 也就是說raft 的append 操作必須是連續的. 而paxos 可以並發的. (其實這裡並發只是append log 的並發提高, 應用的state machine 還是必須是有序的)

  * 選主是有限制的, 必須有最新, 最全的日誌節點才可以當選. 而multi-paxos 是隨意的 所以raft 可以看成是簡化版本的multi paxos(這裡multi-paxos 因為允許並發的寫log, 因此不存在一個最新, 最全的日誌節點, 因此只能這麼做. 這樣帶來的麻煩就是選主以後, 需要將主裡面沒有的log 給補全, 並執行commit 過程)

  基於這兩個限制, 因此raft 的實現可以更簡單, 但是multi-paxos 的並發度理論上是更高的.

  可以對比一下multi-paxos 和 raft 可能出現的日誌

  multi-paxos

  raft

  ▲

  可以看出, raft 裡面follower 的log 一定是leader log 的子集, 而multi-paxos 不做這個保證

  3. 關於paxos, multi-paxos, raft 的關係

  所以我覺得multi-paxos, raft 都是對一堆連續的問題達成一致的協議, 而paxos 是對一個問題達成一致的協議, 因此multi-paxos, raft 其實都是為了簡化paxos 在多個問題上面達成一致的需要的兩個階段, 因此都簡化了prepare 階段, 提出了通過有leader 來簡化這個過程. multi-paxos, raft 只是簡化不一樣, raft 讓用戶的log 必須是有序, 選主必須是有日誌最全的節點, 而multi-paxos 沒有這些限制. 因此raft 的實現會更簡單.

  因此從這個角度來看, Diego Ongaro 實現raft 這個論文實現的初衷應該是達到了, 讓大家更容易理解這個paxos 這個東西

  zeppelin 的選擇

  zeppelin MetaServer 一致性是由自己實現的raft 庫floyd 來保證. 寫入和讀取可以通過raft 協議實現強一致, 同時為了性能考慮我們在讀取的時候還提供DirtyRead 的接口, floyd 已經在github上面開源, 是用c++實現的raft 協議, 實現的非常的簡介明了

  https://github.com/Qihoo360/floyd

  floyd 的壓測報告

  https://github.com/Qihoo360/floyd/wiki/5-性能測試

  整體實現

  Meta Server 總體結構

2. Data Server 總體結構

  Zeppelin自上而下的層次如圖所示。

  - Network Proxy:負責網絡的壓包解包,採用Protobuf協議通Meta Server, Client, 及其他Node Server進行交互;

  - Zeppelin Process:Zeppline主要邏輯處理層,包括分表分片,數據同步,命令處理等;

  - Binlog:操作日誌,同時是同步模塊的數據來源;

  - 存儲層:採用Rocksdb進行數據存儲。

  3. 線程模型

  Zeppelin採用多線程的方式進行工作,Zeppline中的所有線程都是與Node綁定的,不會隨著Table或Partiiton的個數增加而增加。根據不同線程的任務及交互對象將線程分為三大類:

  1,元信息線程,包括Heartbeat Thread及MetaCmd Thread

  - Heartbeat Thread:負責與Meta Server保持的心跳連接,並通過PING信息感知Meta Server元信息的更新;

  - MetaCmd Thread:Heartbeat Thread感知到元信息的更新後由MetaCmd Thread從Meta Server獲取最新的元信息。通過元信息中的副本信息,MetaCmd Thread會負責修改和維護改Node Server與其他Node Server的Peer關係;

  2,用戶命令線程,包括Dispatch Thread及Worker Thread

  - Dispatch Thread:接受用的連結請求並將客戶端連結交個某個Worker Thread線程處理;

  - Worker Thread:處理用戶請求,寫命令會先寫Binlog,之後訪問DB完成用戶命令的執行。

  3, 同步線程,包括服務於副本間數據同步功能的多個線程

  - TrySync Thread: 負責發起主從同步請求。MetaCmd Thread修改副本狀態後,TrySync Thread會一次對當前Node Server負責的所有需要建立主從關係的Partition的主Partition發送Sync命令,該Sync命令會首先獲取本地的binlog位置作為當前主從同步的同步點;

  - Binlog Sender Thread:Partition的不同副本之間建立主從關係後會由Binlog Sender Thread讀取並向從Parition的Binlog Receiver Thread 發送binlog項。這個過程通用戶命令的執行異步進行,所以從的Partition可能會落後於主。同一個Sender會負責多個Partition;

  - Binlog Receiver Thread:接受Binlog Sender Thread發來的Binlog項,寫Binlog並將寫DB的操作分發給不同的Binlog BgWorker;

  - Binlog Receive BgWorker:接受Binlog Receiver Thread發來的請求,寫DB完成操作。

  4,後臺工作線程,包括BGSave and DBSync Thread,Binlog Purge Thread

  - Binlog Purge Thread:為了減少對磁碟空間的佔用,Binlog Purge Thread會定期刪除過期的Binlog

  - BGSave and DBSync Thread:建立主從關係時,如果主Partition發現同步點已經落後於當前保留的最早的binlog,則需要進行全量同步。該線程會首先將整個數據內容dump一份並發送給對應從Partition。全同步過程利用Rsync實現。

  4. 客戶端請求

  客戶端需要訪問針對某個業務Table進行操作時,會先向Meta Server請求改Table的元信息。之後每個訪問請求,都會根據key計算出其所屬於的Partition,通過元信息計算器Master所在的Node Server。直接請求改Node Server。

  5. 故障檢測及處理

  Node Server定期向Meta Server發送PING消息,當節點宕機或者網絡中斷發生時。Meta Server會感知並修改其維護的元信息,並將元信息Epoch加一。元信息修改後,其他Node Server會從PING消息的回覆中獲得新Epoch,由於與本地記錄不同,Node Server會由MetaCmd Thread向Meta Server 發送PULL消息主動拉去最新元信息。

  元信息中記錄各個Table中每個Partition所負責的Master Node Server及兩個Slave Node Server。Node Server獲得最新的元信息,並根據該信息修改自己維護的Partitions的主從角色,建立主從關係,提供服務。

相關焦點

  • 天賦異稟,高存儲密度成為海量數據存儲首選
    天賦異稟,高存儲密度成為海量數據存儲首選 IBM中國 發表於 2021-01-06 16:37:37 1986年 1月 28日,美國「挑戰者」號太空梭從佛羅裡達州發射後約 73秒便發生了「爆炸」,機上 7名太空人不幸罹難
  • 360安全大腦賦能安全運營與應急響應:海量數據下的實戰方法論
    從經驗上來看,首先數據收集要儘可能去靠近一些收斂的集中點,這樣可以降低數據收集或者標準化的成本。在整體威脅運營的架構設計上,360本身擁有海量的威脅情報數據的來源,利用360本身雲端的安全大腦結合本地的安全大腦去做整體聯動的運營。
  • 海量結構化數據存儲技術揭秘:Tablestore存儲和索引引擎詳解
    前言表格存儲Tablestore是阿里雲自研的面向海量結構化數據存儲的Serverless NoSQL多模型資料庫。Tablestore在阿里雲官網上有各種文檔介紹,也發布了很多場景案例文章,這些文章收錄在這個合集中《表格存儲Tablestore權威指南》。
  • 基於新型存儲的大數據存儲管理
    PCM等存儲級主存以其非揮發、存儲速度快、易實現高密度等技術特點,在高速與海量存儲方面具有巨大的潛能,已被認為是下一代非易失存儲技術的發展方向。另外,因該技術兼有DRAM的高速隨機訪問和快閃記憶體的非易失特性,模糊了主存和外存的界限,有望突破原有的存儲架構,實現更高性能的存儲。
  • 浪潮推出面向雲計算、大數據業務的全能型存儲AS13000
    雲計算應用模式的發展變化也吸引了應用業務類型的快速增加以及業務規模的迅速擴大,大規模的業務應用帶來了海量規模的數據存儲需求、面向海量數據的高性能IO需求、以及相關的數據冗餘保護和軟硬體故障情況下的數據可靠性保護需求,這就需要有全能型的產品來滿足各種複雜需求。
  • 從一個浪潮案例看海量數據的分級保護應用
    移動互聯時代,企業都面臨著海量數據帶來的挑戰,有一些企業馴服了海量數據,實現了「存的下、算的出」,但即使如此,這些企業很少跨過數據保護的門檻,因為傳統數據保護技術在面對PB級別數據量時,都或多或少的出現了問題,浪潮工程師開發了分級保護方案,很好的滿足了100PB級別的數據保護需求。
  • 河南移動的MPP大數據平臺對象存儲實踐
    而通過對海量數據資源的挖掘,可支撐運營商快速響應需求,實現敏捷運營,以及推動數位化轉型。例如,利用大數據對DPI(Deep Packet Inspection,基於數據包的深度檢測)等數據進行分析,可獲取客戶的行為偏好,實現客戶精準營銷。
  • 理解Human Information和海量數據
    傳統的信息優化方式不能處理分散的、海量的、非結構化的信息數據。惠普最近的一項調查顯示,只有2%的受訪者可以在合適的時間提供合適的信息,以實現實時支持合適業績的目的。   全新惠普信息優化解決方案   惠普可以通過全新惠普信息優化解決方案滿足上述需求,其中包括惠普下一代信息平臺——智能數據操作平臺(IDOL)10。
  • 計算存儲分離之「數據存儲高可用性設計」
    自然地,我們把目光聚焦到了分布式存儲系統上。  從目前行業發展趨勢來看,各大網際網路公司都設計或者維護了自己的分布式存儲系統。如Google的GFS(Colossus 為GFS第二代分布式存儲系統),Facebook和LinkedIn的HDFS等。由此可見,分布式存儲也是大勢所趨。
  • 海量數據優化查詢的套路有哪些?
    對於海量數據查詢的場景,往往對耗時要求有一定的追求,除了默認的索引之外還有什麼方式可以提高檢索速度?本文主要對工作中用到的兩種海量數據存儲和查詢工具:clickhouse和elastic search在查詢中遇到的一類提高檢索速度的方式進行總結 發現,二者均使用了ordinal方式對查詢進行了優化。
  • 釋放海量非結構化數據潛能,愛數AnyShare技術探索之旅揭秘
    海量非結構化數據正在洶湧而來  如今,非結構化數據已佔據數據總量的90%,且保持高速增長;非結構化數據存在於各種設備以及各種系統之中,無處不在。毋庸置疑,海量非結構化數據的時代已經到來,海量非結構化數據的管理、處理、保護等巨大挑戰與難題也接踵而至。
  • 存放海量數據太費錢?科學家們找到了新方法
    文/IT創事記 祁萌這些年在科學界,國際頂級機構一直在做著同一件事,那就是為他們持續增長的海量數據找到價格更便宜的存身之處。現在,他們中的一些說:找到了。這些機構用它來支持超大規模的數據存儲,實現並行文件系統接口(pNFS)和分層存儲管理工具等。兼容TensorFlow等人工智慧和深度學習 (AI/DL) 工具也是他們的關注點——這些國際頂級機構永遠都會站在科技的最前沿。事實上,CORTX的用例非常廣泛,除人工智慧和機器學習,還包括了混合雲、邊緣、高性能計算等領域。
  • 實時海量日誌分析系統的架構設計、實現以及思考
    Storm是一個分布式實時計算系統,它可以很好的處理流式數據。利用storm我們幾乎可以直接實現一個日誌分析系統,但是將日誌分析系統進行模塊化設計可以收到更好的效果。模塊化的設計至少有兩方面的優點:模塊化設計可以使功能更加清晰。整個日誌分析系統可以分為「數據採集-數據緩衝-數據處理-數據存儲」四個步驟。
  • 紫晶存儲發布光存儲數據報告:一圖看懂光存儲介質的技術光環
    在資訊時代,數據呈現出爆炸增長的態勢,但海量數據的丟失也對存儲介質提出了更大的挑戰。近日,紫晶存儲發布了題為《解決大數據存儲,光存儲駕到》的光存儲數據報告,認為光存儲是大數據存儲的最優解,可以有效解決目前存儲行業中面臨的多種難題。但光存儲作為四大存儲介質之一,真的有如此巨大的優勢而成為未來存儲的趨勢嗎?
  • 釋放海量非結構化數據潛能,愛數AnyShare Family 7技術探索之旅揭秘
    海量非結構化數據正在洶湧而來如今,非結構化數據已佔據數據總量的90%,且保持高速增長;非結構化數據存在於各種設備以及各種系統之中,無處不在。毋庸置疑,海量非結構化數據的時代已經到來,海量非結構化數據的管理、處理、保護等巨大挑戰與難題也接踵而至。
  • 精創電氣物聯網電控箱實現製冷數據實時雲存儲
    有業內人士表示,物聯網電控箱是一個可直接控制、可把面板單獨拉出來、可用手機控制、用數據說話的電控箱。網際網路電控箱具備普通電控箱的所有常規功能,另外還兼具延伸功能。它不僅是一個產品,更是一個強大的系統,這個系統對經銷商、工程商和用戶來說均可帶來獲利。  物聯網電控箱憑藉其強大系統在醫藥冷鏈方面廣受關注。
  • 千億級數據毫秒響應,為什麼它最有機會幹掉傳統數據存儲模式?
    李博士介紹,由於Hadoop的設計初衷是針對存儲和分析離線大數據,因此無法提供便捷高效的數據交互、多維分析、快速查詢服務。為了幫助企業做到穩、準、快的實現海量數據的調用需求,掌握PB級數據核心處理技術的大數據產品及解決方案供應商睿帆科技,在原有的零距大數據中臺的基礎上,自研了一款具有千億級數據毫秒查詢速度的分布式分析型資料庫雪球DB。
  • 12位高速ADC存儲電路設計與實現
    4 AD9225的存儲方案設計  在高速數據採集電路的實現中,有兩個關鍵的問題:一是模擬信號的高速轉換;二是變換後數據的存儲及提取。AD9225的採樣速度可達25Msps,完全可以滿足大多數數據採集系統的要求,故首要解決的關鍵問題是與存儲器的配合問題。 在數據採集電路中, 有以下幾種存儲方案可供選擇。  (1)分時存儲方案  分時存儲方案的原理是將高速採集到的數據進行分時處理, 通過高速鎖存器按時序地分配給N個存儲器。
  • 採用SAR系統設計高速數據採集和存儲系統
    SAR系統的數據採集和存儲處理需要滿足正交兩路(I/Q)雷達回波信號數據同時採集,並實現高速傳輸和大容量長時間實時存儲。根據這一要求,結合採集存儲的發展趨勢,設計並實現了一種應用於SAR,基於SATA硬碟的高速數據採集和存儲系統。
  • 海量數據時代,利用鐵威馬NAS搭建私有雲
    隨著技術的發展,我們進入海量數據時代,當數據越來越多,肯定不會希望換一臺手機或者換一臺電腦就丟掉裡面的數據。也許你換機很快,但總有重要的數據需要保留,面對日益增長的數據量,而公有雲盤又各種限速後,越來越多的人將目光轉移到NAS上面,利用NAS搭建自己的私有雲存儲,來滿足數據存儲、備份需求,釋放你的存儲空間!