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

S> На уровне промышленных БД да, на уровне своего кода не всегда.
Это уже проблемы твоего кода. Просто модифицировать ты не имеешь права, так как с очень большой вероятностью ключ во время модификации переедет на другую страницу, поэтому любая модификация ключа индекса это всегда удаление+вставка, если мы говорим о B+.

S> А на пальцах сложно было объснить, всё своим умом доходить надо
Блин. Я устал уже повторять. Мы. обсуждаем. другой. вопрос. К механизму модификации дерева ссылки на предыдущие версии не имеют никакого отношения, они там не используются. Эти предыдущие версии лежат в совершенно отдельном хранилище и обслуживаются отдельным алгоритмом.
Механизм версионности совершенно другая тема не имеющая отношения к модификации дерева. Я не понимаю как эту мысль до тебя донести. Моего русского языка на это не хватает.

S>Версионность на уровне страниц оправдана при массовых модификациях.
Версионность для чего? Если мы все еще говорим о модификации индекса, то там она не оправдана вообще. Если же о версионности как таковой, то это тема отдельного обсуждения и ввязываться еще и в этот разговор с тобой у меня нет никакого желания.
Могу только прокомментировать, что ты ошибаешься.

S> Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
Ошибаешься. Версию записи нужно сверять всегда.

S> Кроме того собирать ненужные страницы легче чем дефрагментировать дерево от ненужных версий на уровне единичных ключей, плюс вырожденность страниц будет большой при частых удалениях.
Если ты опять про дерево, то могу лишь в восемдесят третий раз повторить: версионность при модификации дерева не используется никакая. Ни на уровне страниц, ни на уровне записей.

vdimas wrote:
> C>Ну и с большими данными у меня более резво работает (позволяет делать
> C>memory mapping через специальный интерфейс).
> Хм... уже хочу такой же
К сожалению, copyright на него у заказчика. Но я уже пишу аналог для
другого своего проекта — хотя там еще не все готово.

Так что если интересно, то welcome в почту.

AndrewVK wrote:
> V>Я чего-то в упор не вижу причин нарушений целостности БД и
> рассогласования данных по вине разработчика. И последовательность
> действий вроде тривиальная.
> Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее
> пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако
> при отсылке результата коммита клиенту происходит сбой.
Называется "эвристическое событие" (heuristic event/completion), хотя в
описаной ситуации просто произойдет откат файла назад (так как коммит не
прошел). Точно так же может быть и в ситуации с двумя БД в
распределенной транзакции.

Теоретически эвристические события никак не предотвращаются, благодаря
двухфазному коммиту (two-phase commit) можно только уменьшить их
вероятность.

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

> Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две
> идентичных записи.
Версирование рулит.

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

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

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

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

S>> На уровне промышленных БД да, на уровне своего кода не всегда.
M>Это уже проблемы твоего кода. Просто модифицировать ты не имеешь права, так как с очень большой вероятностью ключ во время модификации переедет на другую страницу, поэтому любая модификация ключа индекса это всегда удаление+вставка, если мы говорим о B+.

Согласен,

S>> А на пальцах сложно было объснить, всё своим умом доходить надо
M>Блин. Я устал уже повторять. Мы. обсуждаем. другой. вопрос. К механизму модификации дерева ссылки на предыдущие версии не имеют никакого отношения, они там не используются. Эти предыдущие версии лежат в совершенно отдельном хранилище и обслуживаются отдельным алгоритмом.

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

При версионности на уровне страниц, тоже несколько другой алгоритм при модификации.

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


S>>Версионность на уровне страниц оправдана при массовых модификациях.
M>Версионность для чего? Если мы все еще говорим о модификации индекса, то там она не оправдана вообще. Если же о версионности как таковой, то это тема отдельного обсуждения и ввязываться еще и в этот разговор с тобой у меня нет никакого желания.

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

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

Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
S>> Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
M>Ошибаешься. Версию записи нужно сверять всегда.

Зачем, если есть версия страницы????

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

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

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

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

