Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 12   вперед  Ctrl      все
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
maximpr1111
DPH,

правильно ли я понимаю, что при расчете оборудования на данную систему, нагрузка ложится на следующие компоненты оборудования:

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)
2. Application Server (процессоры+память). Если есть информация, то каким образом можно посчитать необходимую мощность оборудования, если известно количество одновременных подключений на один сервер
3. memcached (память).
4. Веб-сервер (процессор+память)

Я чет не понял - почему пункты 2 и 4 - разные? Это одно и то же, а вебсервер ради вебсервера - каков смысл? Или вы изначально хотите сделать себе больше работы и проблем с ненужным app-сервером, чтобы потом взять за это больше денег? :))
Т.е. IIS + asp.net (к примеру) все_в_одном почему то не устраивают? А почему?

Товарищи, наверное я пропустил страшную тайну, тогда вы мне расскажите - зачем для системы, которая представляет из себя всего лишь немного расширенный форум, необходим апп-сервер??? Только ли для того, чтобы добавить себе проблем как с разработкой, так и с производительностью, или есть что-то еще? :))

-- Tygra's --
Мои фотогалереи тут и тут
21 май 08, 17:49    [5696849]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
tygra
maximpr1111
DPH,

правильно ли я понимаю, что при расчете оборудования на данную систему, нагрузка ложится на следующие компоненты оборудования:

1. сервер DB (процессор+память+дисковая подсистема). если DB Express-C, то 2 процессора+4 Gb памяти)
2. Application Server (процессоры+память). Если есть информация, то каким образом можно посчитать необходимую мощность оборудования, если известно количество одновременных подключений на один сервер
3. memcached (память).
4. Веб-сервер (процессор+память)

Я чет не понял - почему пункты 2 и 4 - разные? Это одно и то же, а вебсервер ради вебсервера - каков смысл? Или вы изначально хотите сделать себе больше работы и проблем с ненужным app-сервером, чтобы потом взять за это больше денег? :))
Т.е. IIS + asp.net (к примеру) все_в_одном почему то не устраивают? А почему?

Товарищи, наверное я пропустил страшную тайну, тогда вы мне расскажите - зачем для системы, которая представляет из себя всего лишь немного расширенный форум, необходим апп-сервер??? Только ли для того, чтобы добавить себе проблем как с разработкой, так и с производительностью, или есть что-то еще? :))

-- Tygra's --
Мои фотогалереи тут и тут


В данном случае, я подразумеваю под веб сервером, машину которая отвечает за получение запросов и распределение их между Application Server-ами, которые, так как речь идет о servlet-технологии могут их обрабатывать и без посредников. Т.е веб-сервер эта машина единственной задачей которой является распеределение нагрузки. В первоначальной конфигурации ее может и не быть. Если я не прав с терминологией, то поправьте меня. Выбор не а пользу Windows, связан с тем, как правильно подметил DPH, что цены их лицезий на серверные операционки соревнуется с Oracle.
21 май 08, 18:04    [5696970]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
имхо в таких проектах - чем проще, тем лучше, что-то типа такого:

http://www.insight-it.ru/net/scalability/arkhitektura-digg/
21 май 08, 18:16    [5697069]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Yo.!
имхо в таких проектах - чем проще, тем лучше, что-то типа такого:

http://www.insight-it.ru/net/scalability/arkhitektura-digg/


А я примерно это и хочу сделать (я где-то видел картинку по этому проекту, там как раз один сервер выделен под распределение нагрузки, множество MySQL и memcached и серверов с приложением на PHP(Application Server)). Только вместо PHP, я таки использую Java (там больше готовых возможностей для разработки высоконагруженных систем). И не готов я рисковать использовать бесплатные БД. Все же с платными БД всегда есть два варианта, а с бесплатными только шардинг.
21 май 08, 18:34    [5697194]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
с субд - согласен, но с жава я бы еще подумал, что за инструменты вы к нему собрались использовать ...
с пхп все просто, люди лабают код за еду, поэтому ты и не ожидаешь от них гениальности и внимательно отслеживаешь кто, чем занимается, а вот стандартный жава-девелопер жрет как весь "продажный" отдел но при этом считает, что субд это такой тормозной ящик в который можно послать всего три SQL команды и ему проще утянуть гигабайты данных по эзернету в жава и там их лопатить, т.к. в жава "больше готовых возможностей для разработки высоконагруженных систем".
21 май 08, 19:00    [5697376]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Ну, если двух ядер мало, то можно поставить 9.1, а не 9.5
Или, когда двух ядер перестанет хватать, купить поддержку. Или купить ее сразу, благо HADR и репликация нужны сразу, а стоит она копейки.

