Ответы на вопросы, которые были заданы во время записи Youtube-подкаста e2k community с архитектором СУБД ЛИНТЕР SoQoL Андреем Коротченко. Ссылка на подкаст https://youtu.be/Pqc22AcWtkA.
Фри версия есть? В докере есть решение?
Фри-версия сейчас есть и доступна для всех желающих принять участие в альфа-тестировании. Поддержка докера в планах.
Кто спонсор? Откуда деньги на разработку?
Спонсором разработки сейчас является наша компания – научно-производственное предприятие «Реляционные экспертные системы» (сокращенно РЕЛЭКС). У нас уже есть готовые продукты – ЛИНТЕР БАСТИОН и ЛИНТЕР СТАНДАРТ, которые мы продаем (linter.ru). Кроме этого наша компания оказывает услуги по разработке ПО на заказ (relex.ru). Так что деньги на разработку у нас есть, но, чтобы сделать ее быстрее, мы ищем инвестиции в проект и открыты для предложений.
Есть ли поддержка бекапов инкрементальных, ежедневные бекапы, как реализованы точки отката при авариях?
В основе системы лежит классический WAL, инкрементный checkpointing, поэтому восстановление происходит так же как в любой классической СУБД. Реализован SAVEPOINT для управления откатом из программы.
Инкрементные бэкапы, как и горячее резервирование планируются к реализации в следующем году.
Какие есть изюминки кроме повышенной скорости?
Повышение скорости является одной из преследуемых целей и тем, что можно обнаружить достаточно легко. На самом деле важны все параметры. Вот некоторые детали:
2. Внутренняя многозадачность основана на корутинах
3. Обязательная генерация исполняемого кода для запроса/процедуры:
4. Клиентский протокол изначально асинхронный и конвейерный (pipeline):
5. Оптимизация IO
Какие типы ключей у вас и констрейнов?
Наша СУБД построена исключительно на хранилище типа b-tree. Возможность использования разных типов хранилищ для таблиц и индексов заложено в архитектуру, но пока нет альтернативных реализаций.
Реализованы: Primary key (b-tree), Secondary key (b-tree), Clustered key (b-tree).
Немного о Clustered key, в разных СУБД - это может означать разное. Самый близкий аналог - это `create clustred index` от MS. Отличие заключается только в том, что синтаксически наша конструкция используется при `create table`, а в MS это отдельный оператор, который перестраивает таблицу в новом физическом хранилище.
Foreign key планируется к реализации.
Реализованы виртуальные (вычисляемые) колонки, по которым тоже можно делать индексацию. Реализованы UNIQUE, NOT NULL.
Если будут процессоры на 128 бит или ARM мощные -- то будете снова переписывать код?
ARM не проблема, стоит в очереди, сделаем точно. Куда сложнее было спортироваться под e2k.
Адресация в 64 бит еще не исчерпана, пока что не видно и горизонта исчерпания. Сделают 128 бит адресацию, тогда и спортируемся, принципиальных сложностей пока не видится.
Что дает больший прирост, быстрые харды или CPU или много RAM?
Конечно все в совокупности. Разные задачи чувствительны по разному к определенным ресурсам.
Фри версия есть? В докере есть решение?
Фри-версия сейчас есть и доступна для всех желающих принять участие в альфа-тестировании. Поддержка докера в планах.
Кто спонсор? Откуда деньги на разработку?
Спонсором разработки сейчас является наша компания – научно-производственное предприятие «Реляционные экспертные системы» (сокращенно РЕЛЭКС). У нас уже есть готовые продукты – ЛИНТЕР БАСТИОН и ЛИНТЕР СТАНДАРТ, которые мы продаем (linter.ru). Кроме этого наша компания оказывает услуги по разработке ПО на заказ (relex.ru). Так что деньги на разработку у нас есть, но, чтобы сделать ее быстрее, мы ищем инвестиции в проект и открыты для предложений.
Есть ли поддержка бекапов инкрементальных, ежедневные бекапы, как реализованы точки отката при авариях?
В основе системы лежит классический WAL, инкрементный checkpointing, поэтому восстановление происходит так же как в любой классической СУБД. Реализован SAVEPOINT для управления откатом из программы.
Инкрементные бэкапы, как и горячее резервирование планируются к реализации в следующем году.
Какие есть изюминки кроме повышенной скорости?
Повышение скорости является одной из преследуемых целей и тем, что можно обнаружить достаточно легко. На самом деле важны все параметры. Вот некоторые детали:
- Все сравниваемые типы данных имеют лексикографическое представление. Как следствие:
- все ключи сравниваются через memcmp – быстрее;
- такое представление эффективно для префиксного сжатия – меньше хранить;
- странца b-tree использует префиксное дерево для повышения локальности кэша при поиске на странице – траверс дерева быстрее.
2. Внутренняя многозадачность основана на корутинах
- для стека достаточно 64Кбайт – экономия ресурсов;
- задачи в определенных состояниях не требуют стека (stackless coroutine) – больше параллельных задач;
- примитивы синхронизации и lockfree интегрированы в организацию многозадачности - быстрая архитектура, как для исполнения, так и для разработки;
- 10К (и более) активных соединений реальны и весьма эффективны;
- дешевая поддержка пула (бездействующих) соединений.
3. Обязательная генерация исполняемого кода для запроса/процедуры:
- дата-центричный подход генерации кода дает эффект как для виртуального кода, так и для нативного – быстрее;
- для нагруженных запросов нативный код в среднем в 2 раза быстрее, для коротких нет явного преимущества;
- наличие 2-х видов кода позволяет динамически переключать исполнение с виртуального кода на нативный - адаптивность исполнения, минимизация затрат на трансляцию.
4. Клиентский протокол изначально асинхронный и конвейерный (pipeline):
- более эффективный обмен, формирование любых батчей на клиенте;
- больше возможностей по интеграции в приложения в едином цикле обработки сообщений на основе неблокирующей обработки.
5. Оптимизация IO
- минимизация логируемой информации - меньше диска, быстрее
- undo/MVCC вынесен в отдельное хранилище (и поток) без обеспечения persistency - лучше масштабируемость IO
- различаются явные IO потоки с четкой приоритизацией на основе потребности СУБД, что повышает эффективность использования ресурса IO
Какие типы ключей у вас и констрейнов?
Наша СУБД построена исключительно на хранилище типа b-tree. Возможность использования разных типов хранилищ для таблиц и индексов заложено в архитектуру, но пока нет альтернативных реализаций.
Реализованы: Primary key (b-tree), Secondary key (b-tree), Clustered key (b-tree).
Немного о Clustered key, в разных СУБД - это может означать разное. Самый близкий аналог - это `create clustred index` от MS. Отличие заключается только в том, что синтаксически наша конструкция используется при `create table`, а в MS это отдельный оператор, который перестраивает таблицу в новом физическом хранилище.
Foreign key планируется к реализации.
Реализованы виртуальные (вычисляемые) колонки, по которым тоже можно делать индексацию. Реализованы UNIQUE, NOT NULL.
Если будут процессоры на 128 бит или ARM мощные -- то будете снова переписывать код?
ARM не проблема, стоит в очереди, сделаем точно. Куда сложнее было спортироваться под e2k.
Адресация в 64 бит еще не исчерпана, пока что не видно и горизонта исчерпания. Сделают 128 бит адресацию, тогда и спортируемся, принципиальных сложностей пока не видится.
Что дает больший прирост, быстрые харды или CPU или много RAM?
Конечно все в совокупности. Разные задачи чувствительны по разному к определенным ресурсам.