免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

HTAP(Hybrid Transaction and Analytical Processing)數(shù)據(jù)庫，也稱混合型關系數(shù)據(jù)庫，是能同時提供OLTP和OLAP的混合關系型數(shù)據(jù)庫。在互聯(lián)網浪潮出現(xiàn)之前，企業(yè)的數(shù)據(jù)量普遍不大，特別是核心的業(yè)務數(shù)據(jù)，通常一個單機的數(shù)據(jù)庫就可以保存。那時候的存儲并不需要復雜的架構，所有的線上請求OLTP和后臺分析OLAP都跑在同一個數(shù)據(jù)庫實例上。

隨著互聯(lián)網的發(fā)展，企業(yè)的業(yè)務數(shù)據(jù)量不斷增多，單機數(shù)據(jù)庫的容量限制制約了其在海量數(shù)據(jù)場景下的使用。因此在實際應用中，為了面對各種需求，OLTP、OLAP 在技術上分道揚鑣，在很多企業(yè)架構中，這兩類任務處理由不同團隊完成，同時部署的OLAP和OLTP通過ETL進行銜接。為了提升OLAP的性能，需要在ETL過程中進行大量的預計算，包括數(shù)據(jù)結構的調整和業(yè)務邏輯處理。這樣的好處是可以控制OLAP的訪問延遲，提升用戶體驗。但是，因為要避免抽取數(shù)據(jù)對OLTP系統(tǒng)造成影響，所以必須在日終的交易低谷期才能啟動ETL過程。這樣一來， OLAP與OLTP的數(shù)據(jù)延遲通常就在一天左右，習慣上大家把這種時效性表述為T+1。其中，T日就是指OLTP系統(tǒng)產生數(shù)據(jù)的日期，T+1日是OLAP中數(shù)據(jù)可用的日期，兩者間隔為1天。

這個時候我們會發(fā)現(xiàn)，這個體系的主要問題就是OLAP系統(tǒng)的數(shù)據(jù)時效性，T+1太慢了。隨著大數(shù)據(jù)時代互聯(lián)網的高速發(fā)展，商業(yè)決策更加注重數(shù)據(jù)的支撐，大量應用要求對海量數(shù)據(jù)進行實時更新和查詢，這都要求OLAP系統(tǒng)更快速地反映業(yè)務的變化。另一方面，企業(yè)需要維護不同的數(shù)據(jù)庫以便支持兩類不同的任務，管理和維護成本高。

因此，能夠統(tǒng)一支持事務處理和工作負載分析的數(shù)據(jù)庫成為眾多企業(yè)的需求。在此背景下，由 Gartner 提出的 HTAP成為希望?；趧?chuàng)新的計算存儲框架，HTAP 數(shù)據(jù)庫能夠在一份數(shù)據(jù)上同時支撐業(yè)務系統(tǒng)運行和 OLAP 場景，避免在傳統(tǒng)架構中，在線與離線數(shù)據(jù)庫之間大量的數(shù)據(jù)交互。

我們了解了OLAP 數(shù)據(jù)庫和 OLTP 數(shù)據(jù)庫之后，我們再來考慮：HTAP=OLTP+OLAP，是這樣嗎？

我們來仔細考慮考慮，OLTP系統(tǒng)多為行存儲，主打高并發(fā)、低延時和高穩(wěn)定性，能夠實現(xiàn)復雜的查詢操作以秒鐘級的響應，適合經常寫入的小型業(yè)務；而OLAP主要用于大規(guī)模的復雜查詢，持續(xù)時間很長，性能開銷極大，主要以讀取內容為主，且依賴豐富的索引，常常按列存儲；如果他們部署在一起，OLAP的臨時查詢開銷可能會影響OLTP的寫入延時，另外很多OLTP數(shù)據(jù)庫在執(zhí)行OLAP業(yè)務時，仍然需要將行存數(shù)據(jù)轉儲到列存表中，這樣也會大大的影響業(yè)務執(zhí)行效率。

現(xiàn)實情況是，對HTAP的需求，日常還是以OLTP為主，但也需要對數(shù)據(jù)進行加工，以保證偶爾的OLAP工作負載，這里說的OLAP場景并不是真正意義上的OLAP，它只為了提升在OLTP系統(tǒng)中執(zhí)行復雜查詢的性能。所以大部分的HTAP并不完整包含OLAP的完整功能，且他們的OLAP功能整體比較弱，只是滿足偶爾提取一些需要用于分析的少量數(shù)據(jù)。

在實際的使用過程中，很多企業(yè)為了實現(xiàn)HTAP，是花了不少代價的。選型過程中功能需要考慮的因素包括：數(shù)據(jù)存儲格式、SQL引擎的效率、OLTP/OLAP的資源隔離與防干擾措施、數(shù)據(jù)有幾份備份、如何避免大型集群產生數(shù)據(jù)沼澤等等?？梢哉f綜合性能和成本來考量，對于很多企業(yè)，HTAP并不能是OLAP的替代方案。

在大數(shù)據(jù)不斷高速發(fā)展的時代，當您的企業(yè)發(fā)現(xiàn)傳統(tǒng)的數(shù)據(jù)庫已經不能滿足業(yè)務需求，需要選型OLAP或者HTAP來解決OLAP需求時，重要考慮哪些影響數(shù)據(jù)使用的因素呢？

1. SQL能力：是否具備完善的SQL標準和ACID特性，支持對接和兼容常用的開源組件，來保障用戶輕松實現(xiàn)不同數(shù)據(jù)基礎設施的平穩(wěn)遷移。
2. 實時性：在瞬息萬變的商業(yè)社會，要盡快的做出決策需要進行實時的數(shù)據(jù)分析和數(shù)據(jù)服務。正如我們剛才分析的，HTAP要兼容OLAP和OLTP場景，往往很難保證全量數(shù)據(jù)T+0實時性。
3. 高并發(fā)：在需要大量使用高并發(fā)OLAP的場景，HTAP如何滿足；同時，還需要考慮高負載運行時對OLTP業(yè)務的影響。
4. 擴展能力：當計算和存儲需要擴展時，不同的架構的數(shù)據(jù)庫會有不同的擴容方式，相對而言，存算分離的數(shù)據(jù)庫可以自由增減計算和存儲資源，按需付費節(jié)約成本。

按照上述的參考，您在選型OLAP或者HTAP時，如果希望獲得支持存算分離、分布式事務處理、SQL 兼容性、云化彈性供給、Hadoop 生態(tài)、性能優(yōu)化等關鍵特性的解決方案，以此來助力企業(yè)實現(xiàn)降成本、提性能、全融合的大數(shù)據(jù)建設目標，建議選擇Snowflake、Databricks、OushuDB 這一類云原生數(shù)據(jù)平臺，它們突破了傳統(tǒng) MPP 和 Hadoop 的局限性，實現(xiàn)了上述的存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術實現(xiàn)了高并發(fā)，同時保障事務支持。近兩年，國內也誕生了全實時 Omega 架構的湖倉一體，甚至可以完成全量數(shù)據(jù) "T+0"的流處理和實時按需查詢，擺脫了"T+1"的傳統(tǒng)痛點，強大的云原生OLAP也有效解決了HTAP面對海量數(shù)據(jù)管理的問題。