Здравствуйте, eao197, Вы писали:


S>> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций.
S>> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)

E>Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы.
E>Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения.
Лог нужен для отката, что бы не сканировать все страницы, лучше в памяти, а по поводу восстановления полностью согласен.
E>>>Идем далее. Ты утверждаешь о скорости этого решения на основании экспериментов?
S>> Если применть тотже механизм, что и в Re[11]: Объектно-ориентированные БД: основные принципы, орга

Автор: Serginio1
Дата: 04.03.05

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

E>Как раз, если ты не будешь переиспользовать уже устаревшие страницы, то производительность начнет деградировать, т.к. на каждый новый комит ОС придется расширять твой файл данных. А эта операция дороже, чем перезапись уже существующих страниц.
Ты немного не понял. Они возвращаются БД. Но я предполагаю эту операцию производить в бэкграунд потоке, т.к. читающие транзакции могут быть очень долгими, и возвращать все страницы с ID транзакции меньше наименьшей читающей транзакции, или оставлять только актуальные если таковых нет.

E>>>А вообще механизм, при котором нет write-ahead-log, но измененные страницы сохраняются отдельно и как-бы растворяются в старом содержимом БД, является одним из классических способов обеспечения транзакционности. По крайней мере я о нем когда-то давно-давно читал. Но в нем есть один тонкий момент: нужно как-то гарантировать целостность цепочки актуальных страниц.
S>> У меня за цепочки отвечает отдельная таблица, но согласен это основное тонкое место.

E>Да, и ее придется защищать как-то по другому.
В любом случае это пока только фантазии

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, eao197, Вы писали:


S>>> Нет все новые страницы записываются на новом месте. Страницы со старым ID нужны только для читающих транзакций.
S>>> При этом, транзакция должна вести свой лог, измененных страниц, по которой можно восстановить данные (откатить)

E>>Так а зачем тогда лог? Обломилась транзакция, игнорируем ее страницы.
E>>Проще где-то хранить ID последней успешно зафиксированной транзакции. И просто переиспользовать ID, которые больше этого значения.
S> Лог нужен для отката, что бы не сканировать все страницы, лучше в памяти, а по поводу восстановления полностью согласен.

Тогда понятно. Я при откате просто кэш вычищаю и все.

E>>Как раз, если ты не будешь переиспользовать уже устаревшие страницы, то производительность начнет деградировать, т.к. на каждый новый комит ОС придется расширять твой файл данных. А эта операция дороже, чем перезапись уже существующих страниц.
S> Ты немного не понял. Они возвращаются БД. Но я предполагаю эту операцию производить в бэкграунд потоке, т.к. читающие транзакции могут быть очень долгими, и возвращать все страницы с ID транзакции меньше наименьшей читающей транзакции, или оставлять только актуальные если таковых нет.

Мне кажется, что это ты меня немного не понял. Давай еще раз:
— есть страницы, которые принадлежат старым транзакциям с ID=4 и ID=5;
— последняя актуальная цепочка содержит страницы, которые принадлежат транзакции ID=5;
— читающих транзакций нет;
— начинается новая пишущая транзакция с ID=6;
— эта транзакция поглощает страницы с ID=4;
— если затем эта транзакция начнет поглощать страницы с ID=5, то при сбое окажется, что актуальные страницы с ID=5 потеряны.

Ведь так?

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

Здравствуйте, eao197, Вы писали:


E>Мне кажется, что это ты меня немного не понял. Давай еще раз:
E>- есть страницы, которые принадлежат старым транзакциям с ID=4 и ID=5;
E>- последняя актуальная цепочка содержит страницы, которые принадлежат транзакции ID=5;
E>- читающих транзакций нет;
E>- начинается новая пишущая транзакция с ID=6;
E>- эта транзакция поглощает страницы с ID=4;
E>- если затем эта транзакция начнет поглощать страницы с ID=5, то при сбое окажется, что актуальные страницы с ID=5 потеряны.

E>Ведь так?

E>Поэтому тебе нужно будет ввести еще одно уточнение: нельзя забирать страницы последней актуальной транзакции. Даже если читающих транзакций не было.

Приблизительно так, страницы выдает БД, если страница не была ей отдана значит будет выделена новая или отдана из пустых страниц из цепочки свободных страниц.
Актуальная страница может быть отдана только после полной фиксации записывающей транзакции.
или Эдак http://gzip.rsdn.ru/article/db/yukonvers.xml#EHDA

Автор(ы): Иван Бодягин
Дата: 16.07.2004
Статья рассказывает о поддержке версионности, которая должна появиться в новой версии MS SQL Server — Yukon.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

GZ>>Здравствуйте, Sinclair, Вы писали:

S>>>Здравствуйте, GlebZ, Вы писали:
GZ>>>>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).
S>>>Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом.
GZ>>Глянул BOL. Что-то стормозил . Твоя правда. Только varchar всегда — хранятся вместе с row.
S>varchar(<const>) — да. Varchar(max) — нет. Читать здесь.
Спасибо, теперь понятно. Thanks за ссылку. Я в yukonе пока не дока. Не хватает времени хорошо его понять.
S>Верно. Термин компактифицировать == shrink. Не нашел лучшего русского аналога. Не хотелось писать "пошринкать спейс надо тогда, когда гарбадж занимает больше 50% вольюма".

С уважением, Gleb.

Здравствуйте, Serginio1, Вы писали:

S>Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
S>Т.к. запись привязана к странице можно сделать некий менеджер памяти, который хранит цепочку измененных страниц начиная с актуальной.
S>У каждой страницы есть свой ID транзакции (Int64 выше крыши), а так же ссылка на пишущую транзакцию.
S>Для упрощения можно создать два вида транзакции читающие и записывающую. Одновременно может выполняться только одна пишущая транзакция. В большинтве случаях при проведении документов в которых изменяется большое количество регистров это оправдано.
S>Так пишущая транзакция считывает страницу актуальную или транзакционную (пишет только в транзакционную), а читающая в зависимости от ID транзакции.
S>При фиксации транзакции страницы записываются и страницы становяися актуальными.
S>Для возвращения страниц с ID транзакции меньшей чем самая ранняя читающая транзакция эти страницы можно возвращать БД, в потоку просматривающем все страницы.
S>При таком подходе проще вести лог, изменение индексов, архивировании БД итд.
S>А по скорости она будет мало уступать безтранзационной.
Все, теперь понял что ты хотел сказать.
Некоторые замечания и предложения.
1. Индекс в любом случае придется делать. А индекс — это косвенная адресация. Возможно легче будет управлять через него. Особенно, в случае большого кол-ва страниц. Все-таки логарифмический или линейный доступ при большом кол-ве страниц значительно лучше. Кстати, ты примерно рассчитывал сколько для твоей бизнес задачи потребуется памяти для хранения указателей на страницы? От этого много зависит.
2. Вопрос с логгером. Проблема в отказе при сохранении таблицы указателей на страницы. Возможно стоит делать копии этих таблиц, и после этого сохранять номер последней транзакции. Это не даст 100%, но 99.9% я думаю будет достаточно. При восстановлении, брать нормальную таблицу и игнорировать остальные.
3. Возможно увеличение базы данных. Особенно, если я правильно понял, при долгой транзакции. Хотя при нынешних гигабайтах — может быть неактуально.
4. Возможна сильная дефрагментация. БД при чтении читают больше данных чем нужно. Вероятность того, что следующий запрос будет на следующий объект из той же таблицы — высока. Но обязательное условие то, что страницы с данными относящимися к одной таблице лежат в одном месте, чтобы не надо было переводить головку диска с дорожки на дорожку. Для этого нужно вводить систему экстентов.
5. Здесь невозможно переводить транзакцию из read only в пишущую. Также нельзя использовать данные из данной транзакции для записи в другой транзакции. Очень высока вероятность что прочитаны устаревшие данные. Получим несогласованные данные. Поэтому нужно явно или неявно ввести перечитывание данных.
6. После просмотра вариантов с индексами и откатом(п.1,2), я бы просмотрел возможность введения нескольких пишущих транзакций. Ничего криминального в данном механизме, для них не вижу.

С уважением, Gleb.

Здравствуйте, Cyberax, Вы писали:

C>Не знаю как вам, но для меня SQL в языке — бред.

Ничего не слышал о ESQL? Он существет и для С и для С++.
Лично для меня разумным является любое повышение контроля и увеличение удобства если при этом оно не видет к потере универсальности и качества. Так что если ребята из МС сделают это безшевно и не напряжно, то я буду рад.

C> Так как это скорее
C>всего будет сделано в виде железной привязки к MSSQL (знаем мы этих
C>МСников...).

Похоже "вы" их совсем не знаете. Они конечно интергрируют свои продукты, но при этом они всегда блюдут традиции универсальных АПИ. Думаю, что если поддержка БД будет встроена в Шарп, то она будет сделана на базе ADO.NET, а оный АПИ и сегодня неплохо поддерживает БД других производителей.

Здравствуйте, Sinclair, Вы писали:

S>Неа. Там все будет еще интереснее. Никакой привязки не произойдет — это все фичи языка, а не сервера. Прежде чем клеймить, почитай на микрософт ресерче про си-омегу.

Говорить о том как это будет пока что не решается даже сам Хегельберг (или как там его?).

