Всем привет.

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

Что нужно для того чтобы начать IHMO.

1. Какова должна быть совместимось нового продукта с промышленным
Infomix DS. От какой версии отталкиваться.

2. Какие спецификации, докуметацию можно использовать для
reverse engenering. Чтобы не вступать в конфликт с IBM.
Интересует пока неофицильное мнение официальны лиц.
Может официальное и непонадобтся.

3.Язык программирования и основная платформа разработки
(я предлагаю С++&Linux).

4. Сайт проекта, CVS или любой другой синхронизатор версий.

5. Лицензирование.

Что могу предложить от себя(направления деятельности).
1. Разработка системы резидентной и виртуальной памяти и его API.
2. Работы с дисковой подсистемой(AIO),
структура дискового хранения и API.
3. Пул сетевых соединений NETTYPE (API).

Что еще нужно будет на первых этапах
1. Парсинг SQL запросов. Выполнение.
2. Директивный и Cost оптимизатор.
3. Системный каталог(sysmaster).
4. Журнализация
5. SPL.

За что не стоит браться до выхода 1 версии IHMO.
Но иметь ввиду на будующее.
1.Mултипроцессорность и мультирезидентность.
2.Ограничиться одним типом сетевых соединений(onsoctcp например).
3. PDQPRIORITY
4. Стратегия архивирования.
5. KAIO.

Приветствуются любые дополнения и изменения.

Добро пожаловать в команду OPENDSA.

vybegalloА в чем, собственно, суть проекта ? Какой уровень совместимости предполагается ? И структуры данных на диске, и протокол обмена с приложениями являются собственностью IBM - где там место для Open source ?

Я собственно это и хотел выяснить для начала.


onstat
2. Какие спецификации, докуметацию можно использовать для
reverse engenering. Чтобы не вступать в конфликт с IBM.
Интересует пока неофицильное мнение официальны лиц.
Может официальное и непонадобтся.



Кстате насколько закрыта спецификация сетевого обмена?

Никто не говорит, что нужно пользоваться готовым кодом.
Даже имена и сигнатуры API будут отличаться.
И описатели на диске тоже.

Я хотел бы получить внешнюю совместимость с Informix DS
При архитектуре похожей на Informix DSA.

В.К.

Правда, чем, кроме архитектуры, мы тогда будем принципиально лучше MySQL, например? (А тут еще появился PostgreSQL --> EnterpriseDB - http://www.enterprisedb.com). Об этом надо думать.


Все приведенные в примере базы есть
версионники или очень к этому стремятся.

Есть предложение выйти на рынок с чисто блокировочной OLTP базой
расчитаной на большое количество одновременных
пользовательских соединений.
В этом направлении позиционировать работу проекта и оптимизацию.

В.К.
onstat-
3.Язык программирования и основная платформа разработки
(я предлагаю С++&Linux).

С и *nix по выбору (вот для *BSD, например, не хватает достойных СУБД). Кроме того, не забывать про Solaris 10 (а то IBM на него явно не будет торопиться)


Я всетаки хотелбы настоять на С++.
Основополагающий принцип языка "Обьявление - есть инициализация"
со всеми вытекающими дисциплинирует проект.

Еще момент, переопределение в пространстве имен проекта
глабальных орераторов new & delete облегчит работу по реализации
использованию shared memory, все подчиненные VP нити(субпроцессы)
не должны запрашивать память у OC.
Также для первой версии можно поробовать использовать
алгоритмы библиотеки STL.
А если по каким либо причинам они не устроят написать
свои библиотеки.


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


В.К.

onstat-
1. Парсинг SQL запросов. Выполнение.
2. Директивный и Cost оптимизатор.
3. Системный каталог(sysmaster).
4. Журнализация
5. SPL.


Да уж, есть чем заняться (еще предлагаю вместо dbaccess делать сразу аналог Oracle SQL*Plus или db2 command line. Вот этим, наряду с разбором SQL и SPL я бы мог, наверное, заняться).


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

В.К.
Хотя, весь фокус как раз в том, чтобы DSA повторить - реализовать свою невытесняющую многозадачность на своих потоках на основе далеко не полной информации о функционировании Informix...


Основные модули ядра со связями
я поробую нарисовать. Вопрос времени.
И выложить на для обсуждения общественности.

Пока не будет четкого понимания, что и как с чем общается
кодить не имеет смысла.

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


В.К.
onstat-
За что не стоит браться до выхода 1 версии IHMO.
Но иметь ввиду на будующее.
1.Mултипроцессорность и мультирезидентность.
...
4. Стратегия архивирования.
5. KAIO.


Есть замечания:

1. Систему управления своими потоками и VP надо сразу писать так, чтобы она могла работать на нескольких процессорах.


Это очень задержит выход первой версии.
Я думал VP API откатать на AIO VP,
а паралельную обработку запросов включить потом.

В.К.
4. Возможность архивировать по ходу изменений (в On-Line) надо сразу учитывать.


Обязательно нужно,
самый простой вариант oraclовый
alter tablespace begin backup;
а дальше журналами.
Других идей у меня пока нет.

В.К.
5. Сразу надо учитывать возможность KAIO при программировании ядра.

Рано еще, по тем-же причинам что п.1.

В.К.
Это пока так, эмоциональные комментарии. Главное - чтобы IBM в результате не бросила заниматься IDS и обратила таки внимание на то, насколько серьезно к этой СУБД относятся в наших краях.


Система у которой нет реакции на раздажители - мертвая система ;)
Ми и послужим подобного рода раздражителем.
И посмотрим на реакцию.