Насколько я помню, на сервере 2*2 все запустится, просто не будет лишние ядра использовать - что на раннем этапе не страшно.
21 май 08, 20:25    [5697622]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111

В данном случае, я подразумеваю под веб сервером, машину которая отвечает за получение запросов и распределение их между Application Server-ами, которые, так как речь идет о servlet-технологии могут их обрабатывать и без посредников.

А. В этом случае можно подумать о железках - round robin многие умеют делать. Если есть нормальный админ - то выйдет дешевле. Если нет - то все равно проблемы будут.

Я то думал, что ты решил разделить генерацию html и собственно бизнес-логику (так иногда делают, например, накладывая XSL на отдаваемый XML на отдельной машине). Зачастую даже производительнее получается и дешевле.
21 май 08, 20:34    [5697653]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Yo.!
с субд - согласен, но с жава я бы еще подумал, что за инструменты вы к нему собрались использовать ...
...
...
но при этом считает, что субд это такой тормозной ящик в который можно послать всего три SQL команды и ему проще утянуть гигабайты данных по эзернету в жава и там их лопатить, т.к. в жава "больше готовых возможностей для разработки высоконагруженных систем".
Иногда проще данные обработать на уровне приложение / апп.сервера, чем гробить тупейшими запросами СУБД.

А тянуть "гигабайты данных по эзернету в жава и там их лопатить" это сказки. Никто вменяемый так не делает (кроме случая когда это действительно необходимо).
22 май 08, 17:33    [5702113]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
maximpr1111
В данном случае, я подразумеваю под веб сервером, машину которая отвечает за получение запросов и распределение их между Application Server-ами, которые, так как речь идет о servlet-технологии могут их обрабатывать и без посредников. Т.е веб-сервер эта машина единственной задачей которой является распеределение нагрузки. В первоначальной конфигурации ее может и не быть. Если я не прав с терминологией, то поправьте меня. Выбор не а пользу Windows, связан с тем, как правильно подметил DPH, что цены их лицезий на серверные операционки соревнуется с Oracle.

Не понял, кого в первоначальной конфигурации может не быть: вебсервера или аппсервера?
И сколько стоит лицензия на Windows сервер? На чем вы будете делать и сколько это будет стоить? Сколько будет стоить СУБД?

Извините, но если идет речь о системе с количеством пользователей, измеряемым миллионами, и в то же время считать копейки - у вас ничего не получится уже до того, как чего-то начнете.

По поводу Java и быстрой системы - нюню, этто буддетт оччень быстттро, по эсттоннсски :)

-- Tygra's --
Мои фотогалереи тут и тут
22 май 08, 18:06    [5702444]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
VoDA

А тянуть "гигабайты данных по эзернету в жава и там их лопатить" это сказки. Никто вменяемый так не делает (кроме случая когда это действительно необходимо).

делают, еще как делают :(
обычно все начинается с кеширования справочников в хибернейте со словами, хибер же лучше заджоинит ...
22 май 08, 18:10    [5702478]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
tygra
Извините, но если идет речь о системе с количеством пользователей, измеряемым миллионами, и в то же время считать копейки - у вас ничего не получится уже до того, как чего-то начнете.

Не копейки. Для указанной системы стоимость лицензий - самый большой планируемый расход (если не делать систему на, по мере возможности, бесплатных или дешевых решениях). Windows Data Center (да даже и Server 2008 64bit) - это очень дорого.


По поводу Java и быстрой системы - нюню, этто буддетт оччень быстттро, по эсттоннсски :)

