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

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

В РФ вообще мало сколь-нибудь нагруженных систем и меньшая часть из них на top.mail.ru.

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

DPH

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

Яндекс поиск это Perl и C++ остальные сервисы имхо там не шибко популярны в народе.

ЗЫ. кеширование справочников не самое страшное, пораженный ООП мозг подавляющего большинства (согласен, не всех) java-девелоперов не пытается оперировать множествами, повсюду работа с одним объектом. просто на фоне пхп-кодера от java-человека обычно ожидаешь мягко говоря большего...
23 май 08, 15:39    [5707509]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Ну, не все так печально.
Просто основной поток java разработки идет не на рынок РФ. А на западе большой нагруженный сайт, который сразу таковым проектируется - с большой вероятностью делается на Java.

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

Есть гораздо более распространенный вид систем, отягощенных нагрузкой.
Это где-то от сотен запросов на чтение в секунду, сотни пишущих транзакций в секунду в пиках. Тут уже, с одной стороны, точно есть сложности с БД, необходима хорошая масштабируемость, цена на лицензии на "взрослый" софт очень существенна. Таких делается много, в том числе и на Java или C# - так как это вполне "заказные" вещи и нагрузка планируется заранее.

И вот на рынке аутсорсинга найти Java архитекторов, понимающих, как делать подобные системы, отягощенные нагрузкой - можно. Разработчиков, в общем, тоже не сложно. Найти PHPшников, умеющих делать хорошо и нагружено, в общем, не легче и уже не дешевле.

Кстати, нагруженные сервисы в Яндексе есть и на Java.
23 май 08, 16:30    [5707936]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Yo.!
ЗЫ. кеширование справочников не самое страшное, пораженный ООП мозг подавляющего большинства (согласен, не всех) java-девелоперов не пытается оперировать множествами, повсюду работа с одним объектом. просто на фоне пхп-кодера от java-человека обычно ожидаешь мягко говоря большего...

Справочники кэшировать как раз полезно :) И работа с одним объектом иногда (иногда) вполне оправдана.
А единственное, что я жду от любого разработчика - это здравый смысл и огонь в глазах. Остальному и научить можно. Другое дело, что даже таковых приходится искать долго и стоят они не дешево.

Вообще, основной плюс среднего джависта - это написание более читабельного кода и привычка с опаской относится к спагетти. Такие бывают и среди PHPшников, но реже.
К тому же основной поток аутсорса по java дает довольно сомнительные привычки. Впрочем, с другими языками не лучше.
23 май 08, 16:36    [5707983]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Из своего достаточно серьезного опыта общения PHP-программистами, пытаюсь представить себе PHP-программиста рядом со словом "шардинг" и "кеширование" и честно мне страшно, хотя наверное бывает иначе, но как сказала одна моя знакомая: "Когда человек программируя на PHP достигает некоторого уровня он уходит в Java или C#, т.к. там платят больше". Именно по этой причине сложно найти хорошего PHP-программиста, обычно они уже бывшие.

Кстати, еще один вопрос (по лицезированию): правильно ли я понимаю, что веб-системы можно строить на пользовательских лицензиях, и использовать одно соединение с базой на несколько веб-соединений или есть какая-то "засада"?
23 май 08, 17:38    [5708433]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
DPH
Anton Demidov
Вы что-нибудь про нормализацию данных слышали? Третья нормальная форма?

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


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

Откуда: сеРверная пальмира :)
Сообщений: 4898
DPH
Ты в своем предыдущем посте описал именно то, что я имел в виду - сборку на клиенте (да и то, если нужно).
Обратная ситуация: есть БД обо всех жителях России (это пример).
Тогда справочник фамилий может иметь порядки 10 - 100 млн. записей. Тащить это на Апп. сервер дорого и неэффективно, к тому же есть и другие справочники. Потому скорее всего нужно обрабатывать на сервере.

