雖然物聯(lián)網(wǎng) （IoT） 的許多方面都已經(jīng)到位，但用于管理物聯(lián)網(wǎng)傳感器數(shù)據(jù)的數(shù)據(jù)庫(kù)仍然存在一些障礙。在與 hamsterdb 的 Christoph Rupp、ITTIA 的 Sasan Montaseri、McObject 的 Steve Graves 和 ScaleDB 的 Mike Hogan 的圓桌會(huì)議中，我們探討了當(dāng)前限制嵌入式數(shù)據(jù)庫(kù)、擴(kuò)展和保護(hù) IoT 數(shù)據(jù)庫(kù)的因素，以及用于管理和分析傳感器輸入的可用工具和技術(shù)來自連接的嵌入式設(shè)備的海洋。

當(dāng)前嵌入式數(shù)據(jù)庫(kù)和數(shù)據(jù)庫(kù)管理系統(tǒng) （DBMS） 的瓶頸在哪里，尤其是與物聯(lián)網(wǎng)相關(guān)的瓶頸？

MONTASERI，ITTIA：嵌入式數(shù)據(jù)庫(kù)將根據(jù)其所在的系統(tǒng)類型具有不同的數(shù)據(jù)庫(kù)。我們將傳感器、移動(dòng)設(shè)備、物聯(lián)網(wǎng)網(wǎng)關(guān)設(shè)備和嵌入式系統(tǒng)視為物聯(lián)網(wǎng)系統(tǒng)的重要組成部分，每一個(gè)都面臨著不同的數(shù)據(jù)管理挑戰(zhàn)。

對(duì)于傳感器而言，內(nèi)存和閃存介質(zhì)等有限資源是最重要的瓶頸，因?yàn)樗鼈兺ǔ?huì)產(chǎn)生源自單一來源的數(shù)據(jù)流。對(duì)于物聯(lián)網(wǎng)網(wǎng)關(guān)，并發(fā)讀取訪問的寫入性能很重要，因?yàn)樵O(shè)備將從多個(gè)傳感器或類似設(shè)備收集數(shù)據(jù)。對(duì)于移動(dòng)設(shè)備，主要瓶頸是無連接時(shí)數(shù)據(jù)的可用性。對(duì)于嵌入式系統(tǒng)，這些子系統(tǒng)的互操作性和可維護(hù)性非常重要。

GRAVES，McOBJECT：設(shè)備上嵌入式數(shù)據(jù)庫(kù)系統(tǒng)的障礙，在許多情況下，與其說是 DBMS 本身的障礙，不如說是嵌入式系統(tǒng)（設(shè)備）的限制。例如，雖然 McObject 的 eXtremeDB DBMS 是在 2000 年明確為嵌入式系統(tǒng)編寫的，重點(diǎn)是高效率和“占用空間小”，但它仍然需要至少 24 位內(nèi)存地址（24 位指針），實(shí)際上大約需要 1 MB 內(nèi)存。eXtremeDB 數(shù)據(jù)庫(kù)系統(tǒng)核心的代碼大小約為 150 KB，它至少需要 40 KB 的 RAM 用于數(shù)據(jù)庫(kù)字典和其他運(yùn)行時(shí)元數(shù)據(jù)，例如事務(wù)緩沖區(qū)、連接/事務(wù)/對(duì)象句柄、等等然后你需要內(nèi)存來存儲(chǔ)數(shù)據(jù)本身，或者如果它是一個(gè)持久性數(shù)據(jù)庫(kù)，則需要緩存。

16 位系統(tǒng)根本無法為 DBMS （64 KB） 尋址足夠的內(nèi)存。盡管您可以將 DBMS 擠入該空間，但它不會(huì)為元數(shù)據(jù)、應(yīng)用程序代碼等留出空間。另一方面，一個(gè) 24 位指針可以尋址 16 MB——為 DBMS 和應(yīng)用程序提供了足夠的空間。

