Здравствуйте, Serginio1, Вы писали:
S> Тогда давай разбираться.
А до этого мы чем занимались?
S> При модификации только одной страницы легче заменить полностью страницу, нежели удалять и востанавливать индексы при откате.
Нет. Потому что создание копии страницы означает копирование памяти и расход этой самой памяти. При откате ничего не удаляется и не восстанавливается. При откате просто снимается блокировка с конкретного ключа и слот на странице помечается либо как свободное место, либо как занятый.
S>Что будет более производительным.
Нет. Не будет. Это будет менее производительным, так как тратится время и ресурсы процессора на копирование страницы.
S>А зачем эту версионность вообще вводили если по твоим словам она не нужна.
Ее вводили для прикладного кода, а не для модификации дерева. А мы сейчас говорим именно о модификации дерева.
Я устал тебе повторять, что это две совершенно разные вещи.
S> Про версионность индексов.
Самим по себе индексам версионность ненужна, они прекрасно справляются без нее.
S> При версиооности ты обязан дать возможность поиска и прохода по индексу в соответствии с версией транзакции.
Но самому индексу для модификации эта версионность не нужна. А мы сейчас говорим именно о модификации индекса.
S> А это может быть достигнуто только при применении версионности страниц дерева.
Все, надоело. Берешь Бернстайна, берешь Ульмана
, берешь Грея, внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность.
И таких категоричных и неверных утверждений ты больше не делаешь, если тебе ничего лучшего придумать не получается — это вовсе не значит, что лучшего алгоритма не существует.
S> Смотрим выше.
На что? Я же не виноват что ты не можешь отделить задачу работы с деревом от своих личных прикладных нужд.
S> Поэтому предлагаю на этом покончить.
Давно пора.
Здравствуйте, Merle, Вы писали:
M>внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность.
кстати, если версионности страниц индекса нет, то как версионные БД производят поиск по индексу при условии что нужно работать с данными "в прошлом"? т.е. если индексы чисто блокировочные, и есть две транзакции, первая уровня изоляции как минимум oracle statement level read (пусть, oracle read only) которая строит отчет, а вторая удаляет все записи из таблицы с помощью delete. очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится?
Здравствуйте, n0name2, Вы писали:
N> очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится?
Нет, читающая транзакция полезет в лог за старыми значениями. В данном случае старые значения нужны не самому индексу для своей модификации, а читающей транзакции. И это ее головная боль, как эти значения получить, вся необходимая информация ей будет предоставлена, но, еще раз повторюсь, сам для себя индекс этой информацией не пользуется, а у нас речь именно о том как работает сам индекс, а не транзакции поверх него.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, n0name2, Вы писали:
N>> очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится? M>Нет, читающая транзакция полезет в лог за старыми значениями. В данном случае старые значения нужны не самому индексу для своей модификации, а читающей транзакции. И это ее головная боль, как эти значения получить, вся необходимая информация ей будет предоставлена, но, еще раз повторюсь, сам для себя индекс этой информацией не пользуется, а у нас речь именно о том как работает сам индекс, а не транзакции поверх него.
То бишь для того, что бы обратиться по индексу, сначало я должен обратиться к некоему глобальному индексу где храняться все измененный ключи, а затем к если не нашел то, к таблице??? Хорошо это вариант,а как быть при проходе по индексу????
и солнце б утром не вставало, когда бы не было меня
, берешь Грея, внимательно читаешь, потом берешь исходники Postgree, смотришь доки MSSQL и Oracle. И только после этого возвращаешься и мы продолжаем разговор про версионность. M>И таких категоричных и неверных утверждений ты больше не делаешь, если тебе ничего лучшего придумать не получается — это вовсе не значит, что лучшего алгоритма не существует.
А на пальцах никак???? А можно исходники MSSQL и Oracle???
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
V>> Мы как-то пытались обсуждать систему (и здесь на RSDN проскакивали эти обсуждения), как из одного мета-кода генерить две части, ту, что будет исполняться на серваке БД, и ту, что сервером приложений... В общем, ни к чему не пришли, ибо задача слишком многофакторная. M>Ну, не знаю насчет многофакторности, но если я правильно понял о чем ты, то вот у того же AVK такая система вполне себе работает.
Не вопрос просто написать систему, которая делит некоим образом код. Мы в тех обсуждениях уперлись в то, что само решение об перенесении кода на одну из сторон принимается исходя не только из структуры данных, но от их количества, связи с другими данными, количества данных в связанных наборах, а самое главное — от характера и сценариев использования. По сути, такая система должна вести run-time статистику, постепенно динамически подгоняя это разделение под реальную статистику сценариев.
V>> Поэтому работаем "по старинке", то бишь, используем базу как хранилище объектов, а весь SQL генериться в run-time и исполняется в рамках транзакций как батч. M>Отсюда опять-таки два вопроса, в чем проблема перенести и Run-time в Compile-time,
В компайл-тайм непонятно еще какая база будет в качестве бэкенда, у каждого адаптера есть свой SQL-рендерер.
M> и если уж нельзя то почему нельзя всю транзакцию передвавть одним батчем?
Дык, мы и передаем сгенерированный текст-батч SQL на выполнение в рамках одной транзакции. Просто вспоминая прошлые разработки, я не знаю куда бы я пихал теже самые блобы при таком вот раскладе. Получается, что напрямую использовать ср-ва ORM будет проблематично.
(Вернее тут необходимы уточнения... можно создавать запросы с параметрами, и в эти параметры пихать тонны данных и сверх-большие блобы, но вот жопа, это все-таки отдельные запросы, и нам придется тащить управление транзакциями на сервак приложения из БД, т.е. явно создать транзакцию, выполнить пару апдейтов и потом закоммитить. Или делать ручками как-то через временные таблицы, что означает ручное приседание вокруг DAL-а, в то время как сейчас у нас DAL полностью декларативный, а значит нам легко выполнять рефакторинг и развивать систему. А рефакторить БД из сотен таблиц и нескольких тысяч запросов — это в страшном сне не привидится... Вот такой вот набор противоречивых факторов меня и напрягает)
V>>Большинство систем сейчас именно так и написаны. Более того, в таких системах подменяется БД-адаптер и она продолжает с успехом использоваться на совершенно разных БД. M>Большинство — это в каком смысле? по количеству или по масштабам использования? M>Видишь ли, если брать какой-нибудь SAP, то он действительно написан примерно так, только вот он нижележащую БД использует исключительно как тупое хранилище, типа файловой системы (кстати, хороший вопрос, почему именно БД, а не файловую систему — в первую очередь из-за бакапов), у него даже подсистема транзакций своя и всю согласованность он обеспечивает сам. M>А вот в "наколенной" системе таким подходом можно добиться только того, что система будет с любой БД работать одинаково плохо.
Комментировать не могу, ибо это "общепринятая практика". Она диктуется тем, что "маленькие команды" поднимают "большие" задачи. Если бы вынуждены полностью вручную описывать писать персистентность своих данных в БД, и тем более, поддерживать это все up to date после рефакторинга, нам бы потребовалось в двое больше народу на разработку.
V>>Потому и говорю, что согласно твоей логике "у всех руки кривые". V>> Кстати, "погибшие" ObjectSpaces — из той же оперы. Ну и популярный Hibernate (+N) и сотни других аналогичных ORM-тулзов — тоже. M>Все вменяемые ORM, и озвученные тобой в том числе, позволяют работать с транзакциями в одном батче, и вообщем-то ни для кого не секрет, что использование их "в лоб", не задумываясь о том что ты делаешь, до добра не доводит.
Ну поэкпериментируй сам с NHibernate и с теми же большими блобами
M>И то что ты поступаешь так, вовсе не значит, что так поступают все, поэтому не обобщай...
Я как раз так не поступаю. У нас свой ORM-тул, построенный на базе RFD. Просто в текущей задаче не стоит вопрос генерирования очень больших текстов батчей, поэтому автогенерированный нами SQL нас устраивает.
V>> Я пока встречал лишь расплывчатые определения "длинных транзакций". И что характерно, мой характер работы с БД не попадает под эти определения. Но ты почему-то причислил и указал на это как на ошибку и далее построил рассуждения на этом. Жду обоснования. M>Ох. Длинная — это транзакция которая в процессе своей работы взаимодействует/зависит от ресурсов вне СУБД.
Оk. Т.е. если я явно в коде создал транзакцию, типа connection.BeginTransaction(), то это — длинная транзакция. Но понимаешь в чем дело... Когда я должен согласованно прочитать кучу данных, причем разнородную кучу данных... Более того, то, что будет в последней части кучи зависит от тех результатов, что пришли в первой части кучи... Получается, что для такого согласованного извлечения множества данных я должен вытаскивать их из базы в рамках одной транзакции, но я пока не представляю как это сделать в рамках одного батча у нас (просто решение о зачитке последующих кусков принимается исходя из состояний кешей для соотв. связанных сущностей, т.е. из текста SQL батча этот факт не разглядеть). Т.е., если бы все просто сводилось к серии запросов — то было бы проще... А так, я явно создаю транзакцию, управляю временем ее жизни ВНЕ БД, т.е. получается — создаю длинную транзакцию... И если в этот момент сервак приложений по каким-либо причинам грюкнется, то вот у нас и останется та самая подвисшая транзакция, "из-за неправильной архитектуры" (c) не мой. И что характерно, похоже, что многие репортовые тулы работают аналогично. Например у MS есть иерархический провайдер, что позволяет частично решить описанную проблему, но он у такой провайдер есть только к MS SQL.
V>>Это ты согласился или озвучил мое решение? M>Это я согласился, с рядом оговорок. В первую очередь потому, что мне на данный момент системы образца 99-го года доставляют исключительно ностальгический интерес. Я ценю изящество с каким вы выкрутились из сложившейся ситуации, но оставляю засобой право считать, что существовало более удачное решение.
Не знаю, я там в ветке с AVK предложил перенести эти же требования на сегодняшний день, предположив активное редактирование данных размером несколько сотен мег (видео, сырое аудио и т.д.).
Вопрос действительно интересный. Гораздо проще сделать систему которая обслуживает многие тысячи или миллионы коротких транзакций в сутки (типа — банковская платежная система), ибо БД идеально заточены имено под такие сценарии использования.
Так же вполне себе сущестуют медиа-серваки. Но там тоже характер работы с данными весьма специфичен, а именно: строка данных (пусть даже очень большая) заливается лишь однажды, а затем read-only.
Здравствуйте, AndrewVK, Вы писали:
V>>Дык, вроде даже специальные ср-ва есть.
AVK>Есть. Использовать пробовал? Я пробовал.
Я пробовал, когда создавал локальный кеш на основе MDB-формата. Периодически синхронизировал его с основным MS SQL серваком, причем, не по самой быстрой линии связи, в режиме транзакции, разумеется. Вроде, работало... Вернее, у меня даже в памяти подробности не отложились, видать ни с чем таким серьезным и непреодолимым не столкнулся.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты сильно ошибаешься, полагая что надежное транзактное хранилище, обеспечивающее ACID, можно сделать легко. Мне в свое время приходилось — поверь, это суперсложная задача, даже при наличии DTC и прочих. То, что на ваших задачах вам повезло на ряд моментов не напороться еще не означает, что ваш самопал надежнее БД.
Ну, смотри сам и покажи тонкие места:
— сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)
— записывает файл на диск
— после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)
— после этого, если все прошло успешно, т.е. никаких эксепшенов не произошло и мы их не сгенерили, то выполнение некоего удаленного метода с клиентской машины закончилось успешно, и форма, например, закрылась.
— если произошли какие-то ошибки, то клиенту показывается MessageBox с ошибкой, и он может либо опять попробовать что-то там сохранить, либо попробовать сохранить данные локально (т.е. перейти в режим off-line).
Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.
Здравствуйте, Cyberax, Вы писали:
>> C>Я встречал ровно одну задачу, в которой своя база данных была >> C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание >> C>иерархического хранилища внутри файла >> Дык, а как же Structured Storage от MS? C>Как раз оно и было То есть своя реализация IStorage.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, n0name2, Вы писали:
N>> очевидно что вторая транзакция достаточно сильно модифицирует индекс, вы хотите сказать что она будет заблокирована пока построение отчета (с использованием индекса) не закончится? M>Нет, читающая транзакция полезет в лог за старыми значениями. В данном случае старые значения нужны не самому индексу для своей модификации, а читающей транзакции. И это ее головная боль, как эти значения получить, вся необходимая информация ей будет предоставлена, но, еще раз повторюсь, сам для себя индекс этой информацией не пользуется, а у нас речь именно о том как работает сам индекс, а не транзакции поверх него.
На самом деле есть другой вариант
Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем. Ключи могут только удаляться или добавляться.
Ссылка на предыдущую версию ключа у ключей содержащих PK записи можно не держать, т.к. версию можно получить на уровне записи. Замещать удаленные ключи можно либо при модификации страницы.
Этот вариант подходит????
и солнце б утром не вставало, когда бы не было меня
vdimas wrote: >> > C>Я встречал ровно одну задачу, в которой своя база данных была >> > C>эффективнее какой-нибудь SQLite/BDB. Этой задачей было создание >> > C>иерархического хранилища внутри файла >> > Дык, а как же Structured Storage от MS? > C>Как раз оно и было То есть своя реализация IStorage. > А чем лучше "ихней"?
Хотя бы тем, что "собирает мусор" — в стандартной реализации при
удалении потока его страницы остаются в файле. И единственный способ
уменьшить его размер — создать новое хранилище и скопировать в него все
из старого.
Ну и с большими данными у меня более резво работает (позволяет делать
memory mapping через специальный интерфейс).
Здравствуйте, vdimas, Вы писали:
V>- сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)
Версионник значит. Транзакция в БД уже открыта?
V>- записывает файл на диск V>- после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)
Транзакцию БД закрываем?
V>- после этого, если все прошло успешно, т.е. никаких эксепшенов не произошло и мы их не сгенерили, то выполнение некоего удаленного метода с клиентской машины закончилось успешно, и форма, например, закрылась. V>- если произошли какие-то ошибки, то клиенту показывается MessageBox с ошибкой, и он может либо опять попробовать что-то там сохранить, либо попробовать сохранить данные локально (т.е. перейти в режим off-line).
V>Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.
Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако при отсылке результата коммита клиенту происходит сбой. Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две идентичных записи.
Сценарий посложнее. Клиент читает документ. Обращается к БД, считывает заголовок. Потом лезет к файлу и считывает его. После этого другой клиент этот документ грохает. Первый клиент в этот момент что то там в документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Есть. Использовать пробовал? Я пробовал.
Ну и я пробовал. По сравнению с прямым DTS — очень легко. А вот System.Transaction по сравнению с MTS — легче легкого. Он собственно и предназначен именно для построения своих транзакционных ресурсов. Сделать распределенные файловые транзакции, несколько строк кода. Другой вопрос насколько он будет надежен rollback. В случае если у тебя файлы по несколько сотен мегабайт, то формирование каждой копии будет тяжелой операцией. Если rollbaчить в самом файле, то уже меньше гарантий что будет сделана система, которая не упадет в случае выключения питания. И достичь скорости БД по записи на больших данных, тоже вряд ли удастся. Вобщем, серьезная система с полпинка тут не построишь.
Здравствуйте, Cyberax, Вы писали:
>> C>Как раз оно и было То есть своя реализация IStorage. >> А чем лучше "ихней"? C>Хотя бы тем, что "собирает мусор" — в стандартной реализации при C>удалении потока его страницы остаются в файле. И единственный способ C>уменьшить его размер — создать новое хранилище и скопировать в него все C>из старого.
C>Ну и с большими данными у меня более резво работает (позволяет делать C>memory mapping через специальный интерфейс).
Здравствуйте, AndrewVK, Вы писали:
V>>- сервер приложений генерит уникальную версию файла (т.е. генерится уникальное имя)
AVK>Версионник значит. Транзакция в БД уже открыта?
Пусть мы просто сгенерировали уникальный идентификатор нового документа и не более того. Нам же надо сохранить новую версию под уникальным именем.
V>>- записывает файл на диск V>>- после проверки записанного файла заносит в базу запись о нем (т.е. подменяет линк на более новую версию... триггер таблицы мог снести старое значение в журнал изменений версий)
AVK>Транзакцию БД закрываем?
Прямо там же, где и открывали — все можно выполнить на уровне базы за "один заход", то бишь батч, и связать новый идентификатор со сгенерированной версией.
V>>Я чего-то в упор не вижу причин нарушений целостности БД и рассогласования данных по вине разработчика. И последовательность действий вроде тривиальная.
AVK>Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако при отсылке результата коммита клиенту происходит сбой. Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две идентичных записи.
Ну... это очень грубо. Клиент же не просто шлет: "сохрани вот этот мусор хоть как нибудь", он же пошлет примерно так: "сохрани вот эту версию под новым номером, и вот тебе мой текущий кукис". Мы лезем, проверяем версии, видим, кто именно изменил и под каким кукисом. Если этот же клиент и под тем же кукисом — понимаем, что он нас не понял. В смысле, с первого раза не понял и повторяем ответ. Если это был не он и текущая версия не совпадает с его заявленной, то выдаем некий диалог, где честно говорим о конфликте (типа как в CVS). В принципе, statefull-модель и управление блокировками документов (на уровне сервера приложений, а не БД) позволяет частично разруливать этот момент. Если же это тот же клиент, но с более свежым кукисом, значит, сохраняем по новой и возвращаем результат по новой (новое имя версии). Если это тот же клиент но с более старыми кукисами — кричим "kernel panic, we are sinking", или "we are under hacking" и даем отлуп
AVK>Сценарий посложнее. Клиент читает документ. Обращается к БД, считывает заголовок. Потом лезет к файлу и считывает его. После этого другой клиент этот документ грохает. Первый клиент в этот момент что то там в документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
Да... Управление доступом к объектам... Мне удалось первый раз качественно разрулить это дело только в системе, где я полностью управлял сессиями. В сервере на дотнет это сделать оказалось еще легче. Более того, сессия является спонсором для всех временных и statefull сесионных объектов.
Описанный тобой сценарий достигается даже если мы все храним в БД:
— клиент читает список некоего каталога (то бишь — заголовки документов)
— выбирает один из них
— пока он выбирал, кто-то грохнул интересующий документ... Тот же упс...
А твой "Упс" надо разруливать примерно так:
— выдать серверу приложений уникальный аккаунт на доступ к репозиторию (т.е. исключить правку содержимого каталога вне системы)
— когда удаляется документ, то, разумеется, сначала удаляется запись из базы
— когда создается, то наоборот — сначала записывается и проверяется файл, только потом вноситься запись в БД.
Файлы документов никогда не изменяются, по очевидной причине. Всегда сохраняются новые версии. После сохранения новой версии что делать со старой? А это уже пусть политика и настройки решают.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну вот смотри. Предположим пишем файл. Файл записывается успешно. Далее пишем в БД. БД тоже отрабатывает успешно и транзакцию закрывает. Однако при отсылке результата коммита клиенту происходит сбой. Клиент думает что транзакция не завершилась и шлет данные по новой. В итоге в БД две идентичных записи. AVK>Сценарий посложнее. Клиент читает документ. Обращается к БД, считывает заголовок. Потом лезет к файлу и считывает его. После этого другой клиент этот документ грохает. Первый клиент в этот момент что то там в документе анализирует и на его основании вносит что то в БД. Упс, приплыли.
Это все достаточно легко решаемые проблемы. Есть другая, трудно нерешаемая. У нас есть две системы и две системы backup. Одна система бэкапится в момент t1 другая в момент t2, в результате при восстановлении изменения t2-t1 на одной из систем отсутсвует. То есть нет никакой гарантии что существует файл прописанный в БД, или наоборот, что для файла существует запись в БД.
Здравствуйте, Serginio1, Вы писали:
S>То бишь для того, что бы обратиться по индексу, сначало я должен обратиться к некоему глобальному индексу где храняться все измененный ключи, а затем к если не нашел то, к таблице???
Нет.
Здравствуйте, Serginio1, Вы писали:
S> Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем.
Да, только ссылка на предыдущую версию данного ключа.
S> Ключи могут только удаляться или добавляться.
Да. Причем это требование никак не связано с версионностью. Любая модификация ключа в дереве- это всегда удаление старого значения и добавление нового.
S> Этот вариант подходит????
Примерно так и работает сиквел.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Serginio1, Вы писали:
S>> Запись ключа инднкса состоит из ключа, номера транзакции, статуса (удалена, добавлена) и ссылку на предудущую транзакцию с данным ключем. M>Да, только ссылка на предыдущую версию данного ключа.
S>> Ключи могут только удаляться или добавляться. M>Да. Причем это требование никак не связано с версионностью. Любая модификация ключа в дереве- это всегда удаление старого значения и добавление нового.
На уровне промышленных БД да, на уровне своего кода не всегда.
S>> Этот вариант подходит???? M>Примерно так и работает сиквел.
А на пальцах сложно было объснить, всё своим умом доходить надо
Это один из вариантов. Версионность на уровне страниц оправдана при массовых модификациях. Напрмер многострочная часть документа, и его движения. Здесь она оправдана. Кроме того версионность на страницы увеличивает скорость чтения (нужно сверять только версию страницы).
Учитывая, что больше чтения чем записей такой подход вполне оправдан. Кроме того собирать ненужные страницы легче чем дефрагментировать дерево от ненужных версий на уровне единичных ключей, плюс вырожденность страниц будет большой при частых удалениях.
и солнце б утром не вставало, когда бы не было меня
Автор(ы): Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом
Мы уже победили, просто это еще не так заметно...
То есть своя реализация IStorage.
