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

當前嵌入式數據庫和數據庫管理系統 （DBMS） 的瓶頸在哪里，尤其是與物聯網相關的瓶頸？

MONTASERI，ITTIA：嵌入式數據庫將根據其所在的系統類型具有不同的數據庫。我們將傳感器、移動設備、物聯網網關設備和嵌入式系統視為物聯網系統的重要組成部分，每一個都面臨著不同的數據管理挑戰。

對于傳感器而言，內存和閃存介質等有限資源是最重要的瓶頸，因為它們通常會產生源自單一來源的數據流。對于物聯網網關，并發讀取訪問的寫入性能很重要，因為設備將從多個傳感器或類似設備收集數據。對于移動設備，主要瓶頸是無連接時數據的可用性。對于嵌入式系統，這些子系統的互操作性和可維護性非常重要。

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

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

RUPP、hamsterdb：收集傳感器數據或其他數據大多需要存儲，但不一定是數據庫。特別是處理能力低的設備會將其數據傳輸到服務器進行后處理和分析。瓶頸通常是用于將數據傳輸到中央服務器的 I/O 寫入性能或網絡吞吐量。提高 I/O 性能主要是金錢問題，因為更好的設備成本更高。

但是，通常可以在不犧牲數據質量的情況下應用策略來減少數據量，例如每秒僅存儲一個平均值而不是許多離散值。此外，傳感器數據通常不會隨時間發生太大變化，因此可以很好地壓縮（圖 1，表 1）。整數壓縮不是 CPU 密集型的。即使是低成本的 CPU 也可以每秒壓縮數百萬個整數，從而大大降低了存儲需求。通過一些創造力，通常可以創建針對特定數據模式優化的定制解決方案。

在流行的數據庫開發語言中，哪一種最適合物聯網中的嵌入式數據庫部署，為什么？

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

設備上的嵌入式數據庫系統將主要用于收集數據、基于該數據采取一些行動，并對數據進行一些處理/操作。這些操作不需要也不會受益于 SQL 語言的健壯性和復雜性。設備不會執行復雜的（當然也不是臨時的）查詢，這些查詢涉及具有復雜過濾和排序的多個表。

另一方面，在設備的上游，用于收集、聚合和以其他方式處理物聯網生成的大量數據的 DBMS 肯定會受益于 SQL。

HOGAN，SCALEDB：對于后端系統，即那些聚合和處理數據（分析、執行觸發器等）的系統，大部分挑戰是處理海量數據，這與來自間歇性推文或發布的人類數據不同。

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

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

當前的嵌入式數據庫技術如何促進傳感器輸入的存儲和分析，這些輸入可以從數百或數千擴展到可能的數百萬？

GRAVES：管理物聯網中傳感器網絡產生的海量數據集有很多維度。如果 DBMS 要支持應用程序的不同數據訪問模式，則必須支持多個數據庫索引。至少它應該提供：

哈希索引，用于通過鍵（簡單或復合）快速查找特定對象

用于模式匹配、范圍檢索和排序結果的B-tree 索引（B-tree 可以針對內存數據存儲進行優化）

地理空間數據的 R 樹索引

PATRICIA Trie用于網絡通信/電信系統的 IP 地址和電話號碼索引

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

可能導致它們在大數據規模上陷入困境的 DBMS 的一個特征是索引樹的深度。這可以通過使用哈希索引來緩解。在 eXtremeDB 中，我們還修改了 B 樹算法，以使樹比傳統的 B 樹更淺。

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

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

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

我通常建議在服務器上執行后處理。后處理通常會根據產品演變或業務需求頻繁更改，因此需要定期更新軟件。在現場將更新部署到 IoT 設備比部署到由 ISV 直接控制的單個服務器要脆弱得多。如果傳感器數據太大而無法傳輸到服務器，那么設備通常可以在不犧牲數據質量的情況下執行非常簡單的合并策略，例如每秒只發送一個值而不是多個值。此外，通常可以有效地壓縮數據。

審核編輯：郭婷