S>>> На уровне промышленных БД да, на уровне своего кода не всегда.
M>>Это уже проблемы твоего кода. Просто модифицировать ты не имеешь права, так как с очень большой вероятностью ключ во время модификации переедет на другую страницу, поэтому любая модификация ключа индекса это всегда удаление+вставка, если мы говорим о B+.

S>Согласен,

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

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

S> Хорошо при модификации дерева, будут пермещаться только те версии записи индекса, которые актуальны, и будуть затирать удаленные записи чья версия устарела.
Чего хорошего-то? Ты смешиваешь два принципиально разных механизма. Зачем?

S> Заметь что оба варианта по алгоритму отличаются от обычного.
Не отличаются.
Блин, достал. 2 алгоритма, два. понимаешь?
1. Модификация дерева.
2. Поиск разных версий для внешнего кода.
Первый никак не пользуется вторым. В данной ветке идет обсуждение исключительно первого. Версионность в нем не применяется вообще.
Неиспользуется данный механизм при модификации дерева.
Так понятно? До тех пор пока ты этого не поймешь и не определишься о каком из этих алгоритмов ты говоришь — разговор смысла не имеет.

S> Я не знаю о чем ты говорил, я как раз о версионности как на таковой в плане индекса.
Нету версионности как таковой в плане индекса. Есть два разных механизма, каких именно — смотри выше. Я тебе уже все разживал, больше немогу. Не можешь понять — поверь: при модификации индекса версионность не используется. точка.

S> Есть здравый смысл.
Есть. Предлагаю тебе им воспользоваться.

S> Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
Во-первых, прежде чем что-то делать, рекомендуется подумать и ознакомиться с тем, как аналогичные вещи делали до тебя.
А во-вторых, данная подветка исключительно о том как это реализовано на самом деле, и о том, почему сделано именно так, а не о том как ты можешь это придумать.

S> Зачем, если есть версия страницы????
Затем, что на странице могут быть записи разных версий.

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

V>Ну... это очень грубо. Клиент же не просто шлет: "сохрани вот этот мусор хоть как нибудь", он же пошлет примерно так: "сохрани вот эту версию под новым номером, и вот тебе мой текущий кукис". Мы лезем, проверяем версии, видим, кто именно изменил и под каким кукисом. Если этот же клиент и под тем же кукисом — понимаем, что он нас не понял. В смысле, с первого раза не понял и повторяем ответ. Если это был не он и текущая версия не совпадает с его заявленной, то выдаем некий диалог, где честно говорим о конфликте (типа как в CVS).

Вот вот, что и требовалось доказать. Закат солнца вручную.

V>Описанный тобой сценарий достигается даже если мы все храним в БД:

Нет, если уровень изоляции соотв. выставлен. В этом случае блокировочник тормознет удалятора и он будет ждать, пока первый клиент закроет транзакцию, а версионник удалятора пустит, зато первому клиенту выкинет snapshot too old.

V>А твой "Упс" надо разруливать примерно так:
V>- выдать серверу приложений уникальный аккаунт на доступ к репозиторию (т.е. исключить правку содержимого каталога вне системы)
V>- когда удаляется документ, то, разумеется, сначала удаляется запись из базы
V>- когда создается, то наоборот — сначала записывается и проверяется файл, только потом вноситься запись в БД.

Что и требовалось доказать

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

GZ>Это все достаточно легко решаемые проблемы.

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

GZ> Есть другая, трудно нерешаемая. У нас есть две системы и две системы backup. Одна система бэкапится в момент t1 другая в момент t2, в результате при восстановлении изменения t2-t1 на одной из систем отсутсвует.

Ты не понял, они предлагают пользователям курить в сторонке, пока бекап происходит. Соотв. t2-t1 всегда равно 0.

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

C>Называется "эвристическое событие" (heuristic event/completion), хотя в
C>описаной ситуации просто произойдет откат файла назад (так как коммит не
C>прошел). Точно так же может быть и в ситуации с двумя БД в
C>распределенной транзакции.