nkulikovБудучи сотрудником IBM интересно наблюдать за вашими мыслями.
По поводу выбора языка. Informix и DB2 на 80% написаны на C, основная причина переносимость кода.


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

Правда спецификации тоже не помешали бы. :)

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

Как на счет переноса DSA в DB2?

В.К. nkulikovБудучи сотрудником IBM интересно наблюдать за вашими мыслями.
По поводу выбора языка. Informix и DB2 на 80% написаны на C, основная причина переносимость кода.

Про выбор языка С: Именно из-за потенциальной переносимости, а также использования C во всех успешных проектах такого масштаба, я его и предложил. Двухсвязные списки, хеш-таблицы и какой-то механизм управления памятью на C, пожалуй, даже такой "программист", как я, мог бы написать... А зачем еще в таком проекте C++?



Переносимость зависит от 2 вещей
1. Компилятор ( g++(gcc) есть для всех платформ которые мы затрагивали).
и он уже переносим. О портировании на Windows мы пока не говорим.

2. Отличия в поведении системных вызовов.

Второй пункт от языка не зависит.

И еще, можно писать разные модули хоть на C
хоть на С++, а собирать компилятором и линкером C++.

В.К.
Про KAIO (IMHO): самого механизма реализации на уровне ядра ОС не знаю, но на уровне Informix это просто другой алгоритм работы потока Informix (не в очередь ждущих он отправляется, где его поток AIO найдет, а в очередь спящих, где его будет ADM VP периодически будить...).


Можно будет попробовать, но что -то одно AIO VP или KAIO.
см. коментарий ниже

В.К.
Насчет ontape: это ж наше все! У сервера должен быть сразу предусмотрен режим сохранения предварительных образов страниц из физического журнала во временных таблицах по ходу архивирования, и все. Зачем нам повторять ошибки Oracle? Чтобы продукт имел успех, он должен с минимальными изменениями заменять Informix.


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

В.К.
Кстати, не вижу формальных проблем в том, чтобы и структуру страницы данных, например, повторить, и структуру индексов. В версии 7.xx там все просто и понятно :) Короче, если проект станет для IBM Informix тем, чем стала Samba для Microsoft Network-а , - это будет отлично.

Это все пока по-прежнему - эмоциональная реакция...

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


А теперь общий коментарий.
Есть два момента.
1.Ресурсный.
2. Мотивационный.
Все они завязаны на выход первой версии продукта.
На этапе разработки первой версии в проекте будет участвовать
мало людей, соответственно тяжело будет реализовать все.
После выхода первой версии, проект будет уже не просто словами а
делом и к проекту могут присоединиться
большое количество людей силами которых скилет архитектуры
можно будет наращивать фукционалом.
А также появятся отзывы об эксплуатации.
Если же пытыться повторять весь функцонал, как он есть, сразу
1 версия не выйдет никогда.

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

В.К

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



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

О чем нужно подумать во время чтения и осмысления. IHMO

1. Основные(элементарные) типы данных которыми будет оперировать ядро.
На вскидку:
Целые числа.
Числа с плавающей точкой.
Стороковые.
дата и время.
Стек.
Очереди.

Подумать о их допустимых диапазонах значений и размерах
и количестве элементов(для структур) по умолчанию.
И необходимости их параметризации или автоматического
изменения размера при необходимости.


2. Подготовить для согласования общественностью классы виртуальных процессоров и их обязаности.

3. Оценить ISAM ошибки Informix DS и переосмыслить
стратегию их переноса в ядро,
с учетом приблизительного(пока) места их обработки внутри ядра.


Для начала, на первые несколько недель думаю достаточно,
с учетом факультативности проекта.

Изменения и дополнения приветствуются.
добро пожаловать в команду OpenDSA

з.ы. Я пошел читать первоисточники.

Чемберлен a.k.a В.К

Остальные типы данных - служебные, просто используются ядром.



Эти служебные типы данных и должны представлять собой базу
для виртуальной машины, чтобы уйти от OS зависимости VP.
И десятикратного переписывания одинаковой логики.

В любом случае виртуальные процессоры будут
оперировать указателями на эти структуры и стандартизовать
их и функции обработчики лучше сразу
(По ходу можно вносить изменения).

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

В документации есть ссылка на внутренние регистры в блоке TCB.
Интересно каков их логический смысл?.


Чемберлен a.k.a В.К


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

Ошибка выявляется виртуальным процессором, он пишет сообщение и вызывает обработчик (внешний, скрипт) с передачей ему кучи информации.


Я хотел бы расширить понятие ISAM ошибки.
Это не обязательно ошибка, это ситуация, например:

При вставке записей заканчиваются все страницы в экстенте,
возникает ошибка ISAM, которую сервер(VP или нить) может
обработать самостоятельно, выделить следующий экстент таблице
вызвав соответствующий обработчик,
а потом вернуться к вставке.

То есть к ISAM ошибкам можно отнести все ситуации,
требующие дополнительной обработки с усыпанием текущей сессии .

Мне кажется что реально мы видим очень малую часть этих ошибок.
Там есть над чем работать.

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


Чемберлен a.k.a В.К
ADM - таймер ("тикнуть", обработать очередь спящих, заснуть)


Приблизительное API, которое может тикать, с точностью до микросекунды,
а может быть и не только тикать, а и оперировать datetime типом данных.
(взял из своего проекта).

Напильником конечно придется еще потрудиться:).
Время берется у ОС, как быть с параметром USEOSTIME=0 пока не знаю.