全文共5703字，預計學習時長17分鐘
原始網際網路對象符號（RION）是一種快速、緊湊、通用的數據格式。你可能會想：「又一個數據格式。」它和CSV、 XML、JSON、YAML、ProtoBuf、MessagePack、CBOR、亞馬遜的ION、 ApacheAvro 或者ASN.1有什麼不同呢？稍後我會在本文中解釋清楚，但首先必須介紹一下RION的背景信息。
用於高效數據交換和數據存儲的數據格式
RION由Nanosai研發，Nanosai是一家分布式系統研發公司，持「開放標準」——這意味著歡迎所有人使用。設計RION的最初目的是用於高效數據交換。然而現在擴展了目標用例，使其還包括結構化數據的高效存儲。
相信這兩個用例是緊密相關的，所以這個擴展是有意義的。它們的主要區別在於，通過網絡發送的信息通常具有固定的大小（至少發送一次），而文件的大小可能會隨時間推移而增長。
實際上，我們使用RION作為網絡協議的消息編碼和數據流存儲引擎的記錄格式。因此，我們對RION的數據交換和數據存儲進行了壓力測試。
通用的數據格式
從一開始，我們想使RION儘可能的通用化，這意味著可以對多種結構化數據進行編碼。願景在於，通過使用更加通用的數據格式，開發人員將無需經常在不同數據格式間轉換。越經常地默認使用RION，就越好。
很明顯，沒有哪種數據格式能完美適用於所有數據類型。對於如視頻、音頻、強格式化文檔等特定域的編碼， MP3、MP4或PDF等格式可能更合適。為了適應這種情形，RION被設計為能夠嵌入二進位數據和其他結構化數據（如元數據）。
RION的設計還允許在內置數據類型不足時通過自定義數據類型對其進行擴展。
支持的數據結構
要使RION真正通用，RION必須能表示各種各樣的數據結構。目前，RION可以表示：
二進位數據
鍵入數據欄位（布爾型、整型、浮點型、文本、日期時間）
單個欄位
無界欄位流
欄位（數組）的有界列
表格數據（如CSV文件，只包含一次列名）
對象和映射（鍵-值對）
對象圖（具有嵌套對象的對象）
可將這些數據結構組合起來以創造更高級的結構。例如，可以在表中嵌套表，或者在表中嵌套對象圖，該表中也可以有表。
欄位類型
RION編碼的數據包含一個或多個RION欄位。每個欄位都有一個類型。目前，RION包含以下欄位類型：
字節
布爾型
正整型
負整型
浮點型（32或64位）
UTF-8
短UTF-8
UTC
（參考）
數組（*）
表格
對象
鍵
短鍵
擴展
接下來對這些欄位類型進行詳細描述。
字節欄位用於「非結構化」二進位數據。例如，如果需要在RION中嵌入音頻或視頻文件（或者任何其它類型的文件或二進位數據），可將其嵌入字節欄位中。這樣可以高效傳輸二進位數據。
布爾型欄位可將值表示為true或false。
正整型和負整型表示正整數和負整數。正整型是編碼的，只包含有效字節。因此，包含數字127的正整型欄位可用2個字節表示，1024可用3個字節表示。另一方面，負數更具有挑戰性。
例如，32位的負整型需要4個字節，因為所有字節都是有效的。為了更高效地對負數進行編碼，我們創建了包含負整數的絕對（正）值-負1的負整型欄位。這允許使用與處理正整數時相同高效的「有效字節」編碼。
浮點型可以是32位或64位浮點數。
UTF-8或短UTF-8用於以UTF-8格式存儲的文本數據。短UTF-8使用比UTF-8少1位元組的文本來編碼不高於15個字節的文本。在包含許多文本欄位的數據中，每個欄位節省的1個字節匯總起來可能非常之大。
UTC是以UTC的格式存儲數據和時間。在網絡上交換日期-時間信息是常規用例，所以我們認為RION也應該支持這一點。為避免時區紊亂，我們決定「強制」用UTC時間來表示日期時間欄位。
截至目前，參考欄位還停留在設想階段。它旨在表示對RION數據中較早RION欄位的「反向引用」。這可以用於表示循環對象圖，也可避免在RDBMS結果集或微服務查詢響應等中重複冗餘信息。我們可能會添加其他欄位，以表示未來的冗餘數據的副本（如複製欄位）。
數組欄位用於表示RION欄位的數組（列表）。因此，RION數組能包含嵌套其中的其它RION欄位。所以數組欄位是一個複合欄位。請注意，可以把數組表示為具有單列的表，因此，實際上我們可以刪除數組欄位，只保留用於數組和表格數據的表欄位。
表欄位用於表示具有列和行的表格數據，如CSV文件或對相關資料庫的SQL查詢結果。為了高效地編碼表格數據，表只包含行的列名稱（鍵欄位），列名後面是列值行。這與CSV文件相似，第一行是列標題，後續行是每一行的列值。單列的表可表示數組，因此可以像前面所提到的那樣刪除數組欄位。表可以包含嵌套在其中的其它RION欄位。因此，也可以使用具有嵌套表的表來更高效地表示樹結構。
對象欄位用於表示鍵值對的對象或映射（字典）。通常，鍵值對將被編碼為鍵欄位，後跟一些其它欄位，但是如果需要，可以保留鍵（或值——如果這在你的用例中有意義）。可以在對象（包括數組或表欄位）中嵌套其它RION欄位，以表示需要的對象圖。截至目前，只能表示非循環對象圖，但若一旦完成了參考欄位的規範，也能表示循環對象圖。
擴展欄位類型旨在能夠指定自己的欄位類型，因此除了核心的RION欄位類型外，還能嵌入其它數據類型。
緊湊性
為了高效交換和存儲，緊湊性對於RION至關重要。因此，我們已經盡最大努力使RION編碼儘可能緊湊。有時為了實現其他設計目標如高讀取速度，我們不得不做出一些妥協，但在大多數情況下RION還是很緊湊的。
速度
對於RION的另一個設計目標是加快讀寫速度。不論何時在讀取速度和寫入速度之間權衡時，我們都傾向於讀取速度，因為我們期望數據的讀取頻率高於寫入頻率。例如，RION文件可能只寫入一次，但要讀取多次。這同樣適用於網絡消息，它們只寫入一次，然後在傳輸處理過程中讀取一次或多次。
RION使用緊湊的二進位編碼，使其讀寫速度高於XML、JSON、YAML、MessagePack、CBOR以及亞馬遜的ION等文本編碼。
此外，RION直接以二進位形式使用。當直接以二進位形式讀取而非先反序列化到Java對象時，簡單用例的速度可加快10倍。對於更高級的用例，加速量不定，可能更大也可能更小。
另外，RION的設計允許部分可解析性和任意分層導航。在特定情境中，服務往往可能返回比給定客戶端所需的更多數據。RION不必分析所有的返回數據，從而略過不需要的部分，以導航至需要的部分。也可以二進位形式瀏覽RION數據，分析出所需欄位，略過其餘欄位。
二進位編碼
為了實現高度緊湊性和高速度，RION使用二進位編碼。比起文本編碼，二進位編碼能實現對數字、日期以及二進位數據更緊湊的編碼。
對二進位編碼常見的異議是，在開發、調試、監視等過程中，人們很難閱讀它。為了解決這一問題，我們正在研究RION的文本編碼（目前稱其為TION），即可以將RION轉換為TION並返回，以實現在文本編輯器中的輕鬆閱讀和編輯。TION還未完全就緒，但預計將在2020年某個時間點完成。我們還實現了從RION到「格式化十六進位表示法」的轉換器，使其可在文本編輯器中檢查原始字節值。
自描述
RION使用自描述編碼，意味著不需要架構來理解RION數據塊。自描述的數據格式使其更容易使用，因為可以在不知道其架構的情況下通過瀏覽數據來查看結構。這也使得未知信息架構的中間節點發送信息變得更容易。
即使數據格式是自描述的，但將其與架構相結合仍然有意義。XML + XML架構和JSON + Swagger/RAML架構就是如此。架構可以對給定欄位的允許值、預期欄位等提供額外限制。目前的RION沒有任何架構機制，但正在考慮之中。
更多設計目標
為使本文儘可能簡短，我略去了一些「不太重要」的RION設計目標，可在這裡查看完整版。
http://tutorials.jenkov.com/rion/rion-design-goals.html
RION vs.其它數據格式
本節將簡要講述RION與今天所使用的其它流行數據格式的不同之處。不過，請記住，完整的概述需要對數據格式有深入的了解，因此本文所講的細節深度有限。
首先，RION作為一種二進位數據格式，與CSV、XML、JSON以及YAML不同。二進位的RION意味著它比這些格式更緊湊且讀寫速度更快。平均來講，RION的緊湊性比JSON高10%到33%，如果用於表格數據，其差異可超過50%。這種緊湊性差異也被轉換為類似的讀/寫速度差異。
文本數據格式確實更易於在文本編輯器中讀取和編輯，但是我們打算通過RION的文本表示（TION）來解決這個問題，使得RION和TION能相互轉換。這應該可以減少人的可見性/可編輯性問題。
RION在文件的根級別包含多個欄位，這將RION與XML、JSON區分開來，後兩者只能在文件的根級別包含單個元素。這使得RION更易用於流數據結構，如日誌文件和連續附加的數據文件。
RION使用類似於MessagePack、 CBOR以及亞馬遜的ION的自描述二進位編碼。然而，RION在一些細微且重要的地方與這三者不同。首先，在這些數據格式中，只有RION能指定表格數據的有效編碼。其次，在瀏覽複合數據結構如對象圖時，RION更容易以二進位形式進行任意瀏覽。第三，RION即將能表示循環對象圖，而MessagePack、 CBOR或者亞馬遜的ION目前都不能做到這一點。
此外， RION除了對表格數據更擅長這點較為突出外，與MessagePack、CBOR以及Amazon’s ION在緊湊性和讀寫速度方面都大致相同。
ProtoBuf、ASN.1和 Avro都使用需要架構來分析的數據編碼。換句話說，它們不能自描述。某些情況下，非自描述數據格式比自描述數據格式更緊湊，但差別較小。但是需要架構的數據格式可能使用起來比較麻煩，所以這是一個折衷方案。
有關更詳細的概述，請見「比較頁面」，會有不時更新。其中缺失一些數據格式，包括亞馬遜的ION、YAML、XML等，最後會添加上。
http://tutorials.jenkov.com/rion/rion-vs-other-formats.html.
在性能方面，測量結果顯示RION能與MessagePack和CBOR的速度相匹配，同時接近ProtoBuf的速度。但是所有的基準都基於序列化和反序列化對象。如果直接使用RION的二進位形式，並/或者只解析它的一部分，可以極大地提高速度。我們的基準有點老舊，因此需要儘快重做。點擊連結可查看目前的基準：
http://tutorials.jenkov.com/rion/rion-performance-benchmarks.html
總結和進一步的細節
總之，我們相信RION是目前最好的全方面數據格式之一。它提供了快速高效的二進位編碼、通用靈活的欄位類型集，可直接以二進位形式讀取和寫入（為了提高速度），或用於對象的序列化和反序列化。在速度方面，它能匹配大多數流行的數據格式，甚至能用表格數據格式超越它們，或者直接以二進位形式讀取RION。
我們（Nanosai）已經花費大量時間分析RION並將其與其它數據格式做比較，但是我們相信當前的編碼提供了一個很好的擴展基礎。目前仍有一些地方需要處理（如參考），但是我們期望在2020年大多數問題能夠得到解決。當RION變得越來越完整時，我們將再次發布推文。
我們目前正在使用RION作為網絡協議IAP的消息編碼，IAP是HTTP的替代物，用於在應用層實現高效靈活的網絡通信。IAP仍在研究中，但其基礎已經定義明確了。
我們還在Java的流操作中使用RION作為記錄格式——可嵌入式數據流引擎。流操作就像一束「卡夫卡之光」。雖然目前還處於概念驗證階段，但是我們期望能在整個2020年度來改進它。
流操作使用RION，因此可以獲得很好的記錄處理吞吐速度。現在已經能在開發人員的筆記本電腦上將其壓縮到每秒19.5萬條記錄（小記錄）。希望能在數據中心級的硬體上看到更高的數字。從長遠看，我們爭取達到每秒10億條記錄，這可以在1BRS 挑戰中看到。
目前，我們的RION開源工具包是在Java中實現的，一旦它們穩定下來，我們計劃擴展到其它語言。首先可能是性能語言，如C#、C/C++，然後是Python，因為它被大量用於數據科學。但這仍待決定。
因此，如果你正在尋求一種快速、緊湊、通用的全方面數據格式，不論你是使用Kafka、Pulsar、Hazelcast等進行高性能微服務、數據科學還是事件驅動架構，都有必要去看看RION。
關於RION的更多信息
原始網際網路對象符號（RION）是這種數據格式當前的工作標題。我們最開始使用的名字是ION，但是一年後，亞馬遜發布了一款名為ION的內部使用的數據格式，所以我們改名為RION。將來可能會再次改名，但就目前來看，數據格式本身是十分穩定的。
如果你對RION的詳細信息感興趣，請查看RION教程。
http://tutorials.jenkov.com/rion/index.html
我們還開發了一個名為「Rion Ops for Java」的開源工具包，用於在Java中使用RION。點擊以下連結查看。
https://github.com/nanosai/rion-ops-java
留言點讚關注
我們一起分享AI學習與發展的乾貨
如轉載，請後臺留言，遵守轉載規範