Гм, а что, есть хоть одно возражение против скорости Java? Тем более на сервере. Или есть более быстрые промышленные решения (ну, кроме реализации на голом C - да и то, не факт, что будет заметно быстрее и уж точно на порядок дороже в разработке). Как-то я вот смотрю по сторонам, вижу кучу нагруженных сервисов на Java - и не вижу особых проблем с производительностью. Хотя некоторые из них даже и спроектированы не самым удачным способом.
22 май 08, 19:18    [5702846]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Yo.!
VoDA

А тянуть "гигабайты данных по эзернету в жава и там их лопатить" это сказки. Никто вменяемый так не делает (кроме случая когда это действительно необходимо).

делают, еще как делают :(
обычно все начинается с кеширования справочников в хибернейте со словами, хибер же лучше заджоинит ...


Вменяемые - не делают, они вообще не используют ORM на нагруженных системах.
Угу. Использование Java не значит, что не нужно представлять, как работает БД.
Хотя использование БД как простого и эффективного хранилища для большей части задач имеет смысл - тем не менее это не стоит делать через hibernate.
Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.
22 май 08, 19:23    [5702859]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
DPH
Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.
Вы что-нибудь про нормализацию данных слышали? Третья нормальная форма? Нет? Не слышали? Заметно.

DPH
Гм, а что, есть хоть одно возражение против скорости Java? Тем более на сервере. Или есть более быстрые промышленные решения
Оракл где-то писал (давно было - ссылку не найду), что PL/SQL в режиме интерпретации в два раза быстрее Явы. А начиная с версии 9i PL/SQL может компилироваться в натив код (через С).
22 май 08, 22:15    [5703313]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
mva103
Member

Откуда:
Сообщений: 50
читал читал читал....
Моя пилюля:
Я проводил нагрузочное исследование для выяснения нагрузочной способности MSSQL и Oracle. Задача тестирования была в выяснении потолка количества обслуживаемых простых запросов от application layer(делался селект из таблицы в 4 записи). Архитектура была такая
RDBMS<------>(APACHE + PHP) * 4<----------->nginx+ round robin<--------->client * N
К сожалению не могу привести абсолютных цифр, т.к. тестировал для себя, а не для отчета. Результат - oracle в SHARED MODE победил MSSQL 2005 по кличеству обслуженных пользователей. При этом Oracle сложнее в суппорте application layer т.к. апач ЖДЕТ пока оракл таки даст ответ на запрос, что приводит к быстрому переполнению доступных юзеров у апача, а mssql при перегрузке быстро рвал сессию, т.е. возвращал пустой результат. Результат теста - business critical web стучит в оракл. Несмотря на то что лично мне MSSQL обслуживать проще.
23 май 08, 00:29    [5703580]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Anton Demidov
Вы что-нибудь про нормализацию данных слышали? Третья нормальная форма?

О, умный какой. Судя по вопросу, ты про 3НФ услышал совсем недавно?
Ты подумай, как-нибудь, на досуге, зачем вообще используются нормальные формы, когда они нужны, когда нет. Подумай, какое отношение третья нормальная форма имеет к задаче загрузки справочников в application layer и оптимальности управления справочниками. Зачем вообще в корпоративных системах используются справочники, как их использование сказывается на производительности.
Ну и на все прочие вопросы, которые после пятой/десятой спроектированной системы обычно уже не возникают. И после этого уже "умные" вопросы задавай.
Ах, да, и где там внутри справочника нужны join'ы ;)


Оракл где-то писал (давно было - ссылку не найду), что PL/SQL в режиме интерпретации в два раза быстрее Явы. А начиная с версии 9i PL/SQL может компилироваться в натив код (через С).

Очень хотелось бы посмотреть на ссылку. А то Java, вообще говоря, чистому C уступает максимум на десятки процентов, а зачастую и превосходит. Может, это про Java 1.0 было? Так с тех пор много воды утекло. В общем, надо посмотреть, что именно Oracle мерял и для чего - а то если меряли для рекламы использования хранимых процедур, то PL/SQL и C мог бы превзойти, дурное дело не хитрое.
P.S. Кстати, Java уже довольно давно автоматически компилится в нативный код (если это окупится при выполнении). См. JIT.
23 май 08, 01:17    [5703704]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
mva103

Я проводил нагрузочное исследование для выяснения нагрузочной способности MSSQL и Oracle. Задача тестирования была в выяснении потолка количества обслуживаемых простых запросов от application layer(делался селект из таблицы в 4 записи). Архитектура была такая
RDBMS<------>(APACHE + PHP) * 4<----------->nginx+ round robin<--------->client * N
К сожалению не могу привести абсолютных цифр, т.к. тестировал для себя, а не для отчета


Было бы, конечно, интересно посмотреть на результаты теста (численные) - хотя бы примерно.

Но, честно говоря, зачем application layer усиленно ходить к БД с такими запросами, да еще и в таком режиме. Кэш делу не помог бы? Или данные менялись через БД, в обход application layer? И в основном сверялись версии данные в кэше с данными в БД? Т.е. какую задачу решает такое массовое обращение?

И в таком случае правильно ли было использовать схему "тред на запрос"? Если основное, что делают треды - это ждут ответа от БД? Может, использовать схему однопоточной последовательной обработки было бы лучше? Правда, конечно, кодировать это существенно сложнее и думать нужно гораздо больше (и не знаю, можно ли это вообще сделать на PHP).
23 май 08, 01:25    [5703722]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
2DPH
У вас несколько односторонний взгляд на вещи. БД - для хранения и обработки данных. Она проектируется и живёт по своим правилам, отличным от того, что вы делаете на уровне приложения, особенно java-приложения.
Я это к тому, что справочники должны храниться в базе нормализованными и "разворачиваться" при помощи "джойнов" в удобоваримый для application layer вид. А вы уже можете кешировать результаты этой выборки, а не сырой селект из таблиц. Проблемы здесь не вижу.

Ещё меня смутило ваше предложение
DPH
Или данные менялись через БД, в обход application layer?
Звучит так, как будто это вас удивляет и возмущает. Я вас правильно понял?


P.S.
Выступления под анонимом дают вам ложное чувство безнаказанности, переходящее в хамство. А это всё же технический форум. Пожалуйста, будьте более профессиональным в своих сообщениях и адекватным в использовании "ты" и "вы".

--
Per rectum ad astrum
23 май 08, 03:25    [5703793]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
DPH
tygra
Извините, но если идет речь о системе с количеством пользователей, измеряемым миллионами, и в то же время считать копейки - у вас ничего не получится уже до того, как чего-то начнете.

Не копейки. Для указанной системы стоимость лицензий - самый большой планируемый расход (если не делать систему на, по мере возможности, бесплатных или дешевых решениях). Windows Data Center (да даже и Server 2008 64bit) - это очень дорого.

Так где же примеры расчетов то? Где цена win-решения, где другая цена? Или цифр не знаете, но просто религия не позволяет windows использовать?

mva103
читал читал читал....
Моя пилюля:
Я проводил нагрузочное исследование для выяснения нагрузочной способности MSSQL и Oracle. Задача тестирования была в выяснении потолка количества обслуживаемых простых запросов от application layer(делался селект из таблицы в 4 записи). Архитектура была такая
RDBMS<------>(APACHE + PHP) * 4<----------->nginx+ round robin<--------->client * N
К сожалению не могу привести абсолютных цифр, т.к. тестировал для себя, а не для отчета. Результат - oracle в SHARED MODE победил MSSQL 2005 по кличеству обслуженных пользователей. При этом Oracle сложнее в суппорте application layer т.к. апач ЖДЕТ пока оракл таки даст ответ на запрос, что приводит к быстрому переполнению доступных юзеров у апача, а mssql при перегрузке быстро рвал сессию, т.е. возвращал пустой результат. Результат теста - business critical web стучит в оракл. Несмотря на то что лично мне MSSQL обслуживать проще.

Результаты без цифр, без конфигураций и т.д. - это типа "мамой клянусь" :))

Тем более, на сколько пользователей больше обслужил Оракл - на 1, 2, 5?

-- Tygra's --
Мои фотогалереи тут и тут
23 май 08, 09:16    [5703969]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
mva103
Member

Откуда:
Сообщений: 50
автор
Было бы, конечно, интересно посмотреть на результаты теста (численные) - хотя бы примерно.

К сожалению рад бы помочь - но нету цифр, а собирать второй раз такую систему только ради цифр как то некошерно :)
автор

Но, честно говоря, зачем application layer усиленно ходить к БД с такими запросами, да еще и в таком режиме. Кэш делу не помог бы? Или данные менялись через БД, в обход application layer? И в основном сверялись версии данные в кэше с данными в БД? Т.е. какую задачу решает такое массовое обращение?

У меня были проблемы с вебприложениями - когда большой поток клиентов на один из сайтов укладывал базу и все начинало безбожно тормозить. Клиенты 99.999% обычно читали, а не писали. Т.е. база большее время работает на select'ы чем на изменение данных. Поэтому такой тест и проводил.

автор
И в таком случае правильно ли было использовать схему "тред на запрос"? Если основное, что делают треды - это ждут ответа от БД? Может, использовать схему однопоточной последовательной обработки было бы лучше? Правда, конечно, кодировать это существенно сложнее и думать нужно гораздо больше (и не знаю, можно ли это вообще сделать на PHP).

Тред апача инициирует TCP/IP соединение к субд (уже жрет кучу времени и ресурсов), посылает СУБД запрос, ждет ответа, потом отваливается. Если ответ долго не приходит - то тред висит и только по таймауту отпадает. Такая история в случае с ораклом приводила к неработоспособности всего application layer и с ней проводится борьба тюнингом лоадбалансера и апачей :).


автор
Результаты без цифр, без конфигураций и т.д. - это типа "мамой клянусь" :))
Тем более, на сколько пользователей больше обслужил Оракл - на 1, 2, 5?

Ну конфигурации были более чем достаточные, смею вас уверить :). А что касается цифр - тест проводился не для публикации, не для того чтобы потом на форумах кричать "ААААА оракл поборол мсскл, мсскл г*вно!". А для того чтобы построить наежную и живую аппликуху. У меня хватает серверов ораклиных и MSSQL (вендоры софта используют только MSSQL). Ядро мы выстроили на оракл (хотя логичней бы было конечно для преемственности использовать решение Microsoft). У обеих субд есть масса достоинств и недостатков и каждая хороша для своих целей. Для heavy load www по моему скромному мнению хорош оракл.
23 май 08, 11:33    [5705057]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
DPH

Вменяемые - не делают, они вообще не используют ORM на нагруженных системах.

ну и много твоих вменяемых хотя бы в России/СНГ забубенивших нагруженную систему на жабе ? чо-то на top.mail.ru я таковых не наблюдаю.

DPH

Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.

DPH

Ну и на все прочие вопросы, которые после пятой/десятой спроектированной системы обычно уже не возникают. И после этого уже "умные" вопросы задавай.

ахтунг ! ниосиливший сомучитель сейчас нас всех научит как нужно проектировать
это должно быть занимательно !
23 май 08, 11:35    [5705079]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Yo.!
VoDA

А тянуть "гигабайты данных по эзернету в жава и там их лопатить" это сказки. Никто вменяемый так не делает (кроме случая когда это действительно необходимо).

делают, еще как делают :(
обычно все начинается с кеширования справочников в хибернейте со словами, хибер же лучше заджоинит ...
ХЗ если product owner говорит "мамой клянусь справочник будет меньше 100 записей", а запросов его использующий много... то может иметь смысл доделывать именно этот джойн на клиенте.

Зачем int значение - внешний ключ разворачивать в nvarchar(1024) на сервере, если сам клиент обладает этой информацией.


преждевременная оптимизация - корень всех бед.
23 май 08, 11:55    [5705344]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
DPH
Вменяемые - не делают, они вообще не используют ORM на нагруженных системах.
Большинство систем создаваемых на любом языке - не нагруженные. А за счет hibernate софто-присатели хотят уменьшить время программирования, а значит понизить себестоимость.


DPH
Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.
А как вы собираетесь использовать справочник по ссылке через внешний ключ НО не джойнясь при этом???
23 май 08, 11:59    [5705406]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Anton Demidov

У вас несколько односторонний взгляд на вещи. БД - для хранения и обработки данных. Она проектируется и живёт по своим правилам, отличным от того, что вы делаете на уровне приложения, особенно java-приложения.

Все верно, конечно. Но если мы проектируем сразу трехзвенку (а такое часто случается), то стоит учитывать и возможности/ограничения БД и возможности/ограничения AppLayer'а - тогда всем будет проще. Увы, обычно в проекте или хорошо знают БД или хорошо умеют работать с Java/PHP/C# - в результате появляются странные решения.

Anton Demidov

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

В общем, конечно, да. Но смотри(те), для обычных звездочек (таблица с данными, куча классификаторов через искусственные, например, ключи) при таком решении мы получим:
1) Для каждого запроса нужно делать несколько join'ов по всем таблицам справочников (обычно редко изменяемых)
2) Для каждого типа запроса на AL придеться: получать очередную звезду, вытаскивать и переводить в соответствующие Java(например) объекты все полученные сущности (как факты, так и каждый из классификаторов). При этом есть некоторые проблемы - например, придумать всегда одинаковую (для простоты кодирования) схему именования алиасов для разных объектов.
В любом случае нужно будет дополнительное кодирование и сложно делать code reuse.