Cw — это всего лишь иссплдовательский проект. Реализация в Шарпе может оказаться совсем иной.

Здравствуйте, Cyberax, Вы писали:

C>Гадость. В язык тянут прикладные вещи типа XML, вместо того, чтобы
C>добавить средства, позволяющие реализовать то же самое, но в виде библиотек.

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

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

Почему ребяата из МС не идут по этому пути я незнаю. Возможно боятся резкого усложнения связанного с метапрогарммированием. А возможно недопетривают. Ну, да лучше каки-то возможности чем никаких. А метафрэймворк и и без них сделаем.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Кстати, не просветишь о "политике партии" на этот счет? А то я встречал
ANS>в Инете упоминания, что XPath не будет, а будет что-то другое, но
ANS>подробно не разбирался. Отложилось в голове, что что-то меняется, но вот
ANS> что и зачем?

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

В СиОмеге XPath остается наместе, но плотно интегрирвется с компиляторм. Его парсинг происходит во вермя компиляции и система типов XPath мапится на систему типов СиОмеги. Отсюда полная статическая типизация и контроль XSD в компайлтайме. Возможно так же подсветка синтаквииса, автозавершение и т.п.

Здравствуйте, prVovik, Вы писали:

VD>>А в качестве импереативного языка обработки данных использую XPath.
V>Может, всетаки, декларативного?

Ессэсна. Апять оговорился.

Здравствуйте, GlebZ, Вы писали:

GZ>Во блин. Почему мне больше нравится OQL чем XPath.

Незнаю. Наверно тем, что тебе пофигу есть ли доступная реализаци или нет.

GZ>Не тем что он похож на SQL. Мне на это полностью начхать. XPath все-таки подразумевает дерево(для того и делался), а не произвольный граф.

А ХМЛ и есть дерево. Граф объектов тоже в общем-то дерево. По крайней мере для нас деревянных.

GZ>Например, напиши такой запрос:
GZ>select a where a.f1=b.f1 and b.f1=c.f1 and c.f2=20
GZ>где никакие связи между a, b, и с нигде не отражены.

Вообще-то с этим особых проблем нет. Вопрос тольк в эффективности исполнения. Ну, да меня лично не трогую проблемы реляционных БД. У меня AST. Даже название говорит о дереве. И для этого XPath выше крыша. Если бы он не отрмозил и небыло бы проблем с перходм с системы типов XPath на систему типов дотнета, то я горя бы не знал.

Здравствуйте, eao197, Вы писали:

E>Потрясающая читабельность у обоих вариантов

Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.

Здравствуйте, eao197, Вы писали:

E>А что он вообще делает? Я ведь XPath не знаю

Незная языка очень врено говорить о читабельности.

Здравствуйте, Serginio1, Вы писали:
S> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
[пересказ механики ранних interbase поскипан]
Фишка в том, что не вполне ясна методика коммита, а также действия СУБД при восстановлении после сбоя. То, что ты рассказываешь, пока относится только к одновременному использованию. Или ты, как обычно, на какую-то свою тему уже съехал?

Здравствуйте, Serginio1, Вы писали:

S> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
<...>

Sirginio1, а можно соединить твою идею и вот это

Автор: eao197
Дата: 05.03.05

:

Пусть каждая транзакция фиксируется в новом файле с именем <TID>.dat, где TID -- это идентификатор транзакции. Например 00000000.dat, 00f45779.dat, ...

Когда БД открывается, ищутся файлы по регекспу "^[[:xdigit:]]{8}\.dat$". Из полученных имен выделяются все номера транзакций и определяется TIDmax -- максимальный номер транзакции. Транзакция с этим номером и будет актуальной. Все остальные файлы, в принципе, уже не нужны и могут быть удалены.

Когда стартует пишущая транзакция, она создает файл <TIDmax+1>.tmp, куда записывает свое содержимое. Если транзакция завершается успешно, то файл флушируется и закрывается. После чего переименовывается в <TIDmax+1>.dat. Т.о. появляется новая актуальная транзакция и новый TIDmax=TIDmax+1.

Если при этом существуют читающие транзакции, то они читают старое содержимое БД из .dat-файлов со старыми TID. Как только все читающие транзакции освобождают некий TIDi и TIDi!=TIDmax, то файл <TIDi>.dat может быть уничтожен.

Если пишущая транзакция откатывается, то просто удаляется <TIDmax+1>.tmp и TIDmax остается без изменения.

Если происходит сбой при записи <TIDmax+1>.tmp, то при последующем рестарте этот файл будет просто проигнорирован.

---

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

VladD2 пишет:
> В принципе есть один выход из положения (чтобы и язык не расширять и
> проблем не иметь). Нужно создать мета-фрэймворк которые позволит
> дописывать такие фичи в виде мета-библиотек. По сути это будет такое же
> расширение компилятора, но его сможет сделать каждый смертаный, так как
> это будет делаться через специальный АПИ.
>
> Почему ребяата из МС не идут по этому пути я незнаю. Возможно боятся

Похожа, что будет слишком похоже на устаревший Smalltalk или поросший
мхом CLOS.

--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Потрясающая читабельность у обоих вариантов

VD>Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.
SQL да. OQL нет. Хотя и по кол-ву символов проиграет XPath.

С уважением, Gleb.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

E>>Потрясающая читабельность у обоих вариантов

VD>Ды варианты эмулируют реляционные отношения в древесном языке запросв. А ты перейди к обрботке деревьев и сразу получишь обратную картину. XPath окажется лапочкой, а SQL жутчайшим уродом.

Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается
Да и вообще, это типа шутка была.

Здравствуйте, prVovik, Вы писали:

V>Ну, допустим у нас есть XML дерево:
V>

V><a f="10" >
V>    <b f="15" />
V>    <b f="20" >
V>        <c f="25" />
V>        <c f="30" >
V>            <d f="40"> <!-- значение атрибута f этого узла и надо получить -->
V>        </c>
V>    </b>
V></a>
V>

А как будет выглядеть запрос в XPath, если XML выглядит так (идея в том, что b -- это ссылки на другие объекты):

<some-root>
<a f="10">
    <b ref="#0001" />
    <b ref="#0002" />
</a>
<b id="0001" f="15" />
<b id="0002" f="20" >
    <c f="25" />
    <c f="30" >
        <d f="40" /> <!-- значение атрибута f этого узла и надо получить -->
    </c>
</b>
</some-root>

Здравствуйте, GlebZ, Вы писали:


GZ>Некоторые замечания и предложения.
GZ>1. Индекс в любом случае придется делать. А индекс — это косвенная адресация. Возможно легче будет управлять через него. Особенно, в случае большого кол-ва страниц. Все-таки логарифмический или линейный доступ при большом кол-ве страниц значительно лучше. Кстати, ты примерно рассчитывал сколько для твоей бизнес задачи потребуется памяти для хранения указателей на страницы? От этого много зависит.

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

Если БД занимает порядка 10 ГБ памяти по массив страниц будет порядка (30-60 МБ).

GZ>2. Вопрос с логгером. Проблема в отказе при сохранении таблицы указателей на страницы. Возможно стоит делать копии этих таблиц, и после этого сохранять номер последней транзакции. Это не даст 100%, но 99.9% я думаю будет достаточно. При восстановлении, брать нормальную таблицу и игнорировать остальные.

Согласен.
GZ>3. Возможно увеличение базы данных. Особенно, если я правильно понял, при долгой транзакции. Хотя при нынешних гигабайтах — может быть неактуально.

Что бы набить 10 ГБ нужно сильно постараться. В любом случае нужно смотреть на предметную область, универсальных решений не бывает.
GZ>4. Возможна сильная дефрагментация. БД при чтении читают больше данных чем нужно. Вероятность того, что следующий запрос будет на следующий объект из той же таблицы — высока. Но обязательное условие то, что страницы с данными относящимися к одной таблице лежат в одном месте, чтобы не надо было переводить головку диска с дорожки на дорожку. Для этого нужно вводить систему экстентов.

Все равно читается все страницами, а некий аналог дефрагментаци ты и так получишь если при выборке будешь использовать индес, где данные будут разбросаны как попало (если конечно этот индекс не клястерный)
GZ>5. Здесь невозможно переводить транзакцию из read only в пишущую. Также нельзя использовать данные из данной транзакции для записи в другой транзакции. Очень высока вероятность что прочитаны устаревшие данные. Получим несогласованные данные. Поэтому нужно явно или неявно ввести перечитывание данных.
Пишущая транзакция есть и читающая и пишущая одновременно, просто при обращении к страницам она должна использоваь транзакционные, при чтении если их нет то считывать с актуальных, запись идет только на транзакционные. Поэтому пересчет в этой транзакции идет полный, в том числе и индексов.
GZ>6. После просмотра вариантов с индексами и откатом(п.1,2), я бы просмотрел возможность введения нескольких пишущих транзакций. Ничего криминального в данном механизме, для них не вижу.
А я ох как их вижу. Небольшой пример. Ведем партийный учет, две транзакции списывают один и тот же товар, товара хватает а вот партий нет,
и как две незавершенные транзакции будут согласовываться ????
Кроме того при страничной версионности, баги могут возникать намного чаще чем при версионности записями. Но уверяю, что скорости хватит на все пишущие транзакции (народ ждет и поболее

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