Я тут потихоньку начинаю ПиаРить свой продукт.
http://sourceforge.net/projects/opendsa/
http://www.sql.ru/forum/actualthread.aspx?tid=699842&pg=2#7731994

соответсвенно хочу спросить у сообщества правильно ли я понимаю , и делаю ли я то что будет востребовано.
Заодно потренеруюсь в докописательстве.

И так:

Концептуальные понятия:

1. Транзакции явные и неявные.
Явная транзакция начинается begin work; и заканчивается commit (work).
Неявная транзакция открывается любым dml оператором и автоматически завершается
после его окончания.

2. Уровни изолированности транзакций.
dirty read, versionning, commited read, repeatable read, serializable.
Описание поведения всех уровне изолированности кроме versionning
можно найти в стандарте SQL92.

3. Точка консистентности - запись в логическом журнале opendsa момента начала транзакции(явной или не явной) или выполнения команды set isolation versionning .
Точка консистентности отмечается в логическом журнале явно, в случае если внутри транзакции производится изменение уровня изолированости на versionnning.
Если уровень изолированности установлен в значение versionning до начала транзакции, то точкой консистентности считается начало транзакции.


4. Точка консистентности не может быть сдвинута в процессе транзакции.

5. Консистентный курсор - набор записей значения полей в которых
были подтверждены commit work по состоянию на точку консистентности.

5. Версионный механизм opendsa всегда возвращает консистентный курсор по состоянию на точку консистентности.
Другими словами , все запросы и подзапросы ( в dml операторах в том числе) всегда
возвращяют выборку по состоянию на начало транзакции или точку перехода в версионный режим.

6. Оператор select .... for update на уровне versionning неявно переводит транзакцю на уровень reapetable read на время своего выполнения, со всеми вытекающими
блокировками читателей писателями. Он никогда не возвращаяет консистентный курсор.
Все его вложенные подзапросы также работают на уровне изолированности repeatable read.
Запросы внутри цикла по курсору select ..... for update тоже всегда работают в repeatable read. После завершения запроса или цикла обработки курсора, транзакция продолжает выполняться на уровень изолированности versionning с точкой консистентности на начало транзакции или явного перехода в режим versionning .

Вопросы и замечания по существу приветствуются.

SergSuperа как Вы представляете потребителя своего продукта?

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

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

Круг пользователей этого продукта OLTP приложения и WEB . Это конкурент MySQL.

Лицензия LGPL.

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



ps Еще один повод начать тему - скучно как то стало в ветке "Cравнение СУБД".

что касается одного человека, то один я не буду, я в этом практически уверен.

Команда обязательно соберется.

После стабилизации внутреннего API исходинки появятся в Интернете,
Дорабатывать функционал и писать плагины сможет кто угодно, и соответсвенно зарабатывать на архитектуре opendsa.

Yo.!
1. так версионность как-то работает или это только планы ?


Практически работает. API еще не стабилен поэтому все может поменяться в любую сторону.
Еще есть куча логических ошибок с транзакционной целостностью.
Над которыми я работаю.



Yo.!
2. где/как хранятся версии строк для mvcc ?


Версии строк формируются на лету из логического журнала.
Логический журнал это undo & redo в одном флаконе.

Yo.!
3. версии строк плодятся обсалютно всегда или как в мсскл на уровне БД переключатель (allow_snapshot_isolation on) ?

Версии строк вообще не плодятся, мотор блокировочный.
с.м. в. 2

Yo.!
4. DDL и версионные транзакции как уживаются ?

пока никак.
Интересный вопрос. нужно поработать, спасибо.

Yo.!
5. где/как хранятся блокировки ?

В памяти .

ОКТОГЕНК Yo.! можно добавить ещё вопрос
чем новая база лучше уже существующих открытых аналогов(хотя бы концептуально)?

концептуално:

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

2. Полный асинхронный дисковый ввод вывод, Direct IO.

3. Глобальный пул сортировок для всех сессий в ОЗУ. по исчерпанию пула, сортировки уходят в темп.

4. Партиционирование .

5. Если в TS есть несколько датафайлов мотор неявно делает раундробин
партиционирование.

