Introduction to Hybrid Data Warehouse¶
A hybrid data warehouse needs to work with data sources, such as upstream databases or applications, to insert, upsert, and update data in real time. The data warehouse should also be able to query data shortly after it was imported.
Currently, the existing row-store and column-store tables in a conventional GaussDB(DWS) data warehouse cannot meet real-time data import and query requirements. Row-store tables have strong real-time import capabilities and support highly concurrent updates, but their disk usage is high and query efficiency is low. Column-store tables have high data compression ratio and good OLAP query performance, but do not support concurrent updates. Concurrent import will cause severe lock conflicts.
To solve these problems, we use column storage to reduce the disk usage, support highly concurrency updates, and improve query speed. GaussDB(DWS) hybrid data warehouses use HStore tables to achieve high performance during real-time data import and query, and have the transaction processing capabilities required for traditional OLTP scenarios.
The HStore tables uniquely support single and small-batch real-time IUD operations, as well as regular large-batch import. Data can be queried immediately after being imported. You can deduplicate traditional indexes (such as primary keys) and accelerate point queries. You can further accelerate OLAP queries through partitioning, multi-dimensional dictionaries, and partial sorting. Strong data consistency can be ensured for transactions with heavy workloads, such as TPC-C.
Note
Only clusters 8.2.0.100 and later support the HStore tables of the hybrid data warehouse.
The hybrid data warehouse is used for both production and analysis. It is applicable to hybrid transaction and analysis scenarios. It can be deployed in single-node or cluster mode. For details about how to create a hybrid data warehouse, see "Creating a GaussDB(DWS) 2.0 Cluster" in User Guide.
Hot and cold data management is supported for HStore tables. For details, see Hot and Cold Data Management. This function is supported only by cluster versions 8.2.0.101 and later.
HStore is a table type designed for the hybrid data warehouse and is irrelevant to the SQL parameter hstore.
Differences from Standard Data Warehouses¶
The hybrid data warehouse and standard data warehouse are two different types of GaussDB(DWS) products and have different usages. For details, see Table 1.
Type | Standard Data Warehouse | Hybrid Data Warehouse | ||
|---|---|---|---|---|
Application scenario | Converged data analysis using OLAP. It is used in sectors such as finance, government and enterprise, e-commerce, and energy. | Real-time data import + Hybrid analysis. Real-time upstream data import + Real-time query after data import. It is mainly used in scenarios that have high requirements on real-time data import, such as e-commerce and finance. | ||
Advantage | It is cost-effective and widely used. Cost effective, both hot and cold data analysis supported, elastic storage and compute capacities. | Hybrid load, high data import performance. It achieves high query efficiency and high data compression ratio that are equivalent to those of column storage. It can also process transactions in traditional OLTP scenarios. | ||
Features | Excellent performance in interactive analysis and offline processing of massive data, as well as complex data mining. | It supports highly concurrent update operations on massive amounts of data and can achieve high query efficiency. It achieves high performance when processing a large amount of data in scenarios like high-concurrency import and latency-sensitive queries. | ||
SQL syntax | Highly compatible with SQL syntax | Compatible with column-store syntax | ||
GUC parameter | You can configure a wide variety of GUC parameters to tailor your data warehouse environment. | It is compatible with standard data warehouse GUC parameters and supports hybrid data warehouse tuning parameters. |
Technical Highlights¶
Transaction consistency
Data can be retrieved for queries immediately after being inserted or updated. After concurrent updates, data is strongly consistent, and there will not be incorrect results caused by wrong update sequence.
High query performance
In complex OLAP queries, such as multi-table correlation, the data warehouse achieves high performance through comprehensive distributed query plans and distributed executors. It also supports complex subqueries and stored procedures.
Quick import
There will not be lock conflicts on column-store CUs. High-concurrency update and import operations are supported. The concurrent update performance can be over 100 times higher than before in general scenarios.
High compression
Column storage can achieve a high compression ratio. Data is stored in the column-store primary table through MERGE can be compressed to greatly reduce disk usage and I/O.
Query acceleration
You can deduplicate traditional indexes (such as primary keys) and accelerate point queries. You can further accelerate OLAP queries through partitioning, multi-dimensional dictionaries, and partial sorting.
Comparison Between Row-store, Column-store, and HStore Tables¶
Table Type | Row-Store | Column-Store | HStore | ||
|---|---|---|---|---|---|
Data storage mode | The attributes of a tuple are stored nearby. | The values of an attribute are stored nearby in the unit of CU. | Data is stored in the column-store primary tables as CUs. Updated columns and data inserted in small batches is serialized and then stored in a newly designed delta table. | ||
Data write | Row-store compression has not been put into commercial use. Data is stored as it is, occupying a large amount of disk space. | In row storage, data with the same attribute value types is easy to compress. Data write consumes much fewer I/O resources and less disk space. | Data inserted in batches is directly written to CUs, which are as easy to compress as column storage. Updated columns and data inserted in small batches are serialized and then compressed. They will also be periodically merged to primary table CUs. | ||
Data update | Data is updated by row, avoiding CU lock conflicts. The performance of concurrent updates (UPDATE/UPSERT/DELETE) is high. | The entire CU needs to be locked even if only one record in it is updated. Generally, concurrent updates (UPDATE/UPSERT/DELETE) are not supported. | CU lock conflicts can be avoided. The performance of concurrent updates (UPDATE/UPSERT/DELETE) is higher than 60% of the row-store update performance. | ||
Data read | Data is read by row. An entire row needs to be retrieved even if only one column in it needs to be accessed. The query performance is low. | When data is read by column, only the CU of a column needs to be accessed. CUs can be easily compressed, occupying less I/O resources, and achieve high read performance. | Data in a column-store primary table is read by column. Updated columns and data inserted in small batches are deserialized and then retrieved. After data is merged to the primary table, the data can be read as easily as that in column storage. | ||
Advantage | The concurrent update performance is high. | The query performance is high, and the disk space usage is small. | The concurrent update performance is high. After data merge, the query and compression performance are the same as those of column storage. | ||
Disadvantage | A large amount of disk space is occupied, and the query performance is low. | Generally, concurrent updates are not supported. | A background permanent thread is required to clear unnecessary HStore table data after merge. Data is merged to the primary table CUs and then cleared. This operation is irrelevant to the SQL syntax MERGE. | ||
Application scenario |
|
|
|