How to Build a Mature, Stable, Cost-Effective, and Easy-to-Use AI Application — Quwan Technology's Hands-on Practice Building an Employee Assistant on OceanBase

Author: Su Chenghui, Head of Database at Quwan

Today, it is widely known that LLMs are accelerating the intelligent transformation of every industry. In practice, however, an #LLM’s ignorance of specific domains or private data inevitably leads to “#hallucination” problems, giving rise to an urgent enterprise need for efficient, accurate “memory systems.” As the core bridge connecting LLMs with massive amounts of unstructured data, vector databases — with their powerful similarity-search capabilities — have rapidly become the infrastructure for building a new generation of #AI applications (such as intelligent Q&A, recommendation systems, and semantic search), directly determining the intelligence ceiling and user experience of AI applications. This article shares Quwan Technology’s thinking and experience in selecting OceanBase, after comparing multiple vector databases, as the underlying database for its custom AI assistant.

Business Needs: A Mature, Stable, Cost-Effective, and Easy-to-Use AI Application

Quwan Technology, founded in 2014, is an innovative tech company integrating interest-based social networking, artificial intelligence, esports, and other technologies. Among its 1,600+ employees, 50% are technical staff, and it holds nearly 500 software copyrights and patents. It has become one of China’s top 100 internet companies by overall strength and one of the top 20 internet companies in Guangzhou.

Embracing AI for Cost Reduction and Efficiency Gains

As an advanced tech company, its attitude toward new technologies is one of open arms. Over the past two years, the maturity and application of AI technology have had a positive impact on every department within Quwan. Quwan hopes to use AI to improve efficiency and reduce labor costs, especially in everyday database-middleware scenarios and operations-and-monitoring scenarios.

The everyday-scenario needs for AI can be grouped into four categories:

1. AI slow-log optimization. R&D staff can converse directly with the AI, which outputs index suggestions, rewrite plans, and cost estimates in real time — no longer needing to manually file tickets to the DBA team. SQL optimization efficiency improves greatly.
2. AI database disk-resource analysis. The system needs to collect database/table-level increments, TOP rankings, and data trends daily. AI can complete this directly, and combining it with business characteristics to predict capacity peaks can proactively trigger archiving or scaling suggestions, improving system stability.
3. AI database-connection analysis. When the number of connections approaches the threshold, AI can output detailed connection information such as the business source, helping quickly locate abnormal businesses.
4. AI database CPU alert analysis. After a CPU alert is triggered, AI can automatically correlate slow logs, execution plans, and system metrics to generate a root-cause analysis report. Front-line staff can directly perform optimization or scaling based on the report, resolving the alert and resource issues.

On the operations-and-monitoring side, the plan is to apply AI capabilities in the following two directions:

1. AI database alert root-cause analysis. Generally, an alert involves multiple scenarios, requiring multiple monitoring logs to be investigated. AI can quickly locate the problem, correlating multi-dimensional logs such as transactions, I/O, and slow queries to output a root-cause conclusion — for example, concurrent large transactions causing lock waits that lead to a momentary I/O surge that triggers blocking — effectively reducing manual troubleshooting time.
2. AIOps alert governance. Alerts span a variety of databases, including traditional databases such as MySQL, PostgreSQL, PolarDB, and GaussDB, and message middleware such as Kafka and RocketMQ. The alert volume is too large to close the loop with pure manual effort, so AI is introduced for intelligent governance.

Based on the different needs of various departments, the company launched a unified service entry point for employees — the employee assistant. Every employee needs to have an independent, private assistant to meet customized needs. This places four core requirements on the underlying database.

1. Scalar data storage: must have high performance and easy scalability to support high-concurrency reads and writes.
2. Full-text search: support for full-text search.
3. Vector storage and computation: support for writing, indexing, and similarity querying of vector data.
4. HTAP capability: session-context data is permanently stored and can be analyzed in real time directly within the database, with no extra data pipeline.

The Difficulty of AI Application Development: Not a Single Ideal Database

During the development of the employee assistant, the database team researched the industry’s state of AI applications, development difficulty, and stability guarantees, and found reality far more challenging than imagined.

First, no mature, out-of-the-box underlying database capable of supporting rapid AI application development has yet emerged in the industry.

Second, meeting the various needs may require simultaneously maintaining MySQL (scalar retrieval, TP support), Elasticsearch (full-text search, vector search), and a VDB/Milvus (vector database) — at least three systems — greatly increasing adoption cost and development difficulty.

Finally, the stability of each component must be guaranteed separately, including high availability, monitoring, backup, and troubleshooting — a heavy operational workload with a long diagnostic chain.

The Selection Journey: Comparing Three Vector-Database Options

Based on the dual requirements of rapid business rollout and stability, the database team refined its selection plan, with the following core demands.

• Scalar data: support for massive-scale storage, with consistency and high-availability guarantees.
• Vector data: high-performance vector writes, index building, and approximate query, meeting millisecond-level recall.
• Development interface: compatible with standard SQL so the R&D side can develop AI applications rapidly with zero learning cost.
• Overall cost: significantly reduce hardware and labor investment through storage compression, resource pooling, and unified operations.

Guided by this goal, three database options were initially selected and compared.

Option 1: MySQL + Elasticsearch + Milvus/VDB

As described above, this option requires maintaining three independent systems with a long data-synchronization chain, multiplying the development, testing, and release cycles. Both hardware investment and operational labor cost are high, which does not meet the goal of “low-cost rapid rollout.”

Option 2: TiDB + ES

• Requires deploying multiple nodes such as PD, Server, and KV, with high deployment cost;
• Full-text search requires additionally introducing Elasticsearch, further driving up cost;

In addition, TiDB must be deployed manually or via the TiUP component, with a lower degree of automation and platformization than OceanBase and insufficient operational convenience.

Option 3: OceanBase

• Has native HTAP, high compression, and vector-index capabilities; a single cluster can simultaneously meet scalar, vector, and full-text search needs;
• Compatible with the MySQL protocol, with zero learning cost;
• Resource-pooled multi-tenancy with high hardware utilization, operations done through a graphical platform, and fully automated scaling.

Weighing multiple dimensions — performance, compatibility, persistence, scalability, cost, and operational convenience — OceanBase was ultimately chosen as the unified data foundation, mainly for five reasons:

1. High compatibility. Highly compatible with MySQL syntax, with native SQL support for vector queries, helping to quickly and cost-effectively implement the business’s AI application needs.
2. Stable reliability. Strong cluster high-availability with fast recovery, RTO < 8s, ensuring system stability. At the same time, under the three-replica architecture, each replica holds a complete copy of the data, with no risk of data loss.
3. HTAP capability. Based on “the same copy of data, the same engine,” it supports both online real-time transactions and real-time analytics scenarios simultaneously.
4. Strong scalability. Node scaling can be completed in minutes and capacity scaling in seconds, providing smooth, efficient online scaling.
5. Multi-path fused retrieval over text. OceanBase’s hybrid retrieval — combining vector search and full-text search — enables multi-path fused retrieval over text. The whole process includes steps such as inserting text (Chunk), vectorization (Embedding), tokenization, vector search, full-text search, and reranking (Rerank).

In addition, during its research, Quwan also found that OceanBase has three standout advantages that other options lack.

First, the OCP operations platform provides graphical, automated cluster-management capabilities, significantly reducing the complexity of daily operations. It enables common operations such as one-click scaling, monitoring and alerting, backup and recovery, patching and upgrades, and failure self-healing.

Second, replica-level columnar storage. Without adding extra components, by presenting one of the replicas in columnar storage, it can meet lightweight analytical needs.

Third, a high data-compression ratio. OceanBase provides multi-level data-compression capabilities, with compression ratios reaching 3:1 to 5:1. Although the unit price of a single TB of disk is low, when the data scale reaches tens of TB and is used for long-term archiving, the high-compression characteristic can directly reduce the number of machines, forming considerable cost savings.

Application Results: A Three-in-One Database Foundation Meeting Multiple Needs

Production Rollout Results

The OceanBase-based employee assistant is now live and running smoothly. CPU utilization has long stayed below 15% with very little jitter, and the overall average response time meets business needs.

The reason this business could go live so quickly comes down to three things: improved development efficiency, standardized operations, and cost savings.

Improved development efficiency: OceanBase supports hybrid retrieval across scalar, vector, full-text, and more — a single SQL statement can solve complex multi-dimensional query needs, simplifying development logic and reducing coding complexity.

Standardized operations: OceanBase’s migration tools and operations platform are convenient and easy to use, simplifying deployment and monitoring, enabling a fast rollout and reducing deployment time.

Cost savings: compared with a solution requiring three databases to meet business needs, adopting a three-in-one database foundation reduces resource-application and approval workflows and significantly cuts resource consumption.

Notes on Testing OceanBase

During the OceanBase rollout, the operations team encountered two problems that can serve as cautionary notes for everyone.

First, OceanBase’s initial resource footprint is relatively high. While trying to validate the resource specifications required for the production environment, the operations team found that the usual resource configuration of 8C16G could not complete deployment successfully. Especially when installing the full set of components such as OCP, there may be insufficient-resource problems. Therefore, it is recommended to configure higher-spec resources such as 8C32G for production deployment.

Second, in performance testing, the operations team used tenant configurations commonly used in production — such as 2C4G and 4C8G. The test results showed that OceanBase’s performance did not meet expectations under these configurations. It is recommended to use higher-spec tenants for testing to avoid below-target performance problems, while also gaining a sense of performance in a real business environment.

Expectations for the Underlying Database of AI Applications

The employee assistant is a service entry point at Quwan for internal employee use, and it will later be integrated into other #AI products. Therefore, regarding OceanBase as the underlying database for AI applications, Quwan also has a few expectations:

1. Distributed migration — automatic partitioning. OceanBase 4.3.5 already supports automatic partitioning. During migration from the test environment to production, it provides automatic rule-based partitioning for large tables, reducing the manual workload of splitting and verification. We also hope to try this approach in future business scenarios to reduce development and operations work.
2. Shared storage. For businesses with low I/O sensitivity, we hope to introduce a shared-storage solution to improve storage-resource utilization and simplify the scaling process.
3. Automatic hot-cold storage separation. For infrequently used cold data, we hope to store it on low-cost media such as OSS, automatically driven by policy rules (such as time fields or access frequency), to reduce storage cost.