Создание SQL-сервера
Есть идейка собрать (небольшую) группу программистов для разработки собственного SQL-сервера. Приглашаются опытные программисты на С++ (MS Visual), желательно со знанием SQL.
Наработки уже есть.
Возможно, проект будет коммерческим - недорогая альтернатива с неплохим соотношением цена/качество. Хотя это зависит от нас, программистов :)
На данном этапе проект находится в реализации.
1) Организовано универсальное хранилище данных (в одном файле), которое, скорее всего, и будет представлять собой базу данных. Реализовано выделение памяти, уничтожение объекта хранилища. Поддерживается объем до 2^63 байт (64-битная адресация внутри хранилища). Работает по принципу отображения файла на память страницами.
2) Создана универсальная индексируемая коллекция с динамическим составом полей и индексов, способная храниться в вышеуказанном хранилище данных. Скорее всего, таблицы будут представлены именно такой коллекцией.
3) В процессе реализации - система интерпретации и исполнения запросов.
Примечания: первое время СУБД будет одноклиентской, т. к. на первом этапе будет писаться и отлаживаться непосредственно работа с данными и немного система запросов. Система блокировок, работа с многими клиентами, работа с сетевыми пакетами - будет позже.
Оптимизация запросов также будет реализована позже.
Пока будет непроцедурный, простой SQL.
Кто заинтересовался, оставляйте сообщения. Подробности, скорее всего, при личном контакте.
Наработки уже есть.
Возможно, проект будет коммерческим - недорогая альтернатива с неплохим соотношением цена/качество. Хотя это зависит от нас, программистов :)
На данном этапе проект находится в реализации.
1) Организовано универсальное хранилище данных (в одном файле), которое, скорее всего, и будет представлять собой базу данных. Реализовано выделение памяти, уничтожение объекта хранилища. Поддерживается объем до 2^63 байт (64-битная адресация внутри хранилища). Работает по принципу отображения файла на память страницами.
2) Создана универсальная индексируемая коллекция с динамическим составом полей и индексов, способная храниться в вышеуказанном хранилище данных. Скорее всего, таблицы будут представлены именно такой коллекцией.
3) В процессе реализации - система интерпретации и исполнения запросов.
Примечания: первое время СУБД будет одноклиентской, т. к. на первом этапе будет писаться и отлаживаться непосредственно работа с данными и немного система запросов. Система блокировок, работа с многими клиентами, работа с сетевыми пакетами - будет позже.
Оптимизация запросов также будет реализована позже.
Пока будет непроцедурный, простой SQL.
Кто заинтересовался, оставляйте сообщения. Подробности, скорее всего, при личном контакте.
SQLIte?
[QUOTE=Freeman]SQLIte?[/QUOTE]
Ну, "переписывать" ниоткуда я не собираюсь. Это будет работа "с нуля". Пусть не продадим, хотя бы ради интереса :)
К тому же, если все получится, есть вторая идея - реализовать на ее основе систему автоматизации предприятий типа 1С, составив ей конкуренцию. Поскольку опыт автоматизации у меня достаточно неплохой.
Ну, "переписывать" ниоткуда я не собираюсь. Это будет работа "с нуля". Пусть не продадим, хотя бы ради интереса :)
К тому же, если все получится, есть вторая идея - реализовать на ее основе систему автоматизации предприятий типа 1С, составив ей конкуренцию. Поскольку опыт автоматизации у меня достаточно неплохой.
[QUOTE=cheburator]Есть идейка собрать (небольшую) группу программистов для разработки собственного SQL-сервера.
[/QUOTE]
P. S.
Если у кого есть соображения, можно постить сюда, если не жалко :)
К примеру, такой вопрос: в MS SQL Server есть понятие Clustered Index. Что бы это значило? Это дает какие-то преимущества?
Вопрос второй. Почему некоторые СУБД хранят данные в нескольких файлах, т. е. как только файл переваливает за некоторый лимит, создается второй файл, и т. д. В чем плюсы? Дело в организации файловой системы? Я вот например предполагаю хранить все в 1 файле.
[/QUOTE]
P. S.
Если у кого есть соображения, можно постить сюда, если не жалко :)
К примеру, такой вопрос: в MS SQL Server есть понятие Clustered Index. Что бы это значило? Это дает какие-то преимущества?
Вопрос второй. Почему некоторые СУБД хранят данные в нескольких файлах, т. е. как только файл переваливает за некоторый лимит, создается второй файл, и т. д. В чем плюсы? Дело в организации файловой системы? Я вот например предполагаю хранить все в 1 файле.
[QUOTE=cheburator]Почему некоторые СУБД хранят данные в нескольких файлах, т. е. как только файл переваливает за некоторый лимит, создается второй файл, и т. д. В чем плюсы? Дело в организации файловой системы? Я вот например предполагаю хранить все в 1 файле.[/QUOTE]
Файлы могут храниться на разных устройствах SCSI, например. При правильной организации хранения запросы на чтение, скажем, блоков индексов и блоков таблиц будут выполняться параллельно.
Некоторые СУБД позволяют вообще обходиться без файловой системы. Внутренняя структура контейнера СУБД лепится непосредственно в RAW-раздел, управляемый СУБД.
Файлы могут храниться на разных устройствах SCSI, например. При правильной организации хранения запросы на чтение, скажем, блоков индексов и блоков таблиц будут выполняться параллельно.
Некоторые СУБД позволяют вообще обходиться без файловой системы. Внутренняя структура контейнера СУБД лепится непосредственно в RAW-раздел, управляемый СУБД.
[QUOTE=cheburator]Примечания: первое время СУБД будет одноклиентской, т. к. на первом этапе будет писаться и отлаживаться непосредственно работа с данными и немного система запросов. Система блокировок, работа с многими клиентами, работа с сетевыми пакетами - будет позже.[/QUOTE]
Скажу по секрету, как проектировщик проектировщику - изначально однопользовательскую СУБД невозможно переделать в полноценную многопользовательскую - это равносильно полному переписыванию ядра.
Для многопользовательской работы, кстати, необязательно связываться с сетью - достаточно подключить несколько пользователей в разных сеансах (окнах), или запустить несколько программ, работающих с одной базой.
Скажу по секрету, как проектировщик проектировщику - изначально однопользовательскую СУБД невозможно переделать в полноценную многопользовательскую - это равносильно полному переписыванию ядра.
Для многопользовательской работы, кстати, необязательно связываться с сетью - достаточно подключить несколько пользователей в разных сеансах (окнах), или запустить несколько программ, работающих с одной базой.
[QUOTE=Freeman]Скажу по секрету, как проектировщик проектировщику - изначально однопользовательскую СУБД невозможно переделать в полноценную многопользовательскую - это равносильно полному переписыванию ядра.
[/QUOTE]
Не согласен. Хотя смотря что понимать под ядром. Если ядро - система исполнения запросов, дык я и так ее собираюсь [почти] полностью переписать при переходе на многопользование.
А система хранения данных и доступа к ним останется как была.
[/QUOTE]
Не согласен. Хотя смотря что понимать под ядром. Если ядро - система исполнения запросов, дык я и так ее собираюсь [почти] полностью переписать при переходе на многопользование.
А система хранения данных и доступа к ним останется как была.
[QUOTE=Freeman]
Внутренняя структура контейнера СУБД лепится непосредственно в RAW-раздел, управляемый СУБД.
[/QUOTE]
Неплохая идея. Но отображение на память вряд ли будет работать :( придется изобретать какой-то аналог
Внутренняя структура контейнера СУБД лепится непосредственно в RAW-раздел, управляемый СУБД.
[/QUOTE]
Неплохая идея. Но отображение на память вряд ли будет работать :( придется изобретать какой-то аналог
[QUOTE=cheburator]А система хранения данных и доступа к ним останется как была.[/QUOTE]
Блокировки и параллелизм - неотъемлемая часть подисистемы хранения.
Вообще, не представляю, как можно создать однопользовательскую СУБД, даже если реализовывать только базовые стандарты. Транзакции у тебя будут? Если будут - до полноценной многопользовательской базы один шаг.
Блокировки и параллелизм - неотъемлемая часть подисистемы хранения.
Вообще, не представляю, как можно создать однопользовательскую СУБД, даже если реализовывать только базовые стандарты. Транзакции у тебя будут? Если будут - до полноценной многопользовательской базы один шаг.
[QUOTE=Freeman]
Блокировки и параллелизм - неотъемлемая часть подисистемы хранения.
[/QUOTE]
1. Транзакции будут, но чуть позже.
2. А вот насчет блокировок и параллелизма, здесь можно поподробнее?
Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection. Ну думаю что добавочные колонки в таблицах создать будет несложно и соответствующий код внедрить в нужных местах тоже.
Блокировки и параллелизм - неотъемлемая часть подисистемы хранения.
[/QUOTE]
1. Транзакции будут, но чуть позже.
2. А вот насчет блокировок и параллелизма, здесь можно поподробнее?
Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection. Ну думаю что добавочные колонки в таблицах создать будет несложно и соответствующий код внедрить в нужных местах тоже.
[QUOTE=cheburator]2. А вот насчет блокировок и параллелизма, здесь можно поподробнее?[/QUOTE]
Почитай Тома Кайта. Из популярных СУБД в Oracle это сделано правильнее всего.
[QUOTE=cheburator]Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection.[/QUOTE]
Тут есть много подводных камней. Например, согласованность по чтению. У тебя же не предполагается т. н. "грязное чтение"?
Почитай Тома Кайта. Из популярных СУБД в Oracle это сделано правильнее всего.
[QUOTE=cheburator]Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection.[/QUOTE]
Тут есть много подводных камней. Например, согласованность по чтению. У тебя же не предполагается т. н. "грязное чтение"?
А можно ссылку на этого самого Кайта? Или хотя бы название
Спасибо за ссылки, почитаю.
[quote=cheburator]1. Транзакции будут, но чуть позже.
2. А вот насчет блокировок и параллелизма, здесь можно поподробнее?
Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection. Ну думаю что добавочные колонки в таблицах создать будет несложно и соответствующий код внедрить в нужных местах тоже.[/quote]
А как же несколько уровней блокировок, схема откатов (Rollback)? С самого начала предлагаю реализовать самую простую схему избежания блокировок - это сериализация. Ну а дальше можно предложить использовать алгоритм WSClock, использующихся в ОС для обработки процессов. Можно предложить разработать схему управляемых блокировок: создать средство для описания детерменированного автомата, по схеме которого будет происходить откат. Это можно реализовать в виде простого языка и предлагать разработчикам баз под ваш сервак управлять блокировками самим.
2. А вот насчет блокировок и параллелизма, здесь можно поподробнее?
Потому что я предполагал, что механизм блокировок предполагает наличие специальных служебных колонок в таблицах и т. д., а также стандартные средства синхронизации типа Event или CriticalSection. Ну думаю что добавочные колонки в таблицах создать будет несложно и соответствующий код внедрить в нужных местах тоже.[/quote]
А как же несколько уровней блокировок, схема откатов (Rollback)? С самого начала предлагаю реализовать самую простую схему избежания блокировок - это сериализация. Ну а дальше можно предложить использовать алгоритм WSClock, использующихся в ОС для обработки процессов. Можно предложить разработать схему управляемых блокировок: создать средство для описания детерменированного автомата, по схеме которого будет происходить откат. Это можно реализовать в виде простого языка и предлагать разработчикам баз под ваш сервак управлять блокировками самим.
[QUOTE=3A3-968M]А как же несколько уровней блокировок, схема откатов (Rollback)? С самого начала предлагаю реализовать самую простую схему избежания блокировок - это сериализация. Ну а дальше можно предложить использовать алгоритм WSClock, использующихся в ОС для обработки процессов. Можно предложить разработать схему управляемых блокировок: создать средство для описания детерменированного автомата, по схеме которого будет происходить откат. Это можно реализовать в виде простого языка и предлагать разработчикам баз под ваш сервак управлять блокировками самим.[/QUOTE]
В общем, я еще почитаю поподробнее про блокировки и т. д.
Если дадите побольше хороших ссылок.
В общем, я еще почитаю поподробнее про блокировки и т. д.
Если дадите побольше хороших ссылок.