Я тут потихоньку начинаю ПиаРить свой продукт.
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 например.

Yo.!

opendsa
Строки воссоздаются из оригинальной строки путем локального отката значений конкретной строки с текущего времени , до состояния на точку консистентности.
тогда для чтения каждой строки нуна перелопатить весь лог транзакций, имено поэтому в оракле разделены REDO и UNDO логи. слабо представляю в какой задачи будет оправдано использование версионности opendsa.


Нет , теоретически это должно занять ровно столько же времени как и индексный поиск по любой другой таблице, + чуть чуть нагрузки на CPU.
Тесты на производительность еще рано делать.
Соответственно рано говорить о производительности ( с чем то сравнивать).

Yo.!

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

Если это alter table то думаю что проблем не будет,
Изменение структуры ( записей таблиц системного каталога)
также регистрируется в логическом журнале.
просто операция займет еще чуть больше CPU.

Если удаление- создание , то это уже другая таблица , хоть и с тем же именем.

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

Поэтому и select ..... for update ведет себя именно так как описано в первом сообщении.
И по другому вести себя не будет никогда.
Это соответствует моему пониманию логической целостности всех данных сервера
на любой момент времени.

ОКТОГЕНopendsa, ещё вопрос.
А что будет с версиями при длительных транзакциях?
Как будет реагировать система на висячие транзакции?


Также как в оракле ORA-15555 или в информиксе диннная транзакция.
Откат начинается принудительно. По исключению не ловится.

Разработчик плагина может конечно перехватить исключение, но целостность данных сервера в 99.9 % будет нарушена.

Yo.!


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

Именно над этим вопросом я работую последние ~3 месяца.
Некоторые Таблицы системного каталога имеют псевдоверсионность
глубиной в 255 изменений, Каждая строка имеет ссылку на свою текущую версию.
Думаю все будет ОК , придет время , и если хватит у меня мотивации - вы все увидите.

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

vadiminfoopendsa
Думаю все будет ОК , придет время , и если хватит у меня мотивации - вы все увидите.

Что мы можем такого увидеть? Самопальную РСУБД? Ить мы давно уже насмотрелись на много разных, в том числе и лидирующих СУБД.
Если у вас стока энгергии чтобы на такие сложные продукты замахиваться, то может луче найти другие цели? Поновее и поперспективнее? Ить сегодняшние лидеры в производстьве СУБД именно так и начинали, када идеи РСУБД еще тока появлялись.
Тут был парень с Селебрумом. Он пытался свое детище и СУБЗ назвать, и СУБД но с егойной новой МД. Т.е. чувствоал шо новое нуно, где нет еще развитых продуктов. Но само "новое" не проканалывало как новое, и тем более стоящее новое (у него это было скорее старое но с ошибкИми, и потому казалось новым для него). Но все же. А Вы просто РСУБД без всяких там попыток инноваций.

Все начиналось когда IBM купил infromix, я до сих пор люблю эту СУБД.
Потом я перескочил на Oracle. Охренел от его понимания целостности данных
в терминах его консистентности.

Что их этого получится - время покажет.
Пока это только гимнастика для мозгов и я никуда не спешу.

Хотелось бы что бы проект мне обеспечил мне безбедную старость, но до старости еще далеко.

NextManDimitry Sibiryakov
opendsa
Некоторые Таблицы системного каталога имеют псевдоверсионность глубиной
в 255 изменений, Каждая строка имеет ссылку на свою текущую версию.

Что-то мне это до боли напоминает...



Дайте ссылку плс

vadiminfo

Так и я о том же. Есть риски, что проект не подходит для обеспечения безбедной старости, поскоку от РСУБД уже почти все взяли для обспечения безбедной страсти другие, кто начинал 30 лет назад. Не говоря о том, что есть риски появления чего-то нового, что отменит все подобные проеты в принципе: чисто по времени.

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

Это мое хобби.

Это офтопик,
по существу есть что спросить - сказать ?

ОКТОГЕНopendsa,в любом случае, пороха вы скорее всего не изобретёте. Я бы посоветовал поразбираться с ораклом и сделать что-то подобное, но
легче в использовании.
Внутренности движка эти ребята вылизали до блеска, а вот лёгкость хромает,
и вряд ли когда будет приведено в норму(слишком дофига понаписано).
Это мои субъективные ощущения, но если они доведут до ума юзабельность,
то многим конкурентам придётся идти пить пиво.

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

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

А в остальном попробую.

ЗЫ Спасибо за поддержку.

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

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

Неуд. Oracle не хранит NULL-значения в конце строки

Та мне побарабану, кто где хранит или не хранит.

У меня не хранит нигде кроме системного каталога.

ОКТОГЕНopendsa, а не надо делать "как у них", вы просто оттуда хорошие идеи возьмите, какие сможете.
Кстати, ограничение на 255 изменений это, ИМХО, не плюс. Это лишняя головная боль пользователям такой СУБД, ежели, к примеру, накладываются патчи на боевую базу, и тут раз - облом. Останавливать сервак, перезаливать дамп? Очень плохо.


Нут ту все предусмотрено ( в планах пока), если есть доступ к старым версиям строк
или при сборе статистики на таблицу ( с СВО конь еще не валялся) , то они полностью переконвертятся в последнюю версию. Если конечно значения ковертабельны.

Если при alter table перескочит значение 255 , то операция повиснет пока все старые версии
не конвертнет.
Там могут быть проблемы с длинными транзакциями, но я над этим еще думаю.

2 Gluk (Kazan) Правильнее сказать хранит, но место не занимает, хранит в битмапе строки
1 бит на одно поле.

Gluk (Kazan)

пабарабану, так и не треплись, об чем не знаешь

Та я про оракл в этом контексте ни слова не сказал.

Я говорил про Informix.

Yo.!
боюсь, что дальше нам останется лишь охреневать от идеи перелопачивать транзакционный лог для версионности...

Я никому ничего не навязываю.

Еще раз спасибо за правильные вопросы.

ОКТОГЕНПричём, читающие транзакции наверняка можно исключить из лога.

Если транзакция объявлена явно, то так и есть.
Только в начале транзакции или в месте перехода.

Если не явно , то каждый последующий оператор ставит точку консистентности на свое начало
даже читающие.