Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, eao197, Вы писали:
S>>>Одно из требований (желаний) я определил: Надо сделать так, чтобы при изменении одного конца связи не нужно было грузить всю коллекцию (или объект со ссылкой) на другом конце.
E>>Но тогда нужно определить еще и условия, при которых этого не нужно делать. Ведь если все коллекции ссылок будут обрабатываться таким образом независимо от их размера, то накладные расходы на хранение этих коллекций могут оказаться слишком высокими.
S>В базах данных, в этом смысле, есть один очень положительный момент: основное время тратиться на работу с диском. Это само по себе, конечно очень плохо, но зато можно не экономить на работе в кэше. То есть формат данных в кэше можно сделать и более навороченным, по сравнению, например, со стандартными коллекциями C++.
Чесно говоря я не понял, причем тут кэш и экономия времении, а так же навороченность коллекций
S>В данном конкретном случае — всегда нужно стремиться к тому, чтобы не загружать зря коллекцию с другой стороны. Так как накладные расходы на загрузку будут несоизмеримо больше, чем работа с кэшем.
Это да, согласен.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
S>Я о чем и говорю: коллекции в таком случае должны быть построены так, чтобы не нужно было подгружать ее вообще. Может быть даже просто запоминать все изменения в какой-то другой структуре, для того чтобы когда коллекция реально потребуется — загрузить ее (коллекцию) и скорректировать.
S>Тут еще фишка в том, что в большинстве случаев коллекции — маленькие и без разницы грузить ее всю или только часть. Это все равно одно обращение к базе. А вот если совсем не грузить , это да, это хорошо.
S>А еще может быть и обратная ситуация. Когда коллекция уже загружена, и из нее, например, удаляем объект. Или еще круче: делаем просто Clear(). И прикинь, что для этого необходимо будет подгрузить все соответствующие children объекты, чтобы изменить в них ссылки.
S>А ведь и та и другая ситуация может быть с равной вероятностью. И придумать алгоритм, который бы не грузил лишнее в обоих случаях — вот хитрая задачка.
Все, что применимо в обычном программировании, применимо и для БД. Реально можно обходится и без индексов для подчиненных коллекций если ее применять ввиде двухнаправленного связного списка, а начало и конец держать в родителе (при этом запись может содержать относительное место в БД например номер записи). При этом всиавка,Clear() вообще простая операция.
Еще лично мое видение и повторюсь в сотый раз, это делать объектную надстройку над записями (записью) в БД. Нужно только считать данные с нужно страницы, и не держать огромное количество объектов в памяти, а только те которые необходимы при данной транзакции.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
BaZa wrote:
> C>Я работал немного с Versant в свое время — Hibernate его (по моим > C>ощущениям) намного превосходит в удобстве. > Просто вопрос: а с каким именно продуктом Вы работали? > (действительно интересно)
C FastObjects .NET — писал небольшой проектик, в нем уже FastObjects
использовался.
Здравствуйте, Serginio1, Вы писали:
S> Все, что применимо в обычном программировании, применимо и для БД. Реально можно обходится и без индексов для подчиненных коллекций если ее применять ввиде двухнаправленного связного списка, а начало и конец держать в родителе (при этом запись может содержать относительное место в БД например номер записи). При этом всиавка,Clear() вообще простая операция.
Дело в том, что речь идет о двунаправленной связи. И если ты делаешь в коллекции Clear(), то необходимо еще учтановить в null все ссылки с противоположной стороны, то есть в возможно большом количестве объектов.
V>Я же русским языком сказал, что в ячейках хеш-таблицы хранятся сортированные индексы, в которых всегда поиск NLog(N). V>Я все-таки буду писать подобную хеш-таблицу для второго дотнета (нужна самим подобная), учитывая твое замечание, предусмотрю в конструкторе фабрику для создания сортированных индексов в ячейках таблицы. Т.е., если будут подозрения плохое хеширование, можно подать фабрику для B+ индексов в ячейках. По умолчанию будет простой сортированный массив, в котором опять же трудоемкость не более NLog(N).
Таких хэш таблиц много, но опять же ты упрешься в неопределенность размера индекса и в итоге получишь гибрид хэш таблицы с Б+ деревом в каждой ячейке. Б+ деревья сами по себе очень универсальны и особенно подходят для неопределенного размера. Другое дело, что для больших структур лучше делать Б+ дерево на их хэшах со сравнением при выборе диапозона поискового хэша с искомым значением.
Кстати разница в поиске не столь огромна для Б+ деревьев и хэш таблиц. На практике всего в 4 раза http://gzip.rsdn.ru/article/alg/tlsd.xml
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Все, что применимо в обычном программировании, применимо и для БД. Реально можно обходится и без индексов для подчиненных коллекций если ее применять ввиде двухнаправленного связного списка, а начало и конец держать в родителе (при этом запись может содержать относительное место в БД например номер записи). При этом всиавка,Clear() вообще простая операция.
S>Дело в том, что речь идет о двунаправленной связи. И если ты делаешь в коллекции Clear(), то необходимо еще учтановить в null все ссылки с противоположной стороны, то есть в возможно большом количестве объектов.
То бишь упираемся в GC . Но пятьже все зависит от организации данных. Возможно держать для каждой записи некий список ссылающихся объектов, а в ссылающихся объектах держать не только ссылку, но и адрес в этом списке, для быстрого удаления при смене ссылки.
Но это так фантазии не слишком продуманные
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Дело в том, что речь идет о двунаправленной связи. И если ты делаешь в коллекции Clear(), то необходимо еще учтановить в null все ссылки с противоположной стороны, то есть в возможно большом количестве объектов.
S> То бишь упираемся в GC . Но пятьже все зависит от организации данных. Возможно держать для каждой записи некий список ссылающихся объектов, а в ссылающихся объектах держать не только ссылку, но и адрес в этом списке, для быстрого удаления при смене ссылки.
Неа. Я не про это вовсе. Здесь же речь идет о кэшировании объектов базы данных. Вот это "возможно большое количество объектов" может быть вообще не подгружено в кэш. И что тогда делать? Тупой вариант — это подгрузить их все, изменить в каждом поле, и сохранить эти изменения обратно на диск. Но, это плохой вариант.
Здравствуйте, stalcer, Вы писали:
S>Неа. Я не про это вовсе. Здесь же речь идет о кэшировании объектов базы данных. Вот это "возможно большое количество объектов" может быть вообще не подгружено в кэш. И что тогда делать? Тупой вариант — это подгрузить их все, изменить в каждом поле, и сохранить эти изменения обратно на диск. Но, это плохой вариант.
А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам?
S>Неа. Я не про это вовсе. Здесь же речь идет о кэшировании объектов базы данных. Вот это "возможно большое количество объектов" может быть вообще не подгружено в кэш. И что тогда делать? Тупой вариант — это подгрузить их все, изменить в каждом поле, и сохранить эти изменения обратно на диск. Но, это плохой вариант.
Я вообще противник кэширования объектов, либо только в одной транзакции. В сложных системах один из лучших вариантов, является много версионных читателей, один экслюзивный писатель. Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Alexey Rovdo, Вы писали:
AR>А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам?
Здравствуйте, Serginio1, Вы писали:
S> Я вообще противник кэширования объектов, либо только в одной транзакции. В сложных системах один из лучших вариантов, является много версионных читателей, один экслюзивный писатель. Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здесь вроде речь идет о движке СУБД, а не о ORM или других надстройках. Сам то движок должен как-то кэшировать для выполнения запросов и update'ов, хранимые процедуры (методы) должны как-то работать. Не с диском же напрямую.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам?
Здесь еще одна хитрость в том, как эти данные хранятся на диске. Если двунаправленная связь храниться на диске тоже в двух местах, т.е. со стороны каждого из связываемых объектов, то и обновлять придется оба конца. Независимо от того, были все объекты подгружены в кэш или не были.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Я вообще противник кэширования объектов, либо только в одной транзакции. В сложных системах один из лучших вариантов, является много версионных читателей, один экслюзивный писатель. Re[20]: Объектно-ориентированные БД: основные принципы, орга
S>Здесь вроде речь идет о движке СУБД, а не о ORM или других надстройках. Сам то движок должен как-то кэшировать для выполнения запросов и update'ов, хранимые процедуры (методы) должны как-то работать. Не с диском же напрямую.
Прошу прощения, как то потерял нить. Я это о своем эфимерном движке. Ну а с диском помоему уже давно никто не работает при кэшированных страницах. Просто доступ к ним возможенн только при своей реализации.
Еще раз прошу прощения за высказывания в невпопад.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Alexey Rovdo, Вы писали:
AR>А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам?
Тут встанет другая проблема. Транзакционный механизм с их savepoint's.
AR>>А почему бы просто не подождать до тех пор, пока они не подгрузятся в кэш по какой-либо иной надобности? А пока просто оставить специальную метку на месте удаленного объекта. Т.е. ссылки редактировать не сразу, а только по мере обращения к соответствующим объектам? GZ>Тут встанет другая проблема. Транзакционный механизм с их savepoint's.
Что то вы не так поняли. Я не имел ввиду никакого нарушения транзакционной целостности. Просто внутренние механизмы ООСУБД вовсе не обязаны физически удалять с диска (исправлять) те элементы, которые мы удалили. Достаточно пометить этот элемент как удаленный, а дальше — работа GC, который может исполняться асинхронно вне транзакции. То же самое и с исправлением ссылок. Если после поднятия ссылки (уже в другой задаче) оказывается, что она указывает на помеченный как удаленный элемент, то без уведомления приложения СУБД сама может обнулить соответсвующую ссылку и передать дальше уже null, а объект на диске исправить (вписать нул в хначение ссылки). Это очень похоже на то, как в FastObjects работает механизм версионности. Например, если мы исправили описание класса и удалили один из его атрибутов, то это вовсе не значит, что СУБД тут же перелопатит всю базу и изменит записи всех объектов данного класса (хотя мы и можем заставить ее сделать это). Вместо этого она будет править хранимые объекты только по мере их очередного редактирования, автоматически переводя их в новую версию при сохранении.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Что то вы не так поняли. Я не имел ввиду никакого нарушения транзакционной целостности. Просто внутренние механизмы ООСУБД вовсе не обязаны физически удалять с диска (исправлять) те элементы, которые мы удалили. Достаточно пометить этот элемент как удаленный, а дальше — работа GC, который может исполняться асинхронно вне транзакции. То же самое и с исправлением ссылок. Если после поднятия ссылки (уже в другой задаче) оказывается, что она указывает на помеченный как удаленный элемент, то без уведомления приложения СУБД сама может обнулить соответсвующую ссылку и передать дальше уже null, а объект на диске исправить (вписать нул в хначение ссылки). Это очень похоже на то, как в FastObjects работает механизм версионности. Например, если мы исправили описание класса и удалили один из его атрибутов, то это вовсе не значит, что СУБД тут же перелопатит всю базу и изменит записи всех объектов данного класса (хотя мы и можем заставить ее сделать это). Вместо этого она будет править хранимые объекты только по мере их очередного редактирования, автоматически переводя их в новую версию при сохранении.
В данном случае мы подразумеваем, что можем выловить некорректную ситуацию (независимо от типа доступа) еще на уровне обработки метаданных. Но если у нас метаданные не затронуты. В результате мы получаем запрос, в котором мы должна учитывать, что информация о удаленной ссылки не лежит именно в данном объекте. Там проблемы начнутся нехилые.
Что касается транзакционного механизма. Как примерно работает нормальный (я бы сказал самый распространенный) механизм транзакции. Все изменения производятся в кольцевом логе. После определенного момента — происходит сброс изменений на диск (savepoint). После этого лог можно перезаписывать. Система достаточно проста и выдерживает отключение питания. У нас получается несколько неприятная вещь. С одной стороны, часть ссылок уже нормализована, а часть нет. Как это отразится на функционировании восстановления, с ходу не скажу, но то что надо что-то делать, вполне понятно.
Очень интересует вопрос функционирования GC для ООБД. То бишь, в персистентном хранилище(большом и медленном). Не мог бы кто-нибудь "плюнуть" какую-нибудь ссылочку. Должна быть занятная вещь.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Alexey Rovdo, Вы писали:
AR>>Что то вы не так поняли. Я не имел ввиду никакого нарушения транзакционной целостности. Просто внутренние механизмы ООСУБД вовсе не обязаны физически удалять с диска (исправлять) те элементы, которые мы удалили. Достаточно пометить этот элемент как удаленный, а дальше — работа GC, который может исполняться асинхронно вне транзакции. То же самое и с исправлением ссылок. Если после поднятия ссылки (уже в другой задаче) оказывается, что она указывает на помеченный как удаленный элемент, то без уведомления приложения СУБД сама может обнулить соответсвующую ссылку и передать дальше уже null, а объект на диске исправить (вписать нул в хначение ссылки). Это очень похоже на то, как в FastObjects работает механизм версионности. Например, если мы исправили описание класса и удалили один из его атрибутов, то это вовсе не значит, что СУБД тут же перелопатит всю базу и изменит записи всех объектов данного класса (хотя мы и можем заставить ее сделать это). Вместо этого она будет править хранимые объекты только по мере их очередного редактирования, автоматически переводя их в новую версию при сохранении. GZ>В данном случае мы подразумеваем, что можем выловить некорректную ситуацию (независимо от типа доступа) еще на уровне обработки метаданных. Но если у нас метаданные не затронуты. В результате мы получаем запрос, в котором мы должна учитывать, что информация о удаленной ссылки не лежит именно в данном объекте. Там проблемы начнутся нехилые.
Я думаю, что здесь проблем нет. Просто такая обработка лежит на отдельном уровне абстракции. Где-то выше кэша, но ниже планировщика запросов (или какая там архитектура будет).
GZ>Что касается транзакционного механизма. Как примерно работает нормальный (я бы сказал самый распространенный) механизм транзакции. Все изменения производятся в кольцевом логе. После определенного момента — происходит сброс изменений на диск (savepoint). После этого лог можно перезаписывать. Система достаточно проста и выдерживает отключение питания. У нас получается несколько неприятная вещь. С одной стороны, часть ссылок уже нормализована, а часть нет. Как это отразится на функционировании восстановления, с ходу не скажу, но то что надо что-то делать, вполне понятно.
Здесь я так же не вижу проблемы. Главное, чтобы надежно сохранился объект-ссылка, в котором установлен признак, что она уже некорректна.
GZ>Очень интересует вопрос функционирования GC для ООБД. То бишь, в персистентном хранилище(большом и медленном). Не мог бы кто-нибудь "плюнуть" какую-нибудь ссылочку. Должна быть занятная вещь.
У Константина Книжника в Goods подобный механизм был реализован. Он даже в своей диссертации какую-то теорему доказывал на эту тему. Если не ошибаюсь о том, что объект можно удалять из БД, если он не достижим по ссылкам из других объектов.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
GZ>>В данном случае мы подразумеваем, что можем выловить некорректную ситуацию (независимо от типа доступа) еще на уровне обработки метаданных. Но если у нас метаданные не затронуты. В результате мы получаем запрос, в котором мы должна учитывать, что информация о удаленной ссылки не лежит именно в данном объекте. Там проблемы начнутся нехилые.
E>Я думаю, что здесь проблем нет. Просто такая обработка лежит на отдельном уровне абстракции. Где-то выше кэша, но ниже планировщика запросов (или какая там архитектура будет).
Смотри что получается. У нас есть запрос вместе с where exist(object.reference) Три варианта:
1. Мы просматриваем объект на который ссылаемся. Плохо. Избыточное чтение.
2. Мы кладем это в запрос. Плохо. В результате у нас получается очень неприятное условие и длинное.(в ОРМ — более чем криминально, но для ООДБ этот вариант я считаю наименее плохим)
3. Мы смотрим после выполнения запроса. Плохо. Избыточное чтение.
GZ>>Что касается транзакционного механизма. Как примерно работает нормальный (я бы сказал самый распространенный) механизм транзакции. Все изменения производятся в кольцевом логе. После определенного момента — происходит сброс изменений на диск (savepoint). После этого лог можно перезаписывать. Система достаточно проста и выдерживает отключение питания. У нас получается несколько неприятная вещь. С одной стороны, часть ссылок уже нормализована, а часть нет. Как это отразится на функционировании восстановления, с ходу не скажу, но то что надо что-то делать, вполне понятно.
E>Здесь я так же не вижу проблемы. Главное, чтобы надежно сохранился объект-ссылка, в котором установлен признак, что она уже некорректна.
Я тоже явно не вижу. Но тут нужно сохранять не ссылку, а состояние GC. Что может быть очень накладным и сложным процессом.(сходу не скажу).
GZ>>Очень интересует вопрос функционирования GC для ООБД. То бишь, в персистентном хранилище(большом и медленном). Не мог бы кто-нибудь "плюнуть" какую-нибудь ссылочку. Должна быть занятная вещь.
E>У Константина Книжника в Goods подобный механизм был реализован. Он даже в своей диссертации какую-то теорему доказывал на эту тему. Если не ошибаюсь о том, что объект можно удалять из БД, если он не достижим по ссылкам из других объектов.
Тут несколько другой GC. Второй тип ссылочной целостности, в котором при удалении объекта — все ссылки на него обнуляются. Хотя в принципе это можно организовать более простым способом чем в goods. При наличии метаданных, ессно.
Здравствуйте, eao197, Вы писали:
E>У Константина Книжника в Goods подобный механизм был реализован. Он даже в своей диссертации какую-то теорему доказывал на эту тему. Если не ошибаюсь о том, что объект можно удалять из БД, если он не достижим по ссылкам из других объектов.
GC в FastObjects t7 работает фактически по данному принципу (там только всякие настроечки имеются).
, это да, это хорошо.
. Но пятьже все зависит от организации данных. Возможно держать для каждой записи некий список ссылающихся объектов, а в ссылающихся объектах держать не только ссылку, но и адрес в этом списке, для быстрого удаления при смене ссылки.