Потому нужно понимать что делаешь и зачем.
23 май 08, 17:58    [5708569]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
maximpr1111
Кстати, при разработке баз данных для высоконагруженных систем обычно применяется денормализация и не используются встроенные в СУБД механизмы поддержки целостности данных.
Я бы осторожнее использовал термин "обычно". Отказ от foreign key в высоконагруженной системе - это одно (добровольное согласие проверять целостность связей вручную с возможным геморроем по востановлению). Денормализация для улучшения производительности высоконагруженной системы - это совсем другое. Это же получается перенос части нагрузки с ЦПУ на дисковую систему. Странно, очень странно.
maximpr1111
Когда я занимался нагрузочным тестированием для одного очень известного банка именно таким образом проводилась оптимизация системы под нагрузку.
Какая была СУБД?
DPH
Стандартной практикой для трехзвенок является запрет на изменение БД не через стандартные средства AL. Если делается иначе - то нужно точно понимать, почему.
Запрет на изменения справочников в БД - согласен. Изменения БД в общем - нонсенс (пакетная обработка как пример).
По остальным вопросам мы, похоже, достигли консенсуса.
23 май 08, 19:21    [5708955]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
VoDA
Обратная ситуация: есть БД обо всех жителях России (это пример).
Тогда справочник фамилий может иметь порядки 10 - 100 млн. записей. Тащить это на Апп. сервер дорого и неэффективно, к тому же есть и другие справочники. Потому скорее всего нужно обрабатывать на сервере.
Потому нужно понимать что делаешь и зачем.

Угу, понимать точно нужно ;) Универсальных решений нет.
23 май 08, 21:16    [5709209]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Anton Demidov
Денормализация для улучшения производительности высоконагруженной системы - это совсем другое. Это же получается перенос части нагрузки с ЦПУ на дисковую систему. Странно, очень странно.

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

Anton Demidov
Запрет на изменения справочников в БД - согласен. Изменения БД в общем - нонсенс (пакетная обработка как пример).

Зависит от стратегии кэширования, стратегии хранения и т.п. Иногда, конечно, приходится допускать и прямое изменение БД, но в среднем - страшно. Например, если я храню предвычисленные остатки, то пакетная вставка данных по операциям в БД мне очень дорого обойдется.
Когда такое нужно - приходится создавать очень специальные способы для пакетной вставки, готовить эти пакеты хитрым образом. Т.е., по сути, создание на сервере приложений специальной команды пакетной вставки :)

Длительные размышления о хранении данных как сервисе - опущены ;)


По остальным вопросам мы, похоже, достигли консенсуса.

Ага.
23 май 08, 21:30    [5709234]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Anton Demidov
maximpr1111
Кстати, при разработке баз данных для высоконагруженных систем обычно применяется денормализация и не используются встроенные в СУБД механизмы поддержки целостности данных.
Я бы осторожнее использовал термин "обычно". Отказ от foreign key в высоконагруженной системе - это одно (добровольное согласие проверять целостность связей вручную с возможным геморроем по востановлению). Денормализация для улучшения производительности высоконагруженной системы - это совсем другое. Это же получается перенос части нагрузки с ЦПУ на дисковую систему. Странно, очень странно.


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

Вообщем, это достаточно творческий процесс, и при принятии решений учитывается очень много факторов. Просто я хотел сказать, что когда начинается проектирование баз под высоконагруженные системы многие устоявшиеся представления о правилах проектирования переворачиваются с ног на голову. При чем оптимизация идет под конкретную СУБД. Там был Oracle.
24 май 08, 11:40    [5709969]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Что бы моё молчание не расценили как согласие отвечу.

DPH. Пакетная обработка на application сервере - только для маленьких объёмов. Проблемы производительности заставят вас перенести обработку непосредствено не сервер. Если у вас не было таких проблем - значит у вас не было больших объёмов (больших относительно аппаратных возможностей серверов). Например, я сейчас работаю над системой, которая обработала 4.8Тб в апреле. Оракл 10.2, Линукс 64бит, Интел.