6 Конвеерная обработка
Одна пользовательская сессия может загрузить все процессора системы и будет пытаться это делать в отсутствие конкуренции от других сессий особенно на партиционированных таблицах.
процессор асинхронного ВВ читает, передеает процессу который фильтрует, тот процессу который сортирует и т.д. Если сессия натыкается на блокировку переключается контекст выполнения на другу сессию.
Если сессия пытается занять блокировку, то она становится в очередь и при освобождении блокировки получает доступ к записи первой и проц на выполнение, пока не наткнется на блокировку или не отдаст управление сама и или по сигналу.
в некоторых случаях сессия пропускает заблокированные записи, и переходит к обработке
следующей в очереди а по освобождении блокировки получает к ней доступ первой без переключения контекста віполнения.

Алгоритм переключения контекста сессий еще тоже достаточно сырой.

softwareropendsa5. Версионный механизм opendsa всегда возвращает консистентный курсор по состоянию на точку консистентности. Другими словами , все запросы и подзапросы ( в dml операторах в том числе) всегда возвращяют выборку по состоянию на начало транзакции или точку перехода в версионный режим.
Иначе говоря, скрипт


запросто вернёт записи с SomeField != 1?


Конечно же он возвращает то, что сам изменил.
и записи останутся заблокироваными до комита.

Я некорректно написал, сказывается недостаток опыта в докописательстве :(

Для других сессий заблокированными.

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

Стоп что то я торможу в пятницу вечером, у вас же нет явной транзакции.

update закомитится автоматически( неявно ).

Точка консистентности переходит на начало select.

Записи на которых стоят блокировки востанавливаются из логического журнала.

Yo.!opendsa
Версии строк формируются на лету из логического журнала.
Логический журнал это undo & redo в одном флаконе.
не понял, что значит на лету ? для каждой строки версионного чтения тратиться пара часов на перелопачивание какого-то журнала и к тому же результат ограничен лишь доступной памятью ?
до кучи - версионность у вас на что накладывается, на строки или страницы данных (блоки)?


opendsa
2. Полный асинхронный дисковый ввод вывод, Direct IO.
при отсутсвии лога транзакций с асихронной записью вы ACID не обеспечите.
современные субд по коммиту пишут в лог транзакций, когда произойдет запись в таблицы не суть важно. у вас же я так понимаю вся зпись идет сразу в датафайлы ?

Сначала отвечу на второй вопрос.
Логический журнал это и есть лог транзакций. Которые позволяет делать как rollback так и rollforward.
Помимо этого есть еще физический журнал , который хранит before image страниц
между контрольными точками.

Теперь по первому вопросу.
Логический журнал , это по сути партиционированная таблица индексированная по полям
id транзакции и точка консистентности.
Еще одна отличительная особенность СУБД , что в таблицах , кроме системного каталога
не хранится null значения полей.
Версионность ни на что не накладывается, (мотор блокировочный),
Строки воссоздаются из оригинальной строки путем локального отката значений конкретной строки с текущего времени , до состояния на точку консистентности.

opendsa


Yo.!
4. DDL и версионные транзакции как уживаются ?

пока никак.
Интересный вопрос. нужно поработать, спасибо.



В выходные проверил , некоторые вещи.

Drop table откатывает версионную транзакцию. Ошибка - отсутствие объекта.

Alter table должен уживаться, но его функционал еще не реализован.
Но он точно будет ждать пока некоторые таблицы системного каталога не будут разблокированы.

Truncate не уживается с ошибкой подозрения в нарушении целостности файлов БД
и остановкой сервера.
И вероятнее всего уживаться не будет в первой версии , но ошибка будет приведена в
логическое соответствие, и транзакция просто откатится.

Еще раз спасибо вопрос. В очень правильное время задан.

ApexавторЕще одна отличительная особенность СУБД , что в таблицах , кроме системного каталога
не хранится null значения полей.
Отличительная от чего?

От всех других моторов СУБД где NULL поля занимают место в строках при хранинии записей на диске.

Dimitry Sibiryakov
opendsa
От всех других моторов СУБД где NULL поля занимают место в строках при
хранинии записей на диске.

О_о
Это у каких таких других движков NULL занимает место на диске?


В Informix например.