> Раз уж пошла такая пьянка, вы бы дали какое обзорное представление, как она сейчас стоит против таких или сяких соседей, и, в какую сторону, хотя бы в короткой перспективе, будет двигаться.

С точки зрения пользователя Сокол - классическая реляционная СУБД. Как и Postgres, Oracle, MySQL, ...
Это дисковая СУБД. Но есть одно маааленькое отличие. Мы построили архитектуру, которая позволяет использовать lock-free алгоритмы. Не фрагментарно, а на всем пути обработки запроса в системе. Lock-free можно встретить в in-memory решениях, которые, как известно, показывают значительно более высокие результаты в обработке данных. Использование этой технологии открывает новые возможности по масштабированию на многоядерном оборудовании.

В дальнейшем мы ориентированы на построение распределенной СУБД с распределенными транзакциями с высокой степенью управляемости. Изначально в архитектуру заложены технологии, применяемые в облачных системах.

> Как вы отличаетесь от Oracle 8.0 или Postgress с такой же маркировкой уже сейчас, и будет ли увеличиваться ваше отличие.

Указание версии `8.0` я с вашего позволения проигнорирую, поскольку не знаю, что под этим в вопросе подразумевалось. Если речь идет о доступной функциональности, то, безусловно, не следует ожидать сразу слишком многого, в указанных решениях
все это создавалось десятилетиями и в один миг все воссоздать не
получится. Безусловно, мы работаем над развитием функционала и запросы на такое развитие в процессе тестирования выпусков (первый - это озвученная альфа) будут нами серьезно рассматриваться в рамках ближайших планируемых работ.

По внутренней архитектуре, если говорить сейчас о каждом отдельном компьютере (по распределенке можно будет поговорить позже, когда вплотную будем работать над соответствующей версией) стоит отметить, что все делается для эффективного использования современных многоядерных систем.
Это, например:

- конкурентная работа, реализованная на lockfree подходах. Так, например,
10К соединений в TPC-C для Сокола не фантастика;

- алгоритмы и структура основного хранилища типа B-Tree оптимизируется
для повышения cache-locality, так что работа одним пользователем
будет тоже заметно быстрее (пока не все сделано);

- если копать детали, то технологических отличий много, описывать их будем по мере возможности. Как примеры: исполняющая система построена на дата-центричной модели, которая может конкурировать с векторными подходами, есть возможность генерации нативного кода для запросов и процедур, обмен между клиентом и сервером может быть построен на основе конвейера (таким образом можно организовывать batch) и многое другое.

Не все технологические отличия можно уже сейчас увидеть в
проявлении. Заложенные архитектурные и технологические возможности
ждут еще своего часа. Так что с развитием система будет еще быстрее
или во всяком случае не медленнее :)

> У вас MVCC какой системы?

MVCC организован на уровне списка версий в кортеже. Ближайшие аналоги: MSSQL, MySQL.

> Кого вы себе конкурентом видите - NuoDB, Altibase, Postgress или еще кого, как вы против них стоять планируете.

NuoDB - это распределенная система, так что пока здесь сравнения преждевременны.

Altibase - предоставляет два варианта хранилищ для таблиц на выбор: disc-based и in-memory.

Сокол - это disc-based хранилище, но во многом конкурирующие с in-memory вариантами по своим свойствам.

Нашу систему тоже можно обозвать гибридной в смысле свойств системы. Принципиальное отличие в том, что нет дополнительных ограничений от in-memory и отрицательных последствий от гибридности тоже нет.


В качестве конкурентов нужно рассматривать прежде всего классические СУБД, и, безусловно, мы намерены наступить на хвост in-memory системам. В перспективе зайдем и в распределенные системы.

Рады интересу к нашей СУБД. Пишите вопросы, будем стараться по мере сил отвечать (хотя все глубоко погружены в разработку, спешат быстрее выпустить бету и релиз) чтобы раскрыть возможности новой СУБД во всей красе. Хотя на отдельные вопросы не так легко ответить просто…

Нет все несколько по другому, для старта по lockfree рекомендую документ
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf

Отдельно по спинлоку.

В нашем проекте использование спинлока, мутекса и прочих блокирующих объектов запрещено. Но запрет условный. Несомненно у нас есть места где использование подобных объектов имеет смысл, выбор всегда должен быть осознанным.

Например, у нас имеется собственный планировщик, подобный тому что можно увидеть в ядре Линукс.
Для перебалансировки нагрузки в двух runqueues захватывается спин, так как обработать 2 очереди проще с блокировкой. Также, вся локальная работа внутри runqueue прикрыта спинлоком. При этом пробуждение задачи по инициативе из конкурирующего runqueue обычно используется асинхронная lockfree очередь.

Таким образом мы получаем простой код, а код шедулера просто обязан быть простым и тупым, его вообще не должно быть видно, так как его повторяемость достаточно высокая. В тоже время у нас практически отсутствует конкуренция на спине здесь.

По поводу CAS.

Мы опираемся на барьеры памяти и атомарные операции из стандарта C11.
CAS это одна из таких операций, если алгоритмически можно использовать другие варианты, то конечно мы предпочитаем их. Впрочем дело не столько в самой атомарной операции. Скорее важно какие алгоритмы контроля доступа к данным применяются, именно изменения основных алгоритмов по обработке данных и есть возможность параллельной работы.

По поводу честного спинлока в userspace и lockfree в том же числе.

Да, несомненно, мы не можем управлять системным планировщиком, все что мы можем со своей стороны сделать, так чтоб не создавать условий провоцирующих системный планировщик действовать "неправильно".