maximpr1111.
Выигрыш от такого типа денормализации можно получить, но он потеряется с ростом размера таблицы. А таблицы склонны расти со временем ... И ещё меня смутили ваши слова чтобы ускорить выборку данных и уменьшить количество запросов к БД - звучит так, как будто вы отдельным запросом делаете выборку из справочника. А что, сразу одним селектом нельзя вытащить на апп сервер ваши данные?

--
Per rectum ad astrum
27 май 08, 22:50    [5724195]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Dan Black
Member

Откуда:
Сообщений: 544
автор
я сейчас работаю над системой, которая обработала 4.8Тб в апреле
Посчитал и получилось ~ 8 Мб/с при 8 часовом рабочем. Негусто... Свитч на 100 Мбит/с за 10 баксов и то быстрее данные обрабатывает :) При этом размер его внутренней БД невелик, даже самодельной БД достаточно :)
----------------------------
Verba volent, scripta manent
28 май 08, 14:35    [5727278]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
этот свич данные не хранит и не обрабатывает историю
28 май 08, 21:30    [5729962]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Dan Black
Посчитал и получилось ~ 8 Мб/с при 8 часовом рабочем. Негусто... Свитч на 100 Мбит/с за 10 баксов и то быстрее данные обрабатывает :) При этом размер его внутренней БД невелик, даже самодельной БД достаточно :)

Немного нестандартный ход, но тем не менее он показывает осознание вами проблемы с производительностью у Явы.
Ява - не универсальный инструмент. Для массовой обработки больших объёмов данных он не подходит.

Позвольте небольшое отступление в оффтоп.
Яву продвигают Sun и IBM - т.е. производители железа. С чего они получают доход: с продажи компилятора Явы или супер-пупер числомолотилки? Вот и подумайте, насколько они заинтересованы в оптимальности скомпилированного кода.
28 май 08, 21:53    [5730013]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Dan Black
Member

Откуда:
Сообщений: 544
Anton Demidov
Немного нестандартный ход, но тем не менее он показывает осознание вами проблемы с производительностью у Явы.
Ява - не универсальный инструмент. Для массовой обработки больших объёмов данных он не подходит.
Позвольте небольшое отступление в оффтоп.
Яву продвигают Sun и IBM - т.е. производители железа. С чего они получают доход: с продажи компилятора Явы или супер-пупер числомолотилки? Вот и подумайте, насколько они заинтересованы в оптимальности скомпилированного кода.
Просто из Вашего поста неясно, что за данные и в чём заключается их обработка, поэтому я написал первое, что пришло в голову :)
Опять же всё вышесказанное очень зависит от типов данных и способов их обработки.
(ОФФ: пример, простая утилита, написанная на яве парсит гигабайтный файл за 20-30 секунд на моём домашнем не особо мощном компьютере. Парсер, написанный на С, работает в 1,5 - 2 раза быстрее. Программа на яве кушает памяти в 1,5 больше программы на С. Разница небольшая, учитывая сколько вкусностей несёт вместе с собой Java)
Понятно, что ява не является универсальным инструментом для всего и вся. Но выбор инструмента для конкретной задачи всегда является компромиссом между возможными решениями. А критерии, на основе которых происходит выбор, обычно зависят от возможностей выбирающего и ограничений, накладываемых требованиями. И если после сложения плюсов и минусов будет выбрана ява для обработки данных, то значит будет использоваться ява, а если будет выбран С++, то будет использоваться С++. И все будут довольны, так как требования выполняются.
Про Sun и IBM ничего сказать не могу, так как не интересовался их политикой. Но, думаю, у них, конечно, есть свой интерес в этом деле.
28 май 08, 22:42    [5730122]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

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

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

Откуда: spb
Сообщений: 1166
Dan Black
поэтому я написал первое, что пришло в голову :)