C>Теоретически эвристические события никак не предотвращаются, благодаря
C>двухфазному коммиту (two-phase commit) можно только уменьшить их
C>вероятность.

Спасибо за информацию. Ты что, всерьез считаешь что я об этом не знал?

C>Для борьбы с этим можно использовать разные механизмы, например, чтобы
C>файлы не затирали предидущие.

Ага, и все за один день работы.

>> Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две
>> идентичных записи.
C>Версирование рулит.

И все за один день работы.

C>С этого места помедленнее — файлы в системах документоборота обычно
C>нельзя уничтожить. Они просто помечаются в БД как "устаревшие" и через
C>некоторое время могут быть прибиты "сборщиком мусора" (обычно после их
C>архивирования).

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

>> Первый клиент в этот момент что то там в
>> документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
C>В БД для этого нужно хранить запись о том, что документ заблокирован.

Называется закат слонца вручную.

AndrewVK wrote:
> C>Для борьбы с этим можно использовать разные механизмы, например, чтобы
> C>файлы не затирали предидущие.
> Ага, и все за один день работы.
Да, один день. А что сложного? При записи/изменении файл создается с
уникальным именем (типа tmpDoc12354.doc), при коммите переименовывается
в следующий документ (Doc21.doc), а старый файл (Doc20.doc) становится
"устаревшим".

Для этой схемы в будущем планируем использовать Subversion — там и явные
транзакции с разруливанием конфликтов есть

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

>> > идентичных записи.
> C>Версирование рулит.
> И все за один день работы.
Нам не нужны все возможные сценарии, используется простейший
lock-modify-commit-unlock.

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

> C>В БД для этого нужно хранить запись о том, что документ заблокирован.
> Называется закат слонца вручную.
Да. Но он оправдывается намного большей производительностью и
безгеморройностью.

Здравствуйте, AndrewVK, Вы писали:
AVK>Называется закат слонца вручную.
Это да! Как известно, результат радикальным образом зависит от размера слонца. Маленького вручную закатить еще можно, но это приводит к иллюзиям. Однако если слонец достаточно велик, то ручной закат быстро выходит за пределы коммерческой реализуемости.

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

S>Это да! Как известно, результат радикальным образом зависит от размера слонца. Маленького вручную закатить еще можно, но это приводит к иллюзиям. Однако если слонец достаточно велик, то ручной закат быстро выходит за пределы коммерческой реализуемости.

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

Здравствуйте, eao197, Вы писали:
E>Только разработчикам Opera об этом не рассказывайте, пожалуйста. А то заменят свое кустарное, но очень быстрое хранилище почтовых сообщений, на что-нибудь промышленно-стандартное.
Разбудите меня, когда опера научится поддерживать ACID в своем кустарном хранилище.

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

S>Разбудите меня, когда опера научится поддерживать ACID в своем кустарном хранилище.

Это будет сложно, т.к. я не знаю, как именно у них хранилище организованно (вполне вероятно, что ACID у них есть).
Но вот почту в Opera терять пока не приходилось (тьфу-тьфу). Даже после жестоких принудительных перезагрузок машины.

Здравствуйте, eao197, Вы писали:
E>Это будет сложно, т.к. я не знаю, как именно у них хранилище организованно (вполне вероятно, что ACID у них есть).
E>Но вот почту в Opera терять пока не приходилось (тьфу-тьфу). Даже после жестоких принудительных перезагрузок машины.
Это просто означает, что не все йогурты одинаково полезны. Мне лично совершенно лень скачивать оперу, но что-то мне подсказывает, что никакой атомарности не будет, если в опере, скажем, выделить 5000 писем и начать перекладывать их из папки в папку. Вряд ли они вернут все на место если я рубану в это время питание.
А то, что файлуха умеет атомарно выполнять операцию переименования отдельного файла, малоинтересно для общего случая.


