原始Internet對象符號（RION）是一種快速，緊湊，通用的數據格式。是的，我知道您在想什麼：“還有另一種數據格式。” 這與CSV，XML，JSON，YAML，ProtoBuf，MessagePack，CBOR，Amazon的ION，Apache Avro或ASN.1有何不同？繼續，我將在整個文章中對此進行解釋，但是首先，我將提供一些有關RION的背景信息。
一種有效交換和存儲數據的數據格式
RION由Nanosai（一家分佈式系統研發公司（我是聯合創始人））開發為“開放標準”，這意味著歡迎所有人使用它。RION最初被設計為用於高效數據交換的數據格式。但是，自那時以來，我們已將目標用例擴展到包括結構化數據的有效存儲。
我們相信用例之間的聯繫緊密，以至於這種擴展是有意義的。這兩種用例之間的主要區別在於，通過網絡發送的消息往往具有固定的大小（至少一次發送），而隨著時間的推移，文件可能會不斷增長。
實際上，我們將RION既用作網絡協議的消息編碼，又用作數據流存儲引擎中的記錄格式，因此我們對RION進行了壓力測試，以進行數據交換和數據存儲。
多種數據格式
從一開始，我們就希望使RION儘可能地通用，這意味著它應該能夠對各種各樣的結構化數據進行編碼。希望是，有了更通用的數據格式，開發人員將不必經常在不同的數據格式之間切換。我們越常能夠默認為RION，就越好。
顯然，沒有一種數據格式適合每種類型的數據。對於某些用例，例如音頻，視頻，強格式文檔等，特定於域的編碼（例如MP3，MP4或PDF）可能更合適。為了適應這種情況，RION被設計為能夠將二進制數據與其他結構化數據（例如，元數據）一起嵌入。
RION的設計還使您可以在內置數據類型不足的情況下使用自定義數據類型擴展它。
支持的數據結構
為了實現真正的通用性，RION必須能夠代表各種各樣的數據結構。目前，RION使您能夠代表：
- 二進制數據。
- 鍵入的數據字段（布爾值，整數，浮點數，文本，日期時間）。
- 單個字段。
- 無限的字段流。
- 有界的列表（數組）。
- 表格數據（例如CSV文件，其中列名僅包含一次）。
- 對象和映射（鍵值對）。
- 對象圖（帶有嵌套對象的對象）。
這些數據結構可以組合以創建更高級的結構。例如，您可以將一個表與其他表嵌套在其中，或者將一個表與對象圖嵌套在其中，又可以在其中嵌套表，等等。
欄位類型
RION編碼的數據由一個或多個RION字段組成。每個RION字段都有一個類型。RION當前包含以下字段類型：
讓我詳細介紹一下這些字段類型。
字節字段用於“非結構化”二進制數據。例如，如果您需要在RION中嵌入音頻或視頻文件（或任何其他類型的文件或二進制數據），則可以將其嵌入到Bytes字段中。這允許有效地傳輸二進制數據。
布爾字段可以表示值true和false。
Int-Pos和Int-Neg字段表示正整數和負整數。對正整數進行編碼，因此它們僅包含有效字節。因此，包含數字127的Int-Pos字段可以使用2個字節來表示，使用3個字節來表示1024，等等。另一方面，負數更具挑戰性。
例如，一個32位負整數需要4個字節，因為所有字節都是有效的。為了更有效地編碼負數，我們創建了一個負整數字段，其中包含負整數的絕對值（正數）-負1。這使我們可以使用與正整數相同的有效“有效字節”編碼。
浮點數可以是32位或64位浮點數。
UTF-8和UTF-8縮寫適用於以UTF-8格式存儲的文本數據。UTF-8短代碼可以編碼15個字節或更少的文本，使用的字符數比UTF-8字段少1個字節。在具有許多文本字段的數據中，每個字段節省的那1個字節可能很重要。
UTC用於在UTC中存儲數據和時間。通過網絡交換日期時間信息是一個常見的用例，因此我們認為RION應該支持這一點。為避免時區混亂，我們決定“強制”日期時間字段表示為UTC時間。
到目前為止，“參考”字段僅處於構思階段。它旨在表示對RION數據中較早發現的RION字段的“反向引用”。這可以用來表示循環對象圖。這也可用於避免在RDBMS結果集或微服務查詢響應中重複冗餘信息。我們將來可能會添加其他字段來表示冗餘數據的副本（例如，“副本”字段）。
數組字段用於表示RION字段的數組（列表）。因此，RION陣列可以包含嵌套在其中的其他RION字段。因此，數組字段是一個複合字段。請注意，我們已經意識到可以將數組表示為具有單列的表，因此我們實際上可能會刪除Array字段，而只有Table字段用於數組和表格數據。
“表”字段用於表示列和行的表格數據，例如CSV文件或針對關係數據庫的SQL查詢結果。為了有效地對錶格數據進行編碼，表僅包含一次行的列名（鍵字段）。列名稱之後是列值的行。這類似於CSV文件，其中第一行是列標題，隨後的行是每一行的列值。具有單列的表可用於表示Array，因此我們可以刪除前面提到的Array字段。表可以包含嵌套在其中的其他RION字段。因此，您也可以使用帶有嵌套表的表來更有效地表示樹結構。
“對象”字段用於表示鍵值對的對象或地圖（字典）。通常，鍵/值對將被編碼為“鍵”字段，後跟其他一些字段，但是您可以根據需要省略鍵（或者也可以省略值-如果在您的用例中有意義）。您可以將其他RION字段嵌套在一個對象中，包括數組或表字段，以表示所需的對象圖。到目前為止，您只能表示非循環對象圖，但是一旦完成“參考”字段的說明，您也可以表示循環對象圖。
擴展字段類型旨在使您能夠指定自己的字段類型，因此，您可以嵌入其他類型的數據，而對於核心RION字段類型則無法嵌入。
緊湊
為了有效地交換和存儲，緊湊對於RION至關重要。因此，我們竭盡全力使RION編碼儘可能緊湊。有時，為了達到其他設計目標（例如較高的讀取速度），我們不得不做出一些折衷，但是RION在很大程度上是相當緊湊的。
速度
RION的另一個目標是提高讀寫速度。每當必須在讀取速度和寫入速度之間進行權衡時，我們都傾向於讀取速度，因為我們希望讀取數據的頻率要比寫入數據的頻率高。例如，一個RION文件可能被寫入一次，然後被讀取多次。網絡消息也是如此。它們只被寫入一次，然後在傳輸過程中和處理過程中被讀取一次或多次。
RION使用緊湊的二進制編碼。與XML，JSON和YAML之類的文本編碼相比，它本身使讀寫速度更快，並且與MessagePack，CBOR和Amazon的ION相當。
此外，RION被設計為直接以其二進制形式使用。當直接以其二進制形式讀取而不是首先反序列化為Java對象時，對於簡單的用例，我們已經看到了10倍的加速。對於更高級的用例，提速可以更大或更小。
此外，RION設計為允許部分可解析性和任意層次導航。通常，在特定情況下，服務返回的數據可能超過給定客戶端所需的數據。通過RION，您不必解析所有返回的數據，就可以高效地瀏覽不需要的部分，以找到所需的部分。您可以通過以二進制格式瀏覽RION數據並解析出所需的字段，而跳過其餘字段來做到這一點。
二進制編碼
為了能夠實現緊湊性和速度，RION使用二進制編碼。與文本編碼相比，二進制編碼使數字，日期和二進制數據的編碼更加緊湊。
二進制編碼的普遍反對意見之一是，在開發，調試，監視等過程中，人類很難閱讀它們。為解決此問題，我們目前正在研究RION的文本編碼（到目前為止稱為TION），因此您可以將RION轉換為TION並返回，以便在文本編輯器中輕鬆閱讀和編輯。TION尚未100％準備就緒，但我預計它將在2020年某個時候實現。我們還實現了RION到“格式化的十六進制表示法”轉換器，可以在文本編輯器中檢查原始字節值。
自我描述
RION使用自我描述的編碼，這意味著您不需要架構即可理解RION數據塊。使數據格式具有自描述性，可以更輕鬆地使用它，因為您可以在不瞭解其模式的情況下瀏覽數據以查看其結構。這也使得更容易為不知道消息架構的中間節點路由消息。
即使數據格式是自描述的，將其與模式組合仍然有意義。XML + XML Schema和JSON + Swagger / RAML就是這種情況。模式可以對給定字段允許使用哪些值，期望使用哪些字段等提供其他限制。RION目前沒有任何模式機制，但正在考慮中，
更多設計目標
為了使RION的這篇介紹性文章簡短，我為RION保留了一些“不太重要”的設計目標。您可以在此處查看RION的設計目標的完整列表：
http://tutorials.jenkov.com/rion/rion-design-goals.html
RION與其他數據格式
在本節中，我將嘗試向您快速概述RION與當今使用的許多其他流行數據格式的不同之處。但是請記住，完整的概述需要深入瞭解數據格式。因此，本文的詳細信息深度是有限的。
首先，作為二進制數據格式，RION不同於CSV，XML，JSON和YAML。使用二進制表示RION通常比這些格式更緊湊，並且讀寫速度更快。平均而言，RION比JSON緊湊約10％到33％，如果用於表格數據，則差異可以超過50％。這種緊湊性差異還轉化為相似的讀/寫速度差異。
文本數據格式確實具有在文本編輯器中更易於閱讀和編輯的優點，但是我們打算通過使用RION（TION）的文本表示來解決此問題，您可以將其轉換為RION和從RION進行轉換。這將減少人類可見性/可編輯性問題。
RION可以在文件的根級別包含多個字段。這使RION與XML和JSON區別開來，XML和JSON在文件的根級別只能包含一個元素。這使RION更易於用於流數據結構，例如日誌文件和連續追加的數據文件。
RION使用類似於MessagePack，CBOR和Amazon的ION的自描述二進制編碼。但是，RION在一些微妙但重要的方面有所不同。首先，RION是這些數據格式中唯一指定表格數據的有效編碼的格式。其次，在導航諸如對象圖之類的複合數據結構時，RION稍微容易以二進制形式進行任意導航。第三，RION很快將能夠表示循環對象圖。MessagePack，CBOR和Amazon的ION目前都無法做到這一點。
除此之外，RION與MessagePack，CBOR和Amazon的ION一樣緊湊，並且讀寫速度幾乎一樣快，而表格數據是RION擅長的例外。
ProtoBuf，ASN.1和Avro都使用需要模式才能解析它們的數據編碼。換句話說，它們不是自描述的。在某些情況下，非自描述數據格式可以比自描述數據格式更緊湊，但差異很小。需要模式的數據格式可能比較麻煩，因此這是一個折衷方案。
閱讀更多 愛碼農 的文章
