SiemarglМаленький тест скорости

Основная идея - неизобретение велосипедов, которыми занимаются все разработчики СУБД - создают внутри файлов БД свою внутреннюю структуру хранения данных.
Оракл, например, вообще предлагает возможность отказаться от ФС ОС, т.к. у него и так все свое и зачем дублировать функционал!?

Ведь все - блоки, целостность, экстенты, кэш! итп уже есть в ФС операционки.

Вот пробую проверить что будет, если поступить с точностью до наоборот - использовать возможности ОС и упростить все остальное.

Ой как интересно :)

В свете того, что флагманы сами рисуют
автор
свою внутреннюю структуру хранения данных


Как у Вас реализовано кеширование данных ( в двух словах)?

Насколько я понял, Вы полностью полагаетесь на кеш ФС ?

Какой механизм ACID ( Версионный или блокировочный) ?

Siemarglinteresting
Как у Вас реализовано кеширование данных ( в двух словах)?

Насколько я понял, Вы полностью полагаетесь на кеш ФС ?

Какой механизм ACID ( Версионный или блокировочный) ?

Кэш ФС - от него при таком механизме не уйти (можно но не нужно). Фуллскан и rangescan - через ФС и ее кэш.
Выборки - дополнительно через внутренний кэш - для каждой транзакции свой, но разделяемый внутри транзакции.


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


Siemargl
TxF дает версионный механизм уровня RC. Выше можно реализовать только блокировками - и нужно ли???

Просмотрел по диагонали, интересно.

Из бросившегося в глаза обратил внимание на , то что версии хранятся только в памяти,
и могут уходить в своп, это мне не нравится.
Потом, есть некое версионное ветвление для participating processes ,
логику которого я пока понять не могу,
Это какойто аналог разделяемой блокировки ? Не совсем понятно как это работает .

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

Ну простой пример, перебрасываем деньги с одного счета на другие счета
в 2 паралельных сессиях.
Одна вычитала остаток, провела действие , но не закомитила.
Другая , вычитала версию остатка и провела действия .
Потом закомитилась первая и вторая, не важно в каком порядке.

Риторический вопрос:
Как свести баланс если 2 транзакции использовали
одно значение остатка для разных проводок ?

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

Siemargl


interesting
Просмотрел по диагонали, интересно.

Из бросившегося в глаза обратил внимание на , то что версии хранятся только в памяти,
и могут уходить в своп, это мне не нравится.
Потом, есть некое версионное ветвление для participating processes ,
логику которого я пока понять не могу,
Это какойто аналог разделяемой блокировки ? Не совсем понятно как это работает .

К сожалению, версии хранятся не столько в памяти, как в системном файле $LOG. Потому массовое создание данных в транзакции тяжелый процесс - см.тест (но зато в К3 можно сделать его нетранзакционным).
Каждый процесс видит незакоммиченные данные только свои. Неявных блокировок нет.


Думаю ИМХО не получится полностью не транзакционным.
Нужно будет навешивать логику на проверку ссылочной целостности.
Не знаю как лучше , но насколько я понял Вашу идеологию, для этого нужно будет
делать доп проверки, вводить какую то дополнительную транзакционность.
Потому, что чистый версионный механизм ФС ,
вам запросто в тихую нарушит уникальность РК.





Siemargl
Поскольку это эксперимент - можно реализовывать нетипичными для СУБД методами.
Кроме того я логику работы с производными множествами еще не продумал - как лучше сделать.


Думаю SQL самый лучший инструмент, я по крайней мере лучшего не знаю.

Siemargl
Этот пример решается, например мьютексом и без файловых блокировок )


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

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



Siemargl
Транзакции просто разносятся по разным потокам программы. Когда буду проводить тесты параллелизма - будет интересно насколько выгодно (и на каком RAID) параллелить 1 транзакцию.


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

Siemargl

interesting
Потому, что чистый версионный механизм ФС ,
вам запросто в тихую нарушит уникальность РК.

Сама по себе ОС - никак не нарушит. Но следить самому придется, чтобы не создать дубль PK (например PK-GUID).


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


Siemargl
interesting
Думаю SQL самый лучший инструмент, я по крайней мере лучшего не знаю.

SQL неудобен для объектов.

Нельзя создать абслолютно универсальный примитив ( шаблон).
SQL максимально претендует на такую универсальность.





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


Если Вы на форуме надавно , почитайте старые длинные темы,
тут был одни общеизвестный персонаж ЧАЛ , во множестве версий.
Не повторяйте его ошибки.


Siemargl
interesting
В противном случае любой раид( и его кеш) можно очень быстро загнать под плинтус .

Эту задачу я оставлю ОС. Мой кэш маленький и его задачи попроще.

Это Ваше право.

Siemargl

SQL неудобен для объектов.


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



Почитайте http://www.sql.ru/forum/actualthread.aspx?tid=570274&hl=%ed%ee%f0%ec%e0%eb%e8%e7%e0
%f6%e8%ff] эту тему,
это одна из последних с участием ЧАЛа , и подумайте как
Вы будете управлять иерархией объектов.

И насколько это будет удобно тем, кто будет пользоваться Вашими универсальными
примитивами ( шаблонами) для доступа к данным.

Помоему Вы приходите к тому, что уже много раз пережевано ,
только с другой ( версионной ) стороны.

Siemarglinteresting,



Сейчас поразбираемся. Я не адепт MUMPSа и отказа от РМД, если намек на это =)
Но будем выбирать толковые идеи из разных источников.

2 МП: Простой пример реализации - XML объект в отдельном файле. (Правда у меня все же посложнее будет)

Пока утверждение к обсуждению - "абстрактные" ORM работают медленно.



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

Нормализация отношений , уровни изолированности и SQL
есть этими механизмами.

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

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

Siemargl
Но ежу мне и так было понятно, что у меня получится маленькая иерархическая(сетевая) БД. И что в этом плохого?
Есть определенные области, куда не надо совать такой подход и есть, где он выгоднее.
И конкурентов меньше, только IMS да RAIMA ))))



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

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

Без привязки к конкретной предметной области и реализации
дальше обсуждать тему хранения объектов я не вижу смысла.