Comments 9
Добрый день.
Quickstart (~ 60 seconds)
# 1. Download and unpack (Linux x86_64 / aarch64, glibc >= 2.28) # https://github.com/angarabase/angarabase/releases
... но на GitHub нет опубликованных релизов portable версии, когда ожидать?
Или подскажите пожалуйста по какой ссылке еще можно бужет скачать.
Можно поставить из rpm репозитория инструкция прямо на angarabase.dev. На GitHub чуть позже появится.
Движок базы данных - это фундамент любой системы.
Как Вы преодолеваете недоверие клиентов построить фундамент на песчаном грунте?
Тоже с базами данных 30+ лет, и некоторые красные флаги, типа OLTP + OLAP в одной бочке, не могу принять на веру.
Мы и не просим вставать на него прямо сейчас. Мы вышли в открытый доступ на этапе dev preview, чтобы можно было посмотреть и потрогать без обязательств. Предыдущие статьи про архитектуру — ровно для этого: не реклама, а устройство, которое можно разобрать и задать вопросы. Доверие к СУБД зарабатывается только годами эксплуатации — это мы понимаем очень хорошо, и именно поэтому не ждём, что кто-то примет что-либо на веру. Ни архитектурные решения, ни HTAP.
Про OLTP + OLAP — согласны для большинства того, что под этим продаётся: репликация с задержкой под другим именем. Конкретно у нас: аналитические сканы изолированы от OLTP-кэша через отдельный путь чтения, UNDO-модель даёт аналитике консистентный снапшот без давления на версионность.Пока: колоночная материализация ещё не подключена — это v0.7. Сейчас работает изоляция нагрузок и свежие данные без второго хранилища.
Ставьте, тестируйте, сообщайте, где не так.
Было интересно, но читать не стал. Когда люди снова будут текстовую часть полностью писать руками, тогда и почитаю. Основные плюсы и минусы при беглом просмотре не нашел. Как заметил товарищ выше про ядро СУБД ничего не ясно. Основная проблема гибридок в балансе скорости и объеме памяти. Как здесь с этим обстоят дела и на какие максимальные объемы рассчитано ядро?
И вот не надо фантазий на тему "хтап в котором все одинаково быстро работает", такое теоретически невозможно без дублирования структур. Поддержки графов и гиперграфов нет я так понял, т.е. очередной велосипед, когда уже и бугатти и приусы есть. Лучше бы гиперграфовую СУБД сделали, вот честное слово. Не поймите неправильно, не осуждаю, у всех свои цели. Просто пытаюсь понять зачем оно мне, бизнесу и миру.
Не «всё одинаково быстро в одном месте», а конкретный сценарий: высокая OLTP-нагрузка (тысячи транзакций в секунду) и одновременно аналитические запросы — агрегации, отчёты — по тем же свежим данным. Проблема не в том, что это сложно реализовать, а в том, что в классической схеме одно мешает другому: аналитический скан выбивает горячие OLTP-страницы из кэша, OLTP-записи создают мусор, через который аналитика продирается.
Наше решение в том, что аналитические сканы идут через отдельный BufferRing и не конкурируют с OLTP за горячий working set; UNDO-модель даёт то, что скан читает O(живых строк) независимо от интенсивности обновлений. На практике: под конкурентным аналитическим сканом OLTP-throughput у нас проседает меньше чем на 20%. Наша цель — не убрать второй кластер ради красивого слайда, а убрать его потому что он реально не нужен для этого класса нагрузки.
Та же HANA это делает хорошо, но это другой ценовой сегмент: лицензия другого порядка, всё должно влезать в RAM, при рестарте загрузка терабайтной базы занимает часы. Мы целимся туда, где люди держат универсальные СУБД и страдают именно от этой конкуренции.
Если в вопросе про объемы речь про RAM, то In-memory таблицы живут в MVCC overlay напрямую в RAM — buffer pool их не касается, ограничений по объёму нет. Для дисковых таблиц buffer pool сейчас ограничен 32 GiB — это временно, в v0.7 запланирован shared buffer pool, после чего ограничения не будет.
Спасибо что подсветили вопрос про ограничения это тема которая требует отдельного освещения.
Та же HANA это делает хорошо, но это другой ценовой сегмент: лицензия другого порядка, всё должно влезать в RAM, при рестарте загрузка терабайтной базы занимает часы.
У SAP HANA уже давно есть NSE (чтение с диска через буффер-кэш) и "все в память" можно не класть, но "есть нюанс" с производительнстью, да. В плане времени рестарта для кейса рестарта только HANA-истанса есть FRO через tmpfs. А на практике холодный старт 3TB БД, например, проходит за ~20 минут
По существу топика - HTAP тема нужная, вы молодцы, желаю удачи. Другое дело, что "тернист и долог путь в Эдем"
AngaraBase: новая HTAP СУБД