RUPP、hamsterdb：收集傳感器數(shù)據(jù)或其他數(shù)據(jù)大多需要存儲(chǔ)，但不一定是數(shù)據(jù)庫(kù)。特別是處理能力低的設(shè)備會(huì)將其數(shù)據(jù)傳輸?shù)椒?wù)器進(jìn)行后處理和分析。瓶頸通常是用于將數(shù)據(jù)傳輸?shù)街醒敕?wù)器的 I/O 寫入性能或網(wǎng)絡(luò)吞吐量。提高 I/O 性能主要是金錢問題，因?yàn)楦玫脑O(shè)備成本更高。

但是，通?？梢栽诓粻奚鼣?shù)據(jù)質(zhì)量的情況下應(yīng)用策略來減少數(shù)據(jù)量，例如每秒僅存儲(chǔ)一個(gè)平均值而不是許多離散值。此外，傳感器數(shù)據(jù)通常不會(huì)隨時(shí)間發(fā)生太大變化，因此可以很好地壓縮（圖 1，表 1）。整數(shù)壓縮不是 CPU 密集型的。即使是低成本的 CPU 也可以每秒壓縮數(shù)百萬個(gè)整數(shù)，從而大大降低了存儲(chǔ)需求。通過一些創(chuàng)造力，通?？梢詣?chuàng)建針對(duì)特定數(shù)據(jù)模式優(yōu)化的定制解決方案。

在流行的數(shù)據(jù)庫(kù)開發(fā)語言中，哪一種最適合物聯(lián)網(wǎng)中的嵌入式數(shù)據(jù)庫(kù)部署，為什么？

GRAVES：對(duì)于設(shè)備上的數(shù)據(jù)管理，SQL 可能不適合絕大多數(shù)用例。我們認(rèn)為 C/C++ 和具有快速原生 API 的 DBMS 是最合適的。對(duì)于具有足夠資源的嵌入式系統(tǒng)，其中一臺(tái)嵌入式 Java 機(jī)器（例如 Aicas 的 JamaicaVM）可能是合適的。SQL 將過于占用資源。任何 SQL 實(shí)現(xiàn)的代碼大小都將比非 SQL 解決方案大得多——不要與“noSQL”混淆——并且對(duì)于任何給定的工作單元會(huì)消耗更多的 CPU 周期。

設(shè)備上的嵌入式數(shù)據(jù)庫(kù)系統(tǒng)將主要用于收集數(shù)據(jù)、基于該數(shù)據(jù)采取一些行動(dòng)，并對(duì)數(shù)據(jù)進(jìn)行一些處理/操作。這些操作不需要也不會(huì)受益于 SQL 語言的健壯性和復(fù)雜性。設(shè)備不會(huì)執(zhí)行復(fù)雜的（當(dāng)然也不是臨時(shí)的）查詢，這些查詢涉及具有復(fù)雜過濾和排序的多個(gè)表。

另一方面，在設(shè)備的上游，用于收集、聚合和以其他方式處理物聯(lián)網(wǎng)生成的大量數(shù)據(jù)的 DBMS 肯定會(huì)受益于 SQL。

HOGAN，SCALEDB：對(duì)于后端系統(tǒng)，即那些聚合和處理數(shù)據(jù)（分析、執(zhí)行觸發(fā)器等）的系統(tǒng)，大部分挑戰(zhàn)是處理海量數(shù)據(jù)，這與來自間歇性推文或發(fā)布的人類數(shù)據(jù)不同。

MySQL 使用 SQL。它適用于在線事務(wù)處理 （OLTP） 用例，主要用于 IoT 的后端——不是設(shè)備端，而是網(wǎng)關(guān)和后端。大多數(shù)公司最終都采用了多種技術(shù)組合，例如用于客戶/交易信息的 MySQL、用于快速提取設(shè)備數(shù)據(jù)的 NoSQL 以及用于分析設(shè)備數(shù)據(jù)的 Hadoop。我們的技術(shù)通過快速數(shù)據(jù)擴(kuò)展您的 MySQL 基礎(chǔ)架構(gòu)，使您能夠消除 NoSQL 和 Hadoop 部分并專門使用 MySQL 來最大限度地減少您使用的專業(yè)知識(shí)、招聘和不同工具，并顯著降低成本。

RUPP：對(duì)于那些不需要支持 SQL 的數(shù)據(jù)庫(kù)的應(yīng)用程序，像 hamsterdb 這樣的鍵/值存儲(chǔ)的好處將很有吸引力：高性能、低資源要求。對(duì)于嵌入式 SQL 數(shù)據(jù)庫(kù)，SQLite 是最明顯的選擇。

