Архитектура NexusDB
Общий обзор
Section titled “Общий обзор”NexusDB состоит из нескольких слоёв, каждый отвечает за определённые функции:
1. Query Processing Layer
Section titled “1. Query Processing Layer”1.1 SQL Parser
Section titled “1.1 SQL Parser”- Парсирует SQL согласно диалекту PostgreSQL
- Поддерживает SELECT, INSERT, UPDATE, DELETE, CREATE TABLE
- Обрабатывает сложные выражения и операторы
1.2 Query Executor
Section titled “1.2 Query Executor”Основной компонент выполнения запросов:
WHERE Evaluation
// Вычисление условий с типизациейpub fn evaluate_where(&self, row: &Row, condition: &Expr) -> Result<bool>JOINs
- INNER JOIN: только совпадающие строки
- LEFT JOIN: все из левой таблицы
- RIGHT JOIN: все из правой таблицы
- FULL JOIN: все из обеих таблиц
- CROSS JOIN: декартово произведение
Aggregates
- COUNT, SUM, AVG, MIN, MAX
- Работает с GROUP BY и HAVING
1.3 Window Functions
Section titled “1.3 Window Functions”Аналитические функции для расширенного анализа:
ROW_NUMBER() -- Порядковый номер в партицииRANK() -- Ранг с пропускамиDENSE_RANK() -- Плотный рангLAG() -- Предыдущая строкаLEAD() -- Следующая строкаFIRST_VALUE() -- Первое значение в окнеLAST_VALUE() -- Последнее значение в окне1.4 CTEs (Common Table Expressions)
Section titled “1.4 CTEs (Common Table Expressions)”- Простые CTEs с материализацией
- Рекурсивные CTEs с обнаружением циклов
- Оптимизированное кеширование результатов
1.5 Query Optimizer
Section titled “1.5 Query Optimizer”Основан на статистике и селективности:
Сбор статистики ↓Построение гистограмм ↓Оценка селективности ↓Переупорядочение предикатов ↓Рекомендации индексов2. Storage & Index Layer
Section titled “2. Storage & Index Layer”2.1 MVCC (Multi-Version Concurrency Control)
Section titled “2.1 MVCC (Multi-Version Concurrency Control)”Механизм для конкурентного доступа без глобальных блокировок:
Row ID 1 → [Version 1] → [Version 2] → [Version 3] (TxID 100) (TxID 150) (TxID 200)Версионные цепочки:
- Каждая строка имеет цепочку версий
- Каждая версия помечена ID транзакции
- Используется для определения видимости данных
2.2 Transaction Management
Section titled “2.2 Transaction Management”pub enum IsolationLevel { ReadUncommitted, // Грязное чтение разрешено ReadCommitted, // Видны только коммитенные данные RepeatableRead, // Снимок изолирован от других Serializable, // Полная изоляция}Lock Manager:
- Shared Lock (чтение): несколько читателей
- Exclusive Lock (запись): один автор, никого больше
Conflict Detection:
- Граф конфликтов через DFS
- Обнаружение циклов = deadlock
2.3 Write-Ahead Logging (WAL)
Section titled “2.3 Write-Ahead Logging (WAL)”- Все изменения логируются перед применением
- Гарантирует durability при сбого
- Позволяет восстановление после сбоя
2.4 Индексирование
Section titled “2.4 Индексирование”B-Tree Index
- Сбалансированные деревья поиска
- Эффективен для диапазонных запросов
- Используется для PRIMARY KEY
Hash Index
- Быстрый поиск по точному значению
- Оптимален для JOIN условий
Bloom Filter
- Вероятностная структура данных
- Быстро исключает неправильные значения
2.5 Caching
Section titled “2.5 Caching”LRU Cache
Самые свежие ← → Самые старые↑ ↓Новые данные Удаляются первымиBuffer Pool
- Управление страницами памяти
- Pin/Unpin механизм
- Вытеснение LRU политикой
Query Result Cache
- Кеширование результатов запросов
- Потокобезопасное хранилище
- TTL-based invalidation
3. Distribution & HA Layer
Section titled “3. Distribution & HA Layer”3.1 Raft Consensus
Section titled “3.1 Raft Consensus”Алгоритм для распределённого согласия:
Состояния:
- Follower: слушает leader
- Candidate: претендует на лозунство
- Leader: управляет кластером
Log Replication:
Leader → [Log Entry 1] ✓ → [Log Entry 2] ✓ → [Log Entry 3] ✓ (кворум = большинство)3.2 Sharding
Section titled “3.2 Sharding”Распределение данных по узлам:
Consistent Hashing
Node 1 (0°) ↗ ↖Node 4 Node 2 (120°) ↖ ↗Node 3 (240°)
Key hash → ближайший по часовой узелRange Partitioning
Shard 1: Keys [A-L]Shard 2: Keys [M-Z]Shard 3: Keys [0-9]List Partitioning
Shard 1: Country IN ('US', 'CA')Shard 2: Country IN ('UK', 'FR')Shard 3: Country IN (остальные)3.3 Replication & Failover
Section titled “3.3 Replication & Failover”Node Health Monitoring:
- Проверка heartbeat
- Отслеживание
last_heartbeat - Автоматическое понижение при сбое
Failover Process:
1. Leader не отвечает2. Followers видят timeout3. Кандидат запрашивает голоса4. Большинство голосует5. Новый leader становится active4. Full-Text Search
Section titled “4. Full-Text Search”4.1 Inverted Index
Section titled “4.1 Inverted Index”Обратный индекс от термина к документам:
"database" → [Doc1: [pos 1, 5], Doc2: [pos 3]]"query" → [Doc1: [pos 10], Doc3: [pos 2, 8]]4.2 Tokenizer
Section titled “4.2 Tokenizer”- Приведение к нижнему регистру
- Удаление стоп-слов
- Porter stemmer для нормализации
"Running" → "run""databases" → "databas""the" → REMOVED4.3 BM25 Scoring
Section titled “4.3 BM25 Scoring”Алгоритм релевантности:
Score = Σ IDF(term) * ((k1+1) * TF) / (TF + k1*(1-b+b*length_norm))
где: IDF = log(total_docs / docs_with_term) TF = term frequency in doc k1 = term frequency saturation (1.5) b = length normalization (0.75)5. Monitoring & Observability
Section titled “5. Monitoring & Observability”5.1 Query Metrics
Section titled “5.1 Query Metrics”pub struct QueryMetrics { query_id: String, query_text: String, execution_time_ms: u64, rows_scanned: u64, rows_returned: u64, index_used: Option<String>, full_scan: bool,}5.2 Slow Query Log
Section titled “5.2 Slow Query Log”- Порог срабатывания (ms)
- Скользящее окно истории
- Анализ проблемных запросов
5.3 Health Check
Section titled “5.3 Health Check”CPU Usage: 45%Memory: 1.2 GB / 8 GBConnections: 42/100Cache Hit Ratio: 94.2%Response Time (avg): 12msData Flow
Section titled “Data Flow”Write Operation
Section titled “Write Operation”SQL: INSERT INTO users VALUES (...) ↓Parser → Executor → MVCC Manager ↓Version Chain (add new version) ↓WAL (write entry to log) ↓Replication (send to followers) ↓Commit (mark version as committed)Read Operation
Section titled “Read Operation”SQL: SELECT * FROM users WHERE id > 10 ↓Parser → Executor ↓Index Lookup (if available) ↓MVCC Visibility Check (find right version) ↓WHERE Evaluation ↓Aggregation/Window Functions (if needed) ↓Result Caching ↓Return ResultsQuery Optimization
Section titled “Query Optimization”Raw Query ↓Statistics Collection ↓Selectivity Estimation ↓Predicate Ordering ↓Join Order ↓Index Selection ↓Optimized Execution PlanPerformance Characteristics
Section titled “Performance Characteristics”| Операция | Сложность | Примечания |
|---|---|---|
| SELECT точное значение | O(1) | С индексом Hash |
| SELECT диапазон | O(log n) | С индексом B-Tree |
| JOINс индексом | O(n) | Nested loop + index |
| GROUP BY | O(n log n) | Сортировка |
| Window Function | O(n²) | В худшем случае |
| MVCC Read | O(1) | Быстрая версионная цепь |
Дополнительные детали см. в API Reference