Architecture and Services
SynxDB Elastic employs a cloud-native, storage-compute separated architecture that consists of four distinct layers: the metadata service layer, compute service layer, storage service layer, and data science and AI services layer. This design enables efficient resource utilization, horizontal scalability, and optimal performance for diverse analytical and machine learning workloads.
Architecture Overview
The four-layer architecture provides clear functional separation and enables independent scaling of each component:
Metadata Service Layer: Manages metadata persistence and access, handles transaction management and state persistence
Compute Service Layer: Processes query requests with coordinator nodes handling query optimization and segment nodes executing queries, supports multiple warehouses for independent compute clusters
Storage Service Layer: Provides data persistence and access, supporting both row storage and column storage engines for different workload scenarios
Data Science and AI Services: Provides comprehensive machine learning and AI capabilities through the SynxML Platform
Metadata Service Layer
SynxDB Elastic offers two metadata service options: FoundationDB (FDB)-based metadata service and UnionStore-based metadata service.
FoundationDB-based Metadata Service
The Metadata Service is an independent cluster built upon FoundationDB, specifically engineered to manage the diverse metadata required by a computing cluster. This service implements a compute-storage separation design principle, isolating metadata management operations. This architectural choice not only reduces the overall system coupling but also significantly enhances scalability. Its underlying storage leverages FoundationDB, an industry-recognized, highly available, distributed key-value (KV) database renowned for its exceptional scalability and reliability. FoundationDB supports both independent and multi-tenant deployment models, thereby balancing security requirements with cost-effectiveness.
The overall Metadata Service architecture comprises three core components, which collaborate to deliver its functionality:
Coordination and Session Management Service: A session management cluster responsible for service discovery and the allocation of metadata service nodes.
Metadata Service: A stateless service cluster providing critical metadata access, access control, lock management, and distributed transaction capabilities. Internally, this service is further modularized into specific functional components:
Object Definition Manager: Manages queries, modifications, and deletions of database object definitions (e.g., tables, views) and handles their associated access permissions.
Manifest Manager: Provides multi-version management for data manifest files.
Sequence Server: Offers sequence value allocation services.
WAL Manager: Handles the storage and application of metadata Write-Ahead Logs (WAL).
Concurrent Controller: Provides lock-based concurrency control to ensure data consistency during concurrent access.
Metadata Storage Service: A distributed key-value storage engine implemented using FoundationDB, responsible for the actual storage of metadata. This includes, for example, mappings from tables to storage objects, data dictionaries, WAL logs, and index information.
Operational Workflow
Upon receipt of a metadata request, the Coordination and Session Management Service allocates an appropriate Metadata Service node to process the request. The designated node then retrieves the necessary metadata from the Metadata Storage Service and returns the results to the requester. Furthermore, the Coordination and Session Management Service functions as the connection entry point for Database Proxy nodes, managing communication with other nodes within the system.
UnionStore-based Metadata Service
UnionStore serves as an alternative metadata service, providing data persistence and access capabilities. The core concept is “log is database”. It persists redo logs and provides external access through log replay. UnionStore consists of two main components:
WAL Service
Receives data logs from the compute layer and persists them with 3-replica reliability
Synchronizes persisted logs to the Page Service
Page Service
Retrieves and parses persisted logs from WAL Service
Applies log modifications to corresponding pages to obtain the latest page versions
Provides page read requests, returning the appropriate version of pages to clients
UnionStore Features
Multi-version Data: Supports accessing any version of retained data (Time Travel capability)
Multi-tenancy: A single metadata service cluster can serve multiple users, improving resource utilization and cost-effectiveness
Backup and Recovery:
WAL Service backs up persisted logs to object storage for enhanced reliability and cost reduction
Page Service backs up current data snapshots to object storage as checkpoints
Recovery involves retrieving the latest snapshot from object storage and synchronizing data from the snapshot’s log position
Using UnionStore as Metadata Service
All metadata modifications and transaction information are persisted to UnionStore through WAL
Each cluster uses a single tenant, with all cluster nodes accessing the tenant’s metadata (including system table data and transaction data)
Cluster nodes maintain metadata caches, accessing the metadata service only on cache misses
Compute Service Layer
The compute layer consists of two primary components: Coordinator and Segment nodes, where segments are the minimum units of a compute cluster (Warehouse).
Coordinator (Proxy)
Coordinator nodes primarily handle client request reception, query optimization, and query plan distribution to segments for execution.
Key Features
Metadata Distribution:
Coordinator nodes distribute all relevant metadata along with query plans, avoiding segment access to metadata services
Significantly reduces metadata service pressure
Eliminates network interaction delays with metadata services
Lightweight and Stateless:
Primarily handles query optimization and forwarding, with minimal computation involvement
Metadata access primarily uses cache
Metadata and data are stored separately, enabling fast startup and reconstruction
Warehouse
A Warehouse is a compute cluster composed of one or more segments, responsible for receiving and executing query plans from the coordinator and returning results.
Key Features
Multiple Warehouses:
Supports launching multiple independent warehouses that share the same data while performing concurrent read/write operations
Different warehouses can be configured with varying specifications and scales for different business workloads on the same data
Stateless and Rapid Scaling:
Warehouses can quickly scale segments without business impact to improve query performance
Warehouses can be created, started, and stopped rapidly (within seconds) based on business requirements, improving compute resource utilization
Storage Service Layer
The storage service layer supports both row storage and column storage engines to accommodate different workload scenarios. Data is persisted to:
PAX Column Storage (Object Storage): Provides unlimited expansion capabilities
UnionStore: Supports fast row storage read/write operations
All cluster nodes maintain data caches for efficient data access.
UnionStore Row Storage
UnionStore serves as a row storage engine that can provide storage and access for user row tables in addition to metadata services. Users can create and use row tables through specific syntax.
Data Organization
Data is organized at the tuple level and sequentially written to different pages (8K/32K)
Page headers contain pointers for quick tuple location
Key Benefits
Fast reading and writing of complete records
More efficient DML operations
Supports OLTP (Online Transaction Processing) workloads with frequent DML operations and high latency requirements
Handles continuous, batch data writing scenarios
Compatible with PostgreSQL ecosystem, supporting special requirements such as PostGIS
PAX Column Storage
PAX is a new column storage engine that organizes data by columns in continuous storage, grouping multiple column data into row groups within files stored in object storage.
Key Features
Statistical Information:
Collects file-level and row group-level statistics during data writing to accelerate queries
Uses statistics as query results to avoid data scanning and computation (e.g., for aggregates)
Employs min-max filtering for file-level and row group-level data filtering during scanning
Vectorized Engine:
Integrates with vectorized engines, generating internal column storage formats for enhanced data processing and query capabilities
Data Writing and Updates:
Uses append-only writing for data insertion
Employs visibility map (visimap) for delete marking
Data reading determines record visibility based on visimap
Visimap is stored with data rather than as metadata, avoiding excessive metadata growth and frequent metadata access during data reads
Provides Copy on Write writing strategy for delete operations, rewriting related data files to avoid visimap generation, suitable for read-heavy, write-light scenarios
Data Clustering:
Groups “adjacent data” together to enable more effective data filtering through min-max filters
File Management:
Merges multiple data writes into single files to avoid small file generation
Periodically deletes unnecessary files and merges small files to improve data scanning efficiency
Gopher Cache
Gopher is a distributed cache system that supports high-concurrency, low-latency access to massive small and large files. It is deployed to each node in the data warehouse compute layer to accelerate computing I/O access.
Adopts a decentralized design where each cache instance is a self-contained client/server service
Acts as a local file system with two-level caches for data warehouse computing services
Avoids potential intra-cluster network communication constraints observed in centralized master-slave distributed cache systems
Core Components
Metadata Service: The core of the cache system, managing metadata such as task status, file names, and block IDs, interfacing with other modules to facilitate client data access
User File System: Stores destination storage information including target file systems, ports, and buckets
Block Manager and File Manager: Provide data access for blocks and files respectively, utilizing stream reads and writes for large file processing in small memory buffers
Cache Manager: Implements a two-level cache (memory pool and SSD cache) to efficiently utilize limited cache space and improve data access speed
Persistent Storage Module: Incorporates network transmission libraries for S3 object storage, HDFS, and local storage connections
Session Manager: Utilizes epoll multiplexing to handle multiple client connections simultaneously
Key Features
File prefetching, batch reading, shared memory, asynchronous write optimization
Concurrent multiple reads and small file memory merging
High-performance and highly available caching system supporting efficient concurrent processing and rapid scaling
Data Science and AI Services
SynxDB Elastic includes the SynxML Platform, a high-performance distributed computing platform designed for enterprise-grade AI applications. The platform integrates the strengths of open-source technologies and enhances them with enterprise-grade features, offering a complete end-to-end solution covering data preparation, feature engineering, model training, and production deployment.
SynxML Platform Core Features
Visual Modeling
Offers an intuitive graphical interface that lets users train models by selecting algorithms, datasets, and setting hyperparameters
After training, models can be deployed as services with a single click
Supports A/B testing and staged rollouts
Notebook-based Development
Comes with a built-in professional-grade Jupyter environment
Developers can write and debug Python code flexibly, enabling customization and experimentation with complex algorithms
Algorithm and Model Library
Includes a rich collection of built-in algorithms such as Logistic Regression and XGBoost
Deep learning models like MLP, ResNet, and Bert
Fine-tuning algorithms for large language models (supporting QLoRA and Unsloth)
Users can also extend the library with custom algorithms
SynxML Platform Use Cases
Private Model Training for Enterprises
Enables organizations to train machine learning models on sensitive internal data without leaving the enterprise network
Ensures secure end-to-end management and high-performance training
Helps businesses build accurate, compliant, and domain-specific models
Fine-tuning Large Language Models
Integrates efficient fine-tuning methods such as QLoRA and Unsloth to support popular LLMs
Enterprises can quickly adapt LLMs to specialized domains using few-shot learning
Reduces training costs while improving task accuracy and semantic understanding
Model Deployment
Allows trained models to be deployed as RESTful API services in one click
Seamlessly integrates with business systems
Supports A/B testing, phased rollouts, and auto-scaling to maintain stable performance under high concurrency