SingleStore（前身 MemSQL）是一個為資料密集型應用設計的云原生資料庫，它是一個分布式的關系型 SQL 資料庫管理系統（RDBMS），具有 ANSI SQL 支持，它以資料攝入、交易處理和查詢處理的速度而聞名，SingleStore 主要存盤關系型資料，但也可以存盤 JSON 資料、圖形資料和時間序列資料，它支持混合作業負載，也就是我們常說的 HTAP ，以及更傳統的 OLTP 和 OLAP 用例，對于查詢，它將結構化查詢語言（SQL）編譯成機器代碼，SingleStore 資料庫引擎可以在各種 Linux 環境中運行，包括企業內部安裝（on-premises）、公共和私有云供應商、通過 Kubernetes 運營商在容器中運行，或者使用 SingleStore 自有的托管云服務，

今天我們主要來聊一聊資料庫獨角獸公司 SingleStore 對 HTAP 的認知，

SingleStore，HTAP 界的融資寵兒

說起 SingleStore，一些同學可能不太了解，但是提到 MemSQL，相信研究過HTAP 資料庫發展脈絡的同學就很熟悉了，也可以回顧一下這篇文章《深度干貨！一篇Paper帶您讀懂HTAP》，我們在第一節中介紹了 HTAP 資料庫的發展歷史，其中 MemSQL 就是最早的一波提出行列混存+記憶體計算的資料庫，也是在 2014 年要發力 HTAP 的，恰巧和 Gartner 正式提出 HTAP 概念是同一年，不過后來在 2020 年 10 月，MemSQL 正式宣布改名為 SingleStore 了，

關于改名的原因，官方是說是為了更好地描述組織的廣泛價值主張，官方表示，盡管 MemSQL 在資料架構師和性能工程師中廣為人知，但該公司的旗艦資料管理產品已擴展到包括開發人員功能，所以 MemSQL 已不能再反映他們當前功能和產品愿景的廣度和深度，

其進行品牌重塑的目的在于，向外界反映 MemSQL 不僅僅是一個記憶體資料庫，而是一個可以實作企業所有資料的平臺，SingleStore 將為交易和分析提供一個資料平臺，能夠處理結構化、非結構化和半結構化資料，

SingleStore 首席產品官 Jordan Jigani 還透露了團隊的新愿景，即計劃提供對位于 SingleStore 以外任何地方的資料的訪問權限，這項新功能將為跨多云環境的資料提供一個全域命名空間，使 SingleStore 可以提供一個 API，無論資料位于何處，都可以通過該 API 對資料進行操作，用戶可以從擁有 SingleStore 計算群集的任何位置訪問 SingleStore 資料庫，同時遵守訪問權限和主權限制，

不得不說，SingleStore 對市場的敏銳度還是很高的，像 HTAP、云原生、分布式、一體化、平臺化、實時分析處理、資料庫 API 化、DBaas 這些，人家玩得很溜，把這些偉大的愿景拋出去又加上技術確實不錯，自然很受資本市場的歡迎，從其融資歷史就可以窺知一二：

截止目前，SingleStore 的總融資額達到 4.12 億美元，估值超過了 13 億美金，當然，可能一些經常看 VC 圈子的小同學覺得這個估值對于資料庫企業來說不算特別高，也不是很明白，為啥有這么多投資機構給它投錢，因為在資料庫這個賽道上確實太多卷王了，SingleStore 雖然面臨著與 Imply、Oracle、Snowflake 和 MongoDB 等企業的競爭，但要知道，SingleStore 現在只有近 400 名員工，卻已經擁有大約 300 名客戶，估值還高于 10 億美元，相信明眼人都能看出來，SingleStore 的潛力無限，正如 CMU 的 Andy Pavlo 教授在去年預測的那樣，這家公司離 IPO 不遠了，

此外，Gartner 預測，到 2022 年，75% 的資料庫將遷移到云服務，一項調查顯示，每年在大資料和人工智能計劃上投資超過 5000 萬美元的公司數量在 2019 年上升至 33.9%，

如果沒有 HTAP，機器學習和人工智能都是不切實際的

下面是一篇來自 SingleStore 的博客，推薦給大家閱讀，

HTAP，即混合交易/分析處理，將交易（如更新資料庫）與分析（如尋找可能的銷售線索）相結合，HTAP 資料庫在一個資料庫中支持這兩種作業負載，提供速度和簡單性，今天，“云原生 HTAP”的概念很流行，用戶希望 HTAP 資料庫能夠與 Kafka、Spark 和其他技術在云中順利混合和匹配，使用的場景案例包括預防欺詐、電子商務的推薦引擎、智能電網和人工智能等等，

HTAP 資料庫在某種程度上是為集成流資料源(如 Kafka )和用于高級分析、人工智能和機器學習(如 Spark)的訊息系統而設計的，它們為多個分析客戶端提供服務，從輸入SQL查詢的業務分析師，到BI工具、應用程式和機器學習模型，這些客戶端每秒生成數十個或數千個查詢，

HTAP之前--OLTP 和 OLAP 分離

HTAP 將不同型別的資料處理組合成一個連貫的整體，這兩種處理方式差別很大，事務處理（OLTP）——在資料庫中添加和更新記錄——對單個記錄操作要求非常高的可靠性，以及準確性和速度，“更新Sandy Brown的當前地址”就是事務性更新的一個例子，