Виктор Степанович, Вы?..
29 май 08, 10:28    [5731069]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Dan Black
Anton Demidov
Немного нестандартный ход, но тем не менее он показывает осознание вами проблемы с производительностью у Явы.
Ява - не универсальный инструмент. Для массовой обработки больших объёмов данных он не подходит.
Позвольте небольшое отступление в оффтоп.
Яву продвигают Sun и IBM - т.е. производители железа. С чего они получают доход: с продажи компилятора Явы или супер-пупер числомолотилки? Вот и подумайте, насколько они заинтересованы в оптимальности скомпилированного кода.
Просто из Вашего поста неясно, что за данные и в чём заключается их обработка, поэтому я написал первое, что пришло в голову :)
Опять же всё вышесказанное очень зависит от типов данных и способов их обработки.
(ОФФ: пример, простая утилита, написанная на яве парсит гигабайтный файл за 20-30 секунд на моём домашнем не особо мощном компьютере. Парсер, написанный на С, работает в 1,5 - 2 раза быстрее. Программа на яве кушает памяти в 1,5 больше программы на С. Разница небольшая, учитывая сколько вкусностей несёт вместе с собой Java)
Понятно, что ява не является универсальным инструментом для всего и вся. Но выбор инструмента для конкретной задачи всегда является компромиссом между возможными решениями. А критерии, на основе которых происходит выбор, обычно зависят от возможностей выбирающего и ограничений, накладываемых требованиями. И если после сложения плюсов и минусов будет выбрана ява для обработки данных, то значит будет использоваться ява, а если будет выбран С++, то будет использоваться С++. И все будут довольны, так как требования выполняются.
Про Sun и IBM ничего сказать не могу, так как не интересовался их политикой. Но, думаю, у них, конечно, есть свой интерес в этом деле.


Вмешаюсь в данный спор, и напомню, что первоначальной задачей о которой шла речь является веб-приложение. Так что при выборе инструмента речь скорее идет о выборе между Java, PHP, C#(ASP.Net). C++ конечно мощный инструмент и приложение написанное на нем будет самым оптимальным и производительным, но какое количество человеко-часов надо затратить для написания на нем веб-приложения, учитывая, что начинать придется с написания http-сервера.
29 май 08, 10:28    [5731072]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Dan Black
Member

Откуда:
Сообщений: 544
tygra
Читаю и удивляюсь - чего только люди не придумают, чтобы усложнить жизнь себе и системе
В большинстве случаев люди хотят упростить жизнь себе в краткосрочной перспективе, не задумываясь о будущем ;-)
29 май 08, 10:28    [5731074]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Dan Black
Member

Откуда:
Сообщений: 544
maximpr1111
Вмешаюсь в данный спор, и напомню, что первоначальной задачей о которой шла речь является веб-приложение. Так что при выборе инструмента речь скорее идет о выборе между Java, PHP, C#(ASP.Net). C++ конечно мощный инструмент и приложение написанное на нем будет самым оптимальным и производительным, но какое количество человеко-часов надо затратить для написания на нем веб-приложения, учитывая, что начинать придется с написания http-сервера.
Вообще, топик о выборе СУБД ;-) но чем ближе 10 страница, тем сложнее придерживаться темы :)
29 май 08, 10:31    [5731098]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
maximpr1111
Вмешаюсь в данный спор, и напомню, что первоначальной задачей о которой шла речь является веб-приложение. Так что при выборе инструмента речь скорее идет о выборе между Java, PHP, C#(ASP.Net). C++ конечно мощный инструмент и приложение написанное на нем будет самым оптимальным и производительным, но какое количество человеко-часов надо затратить для написания на нем веб-приложения, учитывая, что начинать придется с написания http-сервера.

Я забыл написать, что я пишу и обработку данных и интерфейсный слой на PL/SQL (modplsql + Apache AKA Oracle HTTP Server). БД выступает в роли апп сервера. У меня DWH - данных много, пользователей мало.

Если пользователей много и хочется разгрузить БД от непрофильной нагрузки, то ставится апп сервер от Оракла, который, естественно, понимает, что с этим делать. Пример - сайт поддержки Оракла https://metalink.oracle.com/metalink/plsql
Обратите внимание на plsql в URL-e - это и есть PL/SQL cartridge.
29 май 08, 22:29    [5736225]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
zloy den
Member

Откуда:
Сообщений: 2579
Anton Demidov
[quot maximpr1111] Пример - сайт поддержки Оракла https://metalink.oracle.com/metalink/plsql
Обратите внимание на plsql в URL-e - это и есть PL/SQL cartridge.


Это только у меня окно с логином загружается по 30 секунд?
30 май 08, 10:54    [5737422]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Нет, не только - у них канал в какой-то заднице проходит :))

-- Tygra's --
Мои фотогалереи тут и тут
30 май 08, 11:41    [5737847]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Anton Demidov
Пакетная обработка на application сервере - только для маленьких объёмов. Проблемы производительности заставят вас перенести обработку непосредствено не сервер. Если у вас не было таких проблем - значит у вас не было больших объёмов (больших относительно аппаратных возможностей серверов). Например, я сейчас работаю над системой, которая обработала 4.8Тб в апреле. Оракл 10.2, Линукс 64бит, Интел.

Сложно сказать что-то конкретное, не зная, что скрывается под словом "обработала".
Например, для моих задач "обработка" - это просто пишущая транзакций (ну и куча бизнес-логики вокруг). Для характерных объемов, 4.8TB в месяц - это где-то 2000 раздельных транзакций в секунду. Основные тормоза будут при записи в БД, решаются или хорошим планированием размещения или шардингом (в зависимости от задачи).
Основная беда - что при обычной неравномерности загрузки 2000 в среднем значит до 100 000 в секунду в пике. Сделать кластер (машин из 4х), который держит 100K запросов в секунду можно, а вот с БД уже будут проблемы.

Это если делать OLTP и по одной транзакции на операцию (причем, для моих задач, еще и serializable).

Если же DWH, то вообще никаких проблем не вижу, это вообще не нагрузка для Java. Ну, разве что под обработкой подразумевается построение 3D схем. Точно также не вижу проблем на стороне ApplicationServer готовить пакеты для загрузки в БД.


P.S. Для трейдинговых систем (на Java) нормальным является нагрузка в 50K запросов в секунду на сервер - и ничего, живут вполне спокойно. Основные беды, по общению с разработчиками, не в скорости Java, а в пропускной способности сети, работе с сокетами в ОС и т.п.
P.P.S. У меня сравнимый объем (единицы TB в месяц) генерится логов. И их обработкой занимается вообще shell+awk (в т.ч) - и никаких проблем не возникает.
30 май 08, 14:19    [5739203]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Anton Demidov

Я забыл написать, что я пишу и обработку данных и интерфейсный слой на PL/SQL (modplsql + Apache AKA Oracle HTTP Server). БД выступает в роли апп сервера. У меня DWH - данных много, пользователей мало.

Если пользователей много и хочется разгрузить БД от непрофильной нагрузки, то ставится апп сервер от Оракла, который, естественно, понимает, что с этим делать. Пример - сайт поддержки Оракла https://metalink.oracle.com/metalink/plsql
Обратите внимание на plsql в URL-e - это и есть PL/SQL cartridge.


Гм. Если я правильно помню, сервер приложений от Оракла - это, в девичестве, Orion. Штука для отладки удобная, но в production под нагрузкой лучше не выставлять, тормозит и при нагрузках подглюкивает.

Кстати, а сколько запросов в секунду (простых get) держит интерфейсный слой на PL/SQL? В расчете на ядро?

И, все-таки, что такое "обработала"? И почему обработка в Оракле будет быстрее, чем на сервере приложений (какие причины?)

P.S.
Metalink, насколько я помню, вообще отличается изрядной задумчивостью - это уже не раз обсуждалось. В чем причина - не знаю (и даже не буду строить предположений). Кстати, а metalink разве не на APEX сделан?
30 май 08, 15:59    [5740099]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить