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

P>Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР, который решит эти проблемы? Бред...
Это не бред, это правда жизни... Иногда..
На практике один сервер БД может (и должен) держать 3-4 App-сервера. Хотя это очень сильно зависит от задачи и окружения. Вообще, рассуждать о том что лучше в отрыве от конкретной задачи — довольно бесполезное занятие.

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

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

FD>Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока
FD>старика Дейта не почитал.
Старика Дейта надо читать аккуратно, на неокрепший мозг действует хуже чем капля никотина на того хомячка.

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

FD>Интересно, а какой способ задавать бизнес-правила более мощный ?
DSL

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

IB>Здравствуйте, Flying Dutchman, Вы писали:

FD>>Интересно, а какой способ задавать бизнес-правила более мощный ?
IB>DSL

И как ты задашь Fioreign Key constraint при помощи DSL ?

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

IB>Здравствуйте, Flying Dutchman, Вы писали:

FD>>Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока
FD>>старика Дейта не почитал.
IB>Старика Дейта надо читать аккуратно, на неокрепший мозг действует хуже чем капля никотина на того хомячка.

Это ты о чем ?

Здравствуйте, Flying Dutchman, Вы писали:
FD>И как ты задашь Fioreign Key constraint при помощи DSL ?
Напомню, что DDL — это DSL для описания реляционных таблиц.
DSL может включать в себя всё то же плюс еще тележку, особенно если будет описывать не таблицы, а сущности.
Вот, из свежепридуманного:

define entity OrderItem
(
    Order references Orders,
    Item 
        unique within Order 
        references Items where Item.IsAllowedFor(Order.Owner) 
)

DDL скрывает нервную икоту.

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

IB>Это не бред, это правда жизни... Иногда..

Бесспорно.

IB>На практике один сервер БД может (и должен) держать 3-4 App-сервера. Хотя это очень сильно зависит от задачи и окружения. Вообще, рассуждать о том что лучше в отрыве от конкретной задачи — довольно бесполезное занятие.

И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД? Прошу не относить меня к противником N-звенок. Я противник пихания их куда нипоподя. Вступить в дисскуссию в слишком категоричном тоне меня заставила такая же категоричность сторонников реализации бизнес-логики на апп. серверах. И, как всегда, приводится аргументация, невыдерживающая критики.

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

Это утверждение может быть истиной только в контексте сценария, изолированного от взаимодействия апп.сервера с сервером бд. В противном случие суммарная произодительность (выбрать данные сервера бд, передать их на апп.сервер, закэшировать, отсортировать и вернуть клиенту) в сугубо простых и специфических случаях будет выше в N-звенке.

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

P>И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД?
А кто ACID-ность обеспечивать будет? Нужен конечно...

P>Это утверждение может быть истиной только в контексте сценария, изолированного от взаимодействия апп.сервера с сервером бд.
Нет, дело не в изолированности...

P> В противном случие суммарная произодительность (выбрать данные сервера бд, передать их на апп.сервер, закэшировать, отсортировать и вернуть клиенту) в сугубо простых и специфических случаях будет выше в N-звенке.
Очевидно, кешируются уже отсортированные и сджойненые данные и это будет эффективнее чем в БД — исключается раунд-тип в хранилище и снимается нагрузка на него. Физически БД очень плохо масштабируются, пихать же stateless app-сервероа можно практически даром.

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

FD>Это ты о чем ?
О том, что "бизнес-правила" очень растяжимое понятие.

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

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

P>>И тут соглашусь. Хотя, нужен ли в таком случаи сервер СУБД?
IB>А кто ACID-ность обеспечивать будет? Нужен конечно...

Ну, так он и не только это делать умеет...


IB>Очевидно, кешируются уже отсортированные и сджойненые данные и это будет эффективнее чем в БД — исключается раунд-тип в хранилище и снимается нагрузка на него. Физически БД очень плохо масштабируются, пихать же stateless app-сервероа можно практически даром.

Такой подход (кеширование ПОСЛЕ сортировки и сджоивания в бд) я еще готов признать. Но смех у меня вызвал проспект ebay, где они и сортировку с джоинами вынесли на апп. сервер.

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

C>>Вот. И эта остальная часть — по большей части сливает нормальным
C>>системам разработки. Так как она не была изначально для этого предназначена.
P>Можно конкретные примеры фунциональности, которые Вы не смогли разрулить только на уровне СУБД и перенесли на средний слой? Давайте только не будем про рассылку писем и оповещения, ибо это реализуется и без апп. сервера.
У меня основное приложение — работа с расписанием. Один из достаточно сложных моментов — сортировка людей по количеству денег, которые они заработают за смену. Первая версия была написана в виде жуткой процедуры на Oracle'е. Торррмозилло, особенно с многими клиентами. "Поставить еще один сервер" — далеко уже не так просто, нужно ставить систему репликации, разделяемое хранилище и т.п.

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

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

>>> Долго ржал...
C>>Зря смеешься. Это именно так.
P>
P>Не надо рассказывать мне сказки, чтоб самописные джоины и сортировки "сделали" их аналоги на промышленных серверах СУБД!
Элементарно. Я часто руками могу заоптимизировать так, что некоторым БД даже не снилось даже и при использовании хинтов. У меня вообще "промышленные" решения долго не живут — погибают после глубокой кастомизации под мои задачи.

C>>Зачастую просто написать тупой императивный код, чем громоздить запросы
C>>и работать с курсорами.
P>Курсоры идут в сад! А вот "запросы" — это то, что умеет "переваривать" СУБД гараздо лучше, чем самопальный императивный код на апп. сервере.
Как ты предлагаешь _нормально_ без курсоров работать с понятиями "предидущий ряд результата"/"предидущая точка изменения"?

C>>У меня примерно та же ситуация — клиенты один раз загружают с сервера
C>>нужные данные (которые при этом чаще всего еще и во внутрипроцессном
C>>кэше лежат), а потом уже работают с ними на локальных узлах. Так как
C>>иначе сервер БД бы просто умер.
P>Даешь всю базу на клиента!
Ага, именно. Сейчас делаем архитектуру, когда данные будут рассылаться на локальные супер-ноды, а оттуда уже на клиентские компьютеры. Чтобы даже и эту нагрузку с сервера снять.

P>Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...
А какие проблемы в локальных копиях? Авторитетная копия данных находится на сервере, все изменения тоже проходят исключительно через сервер (а потом автоматически реплицируются во все локальные копии). Так что проблем с безопасностью и прочими timestamp'ами — никаких.

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

C>>Достаточно редко объекты в БД соответствуют 1-в-1 реальным
C>>бизнес-объектам. Так что FKC — это один из _способов_ задавать
C>>бизнес-правила, но не самый мощный.
FD>Интересно, а какой способ задавать бизнес-правила более мощный ?
Мы используем для задания правил кастомизированый JBoss Drools.

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

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

C>У меня основное приложение — работа с расписанием. Один из достаточно сложных моментов — сортировка людей по количеству денег, которые они заработают за смену. Первая версия была написана в виде жуткой процедуры на Oracle'е. Торррмозилло, особенно с многими клиентами. "Поставить еще один сервер" — далеко уже не так просто, нужно ставить систему репликации, разделяемое хранилище и т.п.

Гм... Зачем репликация? Для Oracle — RAC, для MS SQL Federated Database Servers. Вот мне только интересно, какие объемы данных и скольким кол-вом пользователей обсчитывались одновременно, что "тормозило".

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

Повторятся не буду. Считать надо там, где и даные лежат.

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

C>Элементарно. Я часто руками могу заоптимизировать так, что некоторым БД даже не снилось даже и при использовании хинтов. У меня вообще "промышленные" решения долго не живут — погибают после глубокой кастомизации под мои задачи.

Да Вы гений, батенька. Может попросить продуктовую команду, скажем MS SQL чтоб Вас взяли Вас к себе? А то, есть жалобы на некоторые моменты работы оптимизатора.

C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями "предидущий ряд результата"/"предидущая точка изменения"?

Курсор в большинстве случаев может быть заменен циклом.

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

Почему бы на этих "супер-нодах" держат не апп. сервера, а сервера БД?

C>А какие проблемы в локальных копиях? Авторитетная копия данных находится на сервере, все изменения тоже проходят исключительно через сервер (а потом автоматически реплицируются во все локальные копии). Так что проблем с безопасностью и прочими timestamp'ами — никаких.

Это мне все напоминает старый-добрый файл\сервер. Притащили к себе данные и с ними работаем.

pkarklin wrote:
> Гм... Зачем репликация? Для Oracle — RAC, для MS SQL Federated Database
> Servers. Вот мне только интересно, какие объемы данных и скольким
> кол-вом пользователей обсчитывались одновременно, что "тормозило".
Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит
нормальный SAN с винчестерами на fibre channel? На слабом железе RAC
работает очень посредственно — проверено.

В MSSQL примерно такие же требования, AFAIR.

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

pkarklin wrote:
> C>Элементарно. Я часто руками могу заоптимизировать так, что некоторым
> БД даже не снилось даже и при использовании хинтов. У меня вообще
> "промышленные" решения долго не живут — погибают после глубокой
> кастомизации под мои задачи.
> Да Вы гений, батенька. Может попросить продуктовую команду, скажем MS
> SQL чтоб Вас взяли Вас к себе?
Можно Только я туда не пойду.

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

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

> C>Как ты предлагаешь _нормально_ без курсоров работать с понятиями
> "предидущий ряд результата"/"предидущая точка изменения"?
> Курсор в большинстве случаев может быть заменен циклом.
У меня проблема часто в запоминании некоторых предидущих позиций в
списке значений.

> C>Ага, именно. Сейчас делаем архитектуру, когда данные будут рассылаться
> на локальные супер-ноды, а оттуда уже на клиентские компьютеры. Чтобы
> даже и эту нагрузку с сервера снять.
> Почему бы на этих "супер-нодах" держат не апп. сервера, а сервера БД?
Неудобно по некоторым причинам. У меня на app-серверах сейчас,
фактически, объектная база получается.

> C>А какие проблемы в локальных копиях? Авторитетная копия данных
> находится на сервере, все изменения тоже проходят исключительно через
> сервер (а потом автоматически реплицируются во все локальные копии). Так
> что проблем с безопасностью и прочими timestamp'ами — никаких.
> Это мне все напоминает старый-добрый файл\сервер. Притащили к себе
> данные и с ними работаем.
И что тут плохого? У меня локально утаскиваются только те данные, с
которыми надо будет работать (и которые скорее всего придется показать).

В результате у меня GUI работает мгновенно. А вот как сделать мгновенные
запросы по тормозному каналу через половину Земли — пока еще не придумали.

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

C>Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит
C>нормальный SAN с винчестерами на fibre channel? На слабом железе RAC
C>работает очень посредственно — проверено.

А, ну да, понятно. Берем MySQL. Енто у нас будет сервер бд. НА персоналках с идешными винтами делаем апп. сервера. Все счастливы и довольны. И, самое главное, все практически бесплатно.

C>В MSSQL примерно такие же требования, AFAIR.

Эээ... Простите?! Вам шашечки или ехать?

C>Ага. Откуда такое догматическое убеждение?

Ну, считайте меня вот таким догматиком.

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

C>>Можно и RAC. Сколько оно там у нас стоит? А сколько для него стоит
C>>нормальный SAN с винчестерами на fibre channel? На слабом железе RAC
C>>работает очень посредственно — проверено.
P>А, ну да, понятно. Берем MySQL. Енто у нас будет сервер бд. НА персоналках с идешными винтами делаем апп. сервера. Все счастливы и довольны. И, самое главное, все практически бесплатно.
Как ни странно, Google вот примерно так и сделал. Вместо того, чтобы заплатить $$$$$$$$$ за пару десятков тысяч Orcale'ов с RAC — эти идиоты даже сделали свою файловую систему.

У меня на узлах сейчас вообще базы данных нет — ее роль выполняет структурированый кэш в оперативной памяти.

C>>В MSSQL примерно такие же требования, AFAIR.
P>Эээ... Простите?! Вам шашечки или ехать?
Ехать, да еще и без миллионных требований на железо.

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

C>Можно Только я туда не пойду.

Как хотите.

C>Проблема в оптимизаторе в том, что он заточен на общие решения. А в моих
C>частных задачах часто можно применить достаточно значительные
C>оптимизации, до которых оптимизатору не додуматься в ближайшее время.

C>Ситуация такая же, как и с программированием на ассемблере — хороший
C>низкоуровневый программист часто может побить компилятор (особенно в
C>области использования всяких SSE), для которого оптимизатор писали
C>тысячи человеко-лет.

Точно так же и хороший программист баз данных может заставить выполняться запрос так как он пожелает, а не как за отведенное ему на размышление время придумал оптимизатор. К чему это я. Каждый инструмент нужно уметь использовать проффесионально и, самое главное, к месту. Если я счас на T-SQL буду писать обработку видео, то сами понимаете, что у меня получится.

C>У меня проблема часто в запоминании некоторых предидущих позиций в
C>списке значений.

Это слишком обще... Была бы конретная задача — можно было бы полумать о решении.

C>Неудобно по некоторым причинам. У меня на app-серверах сейчас,
C>фактически, объектная база получается.

Ну, тогда понятно. Вам "привычнее" работать с объектами, чем с чисто реляционными данными, поэтому у Вас и апп. сервера.

C>И что тут плохого? У меня локально утаскиваются только те данные, с
C>которыми надо будет работать (и которые скорее всего придется показать).

Да ни каких проблем, когда таких данных не много.

C>В результате у меня GUI работает мгновенно. А вот как сделать мгновенные
C>запросы по тормозному каналу через половину Земли — пока еще не придумали.

Ширина канала на "торознутость запроса" влияет примерно так же, как время, необходимое чтобы доехать до автосервиса на время, необходимое на починку Вашей машины.