另一方面，分析處理意味著非常快速地在一個或多個資料庫表中查找單個記錄、多個記錄或一種型別的記錄的總數，“幫我找到所有住在科羅拉多州并擁有自己房子的訂戶”就是一個分析請求的例子，

第一批有效的資料庫是面向事務的，最初廣泛應用于20世紀70年代和80年代，它們被稱為在線事務處理(OLTP)系統，OLTP系統經過優化，可以在低功率、硬碟較小的計算機上作業——當然，按照今天的標準，唯一的分析是通過列印的報告，這些報告可能根據不同的關鍵欄位進行分類排序，比如按州或郵政編碼，

當后來加入分析時，事務系統已經很忙了，所以資料被復制到另一臺運行不同軟體的計算機上，這些資料庫稱為在線分析處理(OLAP)資料庫，資料倉庫和資料集市是專門的 OLAP 資料庫，存放用于分析的非操作資料，

使用多種語言對 OLAP 系統上的資料進行查詢，這些語言結合了結構化查詢語言(SQL)，一開始，分析查詢是由個別分析師直接輸入的；最后，使用商業智能(BI)程式來簡化查詢，到最近，軟體應用程式已經可以自己生成查詢了，通常以每秒數千個的速度生成，

這創建了名為提取、轉換和加載(Extract、Transform和Load, ETL)的整個程序和規程，只是為了將資料從 OLTP 移動到 OLAP，作為ETL程序的一部分，資料所有者可以混合使用他們自己的不同資料庫、外部購買的資料、社會信號和其他有用的資訊，然而，使用三個不同的筒倉意味著OLAP資料庫中的資料總是過時的--往往是一天到一周的資料，

向 HTAP 變遷

OLTP/ETL/OLAP結構今天仍然被廣泛使用，然而，隨著時間的推移，OLAP和OLTP資料庫(速度較慢)都獲得了以分布式方式作業的能力，也就是說，單個資料表現在可以分布在多臺計算機上，

跨多個服務器分布允許資料表變得更大，分布式資料表可以隨時提高性能，只需添加更多的服務器來處理更多的事務或回復更多的查詢，一個資料庫——一個或多個資料表，在重疊的資料上提供相關功能——現在可以在靈活大小的機器陣列上運行，可以在本地運行，也可以在云中運行，

隨著這些功能的增加，在單個資料庫中混合 OLTP 和 OLAP 功能的令人興奮的可能性已經實作，使這成為可能的資料庫軟體在 2014 年被 Gartner 命名為混合事務和分析處理(HTAP)，

這種能力是如此的新，以至于它有許多名稱，包括混合操作分析處理(HOAP)和translytical資料庫(它結合了trans_actions和ana_lytical函式)，HTAP、HOAP 和 translytical 資料庫也被描述為執行操作分析——“使用SLA的分析”，或者必須提供接近實時回應的分析，Gartner 還提出了增強事務處理(ATP)，它描述了 HTAP 作業負載的一個子集，包括操作 AI 和機器學習，

HTAP 的優勢

HTAP有很多好處，HTAP創建了一個更簡單的體系結構，因為兩種不同型別的資料庫以及ETL流程都被單個資料庫所取代，而且，資料拷貝也被消除了，資料不是先存盤在OLTP資料庫中(用于事務)，然后再被復制到 OLAP 中(可能是多次復制，用于分析)，而是作為單一來源資料駐留在HTAP資料庫中（A single source of truth resides in the HTAP database），

這些根本性的改變帶來了額外的好處：操作要簡單得多，因為只有一個系統在運行，而不是幾個，確保單個資料庫的安全比在不同系統上進行多個資料拷貝要容易，而且資料可以是新鮮的——一旦資料被處理，它也可以用于分析，不再需要等待數小時或數天（有時更長時間），也不要再讓資料通過 OLTP 和 ETL 才能進行分析，

HTAP 可以實作非常大的成本效益，同時還可以增加相關的收入和降低成本，架構和操作的簡單性大大節省了成本，更高的性能使現有的創收功能更具生產力，并使新的功能實作成為可能，

物聯網（IoT）從HTAP中獲益匪淺，如果你正在運行一個智能電網，你需要根據最新的資料快速運行，分析師、儀表盤和應用程式都需要一次性訪問相同的、最新的資料，

沒有 HTAP，機器學習和人工智能實際上是不切實際的，如果不能從當前和歷史資料中學習，那么運行機器學習演算法就沒有多大意義，沒有人想運行一個預測性維護程式——假如這個程式告訴你：你公司的油井可能在一周前需要緊急維護，或者昨天有幾個有趣的旅行便宜貨，我相信你該明白，這絲毫沒有意義，

OK，今天的分享就到這里，歡迎大家關注 StoneDB，

StoneDB 2.0 云原生分布式實時 HTAP 架構詳細設計以 RFC 形式持續進行，歡迎大家關注我們最新進展，更歡迎給我們開源協作的模式和方法提出改進意見，一起通過開源的方式共建 StoneDB ~

https://github.com/stoneatom/stonedb/issues/436

• StoneDB 代碼已完全在 Github 開源：

https://github.com/stoneatom/stonedb

• StoneDB 官網：

https://stonedb.io/

標籤：MySQL

上一篇：解讀數倉常用模糊查詢的優化方法

下一篇：ElasticSearch深度分頁詳解