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



По сути механизм у меня схож с твоим, окромя того, что для каждой записи свой набор страниц. Но при твоем подходе нужны обязательно индексы , хэш таблицы (или я не прав). У меня запись всегда стоит на своем месте ( Даже если прикрутить версионность). Я хотел реализовать не типичную для БД архитектуру.
Просто захотелось выпендриться для Себя и побить кулаком в грудь.
А так как у каждого типа свой набор страниц, то удаленные записи ввиде однонаправленного списка очень бысро указывали новое место.
И прежде всего резко ограничить присутствие индексов. Кстати тоже не сделал возврата пустых страниц, все равно рано или поздно они бы использовались.
Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ????

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

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



S> По сути механизм у меня схож с твоим, окромя того, что для каждой записи свой набор страниц. Но при твоем подходе нужны обязательно индексы , хэш таблицы (или я не прав). У меня запись всегда стоит на своем месте ( Даже если прикрутить версионность). Я хотел реализовать не типичную для БД архитектуру.
S> Просто захотелось выпендриться для Себя и побить кулаком в грудь.
S> А так как у каждого типа свой набор страниц, то удаленные записи ввиде однонаправленного списка очень бысро указывали новое место.
S>И прежде всего резко ограничить присутствие индексов. Кстати тоже не сделал возврата пустых страниц, все равно рано или поздно они бы использовались.
Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.

S>Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ????
Сейчас напишу тебе на мыло (а то offtop)

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

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


GZ>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.
У меня номер записи прописывался как Int64
S>>Глеб а ты кстати вроде на RSDN Group ходишь. Давай пивка попьем пообщаемся ????
GZ>Сейчас напишу тебе на мыло (а то offtop)

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

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

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


GZ>>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.
S> У меня номер записи прописывался как Int64
Сорри, ляпнул не подумавши.
Я просто прошел немного больше, и у меня oid разыменовывался в оперативную память с объектом на странице. Соответсвенно по одному и тому же oid — адресавался объект в странице на диске, и объект на уже загруженной странице в памяти.

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

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

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

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


GZ>>>Я также ставил условие 64-разрядного доступа. Тут уж никак не обойдешься без косвенной адресации.
S>> У меня номер записи прописывался как Int64
GZ>Сорри, ляпнул не подумавши.
GZ>Я просто прошел немного больше, и у меня oid разыменовывался в оперативную память с объектом на странице. Соответсвенно по одному и тому же oid — адресавался объект в странице на диске, и объект на уже загруженной странице в памяти.
Понял. Резонно. Когда хотел кэшировать страницы, хотел держать их ввиде хэш таблицы . Так как запись фиксирована, то нужно былобы найти страницу если она кэширована либо ее загрузить. А смещение в странице заранее известно, без лишней коственности.
Но нужно следить за их количеством, строить статистику итд. По сути система сама за этим следит и решил не заморачиваться.

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

E>ИМХО, причины в том, что ООСУБД на момент принятия ODMG были слишком разными. В POET, например, мне заполнилась работа с ссылками. У них, кажется были четыре режима работы с сылками объекта при выполнении таких операций как загрузка, блокировка и удаление (только сам объект, сам объект и все его ссылки и пара промежуточных вариантов, не помню уже каких). В ODMG этих возможностей не было. Поэтому пользователям POET нужно было решать, либо использовать уникальные возможности POET, но терять портабельность, либо обеспечивать портабильность своих приложений, но отказываться от преимуществ POET. Понятно, что POET Software эта ситуация так же не очень нравилась. Поэтому они и не спешили делать свою СУБД 100% совместимой с ODMG. И у других производителей ООСУБД были, вероятно, схожие мотивы.
Да не в этом проблема. Просто парни, которые проектировали ODMG, слишком многого хотели. Они захотели получить продукт простым сложением SQL+OOP. Увы — очень быстро оказалось, что математика не успевает за этими хотениями. В итоге получился стандарт, буквальное следование которому приведет к:
1. Необходимости поддерживать конструкции, неиспользуемые в 99.9% случаев
2. Предоставлению программисту возможности легким движением руки породить запрос, не поддающийся оптимизации
Поэтому большинство реализаций банально игнорируют те части стандарта, которые не очень нужны, а также те, которые трудно сделать. В итоге страдает как ассоциативный доступ (реляционные черты), так и полиморфизм (объектно-ориентированные черты).
Если бы разработчики ODMG меньше думали о том, как сделать язык обратно совместимым с SQL, а больше о реализации, то мы, вполне возможно, сейчас бы считали RDBMS чем-то таким, что существовало в далеком прошлом.

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

<...>
S>Да не в этом проблема. Просто парни, которые проектировали ODMG, слишком многого хотели. Они захотели получить продукт простым сложением SQL+OOP. Увы — очень быстро оказалось, что математика не успевает за этими хотениями. В итоге получился стандарт, буквальное следование которому приведет к:
S>1. Необходимости поддерживать конструкции, неиспользуемые в 99.9% случаев
S>2. Предоставлению программисту возможности легким движением руки породить запрос, не поддающийся оптимизации
S>Поэтому большинство реализаций банально игнорируют те части стандарта, которые не очень нужны, а также те, которые трудно сделать. В итоге страдает как ассоциативный доступ (реляционные черты), так и полиморфизм (объектно-ориентированные черты).
S>Если бы разработчики ODMG меньше думали о том, как сделать язык обратно совместимым с SQL, а больше о реализации, то мы, вполне возможно, сейчас бы считали RDBMS чем-то таким, что существовало в далеком прошлом.

Думаю, что проблем было не одна и не две, и даже не три. Поэтому, имхо, и я прав, и ты прав.
Только мне кажется, что ODMG не был с нуля спроектирован. А за основу была взята какая-то (сейчас уже не вспомню какая), особо продвинутая на тот момент, ООСУБД. Затем в ODMG напихали еще по мелочам. И получили мертворожденный продукт.

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

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

S>>А насчет эффективности для конкретной задачи это ты зря.
GZ>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.

Здравствуйте, GlebZ, Вы писали:
GZ>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta.
Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.

Здравствуйте, GlebZ, Вы писали:
GZ>Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая).
Не, там все по-другому. Ведь есть гарантия, что запись не пересекает границу страницы! А заполненность страниц проверяется при помощи битмэпов. Дефрагментация нужна далеко не всегда — у нас есть гарантия повторного использования очистившихся страниц! Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать, а во-вторых обязанность следить за ссылочной целостностью лежит не на нем.

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

E>Думаю, что проблем было не одна и не две, и даже не три. Поэтому, имхо, и я прав, и ты прав.
E>Только мне кажется, что ODMG не был с нуля спроектирован. А за основу была взята какая-то (сейчас уже не вспомню какая), особо продвинутая на тот момент, ООСУБД. Затем в ODMG напихали еще по мелочам. И получили мертворожденный продукт.
На тот момент особо продвинутая ODBMS была ровно одна: GemStone. И ODMG, по странному стечению обстоятельств, никакого отношения к ней не имеет (кроме изначальной стандартизации биндинга к SmallTalk и С++. Кстати, добавление в этот список Java было, насколько я помню, основным нововведением в ODMG 2).
Если посмотреть историю научных публикаций на тему ODBMS, то в течение 80х виден растущий интерес к OODB вообще, исследования разных подходов... Начиная с 1993, многие авторы перестают издавать статьи (судя по всему, их детища пали под гнетом стандарта). Остальные бьются над одним вопросом — как обойти ограничения OQL для получения приемлемой производительности. В конце 90х большинство DB-публикаций относится к Fuzzy, Full-text, XML и прочей Web-мишуре.

Sinclair пишет:
> На самом деле для таких простеньких ООДБМС есть несложный вариант
> транзакционности. WriteAhead лог реализуется при помощи перехвата всех
> методов объектов и протоколировании этих вызовов. Регулярно делается
> чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше
> этого момента считаются ненужными и подлежат перезаписи. При старте базы
> выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог
> сканируется в поисках этого чекпоинта, и выполняется воспроизведение
> всех транзакций, для которых стоит метка "commited". Для небольших
> объемов (в пределах ~100 Mb) на современном железе это вполне нормально
> работает.

afaik, prevayler именно так и работает

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

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
S>Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta.
S>Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.
Там к каждому объекту можно прикрутить параметр PCTINCREASE. В нем лежат проценты увеличения. То есть, при аллокации следующего экстента Oracle увеличивает его размер на эту величину. В результате, уменьшается кол-во аллокаций в зависимости от объема данных.

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

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

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

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

S>>>А насчет эффективности для конкретной задачи это ты зря.
GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.
С одной стороны его делать надо. С другой стороны — я имел ввиду порядок сохранения в хранилище(реальные указатели сохраняются последние, старые данные по возможности можно сохранить). При сбое на логгировании — в данном случае получаем деструкцию файла и неизвестное состояние. По механизму, нормальный лог не намного отличается от данного(просто сохранять в кольцевой список).
Если мы не можем запускать компенсирующие действия — у нас еще есть варианты?

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

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



При таком подходе можно вообще без БД обойтись, используя гибернейт (или как его ) (запись памяти процесса на диск).
Кстати народ использует http://www.gotdotnet.ru/Forums/CommonForum/115593.aspx и живет спокойно.

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая).
S>Не, там все по-другому. Ведь есть гарантия, что запись не пересекает границу страницы! А заполненность страниц проверяется при помощи битмэпов. Дефрагментация нужна далеко не всегда — у нас есть гарантия повторного использования очистившихся страниц!
Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).

Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный? Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора?

S>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать,
Что значит явно? В конце транзакции?

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

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

GZ>Там к каждому объекту можно прикрутить параметр PCTINCREASE. В нем лежат проценты увеличения. То есть, при аллокации следующего экстента Oracle увеличивает его размер на эту величину. В результате, уменьшается кол-во аллокаций в зависимости от объема данных.

Честно говоря, в действительности строение хранилища Oracle значительно более сложное. Оно более продвинутое чем в MS SQL, но на мой взгляд сильно избыточный механизм. здесь

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

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
S>Круто! А на чем это было реализовано? Я вот сейчас потихоньку ковыряюсь с оптимизацией полиморфных ассоциативных запросов в управляемых средах. Экспериментирую на .Net 2.0 beta.
S>Когда я получу query optimizer, потребуется хранилище и менеджер транзакций, к которому можно будет его прикрутить.

Круто! "Полиморфных ассоциативных запросов в управляемых средах" -- это звучит. Сразу наукой повеяло
Это в рамках аспирантуры и кандидатской диссертации?

Но вот мне интересно, а что query optimizer оптимизирует, если у вас нет хранилища и менеджера транзакций? Или есть предположение о наличи индексов по конкретным атрибутам, а уже как они реализованы -- это уже другой уровень абстракции?

И что используется в качестве языка запросов?

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

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

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

S>>>А насчет эффективности для конкретной задачи это ты зря.
GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
S>На самом деле для таких простеньких ООДБМС есть несложный вариант транзакционности. WriteAhead лог реализуется при помощи перехвата всех методов объектов и протоколировании этих вызовов. Регулярно делается чекпоинт — т.е. состояние базы скидывается на диск. Лог-записи старше этого момента считаются ненужными и подлежат перезаписи. При старте базы выполняется чтение сигнатуры чекпоинта, которому она соответствует, лог сканируется в поисках этого чекпоинта, и выполняется воспроизведение всех транзакций, для которых стоит метка "commited". Для небольших объемов (в пределах ~100 Mb) на современном железе это вполне нормально работает.

Если уж БД совсем маленькая, в пределах 50-70Mb, и ее обновление можно производить сразу всей (т.е. полной перезаписью), то можно применять совсем простой механизм защиты от сбоев. Записывать сначала все содержимое БД в отдельный файл, например, с расширением .tmp. Если запись не была прервана сбоем, то файл флушируется и закрывается. Затем переименовывается в нужное имя. Если же запись прерывается сбоем, то файл так и остается под расширением .tmp и затем просто игнорируется. В нормальной журналируемой файловой системе (типа NTFS, Ext3, ReiserFS, ...) успешное флуширование и закрытие файла уже будет гарантировать логическую целостность информации. Ну а со сбоями носителя уже ничего не сделаешь.

Здравствуйте, eao197, Вы писали:
E>Круто! "Полиморфных ассоциативных запросов в управляемых средах" -- это звучит. Сразу наукой повеяло
E>Это в рамках аспирантуры и кандидатской диссертации?
Именно.
E>Но вот мне интересно, а что query optimizer оптимизирует, если у вас нет хранилища и менеджера транзакций? Или есть предположение о наличи индексов по конкретным атрибутам, а уже как они реализованы -- это уже другой уровень абстракции?
Ага. Точнее, результатом должно стать формальное описание алгоритма + набор минимальных требований к нижележащему уровню (скорее всего, это будет поддержка сканирования экстентов фиксированного класса и диапазонных сканов по скалярным индексам).
E>И что используется в качестве языка запросов?
В настоящий момент я остановился на, как бы это сказать, использовании исходного языка. Т.е. идея в том, что мы пишем примерно такую штуку:

IEnumerable<IEmployee> = Extent<IEmployee>.Select(
    new bool delegate(IEmployee empl) 
    {
        return empl.Salary < 500;
    }
);

Код делегата (в данном случае анонимного) анализируется, переводится в функциональное представление, и генерируется query plan — императивная программа. В примере вверху все выглядит так, как если бы был вызван вот такой метод:

IEnumerable<IEmployee> SelectWhereSalaryLT500()
{
    foreach(Employee e in EmployeeSalaryIndex.ScanRange(null, 500))
        yield return e;
    foreach(Volunteer v in VolunteerExtent) // добровольцы работают бесплатно
        yield return v;
}

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