PolarVector
PolarDB for MySQL vector search deeply integrates vector similarity search capabilities into the database kernel. While storing and processing structured data, the database also performs efficient similarity searches on vectors generated from unstructured data such as text, images, and audio. Without deploying or maintaining a separate vector database or a complex data synchronization pipeline, you can build AI applications in your PolarDB cluster, such as semantic search, intelligent recommendations, and search by image.PolarDB provides two vector search protocols for different technology stacks and business scenarios: a protocol that is fully compatible with MySQL, and the OpenSearch protocol (PolarSearch), which is compatible with the mainstream search ecosystem.
Key concepts
-
Vector embedding: A technique that uses a pre-trained embedding model to convert real-world unstructured data, such as text and images, into numerical arrays (vectors). These vectors capture the deep semantic information of the data, enabling machines to understand and compare their similarity.
-
Similarity search (k-NN): Also known as k-nearest neighbor search. Its core goal is to find the k vectors closest in “distance” to a given query vector among massive volumes of vector data. This “distance” can be calculated by using different mathematical formulas and represents the semantic similarity of the data.
-
Vector index: To avoid exhaustive one-by-one comparisons across massive volumes of data, build a vector index in advance. An index is a data structure optimized for efficient queries. It uses the distribution characteristics of vectors to quickly narrow the search scope at query time, reducing retrieval latency from seconds to milliseconds while maintaining the recall rate.
-
Comparison of vector index algorithms: PolarDB supports several mainstream vector index algorithms. HNSW and IVF are the two most common, each with different strengths in performance, resource consumption, and applicable scenarios.
-
HNSW (Hierarchical Navigable Small World): A graph-based index with high performance and a high recall rate, but a correspondingly high memory overhead. It is suitable when query latency and accuracy requirements are extremely high and the dataset fits in available memory.
-
IVF (Inverted File): A clustering-based inverted index with lower memory usage. It is more suitable for processing ultra-large datasets in memory-constrained environments, although its search accuracy is usually slightly lower than that of HNSW.
-
Key advantages
PolarDB vector search engine combines the ease of use of a relational database with the high performance of a specialized vector database. Compared with other technology choices, it offers significant advantages.
|
Feature |
Traditional relational database |
Specialized vector database |
PolarDB vector search engine |
|
SQL support |
Supported |
Not supported |
Supported |
|
Vector search |
Poor performance |
High performance |
High performance |
|
Learning cost |
Low |
High |
Low |
|
Ecosystem compatibility |
Rich |
Limited |
Dual ecosystem |
|
Scalability |
Limited |
Good |
Excellent |
|
O&M complexity |
Simple |
Complex |
Simple |
In addition, it offers the following core advantages:
-
All-in-one solution: You do not need to introduce a separate vector database. PolarDB enables you to process business data and vector data at the same time, simplifying the system architecture and reducing O&M costs.
-
Enterprise-grade reliability: It fully supports ACID transactions to ensure data consistency. Its distributed architecture supports high availability and automatic failover, ensuring business continuity.
-
Tight integration with LLMs: Built-in inference for the Qwen model simplifies the AI application development pipeline.
Core capabilities and performance metrics
Search performance
-
Latency: P99 (99% of requests) < 10 ms and P95 (95% of requests) < 5 ms.
-
Throughput: More than 10,000 QPS per single node.
-
Precision: A recall rate greater than 99%.
Scalability
-
Data scale: Supports PB-scale vector data and vector search across billions of vectors.
-
Concurrency: Supports tens of thousands of concurrent queries.
-
Cluster size: Supports dynamic scaling to hundreds of nodes with an intelligent data-sharding strategy.
Resource efficiency
-
Storage compression: Vector data has a compression ratio greater than 50%.
-
Memory usage: Layered caching efficiently supports TB-scale graph indexes.
-
CPU utilization: Multi-core parallel optimization achieves CPU utilization greater than 80%.
Use cases
PolarDB provides a dual-protocol design. You can choose the appropriate protocol based on your team’s technology stack, business needs, and performance expectations.
|
Comparison dimension |
MySQL protocol |
OpenSearch protocol |
|
Access method |
Standard SQL |
RESTful API (compatible with Elasticsearch/OpenSearch) |
|
Core advantages |
Business data integration: You can add vector columns to existing tables and use ACID transactions, with a low learning cost. |
Hybrid search capabilities: Supports combined queries on vectors, full text, and scalars, with a mature ecosystem. |
|
Underlying dependency |
Depends on In-Memory Column Index (IMCI). Vector search runs on IMCI read-only nodes, isolating analytical workloads from transactional workloads. |
Runs on an independent search node (PolarSearch) to provide a search engine-like service. |
|
Data synchronization |
Not required. After data is written to the primary database, it automatically becomes visible to the IMCI read-only nodes. |
Not required. After data is written to the primary database, it automatically becomes visible to the search nodes. |
Intelligent Q&A and customer service chatbots
-
Business pain point: Traditional keyword matching cannot understand the actual intent behind user questions, resulting in inaccurate answers.
-
Solution: Convert question-and-answer pairs in a knowledge base into stored vectors. When a user asks a question, convert the question into a vector and use similarity search to find the most relevant knowledge points, providing more accurate answers.
-
Recommended protocol:
-
MySQL protocol: This option is more convenient if you need only basic semantic matching and want to integrate quickly with an existing MySQL application.
-
OpenSearch protocol: Use its hybrid search capability when you need complex filtering with keywords, category labels, and other criteria.
-
Personalized recommendation systems
-
Business pain point: How to recommend products or content that users may find interesting based on their historical behavior, such as browsing, clicks, and purchases.
-
Solution: Represent both users and items (products, articles, and videos) as vectors. Calculate the similarity between user vectors and item vectors to retrieve a set of candidates that may interest the user. Then apply other strategies for fine ranking.
-
Recommended protocol:
-
OpenSearch protocol: The retrieval layer of a recommendation system usually involves large data volumes and is sensitive to performance and cost. The IVF index and Product Quantization (PQ) technology provided by the OpenSearch protocol are suitable for handling massive data while controlling memory costs.
-
Search by image and multi-modal retrieval
-
Business pain point: How to find similar images by uploading an image, or find images by using a text description.
-
Solution: Convert both images and text into vectors and store them in PolarDB. Whether the input is an image or text, it is converted into a query vector for similarity search in the database.
-
Recommended protocol:
-
MySQL protocol: For scenarios that require strong consistency between image feature vectors and business data such as product IDs and prices, the transaction capability of the MySQL protocol is an important safeguard.
-