Вообще лично я встречал только одну софтину, претендующу на ACID поверх FS. Это SVN. И то, ее клиент совершенно неатомарен. Ну и отлаживалось это дело не один день, и даже не один месяц. Поэтому я не верю во все эти пальцы про ACID на FS. Если бы это было так просто, то это давно бы сделали. А пока мы имеем ReiserFS 4 и SVN. И, собственно, всё.

Мораль: если вы храните именованные блобы, и у вас не бывает транзакций, затрагивающих больше одного блоба, то FS — самое то. Потому что FS и есть СУБД для управления именованными блобами. В частности, ТЗ на оперу запросто может ограничиваться как раз управлением именованными блобами, и тогда никаких претензий к их стораджу нет.

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

Sinclair wrote:
> Вообще лично я встречал только одну софтину, претендующу на ACID поверх
> FS. Это SVN. И то, ее /клиент/ совершенно неатомарен.
Почему же, вот SVK вполне атомарен. Просто в обычном клиенте SVN
атомарность нафиг не сдалась.

> Ну и отлаживалось
> это дело не один день, и даже не один месяц. Поэтому я не верю во все
> эти пальцы про ACID на FS. Если бы это было так просто, то это давно бы
> сделали. А пока мы имеем ReiserFS 4 и SVN. И, собственно, всё.
В SVN используются эффективные алгоритмы дельтификации и разруливания
конфликтов. Они и занимают большую часть кода, а простейший движок для
статической структуры и без разруливания конфликтов — это совсем несложно.

> Мораль: если вы храните именованные блобы, и у вас не бывает транзакций,
> затрагивающих больше одного блоба, то FS — самое то.
Скорее не "затрагивающих больше одного блоба", а "использующих простую
модель доступа".

> есть СУБД для управления именованными блобами. В частности, ТЗ на оперу
> запросто может ограничиваться как раз управлением именованными блобами,
> и тогда никаких претензий к их стораджу нет.
Ну примерно это вам и говорили уже сообщений 30

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

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

S>> Хорошо при модификации дерева, будут пермещаться только те версии записи индекса, которые актуальны, и будуть затирать удаленные записи чья версия устарела.
M>Чего хорошего-то? Ты смешиваешь два принципиально разных механизма. Зачем?

S>> Заметь что оба варианта по алгоритму отличаются от обычного.
M>Не отличаются.
M>Блин, достал. 2 алгоритма, два. понимаешь?
M>1. Модификация дерева.
M>2. Поиск разных версий для внешнего кода.
M>Первый никак не пользуется вторым. В данной ветке идет обсуждение исключительно первого. Версионность в нем не применяется вообще.
M>Неиспользуется данный механизм при модификации дерева.
M>Так понятно? До тех пор пока ты этого не поймешь и не определишься о каком из этих алгоритмов ты говоришь — разговор смысла не имеет.

Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1

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

А вернее о варанте хранение ссылок на элементы в родительских страницах.
S>> Я не знаю о чем ты говорил, я как раз о версионности как на таковой в плане индекса.
M>Нету версионности как таковой в плане индекса. Есть два разных механизма, каких именно — смотри выше. Я тебе уже все разживал, больше немогу. Не можешь понять — поверь: при модификации индекса версионность не используется. точка.

S>> Есть здравый смысл.
M>Есть. Предлагаю тебе им воспользоваться.

S>> Второе не ошибается тот кто ничего не делает,все твои ссылки на промышленные БД.
M>Во-первых, прежде чем что-то делать, рекомендуется подумать и ознакомиться с тем, как аналогичные вещи делали до тебя.
M>А во-вторых, данная подветка исключительно о том как это реализовано на самом деле, и о том, почему сделано именно так, а не о том как ты можешь это придумать.
Нет смотри выше
S>> Зачем, если есть версия страницы????
M>Затем, что на странице могут быть записи разных версий.

Опять в варианте с версионностью на уровне страниц, версии на уровне записи индекса актуальна относително версии страницы.
На уровне ссылки они разные. Кроме того для кластерных индексов и этого не надо.
Или ты отвергаешь вообще версионность на уровне страниц???

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

S> Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1

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

То есть, мы все еще говорим об индексе и только об индексе?

S> А вернее о варанте хранение ссылок на элементы в родительских страницах.
В индексе?

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

S> Кроме того для кластерных индексов и этого не надо.
Забудь про понятие "кластерный индекс". С точки зрения работы с B+ — "кластерный" и "не кластерный" не отличаются ничем.
Похоже у тебя проблема с выделением абстракций, ты все время скатываешься на какую-то конкретику там, где этого не надо.

S> Или ты отвергаешь вообще версионность на уровне страниц???
Я не верю в ее полезность при работе непосредственно с B+ деревом. И в принципе не верю в применимость твоего варианта версионности на уровне страниц. Я тебе в очередной раз настоятельно советую, прежде чем бросаться писать что-то своё — тщательно ознакомиться с существующими решениями.

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

AVK>Процессор Pentium4 2.66 — $100
AVK>Серверная мамка от Supermicro — $230
AVK>Серверный корпус от того же Supermicro — $110
AVK>Гиг памяти ECC Registered от Kingston — $120
AVK>2 винта по 200 гиг для зеркала — $180

Что за винты?

AVK>Итого — $740, в заданные рамки уложились и получили то же самое по надежности железо от тех же самых производителей, что и на rsdn.

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

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

S>> Вообщеть весь сыр бор пошел вот отсюда http://www.rsdn.ru/Forum/Message.aspx?mid=1710977&only=1

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

M>То есть, мы все еще говорим об индексе и только об индексе?

S>> А вернее о варанте хранение ссылок на элементы в родительских страницах.
M>В индексе?
да
S>>Опять в варианте с версионностью на уровне страниц, версии на уровне записи индекса актуальна относително версии страницы.
M>Можно, конечно, сделать и так, но на практике это слишком накладно. В том же Оракле, в котором версионнсть постраничная (не индексов, а данных) так не поступают, а осуществляют переход на новую страницу только если нужная версия записи на странице не нашлась, то есть отслеживается и версия записи, которая не равна версии страницы.
M>Специально для тебя оговорюсь, сейчас я говорю про версионность вообще, а не версионность при работе с индексом. При работе непосредственно с индексом версионность вообще не используется.
Это я понял.
S>> Кроме того для кластерных индексов и этого не надо.
M>Забудь про понятие "кластерный индекс". С точки зрения работы с B+ — "кластерный" и "не кластерный" не отличаются ничем.
Не совсем. Так при изменение записи просхисходит на уровне индекса именно аналог словаря, т.к. Key,Value хранятся совместно. При простом индексе изменяется Запись по ссылке.
M>Похоже у тебя проблема с выделением абстракций, ты все время скатываешься на какую-то конкретику там, где этого не надо.
Есть такой недостаток. Каюсь.
S>> Или ты отвергаешь вообще версионность на уровне страниц???
M>Я не верю в ее полезность при работе непосредственно с B+ деревом. И в принципе не верю в применимость твоего варианта версионности на уровне страниц. Я тебе в очередной раз настоятельно советую, прежде чем бросаться писать что-то своё — тщательно ознакомиться с существующими решениями.

А их на самом деле не так много. А о том, что я говорил просто не применяются, но это не значит что неприменимы.
Так версионность на уровне страницы, кроме места, требуют одного писателя и применение возможно там где изменяются можество последовательных записей . Пример многострочная часть документа, движения документа имеющие именно такую природу, где кюч имеет вид DocID,НомерСтроки итд. И достаточно прост в реализации
Да и при версионности на уровне записи индекса достаточно много конфликтных вариантов которые нужно обходить и реализация намного сложнее.
Кроме того, разговор был бы намного продуктивнее если бы мы изначально поняли друг друга, а всё изучить невозможно, в большинстве случаев это происходит по месту.
В общем на самом деле я остался доволен беседой