ЧАСТЫЕ ВОПРОСЫ
О VELODB

VeloDB управляет конкурентностью через Workload Management: три независимых механизма изоляции, мягкие и жёсткие лимиты, автоматические очереди и circuit breaker.

Стабильность под нагрузкой — это не «магия движка», а управляемая архитектура. Workload Group делит CPU/Memory/IO внутри BE-процесса через cgroups с soft и hard лимитами. Resource Group изолирует BE-ноды на уровне железа. Circuit Breaker автоматически отменяет запросы, превышающие лимиты по памяти или времени выполнения — прежде чем они могут повлиять на кластер. Аналог «падения Greenplum» при массовом входе пользователей воспроизводится только при отсутствии политики WLM — в VeloDB эта политика настраивается явно.

В зависимости от сценария — от конкурентного до 60× быстрее. Ключевое преимущество в трёх классах одновременно: MPP аналитика, lakehouse-запросы, полнотекстовый и векторный поиск.

vs ClickHouse: на широких таблицах с одним JOIN — паритет в ClickBench; на TPC-DS с распределёнными JOIN — до 60× быстрее за счёт собственного cost-based оптимизатора. Real-time обновления: 34× быстрее (Delete Bitmap vs асинхронные мерджи ClickHouse). vs Trino/Presto: TPC-DS 1 ТБ — 3× быстрее благодаря нативному движку на C++ с векторизацией. vs Elasticsearch: скорость записи — 3× выше; хранение (те же логи) — 3–5× меньше места. Все цифры из независимых или воспроизводимых бенчмарков со ссылками.

VeloDB реализует гибридный поиск (BM25 + вектор + RRF) в одном движке с поддержкой ICU-анализаторов для любого языка. Политика идентификации MDM остаётся за процессом и каталогом — движок обеспечивает скорость поиска и хранения.

Для каждого языка настраивается свой анализатор: ICU tokenizer для мультиязычного текста (казахский, русский, английский, арабский), Chinese/IK tokenizer для восточных языков, кастомные pipelines из character filters + tokenizers + token filters. Функция TOKENIZE() позволяет проверить сегментацию текста до создания индекса — без угадывания. Гибридный поиск: BM25 (полнотекст) + ANN (вектор) запускаются параллельно, результаты объединяются через Reciprocal Rank Fusion (RRF) — всё в одном SQL-запросе без внешнего оркестратора. Честно: semantic matching между языками зависит от выбора multilingual embedding модели, а не движка. VeloDB хранит и ищет — логика «одно имя сущности на всех рынках» остаётся в MDM-процессе и политике каталога.

Да. Distributed JOIN с broadcast/shuffle стратегиями и partition colocate позволяет строить 3NF, Anchor и Data Vault без ограничений ClickHouse по числу таблиц. Для deep join graphs рекомендуются Materialized Views.

VeloDB поддерживает произвольные схемы: star, snowflake, 3NF, Anchor modeling, Data Vault. Оптимизатор сам выбирает между broadcast join (малые таблицы) и shuffle join (большие), учитывая статистику и карты разделов. Partition colocate размещает связанные данные на одних нодах, минимизируя сетевой трафик при JOIN. На глубоких графах (Anchor с 10+ hub/link/satellite таблицами) рекомендуется добавить Materialized View на финальную витрину — это стандартная практика, а не ограничение движка: любой MPP потребует агрегации на последнем слое.

ClickHouse силён на широких денормализованных таблицах. Для CDC с UPDATE/DELETE, распределённых JOIN на star/snowflake схемах и реальных конкурентных запросов — VeloDB архитектурно превосходит.

Главная проблема ClickHouse при CDC: мутации (DELETE + INSERT) реализованы асинхронно через merge, что вызывает временные несоответствия данных при высокой частоте обновлений. VeloDB использует Delete Bitmap — синхронная отметка удаления без merge storm, в 34× быстрее на realtimeupdate бенчмарке. На джойнах: ClickHouse оптимизирован для single-table scan; TPC-DS с distributed JOIN (star schema, 15+ таблиц) — VeloDB cost-based optimizer показывает до 60× лучше. При этом на single wide-table analytics результаты паритетны — ClickBench это подтверждает.

Greenplum деградирует из-за архитектурного bottleneck coordinator-ноды и отсутствия встроенного WLM. VeloDB решает это тремя независимыми слоями изоляции с явными лимитами.

Greenplum coordinator принимает все запросы и строит планы — при 50+ конкурентных аналитических запросах он становится узким местом. Без жёстких лимитов один heavy-query блокирует остальных. В VeloDB: Workload Group задаёт CPU%/Memory/IO с soft и hard лимитами на уровне BE-процесса через cgroups. Resource Group изолирует BE-ноды физически. Circuit Breaker отменяет запросы, превышающие лимит памяти или тайм-аут, прежде чем они деградируют кластер. Важно: это не «магия движка» — это явная политика WLM, которую нужно настроить под ваш workload profile.

Trino — federated query engine без собственного storage, оптимизирован для ad-hoc запросов к разным источникам. VeloDB — unified engine с нативным хранилищем и MPP, в 3× быстрее на TPC-DS 1 ТБ.

Trino/Presto не хранит данные — каждый запрос идёт к source system (Hive, S3, JDBC), что создаёт overhead на metadata lookup и data transfer. VeloDB нативно хранит данные в ORC/Parquet-совместимом формате с vectorized execution engine на C++. На TPC-DS 1 ТБ (lakehouse сценарий) VeloDB показывает 3× лучше Trino за счёт: Push-down predicates к storage, native columnar vectorization, materialized views с Auto Query Rewrite. Если цель — federated queries через несколько legacy систем без ETL, Trino имеет смысл. Если данные можно консолидировать — VeloDB даёт существенно лучшую latency и throughput.

Elasticsearch оптимизирован для log analytics и inverted-index поиска без SQL. VeloDB даёт SQL + BM25 + вектор в одном движке с 3× скоростью записи и 3–5× экономией хранилища.

Типичные боли Elasticsearch при аналитических сценариях: нет нативного SQL (Kibana DSL или EQL — не то же самое), тяжёлые aggregations деградируют при высоком ingest rate, merge storms при частых обновлениях. VeloDB покрывает тот же full-text search через BM25 с ICU/custom analyzers, добавляет к нему vector search (ANN) и гибридный RRF — всё в одном SQL-запросе. На write benchmark (тот же объём логов): VeloDB пишет в 3× быстрее, хранит в 3–5× меньше места за счёт columnar compression. Если у вас смешанный сценарий (FTS + аналитика + MDM), VeloDB устраняет необходимость в отдельном ES-кластере.

Разбираем ваш текущий стек: источники данных, CDC, хранилище (S3/Parquet), Data Catalog. Находим узкие места и определяем кейс для пилота.

Привлекаем инженеров VeloDB с опытом production-внедрений в аналогичных сценариях — MDM, multilingual search, real-time analytics на больших объёмах.

MDM с мультиязычным поиском, real-time аналитика, lakehouse на S3/Iceberg, конкурентные запросы — берём ваш конкретный кейс, а не синтетический benchmark.

Замеряем latency, throughput, потребление ресурсов до и после. Вы получаете сравнение на реальных данных с конкретными числами для внутренней защиты решения.