Делимся последними новостями о СУБД SoQoL

Ответы на вопросы подкаста e2k community

Ответы на вопросы подкаста e2k community Ответы на вопросы, которые были заданы во время записи Youtube-подкаста e2k community с архитектором СУБД ЛИНТЕР SoQoL Андреем Коротченко. Ссылка на подкаст https://youtu.be/Pqc22AcWtkA.

Фри версия есть? В докере есть решение?
Фри-версия сейчас есть и доступна для всех желающих принять участие в альфа-тестировании. Поддержка докера в планах.

Кто спонсор? Откуда деньги на разработку?
Спонсором разработки сейчас является наша компания – научно-производственное предприятие «Реляционные экспертные системы» (сокращенно РЕЛЭКС). У нас уже есть готовые продукты – ЛИНТЕР БАСТИОН и ЛИНТЕР СТАНДАРТ, которые мы продаем (linter.ru). Кроме этого наша компания оказывает услуги по разработке ПО на заказ (relex.ru). Так что деньги на разработку у нас есть, но, чтобы сделать ее быстрее, мы ищем инвестиции в проект и открыты для предложений.

Есть ли поддержка бекапов инкрементальных, ежедневные бекапы, как реализованы точки отката при авариях?
В основе системы лежит классический WAL, инкрементный checkpointing, поэтому восстановление происходит так же как в любой классической СУБД. Реализован SAVEPOINT для управления откатом из программы.

Инкрементные бэкапы, как и горячее резервирование планируются к реализации в следующем году.

Какие есть изюминки кроме повышенной скорости?
Повышение скорости является одной из преследуемых целей и тем, что можно обнаружить достаточно легко. На самом деле важны все параметры. Вот некоторые детали:

  1. Все сравниваемые типы данных имеют лексикографическое представление. Как следствие:
  •  все ключи сравниваются через 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?
Конечно все в совокупности. Разные задачи чувствительны по разному к определенным ресурсам.