OceanBase Vector Technology Tackles 360's Three Commercialization Pain Points, Accelerating AI-Driven Business Analytics by 80%
This article is excerpted from the e-book Case Studies on OceanBase Community Edition in Pan-Internet Scenarios. Click “Read Original” at the end of the article to get the full version.
Author: Guan Yuanzheng, database lead of 360’s Commercialization business line
As the business core of the 360 Group, the Commercialization business line carries the key mission of driving the company’s commercialization and opening a new chapter in the market. In the course of data processing, the impact of database technology on business growth has become increasingly prominent. Across the existing business lines, we use multiple types of databases, including the relational databases MySQL, OceanBase, and TiDB, as well as the non-relational databases Aerospike and Pika.
Among these, OceanBase is the newest member of our database lineup. Although it has been in use for less than two years, it has performed impressively and helped us solve many system challenges. In addition, we have applied OceanBase to four AI scenarios, driving the AI transformation of our business.
1. With the Need for Vectorized Storage and Querying, OceanBase Became the Best Choice
From a technical standpoint, 360’s Commercialization business line falls into four categories:
- KV storage scenarios — These require high concurrency, low latency, and massive storage capacity, and are supported by Aerospike and Pika
- Strong AP business scenarios — Offline analytics scenarios use Hive; online real-time analytics scenarios use Flink plus Doris
- Online business scenarios — Online transactional (TP) scenarios are supported by MySQL combined with TiDB; online analytical (HTAP) scenarios use OceanBase as the backbone
- New scenarios — With the development of LLMs, AI-innovation scenarios have emerged in the business, requiring the underlying database to support vectorized storage and querying. After a period of research, we also decided to choose OceanBase to support this business
2. Solving Three Pain Points and Improving Real-Time Advertising Report Efficiency by 80%
The entire business chain of internet advertising can be divided into five stages: ad creative and planning, media requests, bidding and delivery, impressions/clicks/spend, and advertising reports.
Advertising reports play a connecting role throughout the chain. They both turn the data produced by the previous four stages into concrete reports and guide advertisers in adjusting their ad-delivery or product-sales strategies. Reporting-type business is therefore one of the important links in commercial advertising.
When handling HTAP-style offline reporting business, MapReduce reads data from HDFS and ultimately forms offline base tables in Hive. At the same time, reports are generated through business-tightly-coupled jobs and loaded into our system. In OLTP-type systems, the front-end pages can combine various dimensions to support queries by operations staff and advertisers.
But this approach has several obvious pain points that urgently need to be solved:
1. OOM (out-of-memory) problems easily occur when the query range is large. When querying aggregated data spanning more than six months, the row-store approach forces compute nodes to perform large-scale aggregation in memory, which easily causes OOM.
2. High concurrency puts significant pressure on the system. During large-scale concurrent report queries, instantaneous hot-read problems occur. Although the system can recognize hot reads and quickly perform load balancing, load balancing takes time.
3. Uneven resource utilization. The business peak for advertising reports is roughly 9–11 a.m. and 2–5 p.m. During these periods, advertisers and operations staff all query reports, rapidly consuming system resources. During off-peak periods, there is essentially no traffic.
So what is OceanBase’s solution?
First, OceanBase improves large-scale concurrent computing by optimizing the underlying storage and concurrency-scheduling mechanisms. Operations staff only need to enable OceanBase’s Auto DOP feature, and the optimizer will automatically adjust the degree of parallelism based on the complexity of the SQL statement to accelerate SQL execution.
Second, OceanBase provides automatic partition splitting. In OceanBase 4.3.5, the system can automatically partition a single table according to a user-specified size. This way, the leader of a single table is no longer concentrated on one OBServer, thereby avoiding resource hotspots.
Furthermore, OceanBase’s materialized views are very well suited to reporting-type business. The data domain of reporting business changes infrequently, and the joined tables are relatively fixed. Materialized views can perform unified computation during off-peak periods, avoiding the overhead of repeated computation during peak periods. OceanBase also supports periodically refreshing materialized views along a time dimension.
In addition, OceanBase 4.3.3 introduced a columnar storage mode. When creating a table, you can choose row store, column store, or hybrid row-column store. If you need to isolate the column-store replica from the row-store replica, you can also place the column-store replica on a dedicated OBServer. This approach reduces the loading of irrelevant data and lowers I/O overhead.
After adopting the above solutions, the analytics efficiency of 360 Commercialization’s real-time advertising report business improved by 80%, query time was cut from 5 minutes to 40 seconds, and the query range was expanded from six months to one year.
3. Evolving Toward AI to Empower Four Business Scenarios
For 360’s Commercialization business, solving existing problems with the database is the foundation, but having the capacity for future expansion is equally critical. OceanBase has been continuously adding AI-related capabilities. Among all of its AI capabilities, Embedding is a key step in the entire flow—it converts high-dimensional, sparse semantic information into a low-dimensional, dense binary form.
What are the advantages of using OceanBase for vector storage?
The first advantage is ease of use. Operations staff are more adept at handling the capabilities of general-purpose databases. OceanBase supports vectorized querying through standard search methods, which is very friendly to us. Likewise, developers are more adept at the CRUD operations and SQL statements of general-purpose databases.
The second advantage is comprehensive monitoring. OceanBase provides the OCP platform, which can monitor the cluster in an all-around way. This lets operations staff understand the cluster’s status at a glance—whether a bottleneck has emerged or whether resources need to be scaled up.
The third advantage is horizontal scalability. In its early stages, an AI business usually needs a certain amount of starting resources to experiment with business models. OceanBase’s horizontal scalability lets the team flexibly adjust resources and reduce the cost of trial and error.
The fourth advantage is the built-in high-availability mechanism. This provides additional assurance for our business. OceanBase’s built-in Paxos mechanism effectively ensures that we can always retrieve an answer, making the LLM’s responses more accurate.
In our business, OceanBase is applied to the following four scenarios:
The first scenario is advertiser querying. We can vectorize real-time reports and offline reports and store them in OceanBase, enabling advertisers to ask questions in natural language.
The second scenario is the SRE operations knowledge base. This is more like a ChatDBA role. We can combine AI to quickly retrieve fault-resolution solutions, helping novice DBAs speed up problem diagnosis.
The third scenario is standardizing the development process. This is mainly integrated with our IDE. We first vectorize the DBA’s best-practice development handbook into OceanBase. When a developer writes an inefficient loop query, the IDE automatically prompts them.
The fourth scenario involves Dify. This is an LLM application development platform. Since OceanBase 4.3.3, it has supported vector databases, and since version 0.1, Dify has also supported using OceanBase as its underlying vector store.
4. As an Open-Source User, Our Expectations for OceanBase
The above are the advantages we have experienced while using OceanBase, but as an open-source OceanBase user, we also hope it will keep getting better in the future.
First, we eagerly hope OceanBase can support multi-instance deployment on a single machine. Currently, OceanBase only supports deploying one OBServer instance per host. In today’s era of “fat” hosts, each host is often equipped with multiple high-performance disks, but they can only be consolidated through RAID or LVM, which does not achieve the ultimate in efficiency and cost.
Second, we hope OceanBase will make hidden parameters transparent. In practice, I have repeatedly encountered situations where hidden parameters had to be adjusted to restore normal cluster operation. We hope OceanBase can open up these hidden parameters.
Finally, we are concerned about version compatibility. In practice, I have run into cases where a new OBServer kernel version was released but OMS did not support it, requiring a manual patch. Although OceanBase engineers later provided an automatic patching solution, we would prefer OceanBase to reduce the trouble caused by version incompatibilities.