Есть другой вариант:
Все в БД хранится так же, но AL выбирает только нужные факты, без join на справочники.
Справочники (в уже удобном виде) живут в кэше AL (стратегии можно разные придумать - lazy loading, загрузка при старте и т.п. - зависит от размера справочника и много другого). Связывание id с конкретным объектом делает уже сервер приложений. Кстати, зачастую может выяснится, что привязывать объект к справочнику внутри и не нужно.

Нарушений нормализации - нет, но и лишних join'ов - тоже нет. Работает быстрее, кода нужно писать меньше. Это - стандартная практика.

Кстати, я первый пост про join понял в другом ключе - что необходимы join "внутри" справочника - а это уже не совсем правильная вещь.



Ещё меня смутило ваше предложение
DPH
Или данные менялись через БД, в обход application layer?
Звучит так, как будто это вас удивляет и возмущает. Я вас правильно понял?

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

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




Выступления под анонимом дают вам ложное чувство безнаказанности, переходящее в хамство. А это всё же технический форум. Пожалуйста, будьте более профессиональным в своих сообщениях и адекватным в использовании "ты" и "вы".

Я думаю, по моему нику найти все мои личные данные не займет и пяти минут, я не считаю анонимность существенной. Будем считать, что мы взаимно обменялись наездами и на этом прекратили. Я по умолчанию считаю, что собеседника стоит уважать, пока он не показал обратного.

P.S. С "ты" и "вы" все довольно сложно, это очень индивидуальная особенность. Если есть конкретные пожелания по обращению, то постараюсь их выполнить.
Умолчания, увы, практически не действуют - на разных форумах, в разных ветках, для разных людей действуют разные условности обращений.


--
Per rectum ad astrum[/quot]
23 май 08, 13:06    [5706154]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Yo.!

ну и много твоих вменяемых хотя бы в России/СНГ забубенивших нагруженную систему на жабе ? чо-то на top.mail.ru я таковых не наблюдаю.

А как ты отличаешь написанные на JAVA от обычного LAMP? Вообще информация о архитектуре почти всегда NDA.

В РФ вообще мало сколь-нибудь нагруженных систем и меньшая часть из них на top.mail.ru.
Но значительная часть сервисов Яндекса, например, живет на Java, в том числе и сильно нагруженные.
Из не только РФ систем, с которыми знаком - есть биржевые системы (а это - уже 50+K событий в секунду), букмекерские сайты. Из крупных сайтов (хотя это уже не просто нагруженные, а очень нагруженные системы) - eBay.

По моему опыту, сайты, выросшие из мелких студенческих проектов - LAMP. Те, что сразу проектировались под высокую нагрузку - Java или C/С++.
23 май 08, 14:49    [5707080]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
VoDA
Большинство систем создаваемых на любом языке - не нагруженные. А за счет hibernate софто-присатели хотят уменьшить время программирования, а значит понизить себестоимость.

Ага. Я не в малейшей степени не отрицаю полезность hibernate - у него хоть и не безумно широкая, но очень популярная сфера применения. Но вот в нагруженных системах не стоит использовать.

DPH
Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.
А как вы собираетесь использовать справочник по ссылке через внешний ключ НО не джойнясь при этом???[/quot]
Ты в своем предыдущем посте описал именно то, что я имел в виду - сборку на клиенте (да и то, если нужно).
23 май 08, 14:58    [5707162]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить