Здравствуйте, GlebZ, Вы писали:
GZ>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).
Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом.
GZ>Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный?
Брр. Не очень понял. При удалении записи, страница, на которой она живет, уплотняется. Это не стоит практически ничего по сравнению со стоимостью flush этой страницы. Поэтому свободное место на одной странице можно считать нефрагментированным. Остальные записи на этой странице продолжают жить своей жизнью. Я не знаю, выполняется ли слияние страниц, заполненных менее чем на 50%.
GZ>Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора?
Нет, не связано.
S>>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать,
GZ>Что значит явно? В конце транзакции?
Нет, "сборку мусора" в странично-ориентированной СУБД нужно проводить только тогда, когда пользователь явно захочет компактифицировать файл. Потому что алгоритм выделения памяти устроен так, что освобожденные страницы гарантированно будут востребованы до того, как придется увеличивать размер файла. А т.к. болшинство приложений работает с постоянным либо нарастающим объемом данных, то пустые страницы долго не простаивают.

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


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

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

Наверно "байда" не должна содержать "new bool" и должна содержать имя переменной:

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

Кстати, в R# очень хорошо для поиска по объектному графу подошел XPath. Похожий на твой запрос будет выклюеть так:

IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");

Или есби без излишеств:

foreach (Employee employee in Employees.Select("//Employee[Salary < 500]"))
{
    ...
}

Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.

VD>Наверно "байда" не должна содержать "new bool" и должна содержать имя переменной:
VD>

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

Да, конечно. Виноват — предпразничные дни, будь они неладны...
VD>Кстати, в R# очень хорошо для поиска по объектному графу подошел XPath. Похожий на твой запрос будет выклюеть так:
VD>

VD>IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");
VD>

VD>Или есби без излишеств:
VD>

VD>foreach (Employee employee in Employees.Select("//Employee[Salary < 500]"))
VD>{
VD>    ...
VD>}
VD>

VD>Технология надо сказать уже работает и может быть спокойно перенесена на произвольный граф объектов. Если еще и компилируемый XPath сбацаем, то вообще лафа будет.
Let all flowers grow

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

E>>Это в рамках аспирантуры и кандидатской диссертации?
S>Именно.

Понятно. Желаю удачи!

А к то научный руководитель? И где еще в России остался такой интерес к теории БД, особенно ООБД?

<...>

E>>И что используется в качестве языка запросов?
S>В настоящий момент я остановился на, как бы это сказать, использовании исходного языка. Т.е. идея в том, что мы пишем примерно такую штуку:
S>

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

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

Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился? Код на унивесальном языке программирования типа C#? Но тогда нужно будет как-то решать проблемы доверия и безопасности этого кода.

И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам?

Здравствуйте, eao197, Вы писали:
E>Понятно. Желаю удачи!
Спасибо.
E>А к то научный руководитель?
А.М. Федотов.
E> И где еще в России остался такой интерес к теории БД, особенно ООБД?
У меня
E>Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился?
Я думал о сериализации делегатов. Т.е. на клиенте мы вычисляем необходимое замыкание и передаем его на сервер. Это позволяет снять с сервера обязанности по компиляции, которая может завершиться и неудачей.
E>Код на унивесальном языке программирования типа C#?
Конечно.
E>Но тогда нужно будет как-то решать проблемы доверия и безопасности этого кода.
А какие проблемы? Управляемая среда тем и хороша, что не даст сделать ничего лишнего. Мало того, что нет риска "сломать" сервер банальным проходом по памяти — можно еще и ограничить набор допустимых конструкций.
В частности, внутри предиката нельзя менять состояния объектов. Иначе применение оптимизации будет менять семантику запроса — результат будет зависеть от порядка вычисления предиката для разных объектов.
E>И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам?
Собственно, все и затевается ради поддержки обращения к методам. Современные ОДБМС очень плохо дружат с полиморфизмом. В примере, который я приводил, Salary было виртуальным свойством, декларированным в интерфейсе.

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