當(dāng)前的嵌入式數(shù)據(jù)庫(kù)技術(shù)如何促進(jìn)傳感器輸入的存儲(chǔ)和分析，這些輸入可以從數(shù)百或數(shù)千擴(kuò)展到可能的數(shù)百萬？

GRAVES：管理物聯(lián)網(wǎng)中傳感器網(wǎng)絡(luò)產(chǎn)生的海量數(shù)據(jù)集有很多維度。如果 DBMS 要支持應(yīng)用程序的不同數(shù)據(jù)訪問模式，則必須支持多個(gè)數(shù)據(jù)庫(kù)索引。至少它應(yīng)該提供：

哈希索引，用于通過鍵（簡(jiǎn)單或復(fù)合）快速查找特定對(duì)象

用于模式匹配、范圍檢索和排序結(jié)果的B-tree 索引（B-tree 可以針對(duì)內(nèi)存數(shù)據(jù)存儲(chǔ)進(jìn)行優(yōu)化）

地理空間數(shù)據(jù)的 R 樹索引

PATRICIA Trie用于網(wǎng)絡(luò)通信/電信系統(tǒng)的 IP 地址和電話號(hào)碼索引

“模糊搜索”用例的Trigram 索引

可能導(dǎo)致它們?cè)诖髷?shù)據(jù)規(guī)模上陷入困境的 DBMS 的一個(gè)特征是索引樹的深度。這可以通過使用哈希索引來緩解。在 eXtremeDB 中，我們還修改了 B 樹算法，以使樹比傳統(tǒng)的 B 樹更淺。

一些嵌入式數(shù)據(jù)庫(kù)系統(tǒng)（如 SQLite）是單任務(wù)的，因此無法利用多核，這在嵌入式系統(tǒng)中變得越來越普遍。理想情況下，DBMS 將是具有樂觀并發(fā)模型的多任務(wù)處理，允許嵌入式系統(tǒng)開發(fā)人員充分利用目標(biāo)系統(tǒng)的資源。

在某些情況下，從事傳感器數(shù)據(jù)融合的嵌入式系統(tǒng)必須優(yōu)先處理指示某些數(shù)據(jù)到達(dá)的中斷。在 DBMS 中，在運(yùn)行時(shí)確定事務(wù)優(yōu)先級(jí)的能力可以滿足這一要求。缺少這樣的功能可能意味著丟失數(shù)據(jù)，例如當(dāng)一個(gè)傳感器數(shù)據(jù)單元在另一個(gè)傳感器數(shù)據(jù)到達(dá)之前沒有被抓取時(shí)。

RUPP：可能必須將昂貴的操作（如分析查詢）卸載到服務(wù)器上。對(duì)于收集數(shù)據(jù)和簡(jiǎn)單查詢，開發(fā)人員可以求助于鍵/值存儲(chǔ)，這是一種精簡(jiǎn)的、類似 NoSQL 的數(shù)據(jù)庫(kù)方法。一些鍵/值存儲(chǔ)可作為嵌入式庫(kù)使用，這避免了客戶端/服務(wù)器架構(gòu)的通信開銷。這些通常還提供各種配置選項(xiàng)以針對(duì)特定用例進(jìn)行優(yōu)化。

我通常建議在服務(wù)器上執(zhí)行后處理。后處理通常會(huì)根據(jù)產(chǎn)品演變或業(yè)務(wù)需求頻繁更改，因此需要定期更新軟件。在現(xiàn)場(chǎng)將更新部署到 IoT 設(shè)備比部署到由 ISV 直接控制的單個(gè)服務(wù)器要脆弱得多。如果傳感器數(shù)據(jù)太大而無法傳輸?shù)椒?wù)器，那么設(shè)備通?？梢栽诓粻奚鼣?shù)據(jù)質(zhì)量的情況下執(zhí)行非常簡(jiǎn)單的合并策略，例如每秒只發(fā)送一個(gè)值而不是多個(gè)值。此外，通常可以有效地壓縮數(shù)據(jù)。

審核編輯：郭婷