Summary: In this issue we reveal how Hologres supports ultra-high QPS online service (click search) scenarios.

Hologres (Chinese name) interactive analysis is ali cloud from the research on the number of one-stop real-time warehouse, the cloud native system combines real-time service and analysis of large data, fully compatible with PostgreSQL deal with large data ecological seamless get through, can use the same set of data architecture also supports real-time written real-time query and real-time offline federal analysis. Its emergence simplifies the business architecture, provides real-time decision-making capabilities for business, and enables big data to bring greater business value into play. From the birth of Ali Group to the commercialization of cloud, With the development of business and the evolution of technology, Hologres has been continuously optimizing the competitiveness of core technologies. In order to let everyone know Hologres better, we plan to continuously launch the series of secrets of the underlying technology principles of Hologres, from high-performance storage engine to efficient query engine. High throughput write to high QPS query, etc., full interpretation of Hologres, please continue to pay attention to!

The traditional OLAP system usually plays a static role in business. It analyzes massive data to obtain business insights (such as a well-calculated view, model, etc.), and then provides online data services (such as HBase, Redis, MySQL, etc.) from the results of massive data analysis. Serving and Analytical are a separate process here. In contrast, the actual business decision making process is often an online process of continuous optimization. The process of service generates a lot of new data, and we need to perform complex analysis of this new data. The insights generated by analysis are fed back to the service in real time, enabling business decisions to be made in real time and thereby creating greater business value.

Hologres is positioned as a one-stop real-time data store, integrating Analytical and online services to reduce data fragmentation and mobility. This paper will introduce Hologres’ service capabilities (the core of which is the search capability) and the implementation principle behind them.

The point search scenario refers to the Key/Value query scenario, which is widely used in online services. Due to the wide demand for point-and-check scenarios, there are a variety of KV databases in the market that are positioned to support point-and-check scenarios with high throughput and low latency. For example, HBase, which is widely known to the public, provides point-and-check capabilities through a set of self-defined apis and achieves good results in many business scenarios. However, HBase has some disadvantages in actual use, which leads to the migration of many services from HBase to Hologres, including the following:

  • When the data scale reaches a certain level, HBase performance deteriorates and cannot meet the requirements of large-scale point-and-check calculation. In addition, HBase stability deteriorates and requires experienced operation and maintenance (O&M) support

  • HBase provides customized apis, which cost a certain amount of money to get started. Hologres provides high throughput and low latency query services directly through SQL. Compared with other KV systems providing custom API, SQL interface is undoubtedly more simple and easy to use.

  • HBase adopts the Schema Free design and has no data type. Therefore, it is difficult to check data quality and correct data quality. Hologres have compatible with Postgres almost all mainstream data type, can Insert/Select/Update/Delete SQL statements to view and Update data.

  • The point lookup scenario in Hologres refers to a primary key (PK) based query of the row memory table.

    — BEGIN; CREATE TABLE public.holotest ( “a” text NOT NULL, “b” text NOT NULL, “c” text NOT NULL, “d” text NOT NULL, “e” text NOT NULL, PRIMARY KEY (a,b) ); CALL SET_TABLE_PROPERTY(‘public.holotest’, ‘orientation’, ‘row’); CALL SET_TABLE_PROPERTY(‘public.holotest’, ‘time_to_live_in_seconds’, ‘3153600000’); COMMIT;

    Select * from table where pk =? ; Select * from table where pk in (? ,? ,? ,? ,?) ; — Query multiple points at once

Point to check the technical implementation of the scene difficulties

In normal cases, an SQL statement needs to be parsed into an AST (abstract syntax tree) by SQL Parser, and then a Plan (executable Plan) is generated by Query Optimizer. Finally, the calculation result is obtained by executing the Plan. In order to achieve high throughput, low latency and stable point search service through SQL, we must overcome the following difficulties:

  1. How can SQL interfaces achieve high QPS without destroying the PostgreSQL ecosystem?
  • How to do low or even avoid SQL parsing and optimizer overhead
  1. How does an efficient Client SDK interact with back-end storage?
  • How to achieve high concurrency interaction with low consumption
  • How can I reduce the overhead in messaging
  • How to sense the pressure on the back end and coordinate for optimal throughput and latency
  1. How can back-end storage be more stable with high performance?
  2. How to maximize CPU resources
  3. How to reduce memory allocation and copy and avoid system instability caused by hot keys
  4. How can I reduce the impact of cold data I/OS

After overcoming the above three types of difficulties, the overall working mode can be very simple: the access layer (FrontEnd) directly communicates with the back-end storage through the Client SDK.

The following will introduce how Hologres overcomes the above three difficulties to achieve high throughput and low latency point search.

Reduce and avoid SQL parsing and optimizer overhead

Query Optimizer performs a Short Cut

Because the Query queried is simple enough, Hologres Query Optimizer makes the corresponding short cut, and the Query queried does not enter the full flow of Opimizer. After entering the FrontEnd, Query is processed by the Fixed Planner, which generates the Fixed Plan (physical Plan of point-lookup). The Fixed Planner is very light and does not need to go through any equivalent transformation, logical optimization, physical optimization and other steps. It only conducts some simple analysis based on AST tree and constructs corresponding Fixed Plan, so as to avoid the overhead of optimizer as far as possible.

Prepared Statement

Although Query Optimizer makes a short cut to Query, the parsing overhead of Query entering the FrontEnd is still there, and the overhead of Query Optimizer is not completely avoided.

Hologres is compatible with Postgres. Postgres has two front-end and back-end communication protocols: Extended and Simple.

  • Simple: the Client sends the SQL to be executed to the Server each time. After receiving the SQL, the Server parses and executes it, and returns the result to the Client. The Server in the Simple protocol inevitably needs to parse at least the received SQL to understand its semantics.
  • Extended protocol: The interaction between Client and Server is accomplished in multiple phases, which can be roughly divided into two phases.
  • Phase 1: The Client defines a Statement with a name on the Server side and generates a generic plan for the Statement (a generic plan that is not bound to specific parameters).

  • Phase 2: The user executes the Statement defined in phase 1 by sending specific parameters. Phase 2 can be repeated multiple times, each time using the Generic plan generated in phase 1 with the Statement name defined in phase 1 and parameters required for execution. Because the second phase can repeatedly execute the generic plan prepared in the first phase using the Statement name and accompanying parameters, the cost of the second Frontend segment is almost equal to zero.

Hologres is based on Postgres extended protocol and supports Prepared Statement, so the overhead of Query on Frontend is close to zero.

High performance internal communication

BHClient is a set of efficient Private Client SDK implemented by Hologres for direct communication with back-end storage. It has the following advantages:

1) Reactor model, whole-process asynchronous operation without lock

BHClient works in a similar way to the REACTOR model, with each target shard corresponding to an Eventloop that processes requests on the shard in an “infinite loop” manner. Because of HOS’s abstraction of the scheduling execution unit, the base cost of this way of working is low enough even with many shards.

2) Efficient data exchange protocol binary Row

Binary Row is an internal data communication protocol that can be customized to reduce memory allocation and copy over the entire interactive link.

3) Back pressure and batch collection

BHClient can sense the back-end pressure and perform adaptive backpressure and batch matching to improve system throughput without affecting the original Latency.

Stable and reliable back-end storage

1) LSM(Log Structured Merge Tree)

Hologres’s row memory table is stored in LSM. Compared to the traditional B+ tree, LSM can provide higher write throughput because it does not have any random writes, and the Append Only operation ensures that Only sequential writes are made to disks.

  • A row memory tablet can have one MEMtable and multiple IMmutable memtables.
  • All data updates are written to memtable. When memtable is full, it becomes IMMtable memtable, immutable memtable is flushed into SST (Sorted String Table) files. SST files cannot be modified once generated, so random writes do not occur.
  • SST files are organized by layers in the file system, except SST files at level 0 are out of order and exist overlap, SST files at other levels are orderly and not overlap. Therefore, files at level 0 need to be traversed one by one, while files at other levels can be searched in two ways. A lower-layer SST file is propagated to a higher layer by combining a new SST file with a new Compaction. Therefore, data in the lower-layer SST file is newer than that in the upper-layer SST file. Once a key is found on a layer, it is not necessary to query it from a higher layer.

2) development based on C++ pure asynchronous

Hologres is not the only system that uses LSM to organize and store data. After LSM was proposed in Google’s “BigTable” paper, many systems have adopted it for reference, such as HBase. Hologres is developed in C++, a native language that allows us to achieve superior performance compared to Java. At the same time, pure asynchronous development is based on the asynchronous interface provided by Hologres (HOS). HOS manages the scheduling execution of CPU by itself through abstract ExecutionContext, maximizing the utilization of hardware resources and throughput.

IO optimization and rich Cache mechanism

Hologres implements rich Cache mechanisms, such as Row Cache, block Cache, Iterator Cache, meta Cache, to speed up hot data search, reduce I/O access, and avoid new memory allocation. When I/OS are unavoidable, Hologres consolidates concurrent I/OS and uses the WAIT/Notice mechanism to ensure that I/OS are accessed only once to reduce THE AMOUNT of I/OS processed. Reduce physical file storage costs and IO access by generating file-level dictionaries and compression.

conclusion

Hologres is committed to one-stop real-time data warehouse. In addition to the ability to deal with complex OLAP analysis scenarios, Hologres also supports ultra-high QPS online search services. By using the standard Postgres SDK interface, you can obtain online services with low latency and high throughput through SQL, simplifying learning costs and improving development efficiency.

Author: Zhou Sihua (pseudonym: Sizhao), a technical expert at Alibaba, is currently working on Hologres, an interactive analysis engine.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.