Что это значит для нас?
СУБД Сокол использует количество системных потоков равное количеству ядер в оборудовании. А вся параллельность, примитивы синхронизации, стек lockfree реализованы через кооперативную многозадачность, корутины со стеком и без стека.

День добрый Ролг Хупин,

> Т.е. это типа "росийская ОС!" (линукс), "отечетсвенная СУБД" (PostgreSQL) и т.д. т.е. важно, чтобы были исходные коды, чтобы можно было исправить название на скреповое.

Читайте внимательно!

Сокол это полностью наша разработка, более того это исследовательская разработка с чистого листа, которая сейчас на стадии трансформации в продукт, разработка ведется нашей компанией собственными силами, никакого государственного участия!

Слово "отечественная" (в указанном смысле) здесь вообще ни причем, хотя, да, данная разработка велась на территории нашего Отечества!
Это разработка МОЯ, моих коллег, нашей компании!

Заимствование какого либо кода НЕТ, ну совсем нет, ни одной строчки, разве что буквы общие, пишем на С!
Заимствований нет ни от Postgres, ни даже от нашего действующего продукта ЛИНТЕР (который, кстати, также НЕ имеет отношения к opensource, к сведению).

Ну от Oracle я не могу ничего заимствовать, хотя бы по одной причине, я не видел их кода и не могу увидеть.

PS:
Почему то подобное восприятие на пространстве интернете является нормой, считается что в нашей стране разработка чего либо фундаментального невозможна, могут только прикладные решения пилить и перелицовывать opensource ...

Да это трудно, но возможно!

По поводу терминов "российская", "отечественная".

Давайте определимся сразу.
Сокол не является инструментом политики или инструментом обогащения на политике!
Разработка проекта ведется не по политическим соображениям!

Проект зародился и живет в России.
Прилагательные "российская", "отечественные" применимы к Соколу только в прямом смысле этих слов .

> Попробую еще позадавать вопросов.
> Их вашего описания у меня пока складывается впечатление, что по набору идей, в качестве ближайшей аналогии,
> можно было бы смотреть на Hekaton от Microsoft.

Мы знакомы с научными работами от MS, и с Hekaton.
Сначала мы пытались оттолкнуться с этими идеями, чему то научились, но в итоге сильно разошлись.
У нас нет разных engine, для в памяти и с вытеснением - это принципиальное отличие.
Конечно есть что то общее, если оно использует общие технологии.

> Насколько справедливо такое предположение, и как далеко оно может быть распространено в технических деталях.
> Например, будут ли доступны в триггерах логические таблицы inserted и deleted.

Oracle-like схема тригеров будет, пока ничего нет

> На что похож у вас "язык процедурных расширений sql", каковы его технические особенности.

Oracle-like. Конечно отличия будут, у нас нет цели сделать клон. Отличия всегда будут, хотя бы из-за разной физической модели.

> Если предположить перевод существующей системы, снабженной большим объемом кода в базе, то с какой из существующих систем переход может происходить наиболее беспроблемно.

Как выше говорил Oracle, система тригеров точно будет не от MS.
По конструкциям PL и SQL смотрим примерно в следующих приоритетах:
- Стандарт & Oracle
- PostgreSQL
- MS
- ...


> Да, не совсем по делу.
> В последние лет уже пять или чуть более, почему-то считается, что один из наиболее перспективных исследовательских европейских проектов, обкатывающий сразу набор относительно свежих идей, это Hyper.
Следите ли вы за тем, что там происходит, и может ли происходящее там повлиять на элементы вашей архитектуры.

По делу.
Это один из самых интересных ресурсов для разработчиков, у них там в Мюнхене гнездо субд строительства:
https://hyper-db.de/
https://umbra-db.com/

Некоторые идеи у нас пересекаются, философия и реализация конечна у каждого своя.
Я упоминал уже, датачентричную модель исполнительной системы.
Используем свой виртуальный код вместо IR от llvm, принципы его отличаются, но тоже весьма неплохо работает, на коротких запросах TPC-C уступает нативному порядка 5%.
Из него же генерируем нативный код через llvm.

В umbra-db делают попытку перейти на дисковую СУБД.
Мы движемся с другого края, от дисковой СУБД.
У нас полноценный кэш страниц (lockfree) с самого начала и по нашей постановке задачи.

Решения из umbra-db местами похожи на наши, забавно что к идеи о двойном дереве мы пришли параллельно, правда мы не печатаем статьи. Можно применить некоторые их архитектурные оптимизации.
Здесь стоит вопрос что к месту и ко времени важнее всего. Разрабатывать и оптимизировать можно вечно.

> Начал читать, возник вопрос:
> С чем связано наличие у таких разработчиков, чьи идеи используются во многих известных продуктах (верим на слово) таких грубых ошибок в тексте?

Ошибался в письме всегда, хоть на русском, хоть на английском. Возможно, у меня какое нибудь генетическое отклонение ;). Мне это не мешает жить, до 50 дотянул как то.

Я не претендую на верховенство авторства, абсолютной истины, грамотности, ...
Если есть неприязнь к моему тексту, предлагаю не читать.

> ничего персонального, просто, закрадывается смутное сомнение, что при таком уровне грамотности такой же уровень и этого т.н. "СУБД"

Сомневаться нужно всегда, поддерживаю, особенно когда пытаются выкатить что-то такое прям исключительное.
Любая "крутая" СУБД может показать заурядные результаты на определенном типе нагрузке вполне по объективным причинам. Просто заявления мы в 5-10 раз быстрее не относятся глобально к любому типу нагрузки.

И любая СУБД это компромисс, у каждой свои сильные и слабые стороны.
Выбирать пользователю.