㈠ 語義信息的存儲
無論是知識庫還是服務的語義描述都需要具有良好的組織和存儲，以支持高效推理和服務檢索發現。目前對於本體的存儲方法基本有三種(李勇等，2008):
(1)純文本，如 OWL 文件。由於 XML 的信息組織和存儲方式結構復雜，而且存在冗餘等，基於其上的查詢檢索效率通常會比較低。純文本的方式適合本體比較小的時候，不適合本體大規模應用的情況。
(2)資料庫: 是一種比較好的持久化存儲方式，最大好處是便於查找，可存放大本體，查詢效率高，特別在 I/O 效率上。但是資料庫方式存在本體查詢語言到 SQL 的轉換問題，需要藉助於第三方中間件或自定義實現。
(3)專門的管理工具: 比如說 OMM(Ontology Middleware Mole)支持對 RDF、OWL 的存儲管理，還提供各種介面，可以使用查詢語言對 RDF 或者 OWL 進行查詢。綜合對比這三種本體存儲方式，由於關系資料庫存儲幾十年的技術積累，以及它的海量存儲特點而成為了許多研究者的首選。
5.4.3.1 本體的關系資料庫存儲模式
由於本體模型和關系模型的差異，目前存在多種在關系模型中存儲本體的方法，其主要可以分為以下四類(陶皖等，2007; 陳光儀，2009)。
5.4.3.1.1 水平模式
該模式只在資料庫中保留一張通用表，表中列為本體中的屬性。整個本體庫中定義了多少個屬性，這張表就有多少個列，具體如圖 5.28 所示。本體中的每個實例對應該表中的一條記錄。這種存儲模式結構簡單，執行查詢操作比較方便。但是該通用表包含了大量的列，而現有的資料庫系統對一張表中列的個數都是有限制的，所以該模式無法存儲規模較大的本體。而且表中的數據過於稀疏。由於每個實例對應關系表中的一行，如果其在某些屬性列上沒有值，那麼必須將對應的屬性值設置為空，這將導致大量空欄位的出現，不僅浪費存儲空間，而且增加了索引維護的代價。另外該通用表中一個實例的屬性和屬性值只能是一對一，而實際情況往往是一對多，因此無法存儲具有這種特徵的本體。隨著應用中本體的進化，還需要時常更新通用表中的列，重新組織表結構，這將耗費極大的系統代價。
圖 5.28 水平存儲模式
5.4.3.1.2 垂直模式
垂直模式包含一張三元組表，表中的每條記錄都對應一個 RDF 三元組(主語，謂詞，賓語)，具體如圖 5.29 所示。因此這種模式下，需要將本體中的所有信息都以 RDF 三元組的形式表示出來。Protege(2002)中便是使用了這種存儲模式將本體存儲於資料庫中。這種模式設計簡單，並且結構穩定。如果本體進行了更新，只需修改表中相應的元組即可。另外，該模式通用性好，因為現有的本體模型都可以轉換為 RDF 模型表示。但是這種模式的可讀性較差，若對本體信息進行查詢，那麼設計對應的 SQL 語句比較麻煩。除此之外，由於所有信息都存放在三元組表中，導致任何一個本體信息查詢都必須遍歷整個數據表，特別是那些需要進行表連接的查詢，使得查詢效率非常低，這是這種模式最大的不足之處。
圖 5.29 垂直存儲模式
5.4.3.1.3 分解模式
該模式與水平模式和垂直模式的一個顯著的區別是它使用了若干張表，其基本思想是將資料庫進行模式分解。根據分解的對象不同，現有的採用分解模式的方法有兩種。①基於類的分解模式，即為本體中的每個類都創建一張單獨的表，表名為類名，表的列為類的屬性，具體如圖 5.30 所示。這種模式結構清晰，但是很難適應本體動態變化的情況，因為隨著本體中類或者屬性的變化，表結構都要隨著變化。②基於屬性的分解模式，即為本體中的每個屬性創建一張單獨的表，表名為屬性名，每個表都包含兩個列，分別代表RDF 三元組中的主語和賓語，具體如圖 5.31 所示。在該模式中對類的隱含實例的查詢代價很大，而且在現有的這兩種分解模式的方法中，隨著本體的變化都要不斷的創建和刪除表，而在資料庫系統中創建和刪除表的效率很低。
圖 5.30 按類分解模式
圖 5.31 按屬性分解模式
5.4.3.1.4 混合模式
該模式通常將上述幾種模式進行混合使用。例如，Pan 等(2003)提出這樣一種將基於類的分解模式與基於屬性的分解模式混合的存儲模式，即在本體中定義一個類就為該類創建一個表(創建方法類似於基於類的分解模式)，在本體中定義一個屬性就為該屬性創建一個表(創建方法類似於基於屬性的分解模式)。然而，與基於類的分解模式不同的是，該混合模式在類對應的表中不記錄相應實例的所有信息，而只記錄實例的 ID。實例在各個屬性上的取值則分別記錄在各屬性對應的表中，所以和基於屬性的分解模式類似，該模式在屬性對應的表中仍然需要兩列: 主語和賓語。對於本體類數目不多的情況下，這種模式在簡單檢索的情況下，運行得很好。但是，如果本體的類比較多，這種方式就會存在一些問題，例如: 資料庫無法容納這么多表，或者效率低下。
針對上述四種模式，陳光儀(2009)從四個方面對適用場合、查詢和更新效率、結構清晰以及易理解性、可擴展性四個方面對他們進行了綜合對比(表 5.4):
表 5.4 不同存儲模式的綜合對比
(修改自陳光儀，2009)
通過上述對本體存儲模式的闡述及之間的綜合對比發現，本體存儲模式除了應該具有盡量高的規范化程度(例如滿足第三範式或 BCNF 范圍等)，還應該滿足以下三個原則。
(1)模式結構易於理解。該原則是為了便於本體查詢的實現。如果模式結構不直觀，會給查詢語句的設計帶來困難。例如，垂直模式不滿足該要求，它將所有的信息都採用三元組的形式存儲在一張表中，不容易理解表中元組的含義，加重了本體查詢設計的負擔。
(2)模式結構穩定。即本體的變化不會引起資料庫表結構的變化。因為本體是不斷進化的，如果設計的模式結構會隨著本體的變化而變化，資料庫系統對其維護代價太大。現有的水平模式、分解模式和混合模式都不滿足該要求。
(3)查詢效率高。該原則是評價各種存儲模式的一個重要指標。因為本體中不僅包含大量的數據，而且查詢中還經常需要進行表連接。例如在現有的垂直模式和基於屬性的分解模式中，那些涉及表連接的查詢效率非常低。
目前在基於資料庫的本體存儲的實踐上，一些學者開展了相關的研究工作:
燕雲鵬(2007)和陳光儀(2009)提出了類似的針對於針對 OWL 的本體資料庫的混合本體存儲模式(圖 5.32，5.33)。可以看出這種模式是以基於屬性的分解模式與垂直模式的混合體，具有較好的擴展性。但是存在的問題是效率不夠高，所有的類存儲在一個表中，所有的實例也存儲在一個表中，這種方式的檢索效率比較低。另外存儲實例的表(Instance，Proterty，Value)中欄位 Value 必須存儲許多種不同類型的數值，比如有的是文本型，而有的卻是數值型，使得數據不夠清晰。此外，在針對幾何體這種復雜的地理對象，這種欄位就比較難以存儲。
圖 5.32 本體的資料庫混合存儲模式(據燕雲鵬，2007)
ebRIM(ebXML Registry Information Model)是一個主流的信息注冊模型，已成為事實上的標准，得到了 OGC 等支持。OGC 已經實現了基於 ebRIM 的目錄服務，並推薦其作為目錄服務的實現規范。但是目前基於 ebRIM 的目錄服務只支持普通的基於關鍵字的檢索。為此，一些學者已經開始研究如何擴展 ebRIM 實現對語義信息特別是 OWL 的注冊。Dogac 等(2004)提出了如圖 5.34 所示的一種通過將 XML 形式存儲的 OWL 文件轉換為以資料庫形式存儲，使得查詢檢索更加快速，管理維護也更加方便。為了能在 ebRIM 存儲復雜的地理空間信息對象，一些學者開展了基於 ebRIM 的地理擴展方面的研究工作。樂鵬(2007)在其論文中提出了兩種擴展方式: ① 從類 「ExtrinsicObject」 派生了「CSWExtrinsicObject」來描述那些不是 ebRIM 自身定義的元數據對象。比如類 「Dataset」繼承了 「CSWExtrinsicObject」來描述空間數據集。②對 ebRIM 已有的類別增加 「Slot」。每一個從 「RegistryObject」繼承下來的類均允許添加 「Slot」。ebRIM 中的 「Service」類可以用來描述空間服務，但是已有的屬性不足以描述空間網路服務。因此，通過添加「Slot」到 「Service」類中以定義從 ISO 19119 派生的屬性。如圖 5.35 所示為經擴展後的ebRIM 高層模型圖，其中 灰 色 填 充 的 矩 形 框表示 擴 展 的對 象 類。該 模 式 與 前 面 燕 雲 鵬(2007)和陳光儀(2009)提出的模式相比，本質上差別不大，也是以基於屬性的分解模式與垂直模式的混合體，只不過是基於標準的 ebRIM 注冊模型，並且將其中的分類系統相關的類單獨以兩張表存儲。該模式也具有很好的擴展性，也存在同樣的一些問題。
圖 5.33 本體的資料庫混合存儲模式(據陳光儀，2009)
海洋信息網格技術與應用
續表
5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)
5.4.3.2 基於多分解策略的混合存儲模式實現
對知識庫以及服務語義注冊信息的存儲的實現上，本書在現有的研究成果的基礎上，結合本體組織構成及特點等實際需求，提出了一種基於多分解策略的混合關系資料庫存儲模式。
該方法的指導思想是: 先按類對其中的數據專題、數據模式、處理模型等進行類的分解，然後結合屬性的特性進行基於屬性的分解。其中基於類的分解中，可能粒度的大小不一，可能是一個類或者具有相關或相似的一些類劃分為一張表存儲; 而基於屬性的剖分，也並不是所有具有該屬性的類以一個表存儲，而可能是只針對一個類也單獨組織為一張表，其具體思路如下:
圖 5.35 經擴展的 ebRIM 高層模型圖(據樂鵬，2007)
(1)類的分解: 因為本研究的存儲模型不是為了實現一個通用的本體存儲模型，而是為了實現一個服務於海洋信息服務領域的本體存儲模型。海洋信息服務領域必然會牽涉到一些對象，比如對服務、模型、參數等對象，並且對這些對象的認識也基本上確定(也就是說這些對象類所具有的屬性及之間的關系基本明確)，所以沒必要像上面幾種實現方案那樣因為不能預知都有哪些類，各類都有哪些屬性而將所有的實例的組織按垂直方式進行存儲，也沒有必要有一些表(比如獨立的屬性表，屬性的作用域和值域表等); 而有必要針對海洋信息服務領域內的這些類的信息內容獨立出一些表: 對於海洋專題，地理名實體、處理模型、數據模式等海洋信息檢索發現中常用的對象，則有必要進行分開存儲，否則必然使得結構不清晰，且檢索查詢效率低。
(2)對於專題、空間形態以及模型功效等只是簡單的分類系統，所具有的屬性少，而且今後存在派生新的種類的可能，因此必須具備一定的擴展性。針對這類數據。它們的存儲方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 標注本體類是屬於專題(比如 「海流」)或者其他。
(3)對於取值不唯一的屬性，且大部分類或實例都具有的屬性，則採用基於屬性的分解模式。比如對於別名屬性(hasAliasName)，有可能一個類實例具有多個別名，這種情況下，則採取基於屬性的組織方式。該表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本體類的 ID，也可以是本體實例的 ID，還可以是本體屬性的 ID，因為類、實例和屬性都可以有別名。
(4)對於復雜的屬性，採取大二進制存儲的方式。比如對於地名實例的空間覆蓋范圍，則不考慮其實際內部是包含多少個組成部分，統一按一個 shape 存儲在資料庫中。當然這里藉助了 ArcGIS 的 GDB 的 FeatureClass 矢量數據模型，並對於不同空間形態的則採用了多張表(點狀地名類、線狀地名類、面狀地名類)，其組織方式是(GeoNameObjec-tID，shape)。同樣，對於模型本體中的內部流程本體，也採用了大二進制方式存儲，將整個流程 XML 描述文件，作為一個整體存放於欄位中，其大體組織方式為(ModelID，FlowXML)。
(5)本研究採用 ArcGIS 的 GeoDatabase 作為存儲模型。本體類(ontClass)的存儲結構如圖 5.36 所示，資料庫的總體組織結構如圖 5.37 所示。
圖 5.36 本體類(onClass)的存儲結構
㈡ 2020-06-29：本地消息使用什麼東西存儲
很多方式，根據要求不同可以選擇不同方式
比如文本，單機資料庫等等
祝好運，望採納。
㈢ 目前主要三種數據存儲方式
三種存儲方式：DAS、SAN、NAS
三種存儲類型：塊存儲、文件存儲、對象存儲
塊存儲和文件存儲是我們比較熟悉的兩種主流的存儲類型，而對象存儲（Object-based Storage）是一種新的網路存儲架構，基於對象存儲技術的設備就是對象存儲設備（Object-based Storage Device）簡稱OSD。
本質是一樣的，底層都是塊存儲，只是在對外介面上表現不一致，分別應用於不同的業務場景。
分布式存儲的應用場景相對於其存儲介面，現在流行分為三種:
對象存儲: 也就是通常意義的鍵值存儲，其介面就是簡單的GET、PUT、DEL和其他擴展，如七牛、又拍、Swift、S3
塊存儲: 這種介面通常以QEMU Driver或者Kernel Mole的方式存在，這種介面需要實現Linux的Block Device的介面或者QEMU提供的Block Driver介面，如Sheepdog，AWS的EBS，青雲的雲硬碟和阿里雲的盤古系統，還有Ceph的RBD（RBD是Ceph面向塊存儲的介面）
文件存儲: 通常意義是支持POSIX介面，它跟傳統的文件系統如Ext4是一個類型的，但區別在於分布式存儲提供了並行化的能力，如Ceph的CephFS(CephFS是Ceph面向文件存儲的介面)，但是有時候又會把GFS，HDFS這種非POSIX介面的類文件存儲介面歸入此類。
㈣ 目前有哪些主流存儲技術
1、直接附加存儲（DAS）
特點是：硬體的堆疊，存儲操作依賴於伺服器，不帶有存儲操作系統。應用環境特殊。數據處理和傳輸能力較低；伺服器出現宕機時，波及到存儲數據，使其無法使用。
2、網路附加存儲（NAS）
通過網路介面與網路直接相連，訪問。存儲設備類似於專用的文件伺服器，提供文件系統功能，降低設備的成本。優化了系統硬軟體體系結構。以數據為中心，存儲設備與伺服器分離，其存儲設備在功能上完全獨立。支持多種TCPIP網路協議。
3、存儲區域網路SAN
通過專用交換機將磁碟陣列與伺服器連接。採用塊（block）級別存儲最大特點是將存儲設備從做乙太網中分離了出來，成為獨立的存儲區域網路SAN的系統結構。
(4)主流消息存儲方法擴展閱讀：
有效利用網路存儲技術是任何數據存儲管理策略的重要組成部分，僅僅依靠硬碟、JBOD和其它類型的本地存儲是不足以保護關鍵業務數據的完整性的，網路存儲在這個時候真正顯示出巨大的威力，它不僅可以容納由伺服器產生的業務數據，還可以容納由PC端產生的數據，並為數據提供良好的保護。
許多網路存儲廠商都提供了合作夥伴計劃，包括惠普、EMC、戴爾、IBM和NetApp等公司，但最重要的是要了解組成存儲網路的每一種技術，如NAS網關，光纖通道SAN，RAID陣列等。
㈤ 目前有哪些主流存儲技術
存儲區域網路 (Storage Area Network, SAN)是一種連接外接存儲設備和伺服器的架構。人們採用包括光纖通道技術、磁碟陣列、磁帶櫃、光碟櫃(en)的各種技術進行實現。該架構的特點是，連接到伺服器的存儲設備，將被操作系統視為直接連接的存儲設備（英語：Direct-attached_storage）。盡管SAN的復雜度和價格已經下降，但目前在大型企業級存儲方案（英語：Enterprise_storage）以外還應用不甚廣泛。
與SAN相比較，網路儲存設備(NAS, Network Attached Storage)使用的是基於文件的通信協議，例如NFS或SMB/CIFS通信協議就被明確滴定義為遠程存儲設備，計算機請求訪問的是抽象文件的一段內容，而非對磁碟進行的塊設備操作。
㈥ 古代 近代 現代的存儲信息方法有哪些
古代，將信息以書寫、印刷等形式記錄在石頭~竹簡~帛~紙上，形成書。
近代，以書寫、印刷等形式記錄在紙上。照相錄像技術發明後，就可以記錄畫面信息了。
現代，以列印和數據硬碟或雲服務存儲為主。
(6)主流消息存儲方法擴展閱讀：
存儲介質
紙張
優點：存量大，體積小，便宜，永久保存性好，並有不易塗改性。存數字、文字和圖像一樣容易。
缺點：傳送信息慢，檢索起來不方便
膠卷
優點：存儲密度大。查詢容易
缺點：閱讀時必須通過介面設備，不方便，價格昂貴。
計算機
優點：存取速度極快，存儲的數據量大
信息存儲應當決定，什麼信息存在什麼介質行比較合適。總的來說憑證文件應當用紙介質存儲；業務文件用紙或磁帶存儲；而主文件，如企業中企業結構;人事方面的檔案材料;設備或材料的庫存賬目，應當存於磁碟，以便聯機檢索和查詢。
參考鏈接：網路_信息儲存
㈦ 消息怎麼存儲在本地
您好，釘釘聊天記錄存儲在雲伺服器中，有效期360天。聊天界面一直往上載入，看到的消息記錄即表示該聊天記錄已經緩存在本地了哦。
㈧ 隊列的兩種存儲方式對比
隊列的兩種存儲方式分為消息投遞實時性：使用短輪詢方式，實時性取決於輪詢間隔時間：使用長輪詢，同寫入實時性一致，消息的寫入延時通常在幾個毫秒。總結：短輪詢：周期性的向服務提供方發起請求，獲取數據優點：前後端程序編寫比較容易。缺點：請求中有大半是無用，難於維護，浪費帶寬和伺服器資源；響應的結果沒有順序（因為是非同步請求，當發送的請求沒有返回結果的時候，後面的請求又被發送。而此時如果後面的請求比前面的請 求要先返回結果，那麼當前面的請求返回結果數據時已經是過時無效的數據了）。長輪詢：客戶端向伺服器發送請求，伺服器接到請求後保持住連接，直到有新消息才返回響應信息並關閉連接，客戶端處理完響應信息後再向伺服器發送新的請求。優點：在無消息的情況下不會頻繁的請求，耗費資源小。缺點：伺服器hold連接會消耗資源，難於管理維護。消費失敗重試Kafka：消費失敗不支持重試RocketMQ：消費失敗支持定時重試，每次重試間隔時間順延總結：kafka也可以通過編寫代碼來實現寫入和消費失敗的重試機制，這種要求需要用戶來編寫代碼實現，kafka只是提供了這種方式，但並不是他推薦的使用方式，他的設計模式上只是兼顧了這種情況，並不是重點。RocketMQ在設計上就考慮了這種情況，在提供的官方api中提供了重試的設置，用戶可以選擇多種模式的重試機制，以及自定義的重試邏輯，簡單場景下用戶只用設置一下參數即可。關於需要重試的場景例如充值類應用，當前時刻調用運營商網關，充值失敗，可能是對方壓力過多，稍後在調用就會成功，如支付寶到銀行扣款也是類似需求。這里的重試需要可靠的重試，即失敗重試的消息不因為Consumer宕機導致丟失。
㈨ 通知消息類如何存儲比較科學
貯存——過多強調放置、存放，隱含了「可能長期不動」的意思
儲存——更多是保存，流動的暫存，不做長期保存計劃
簡單的比較：
「貯存、儲存、寄存」三者的流動速度越來越快，保存時間越來越短。