E>> И где еще в России остался такой интерес к теории БД, особенно ООБД?
S>У меня



E>>Интересно. Но, имхо, такое решение подходит для emebeded ООСУБД. Но как такие запросы обрабатывать в клиент-серверной многопользовательской системе? Передавать код запроса на сервер, чтобы он там скомпилировался, проанализировался и выполнился?
S>Я думал о сериализации делегатов. Т.е. на клиенте мы вычисляем необходимое замыкание и передаем его на сервер. Это позволяет снять с сервера обязанности по компиляции, которая может завершиться и неудачей.

Т.е. на сервер будет передаваться байт-код?

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

AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды (о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта). А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например.

E>>И еще вопрос: в выражениях можно будет использовать только атрибуты объектов или обращения к методам?
S>Собственно, все и затевается ради поддержки обращения к методам. Современные ОДБМС очень плохо дружат с полиморфизмом. В примере, который я приводил, Salary было виртуальным свойством, декларированным в интерфейсе.

Но тогда получится, что речь, в основном идет о getter-ах или о совсем тривиальных методах. А если метод сложнее? Например, если методу требуется проверить цифровую подпись, хранящуюся в одном из атрибутов агентов и сказать, корректна ли она или нет. Откуда на сервере возьмется код по проверке цифровой подписи? Или произвести сложные математические рассчеты (скажем, опрелить, поддает ли указанная точка в на нужную кривую) с применением сторонних библиотек?

Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта. Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод. Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)?

И еще один вопрос, связанный вызовом методов у объектов. Если код методов объекта не хранится централизованно на сервере, то может возникнуть проблема наличия разных версий кода объекта у разных клиентов. Например, метод Salary у какого-то старого объекта будет возращать значение атрибута m_salary, а у более нового клиента -- значение m_salary с учетом каких-либо коэффициентов, премий и штрафов. Тогда один и тот же запрос, выполненый двумя этими клиентами над одним и тем же множеством данных может привести к разным результатам.

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Некоторая поправка — в большинстве своем гарантируется что поле(не блоб) умещается на страницу (MS SQL).
S>Ну, в MS SQL гарантируется, что запись умещается на одной странице. Поля типа image, text, varchar(max) и прочий крупный тоннаж хранятся специальным способом.
Глянул BOL. Что-то стормозил . Твоя правда. Только varchar всегда — хранятся вместе с row.

GZ>>Во вторых — вопрос: они могут удалить объект не затрагивая страницу если он на ней не единственный?
S>Брр. Не очень понял. При удалении записи, страница, на которой она живет, уплотняется. Это не стоит практически ничего по сравнению со стоимостью flush этой страницы. Поэтому свободное место на одной странице можно считать нефрагментированным. Остальные записи на этой странице продолжают жить своей жизнью. Я не знаю, выполняется ли слияние страниц, заполненных менее чем на 50%.
Если не проставлено свойство autoshrink, то скорее всего нет. Есть некоторая вероятность, что есть слияния в clastered tables. Иначе получат большую вероятность того, что освобожденное место до shrink никогда не будет заполнено.

GZ>>Это свойство связано со сборкой мусора? То есть идет очищение при сборке мусора?
S>Нет, не связано.
S>>>Алгоритм "сборки мусора" на порядок проще — т.к. он во-первых запускается явно, т.е. не нужно его слишком уж оптимизировать,
GZ>>Что значит явно? В конце транзакции?
S>Нет, "сборку мусора" в странично-ориентированной СУБД нужно проводить только тогда, когда пользователь явно захочет компактифицировать файл. Потому что алгоритм выделения памяти устроен так, что освобожденные страницы гарантированно будут востребованы до того, как придется увеличивать размер файла. А т.к. болшинство приложений работает с постоянным либо нарастающим объемом данных, то пустые страницы долго не простаивают.

Теперь понял. Че-то происходит нехорошее с терминами. В последнее время я не могу определить что называть дефрагментацией, а что сборкой мусора. В MS SQL процедура оптимизации памяти — вообще называется shrink. Еще у тебя интересный термин "компактифицировать".

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

VladD2 пишет:
> IEnumerable<IEmployee> list = Extent<IEmployee>.Select("//Employee[Salary < 500]");
>
>
> Или есби без излишеств:
>
> foreach (Employee employee in Employees.Select("//Employee[Salary < 500]"))
> {
> ...
> }
>

Хм. А где статическая проверка типов для "Employee[Salary < 500]"?

А то некузяво получается, ты доказываеш всем какой крутой статически
типизируемый С# в качестве скриптового языка, а сам используеш совсем
даже не щарп и совсем даже не статически типизируемый.

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

Здравствуйте, eao197, Вы писали:
E>Т.е. на сервер будет передаваться байт-код?
Именно.
E>AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды
Ну, лично я впервые об этом слышу.
E>(о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта).
Shell-скрипт требует админских привилегий для нанесения ущерба.
E>А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например.
В настоящее время помимо авторизации пользователя дополнительно авторизуют также и код. Есть такой термин — CAS, соde access security. При помощи него можно не дать волку (коду форматирования винта, например) притвориться овцой (безобидным гуи-гаджетом).
E>Но тогда получится, что речь, в основном идет о getter-ах или о совсем тривиальных методах.
Почему?
E> А если метод сложнее? Например, если методу требуется проверить цифровую подпись, хранящуюся в одном из атрибутов агентов и сказать, корректна ли она или нет. Откуда на сервере возьмется код по проверке цифровой подписи?
Ну как откуда? А откуда на сервере вообще берется код? Его заранее деплоят. Не вижу никаких проблем проверить цифровую подпись.
E> Или произвести сложные математические рассчеты (скажем, опрелить, поддает ли указанная точка в на нужную кривую) с применением сторонних библиотек?
То же самое.
E>Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта.
Естественно.
E>Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод.
Не обязательно. Современные ODBMS так и делают. Мой оптимизатор будет пытаться построить такой план, при котором можно инстанцировать не все объекты.
E>Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)?
"Нетривиальные вещи" в наше время занимают о-малое затрат по сравнению со стоимостью загрузки страницы с диска. Поэтому дополнительными расходами по инстанцированию можно пренебречь.
E>И еще один вопрос, связанный вызовом методов у объектов. Если код методов объекта не хранится централизованно на сервере, то может возникнуть проблема наличия разных версий кода объекта у разных клиентов.
Совершенно верно. Поэтому код хранится централизованно на сервере.
E>Например, метод Salary у какого-то старого объекта будет возращать значение атрибута m_salary, а у более нового клиента -- значение m_salary с учетом каких-либо коэффициентов, премий и штрафов. Тогда один и тот же запрос, выполненый двумя этими клиентами над одним и тем же множеством данных может привести к разным результатам.
Ага. Именно это служило причиной критики файл-серверных СУБД, а затем и клиент-серверных решений с толстым клиентом. Client version mismatch — это аналог DLL-hell для data processing. Это как раз то, от чего мы хотим уйти. Навсегда .

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

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

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

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

E>>AFAIK, когда-то было доказано, что для создания вирусов, достаточно штатных средств среды
S>Ну, лично я впервые об этом слышу.
E>>(о какой бы среде не шла речь, простейшие вирусы можно было делать даже на shell-скрипта).
S>Shell-скрипт требует админских привилегий для нанесения ущерба.

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

E>>А тут речь идет об универсальных языках программирования. Может вам в запросе преднамерено передадут код с бесконечным циклом, например.
S>В настоящее время помимо авторизации пользователя дополнительно авторизуют также и код. Есть такой термин — CAS, соde access security. При помощи него можно не дать волку (коду форматирования винта, например) притвориться овцой (безобидным гуи-гаджетом).

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

Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД?
А если запускать в другой ВМ, то там свои вопросы будут возникать.

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

<...>
Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это.
Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер?

E>>Другая сторона медали. Если речь идет о вызовах методов, то метод, по-идее, должен вызываться у инстанцированного объекта.
S>Естественно.
E>>Т.е. для выполнения одного предиката сравнения придется в ОП инстанцировать каждый обрабатываемый объект и вызывать у него метод.
S>Не обязательно. Современные ODBMS так и делают. Мой оптимизатор будет пытаться построить такой план, при котором можно инстанцировать не все объекты.

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

E>>Что тогда будет с производительностью сервера (особенно, если объект при инстанцировании будет выполнять какие-нибудь нетривиальные вещи, например, вычислять значения transient атрибутов на основании persistent атрибутов)?
S>"Нетривиальные вещи" в наше время занимают о-малое затрат по сравнению со стоимостью загрузки страницы с диска. Поэтому дополнительными расходами по инстанцированию можно пренебречь.

Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться. Особенно, если страница уже есть в кэше.

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


E>Была такая книжка, когда-то, "Прикладная вирусология" Николая Безрукова (если память не изменяет). Вот там это и утверждалось.
E>А на счет shell-скрипта: можно сделать простенький скрипт, который просто до бесконечности копирует самого себя, создавая для этого огромное количество вложенных подкаталогов. Завершается его работа только после исчерпания свободного места на диске. И, если для пользователей не установлены квоты дискового пространства (а это не везде возможно), то такой скрипт может поставить на колени всю систему, даже без административных прав.
Это называется DOS-атака. Техника защиты от DOS-атак тоже существует, и особых проблем нет. Акцент надо делать на "если квоты не установлены" и учитывать эти особенности при проектировании сервера приложений. Хотя в современном мире это не очень-то принято — достаточно авторизации. Т.е. квоты требуются там, где есть анонимный доступ.
Вот, например, я могу как нефиг делать подключиться к MS SQL и исполнить там бесконечный цикл (на это вообще практически никаких пермишшнов не надо). И что? Во-первых, придет админ и даст мне в репу, а во-вторых, там есть такая галочка "query governor limit", которую можно включить на сервере избежать необходимости отстреливать бесконечные запросы вручную.
E>Как я понимаю, потребуется запускать код запроса в отдельной виртуальной машине, для которой сильно сокращен список возможных действий (или как это в .Net называется). Но, если коду запроса потребуется обращаться к дополнительным библиотекам, к той же криптографии, например? Сможет ли эта библиотека работать в нужных ограничениях доступа?
E>Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД?
Я думаю, тебе стоит почитать в MSDN про CAS. Вкратце — в управляемой среде мы всегда можем проверить, какой код и откуда выполняется. Ограничения выдаются не всей машине, а отдельным фрагментам кода. Поэтому тому коду, который был задеплоен на сервер доверенными девелоперам, мы выдаем право работать с чем-то важным, а коду, который приехал к нам из клиентского приложения для однократного выполнения — нет.

E>Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это.
E>Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер?
А в чем, собственно, проблема? Главное — в том, что все ссылки между объектами существуют только в пределах БД. При проектировании комплекса весь код известен. Деплоим все, что нужно для жизни, на сервер — и вуаля.
E>А вот это интересно. Как именно?
E>Ведь ты не можешь закэшировать возвращаемые методами значения, если не уверен, что код метода всегда будет возращать одинаковое значение при одинаковых входных параметрах. А вдруг код метода зависит, например, от текущей даты или дня недели.
Ну я вроде написал — как. Я дизассемблирую код и перевожу его в функциональное представление. Если удается выделить в предикате термы, позволяющие провести индексный поиск, то мы сразу сужаем количество объектов, на которых придется вызывать residual predicate. Кэширование результатов вызовов я пока вводить не планирую. Но по другой причине — слишком низки шансы получить cache hit для методов с хотя бы одним параметром.
E>Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться.
Ну допустим, инстанцирование объекта занимает 100000 тактов. Сколько времени займет эта тысяча на моем PIII-1700?
E>Особенно, если страница уже есть в кэше.
Если страница в кэше — то и объекты инстанцированы. Все просто: инстанцирование и удаление объектов должны быть связаны со страничным кэшем 1:1.

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

E>>Как я понимаю, потребуется запускать код запроса в отдельной виртуальной машине, для которой сильно сокращен список возможных действий (или как это в .Net называется). Но, если коду запроса потребуется обращаться к дополнительным библиотекам, к той же криптографии, например? Сможет ли эта библиотека работать в нужных ограничениях доступа?
E>>Или планируется запускать код запросов в той же виртуальной машине, что и код СУБД? Если так, то существуют ли средства, чтобы запретить коду запроса дергать что-либо из внутренностей СУБД?
S>Я думаю, тебе стоит почитать в MSDN про CAS. Вкратце — в управляемой среде мы всегда можем проверить, какой код и откуда выполняется. Ограничения выдаются не всей машине, а отдельным фрагментам кода. Поэтому тому коду, который был задеплоен на сервер доверенными девелоперам, мы выдаем право работать с чем-то важным, а коду, который приехал к нам из клиентского приложения для однократного выполнения — нет.

Найду время, почитаю. Я ведь управляемый код не пишу (пока)

E>>Про код, который деплоится на сервер понятно. Я просто хотел уточнить так ли это.
E>>Но что делать, если в СУБД хранятся данные для решения множества задач? Например, СУБД хранит проектную документацию по проекту самолета, где будут и чертежы, и расчеты, и спецификации. Поскольку СУБД объектная, то легко расставлять ссылки, скажем из чертежа на спецификацию какой-либо детали. И для решения каждой из задач необходимы разные наборы инструментов. Получится ли тогда вообще задеплоить все эти инструменты на один сервер?
S>А в чем, собственно, проблема? Главное — в том, что все ссылки между объектами существуют только в пределах БД. При проектировании комплекса весь код известен. Деплоим все, что нужно для жизни, на сервер — и вуаля.

А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only?

E>>А вот это интересно. Как именно?
E>>Ведь ты не можешь закэшировать возвращаемые методами значения, если не уверен, что код метода всегда будет возращать одинаковое значение при одинаковых входных параметрах. А вдруг код метода зависит, например, от текущей даты или дня недели.
S>Ну я вроде написал — как. Я дизассемблирую код и перевожу его в функциональное представление. Если удается выделить в предикате термы, позволяющие провести индексный поиск, то мы сразу сужаем количество объектов, на которых придется вызывать residual predicate. Кэширование результатов вызовов я пока вводить не планирую. Но по другой причине — слишком низки шансы получить cache hit для методов с хотя бы одним параметром.

Может я просто не увидел, где ты это описывал, ивини.
Интересная идея. А под термами понимается доступ к атрибутам объекта? Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы? А как же тогда инкапсуляция?

E>>Не думаю. Если, скажем, размер страницы 64K, а на ней помещается 1000 объектов, то инстанцирование этой тысячи объектов начнет сказываться.
S>Ну допустим, инстанцирование объекта занимает 100000 тактов. Сколько времени займет эта тысяча на моем PIII-1700?

Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete. В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история.

E>>Особенно, если страница уже есть в кэше.
S>Если страница в кэше — то и объекты инстанцированы. Все просто: инстанцирование и удаление объектов должны быть связаны со страничным кэшем 1:1.

Ok. Теперь предположим, что страница в кэше занимает 64K. Тысяча инстанцированных из нее объектов, например, в полтора раза больше (поскольку для них будет оверхед по занимаемому пространству). Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться.

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

E>Найду время, почитаю. Я ведь управляемый код не пишу (пока)
Ничего, это ненадолго
E>А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only?
Что-то вот тут я перестаю понимать. О каких инструментах идет речь? Серверный код оперирует серверной объектной моделью. Т.е существует некоторый API, представленный набором сборок/пакетов ядра. Попытка задеплоить в сервер сборку System.Windows.Forms ни к чему хорошему не приведет — использование ее объектов подразумевает наличие десктопа, которого в Application Server просто нет. И даже если бы такая попытка удалась, то какова была бы семантика использования таких объектов? Это примерно то же самое, как подключиться к MS SQL Server и выполнить sp_exec('calc.exe'). Ну запустим мы инстанс калькулятора на сервере, и что? Пользователь его все равно не увидит.
В сервере должен жить серверный код. С точки зрения объектов в СУБД окружающая среда состоит из других объектов СУБД и некоторых сервисов (можно считать их static классами), которые помогают объектам выполнять свои обязанности. Я с трудом себе представляю реализацию класса "элемент спецификации самолета", которому бы потребовалась Windows-specific функциональность.

E>Может я просто не увидел, где ты это описывал, ивини.
E>Интересная идея. А под термами понимается доступ к атрибутам объекта?
Под термами понимаются некоторые элементарные булевые операции. В частности, доступ к атрибутам объекта. В общем случае, произвольный предикат не удастся представить в виде функции от значений атрибутов объекта. Например, если в нем участвует метод object.GetClass() Но для простоты можно считать, что мы приводим императивный код к виду, в котором листьями AST являются обращения к атрибутам.
E>Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы?
Для начала да.
E>А как же тогда инкапсуляция?
А она никак не страдает. Инкапсуляция управляет возможностями прикладного кода, изолируя автора предиката от особенностей реализации конкретных классов. С точки зрения сервера, никакой инкапсуляции нет. Пользователь по-прежнему не может использовать приватные атрибуты напрямую; вместо этого он вынужден использовать методы доступа. Сервер просто переформулирует валидный запрос в таком виде, чтобы увеличить производительность.
E>Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete.
Это как минимум очень странно. Я в свое время имел подобный опыт. Но там затраты на превращение raw данных в объекты не превосходили 10%, и то, в основном из-за очень хреновой структуры — там каждый атрибут был объектом, и его размер был очень велик.
Тут надо помнить вот о чем — в инстанцировании объектов, как правило, основное время занимает выделение памяти. Оно становится заметным как только мы залезаем в своп. В СУБД так быть не должно — кэш всегда лежит только в физической памяти. Когда надо поднять еще одну страницу и памяти не хватает, мы должны отфлашить какую-то из занятых, а не лезть в споп.
E>В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история.
E>Ok. Теперь предположим, что страница в кэше занимает 64K.
Ну, это очень толстая страница Типичный размер страницы кэша — 8kb.
E>Тысяча инстанцированных из нее объектов, например, в полтора раза больше (поскольку для них будет оверхед по занимаемому пространству).
Есть такой риск.
E>Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться.
Ну как это "совсем не использоваться"? Надо повышать cache hit ratio В целом верно — то, чего я ожидаю, даст как минимум двукратный оверхед по памяти. С другой стороны, "память больше не ресурс" Просто кэш станет вмещать чуть меньше. В гигабайте памяти поместится не десять миллионов записей, а три миллиона объектов. Но применение оптимизаций запросов уменьшит требования к кэшу. Т.е. если удалось найти терм, связанный с индексом с селективностью хотя бы в 20%, нам потребуется поднять в память, к примеру, два миллиона оюъектов вместо десяти. Т.е. у нас все еще есть риск иметь cache hit ratio ~ 100%, несмотря на уменьшение эффективной емкости кэша втрое.

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

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

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

E>>Найду время, почитаю. Я ведь управляемый код не пишу (пока)
S>Ничего, это ненадолго

Это уже в другой топик

E>>А если не получится? Если для одних задач нужны Windows-only инструменты, а для других -- Unix-only?
S>Что-то вот тут я перестаю понимать. О каких инструментах идет речь? Серверный код оперирует серверной объектной моделью. Т.е

Да, здесь меня занесло. Я забыл, что речь идет о .Net. И все должно будет крутиться под .Net.

E>>Т.е. ты предполагаешь строить индексы по атрибутам, даже если доступ к ним ограничен через getter/setter-ы?
S>Для начала да.

Ok.

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

Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать.

E>>Ну на одной странице может и не много. А на сотне-другой. У меня, лично, получалось, что накладные расходы на инстанцирование мелких объектиков в C++ достигали 1/3 времени от общего времени работы с БД. И уходило это время, в основном, на new/delete.
S>Это как минимум очень странно. Я в свое время имел подобный опыт. Но там затраты на превращение raw данных в объекты не превосходили 10%, и то, в основном из-за очень хреновой структуры — там каждый атрибут был объектом, и его размер был очень велик.

Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее.

E>>В языках со сборкой мусора эти затраты могут быть и ниже, то тех пор, пока в распоряжении есть достаточно памяти. Зато потом может быть затык в самый неподходящий момен. Но это уже совсем другая история.
E>>Ok. Теперь предположим, что страница в кэше занимает 64K.
S>Ну, это очень толстая страница Типичный размер страницы кэша — 8kb.

Ну это как посмотреть. Диски разные бывают. Вот, например, в BerkeleyDB есть возможность изменять размер страницы. И максимальный размер — 64K.

E>>Итак, делаем размер кэша в 100Mb и получаем еще 150Mb на хранение инстанцированных объектов. Которые, при этом, могут совсем и не использоваться.
S>Ну как это "совсем не использоваться"? Надо повышать cache hit ratio В целом верно — то, чего я ожидаю, даст как минимум двукратный оверхед по памяти. С другой стороны, "память больше не ресурс" Просто кэш станет вмещать чуть меньше. В гигабайте памяти поместится не десять миллионов записей, а три миллиона объектов. Но применение оптимизаций запросов уменьшит требования к кэшу. Т.е. если удалось найти терм, связанный с индексом с селективностью хотя бы в 20%, нам потребуется поднять в память, к примеру, два миллиона оюъектов вместо десяти. Т.е. у нас все еще есть риск иметь cache hit ratio ~ 100%, несмотря на уменьшение эффективной емкости кэша втрое.

Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает.

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

Это точно.

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


E>Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать.
Ничего подобного. Тебя же не оскорбляет способность С++ инлайнить методы? Получается, что "среда" выполняет (о, ужас!) прямой доступ к атрибуту вместо честного вызова метода, сопряженного со всеми проблемами конвейера CPU и напряжения кэша . Серверу — можно.

E>Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее.
Угу. Тем не менее, это означает что у тебя была суперэффективная СУБД. Мне в жизни не встречалась СУБД, способная отдавать данные со скоростью, сравнимой со скоростью New.
E>Ну это как посмотреть. Диски разные бывают. Вот, например, в BerkeleyDB есть возможность изменять размер страницы. И максимальный размер — 64K.
Ну как тебе сказать... Размер страницы выбирается из соображений общей эффективности. Вон, в MS SQL помимо страниц есть еще и экстенты — как раз 64к. АФАИК, они такие ровно для улучшения взаимодйствия с дисковым контроллером.
E>Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает.
Ну, тут все зависит от размера страницы, и стратегии размещения объектов в применении к типичным access patterns.

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

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


E>>Это уже иделогический вопрос -- должен ли сервер иметь право напряму работать со значениями объектов. ИМХО, то что ты предлагаешь, есть нарушение инкапсуляции. Но в ООСУБД, может быть, это и можно допускать.
S>Ничего подобного. Тебя же не оскорбляет способность С++ инлайнить методы? Получается, что "среда" выполняет (о, ужас!) прямой доступ к атрибуту вместо честного вызова метода, сопряженного со всеми проблемами конвейера CPU и напряжения кэша . Серверу — можно.

Нет, не удачный пример. Если у меня есть код get_something() { return m_a + f(); }, то мне безразлично, что вычисление (m_a + f()) происходит в месте вызова get_something, поскольку мне возвращается не "голое значение" атрибута m_a, а преобразованное в соответствии с прикладной логикой. Если же СУБД индексирует по m_a неопосредственно обращаясь к нему, то это, ИМХО, нарушение инкапсуляции.

E>>Ну, у меня как раз объекты были не большими, но содержали атрибуты, который нуждались в выделении памяти (std::vector, std::string). В результате инстанцирование одного объекта приводило к множеству new. А еще сказывалось то, что использовался Multithreading режим, в котором new работает медленнее.
S>Угу. Тем не менее, это означает что у тебя была суперэффективная СУБД. Мне в жизни не встречалась СУБД, способная отдавать данные со скоростью, сравнимой со скоростью New.

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

E>>Нет, я имел в виду, что для выполнения какого-то запроса потребовалось 50 объектов со страницы. Для следующего запроса еще 5 объектов. Затем еще 20. А остальные 900 просто место занимает.
S>Ну, тут все зависит от размера страницы, и стратегии размещения объектов в применении к типичным access patterns.

Возможно.

---

Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде?

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

E>Нет, не удачный пример.
Вполне удачный.
E>Если у меня есть код get_something() { return m_a + f(); }, то мне безразлично, что вычисление (m_a + f()) происходит в месте вызова get_something, поскольку мне возвращается не "голое значение" атрибута m_a, а преобразованное в соответствии с прикладной логикой.
E>Если же СУБД индексирует по m_a неопосредственно обращаясь к нему, то это, ИМХО, нарушение инкапсуляции.
По-моему, ты не следуешь за моей мыслью. Ну давай поковыряем твой пример. Предположим, что и get_something, и f() — виртуальные. И предикат устроен примерно так:

bool TempPredicate(myObject m)
{
    return m.get_Something() > 0;
}

Ты не сможешь в предикате написать ничего про m.m_a.
Зато СУБД посмотрит в код, и увидит там вот такое:

bool TempPredicate(myObject m)
{
    return (m.m_a + m.f()) > 0;
}

Предположим, myObject.f() просто возвращает 5. Тогда дальнейшая подстановка приведет к

bool TempPredicate(myObject m)
{
    return (m.m_a + 5) > 0;
}

После чего мы получаем

bool TempPredicate(myObject m)
{
    return m.m_a > -5;
}

А это уже повод посканироваться по индексу по m_a.
Вот и все.
E>

---

E>Sinclair, а у тебя, случайно нет ODMG-3 стандарта в электронном виде?
Неа. Уж очень он дорогой.

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


ANS>Хм. А где статическая проверка типов для "Employee[Salary < 500]"?

А это XPath. Его система типов пока что не совместима с Шарповсокй. Но над этим уже работают. По слухам в следующей версии языка будт встроена работа с ХМЛ и БД.

ANS>А то некузяво получается, ты доказываеш всем какой крутой статически
ANS>типизируемый С# в качестве скриптового языка, а сам используеш совсем
ANS>даже не щарп и совсем даже не статически типизируемый.

Я использую библиотеку осущесавлюющую запросы. А в качестве импереативного языка обработки данных использую XPath. На сегодя используется универсальная библиотека и проверить типы естествнно ен удается. Но в планах создание компилируемых XPath запросов. Вот там (кроме скорости) можно и строгую типизацию между XPath-ом и C# сделать, так как запросы будут превращаться в код на C#.

VladD2 пишет:

> А это XPath. Его система типов пока что не совместима с Шарповсокй. Но
> над этим уже работают. По слухам в следующей версии языка будт
> встроена работа с ХМЛ и БД.

Если они, не дай бог, это сделают, то получится НЕЧТО еще хуже С++

--
С уважением,
Alex Besogonov (alexy@izh.com)