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


не понял, с каких пор процедуры на C++ и Java начали работать внутри ядра db2 ?? для C только пару лет назад компилятор в поставку начали класть. и некий db2 magazine утверждал обратное (в чудо-документации мне ничего на эту тему найти не удалось).
5 июн 08, 15:27    [5765354]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

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

У вас "шапочнозакидочное" отношение к сложным задачам. Я посмотрел на вашу статистику постов - никто из вас не показывал большой активности в форума Оракла. Я подозреваю, что PL/SQL вы не знаете на профессиональном уровне. Так как же вы можете рассуждать о его плюсах и минусах?
У вас "шапочнозакидочное" отношение к сложным задачам. Я посмотрел на вашу статистику постов - никто из вас не показывал большой активности в форума Java. Я подозреваю, что Java вы не знаете на профессиональном уровне. Так как же вы можете рассуждать о его плюсах и минусах?

В общем фраза ни о чем. Сойдемся на этом :))

Anton Demidov
Я не знаю Яву настолько хорошо, чтобы давать советы другим в том форуме.
По работе я занимаюсь ДБА поддержкой программеров и SQL application tuning. У нас используются Oracle 10g, DB2/400 (5R4), DB2 for zOS 7.1, DB2 for LUW 9.1. На Яве много пишут.

А теперь давайте перейдем к техническим преимуществам использования Oracle / Java для анализа.

Плюсами Oracle являются:
1. наличие большого количества документации по PL/SQL.
2. большое количество DBA / script писателей.
3. именитость платформы на рынке хранения и обработки данных.
4. обкатанность платформы на больших проектах / системах.

Минусы Oracle:
1. Стоимость лицензий.
2. Как следствие 1 покупаются более мощьные машины, чтобы получить ту же мощьность, но на меньшем количестве процессоров.
3. Штатно поддерживает только определенные платформы (RHEL / SLES / Solaris / Win / etc).
4. Труднее научить людей мыслить в реляционном подходе.


Плюсы Java:
1. наличие большого количества документации по языку.
2. большое количество Java developers.
3. нулевая стоимость лицензий.
4. возможность запуска на бОльшем числе платформ (Debian как дополнительный пример).
5. именитость платформы только на рынке обработки данных (для данного случая).
6. Проще раскидывается но множество компьютеров.

Минусы Java:
1. больше программистов Java используют процедурный, а не реляционный подход к обработке данных (бегают циклами), что может приводить к сильному падению производительности.
5 июн 08, 15:31    [5765380]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

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

К тому же AS можно поставить десяток вместо 1 мега-Oracle. Производительность зависит от радиуса кривизны рук!
5 июн 08, 15:34    [5765424]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
tygra
Просто вы не умеете готовить бизнес-логику внутри БД :)
Проще делать не внутри БД только то, что там сделать невозможно. Все остальное проще внутри. Уж поверьте - большой опыт и в обычных системах, и в веб. 90% работ с данными делается только в СУБД, и правлю я тоже все в СУБД, это к тому же проще.
Простите, а что вы будете делать в web если количество пользователей подойдет к 1 000 000 пользователей. для больших систем почему то чаще выбирают реализацию с АппСервером. Хотя если верить вам, то стоит всю логику перенести в СУБД (пусть и по http тоже она отвечает) и вот оно сщасттЪе
5 июн 08, 15:42    [5765505]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
что-то не пойму, это же настолько очевидно. апп-сервер это внешний от субд процесс, при запросе вы тащите копию данных через протокол (небойсь еще и TCP/IP) - т.е. самый тормозной и самый не оптимальный путь какой можно придумать для юзания жавы. pl/sql же исполняется в том же адресном пространстве, что и субд и имеет гораздо меньше переключений контекста.
М.б. очевидно для Оракла и совсем не очевидно для DB2. Для DB2 Java, как и C++, может исполняться: фактически внутри сервера; под его управлением, но на выделенной Java-машине; снаружи (апп. сервер) на том же физ. сервере с локальным коннектом (фактически, передача данных через ОП); где угодно через любой сетевой протокол. А насчет PL/SQL - адресное постранство, в котором выполняется интерпретируемый язык - это сильно! :) Думаю, что его интерпретатор - это все-таки группа отдельных процессов/тредов, т.е. для процедур от Java внутри сервера конструктивно он не сильно отличается.
Кстати, следует отличать бизнес-логику (по определению, доп. ограничения, накладываемые на данные и связи между ними) и внешнюю отн. логики БД обработку данных. Бизнес-логика при хорошем SQL не требует особых процедурных наворотов и логично живет внутри БД, и уж точно не требует mail, http и т.д. Внешнюю обработку считаю логичным делать внешним апп. сервером, RDBMS'у и так есть чем заняться.

Yo.!

ЗЫ. документация по DB2 - ужасна, помнится искал может ли процедура на С отслеживать изменения в схеме и вообще в каком адресном пространстве выполняется. не нашел даже намеков на концепции. хуже документация имхо только у FB.
Не поверите, но про адресное пространство процедуры на C надо было искать "CREATE PROCEDURE (External) statement", поиск по "create procedure", 4-я строка сверху :)
вот тут, см. FENCED, THREADSAFE, EXTERNAL ACTION и т.д.
5 июн 08, 15:46    [5765543]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
VoDA

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

минусов гораздо больше:

2. оторвоность данных от логики приводит к невозможности полноценно сопровождать код. в оракле при изменении структуры данных, процедуры которых коснулись изменения пометятся инвалидными и будут защищены от запуска. внешняя жава же запустит поломанный код, не подозреваю об изменения в субд и вывалится с экспшеном лишь когда наткнется на ошибочный SQL. последствия не предсказуемы.
3. очень медленно разработка, то что делается в pl/sql одной конструкцией в жава десятки строк, плюс очень многословный язык, разработчик вынужден строчить мегобайты кода.
4. медленно - если это внешний апп сервер, то лишние расходы на память и транспортировку данных, если это в ядре субд (только оракл такое имеет) - много подводных камней и слабая обкатоность решений.
5 июн 08, 15:47    [5765557]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
2Favn

1. вы имеете ввиду субд на жава ? их возможности сегодня сильно не дотягивают до оракла 80х, особенно в области тяжелых обработки
2. я против того чтоб оракл замещал веб сервер и генерил хтмл, уровень представления имхо должен быть за пределами оракла, речь идет о бизнес логики.
5 июн 08, 15:55    [5765629]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
вот видите на сколько ужасна дока по дб2, вы работая с этой субд не смогли из документации понять даже архитектуры. не расстраивайтесь, когда я задался этим вопросом я тоже потратил несколько дней прочесывая около дб2-шные ресурсы, я нашел в db2 magazine, сейчас покапаюсь в своем архиве, параметры которые вы указали это как раз танцы смягчить оторванность и через чур низкоуровневость С процедур.
5 июн 08, 16:01    [5765677]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
блин предпоследнее сообщение было к VoDa, а последнее Favn
5 июн 08, 16:03    [5765687]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
не понял, с каких пор процедуры на C++ и Java начали работать внутри ядра db2 ?? для C только пару лет назад компилятор в поставку начали класть. и некий db2 magazine утверждал обратное (в чудо-документации мне ничего на эту тему найти не удалось).
Для C как минимум с тех пор, как я стал с DB2 работать (v. 7 лет так с 10 назад), для Java - когда ее native поддержку включили в DB2. В прошлом посте промахнулся, см. вот тут:
"If a procedure is registered as FENCED, the database manager protects its internal resources (for example, data buffers) from access by the procedure. All procedures have the option of running as FENCED or NOT FENCED. Only FENCED can be specified for a procedure with LANGUAGE OLE or NOT THREADSAFE."
Процедуры, объявленные как not fenced, для C работают в адресном пространстве сервера, для Java - на используемой им JVM; fenced процедуры - за забором, для Java - на отдельной JVM.
5 июн 08, 16:07    [5765725]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn

"If a procedure is registered as FENCED, the database manager protects its internal resources (for example, data buffers) from access by the procedure. All procedures have the option of running as FENCED or NOT FENCED. Only FENCED can be specified for a procedure with LANGUAGE OLE or NOT THREADSAFE."
Процедуры, объявленные как not fenced, для C работают в адресном пространстве сервера, для Java - на используемой им JVM; fenced процедуры - за забором, для Java - на отдельной JVM.


опять кривая ссылка, опять минус доки дб2 сложно навигать. про фенцед там же четко пишут:
A NOT FENCED stored procedure runs in the same address space as the database manager (the DB2 Agent's address space). это отдельный процесс который запускается для каждой конекции, ядро в другом процессе, мы это как то с gardenman перетерали.
5 июн 08, 16:22    [5765856]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
вот видите на сколько ужасна дока по дб2, вы работая с этой субд не смогли из документации понять даже архитектуры. не расстраивайтесь, когда я задался этим вопросом я тоже потратил несколько дней прочесывая около дб2-шные ресурсы, я нашел в db2 magazine, сейчас покапаюсь в своем архиве, параметры которые вы указали это как раз танцы смягчить оторванность и через чур низкоуровневость С процедур.
Так же ужасны и суровы преподы курсов IBM, на кот. я ходил лет так несколько назад. Это они пороли мне полную чушь, и тоже не читали тот DB2 Magazine, наверно :) Как "оторванная" C-процедура может попортить data buffers сервера (см. выше)?
"Оторванность и низкоуровнивость" (в чем они заключаются?) непричем - эти параметры как и все остальные указывают оптимизатору возможные режимы использования SP или UDF. Кстати,
Yo.!
для C только пару лет назад компилятор в поставку начали класть.
С каких это пор? Зачем в многоплатформенной поставке СУБД C-компилер? Можно использовать любую среду разработки под нужную платформу. Есть в поставке, правда, add-on к VisualStudio для работы с БД, но к SP и UDF он отношения не имеет, скорее к работе с самой БД из студии. А под Java есть DataStudio на Eclipse, в которой в т.ч. можно писать/отлаживать Java и SQL/PL SP и UDF.
5 июн 08, 16:23    [5765868]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Так же ужасны и суровы преподы курсов IBM, на кот. я ходил лет так несколько назад. Это они пороли мне полную чушь, и тоже не читали тот DB2 Magazine, наверно :) Как "оторванная" C-процедура может попортить data buffers сервера (см. выше)?

ну давай вместе по косвенным признакам гадать.

DB2 Agent
Description

Monitors database agents and their related applications. An agent is a process or thread that carries out the requests made by a client application. Each connected application is served by exactly one coordinator agent and possibly by a set of subagents. Subagents are used for parallel SQL processing in partitioned databases and on System Modification Program (SMP) machines.

For each database transaction (unit of work) that occurs when the client is connected to a database, an agent requests permission from the database manager to process the transaction.

http://publib.boulder.ibm.com/tividd/td/ITMD/SC23-4727-00/en_US/HTML/db2ref30.htm#HDRRM-AGENT

тхредовая архитектура появилось лишь в прошлом году в 9.5 и только у UDB, я еще в ней сильно не копался.

Favn

"Оторванность и низкоуровнивость" (в чем они заключаются?) непричем - эти параметры как и все остальные указывают оптимизатору возможные режимы использования SP или UDF.

в том что низкоуровневый С и C++ должен самостоятельно следить за памятью и программеру ничего не стоит сделать логическую ошибку которая приведет к memory leak. PL/SQL и Java освобождает программера от этой трудоемкой задачи.

Favn
А под Java есть DataStudio на Eclipse, в которой в т.ч. можно писать/отлаживать Java и SQL/PL SP и UDF.

а можно ссылочку на fenced java процедуры ?
5 июн 08, 16:50    [5766145]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
A NOT FENCED stored procedure runs in the same address space as the database manager (the DB2 Agent's address space). это отдельный процесс который запускается для каждой конекции, ядро в другом процессе, мы это как то с gardenman перетерали.

Процесс для каждого коннекта?! Вообще-то, там сейчас все на thread-ах. Сейчас посмотрел на один из наших серверов под Win - 167 коннектов и 8 процессов, считая db2systray :)
А в пространстве какого процесса SP, по определению делающая внешние отн. БД действия, должна выполняться? Disk i/o, что ли? Ядро - оно из разных процессов состоит. Для fenced процедур запускается отдельный процесс db2fmp. А вот not fenced UDF на C, насколько я помню, как раз внутри собственно ядра работает.
5 июн 08, 16:57    [5766230]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
на тхредах работает лишь 9.5 UDB, который только только появился, т.е. в продакшене вообще их единицы. по 9.5 я не готов разговаривать, может там в связи с тхредами все изменилось, но до 9.5 запускались отдельные процессы на каждый конект, вы с этим не согласны ?
5 июн 08, 17:09    [5766348]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
VoDA
tygra
Просто вы не умеете готовить бизнес-логику внутри БД :)
Проще делать не внутри БД только то, что там сделать невозможно. Все остальное проще внутри. Уж поверьте - большой опыт и в обычных системах, и в веб. 90% работ с данными делается только в СУБД, и правлю я тоже все в СУБД, это к тому же проще.
Простите, а что вы будете делать в web если количество пользователей подойдет к 1 000 000 пользователей. для больших систем почему то чаще выбирают реализацию с АппСервером. Хотя если верить вам, то стоит всю логику перенести в СУБД (пусть и по http тоже она отвечает) и вот оно сщасттЪе

Йа процитирую не мой, но ответ:
Yo.!
2. я против того чтоб оракл замещал веб сервер и генерил хтмл, уровень представления имхо должен быть за пределами оракла, речь идет о бизнес логики.


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

Тадыть гораздо больше гибкости и возможности.
Кстати, про перенести в СУБД (пусть и по http тоже она отвечает) - это ваши фантазии, я такого никогда не говорил и не скажу :)) Хотя тут многие говорят, только наоборот - отдадим апп-серверу и отображение, и обработку данных, а СУБД пусть будет в роли большого dbf - и будет вам щастте :))

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

В общем, я не вижу проблем с тем, чтобы отдать только СУБД обработку данных, а веб-апп-серверу - только отображение этих самых данных. Надо отойти от стереотипов джавы - вся обработка только на джаве, субд на джаве (ужос то какой!!!)....

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

Откуда: Atlanta, GA
Сообщений: 1187
DPH
Просто моя текущая система (одна из), так сложилось, в качестве БД использует Oracle - и я постоянно слышу от DBA (с ссылками на документацию и Кейта), что бизнес-логику эффективнее реализовать внутри БД. Правда, пояснить, почему так лучше, DBA так и не смог.

Потестируем? Только в новой ветке, а то здесь уже тесно стало.

Предлагаю создать пару таблиц по миллиону записей и сделать с ними что-нибудь (на ваш вкус) из Явы. Я, в свою очередь, напишу аналог на PL/SQL. У вас же Оракл есть - запустите пару раз и результаты тайминга сюда в форум потом на обсуждение.
5 июн 08, 17:21    [5766461]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

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

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

Yo.!
3. очень медленно разработка, то что делается в pl/sql одной конструкцией в жава десятки строк, плюс очень многословный язык, разработчик вынужден строчить мегобайты кода.
в общем все равно. вопрос что стоит дороже одна строка на PL/SQL + разработчик + лицензии + etc ИЛИ 10 строк на Java + разработчик + etc (лицензионных плат здесь нет, и цена разработчика может быть меньше).

Yo.!
4. медленно - если это внешний апп сервер, то лишние расходы на память и транспортировку данных, если это в ядре субд (только оракл такое имеет) - много подводных камней и слабая обкатоность решений.
Во первых не только Oracle. Во вторых можно проводить обработку на апп сервере ВООБЩЕ без СУБД! это вопрос архитектуры.

Да, обработка на апп сервере может требовать больше памяти, НО при нынешней цене разработки ПО стоимость памяти и дополнительных серверов (даже 10-ка) для Java это копейки. А параллелиться система на Java будет намного дешевле - докупил комп, вот еще одна рабочая нода.
5 июн 08, 17:29    [5766517]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
VoDA
Минусы Oracle:
....
4. Труднее научить людей мыслить в реляционном подходе.

Минусы Java:
1. больше программистов Java используют процедурный, а не реляционный подход к обработке данных (бегают циклами), что может приводить к сильному падению производительности.
Я считаю ваш пример очень показательным. Он отражает суть проблемы, обсуждаемой в данный момент в этой ветке.
Работая с реляционными данными, программисты на Яве не знают и, следовательно, не могут эффективно использовать SQL для обработки данных. Отсюда и попытки реализовать встроенную в БД логику на стороне клиента. Отсюда и упомянутое tygra отношение к БД как к набору DBF файлов.
5 июн 08, 17:35    [5766560]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Yo.!
вы имеете ввиду субд на жава ? их возможности сегодня сильно не дотягивают до оракла 80х, особенно в области тяжелых обработки
Конечно они не дотягивают. Тут главное, что легко можно натыкать еще нод и параллельно обрабатывать данные на множестве систем. Тогда получается или один мега-Oracle или много маломощьных Java машинок. Но Java-app будут масштабироваться линейно в отличии от одной Oracle.
5 июн 08, 17:36    [5766577]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
VoDA
Yo.!
вы имеете ввиду субд на жава ? их возможности сегодня сильно не дотягивают до оракла 80х, особенно в области тяжелых обработки
Конечно они не дотягивают. Тут главное, что легко можно натыкать еще нод и параллельно обрабатывать данные на множестве систем. Тогда получается или один мега-Oracle или много маломощьных Java машинок. Но Java-app будут масштабироваться линейно в отличии от одной Oracle.
А как они будут синхронизировать свои БД? Или это не важно!?
5 июн 08, 17:41    [5766622]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Anton Demidov
DPH
Просто моя текущая система (одна из), так сложилось, в качестве БД использует Oracle - и я постоянно слышу от DBA (с ссылками на документацию и Кейта), что бизнес-логику эффективнее реализовать внутри БД. Правда, пояснить, почему так лучше, DBA так и не смог.

Потестируем? Только в новой ветке, а то здесь уже тесно стало.

Предлагаю создать пару таблиц по миллиону записей и сделать с ними что-нибудь (на ваш вкус) из Явы. Я, в свою очередь, напишу аналог на PL/SQL. У вас же Оракл есть - запустите пару раз и результаты тайминга сюда в форум потом на обсуждение.


Прикоединяюсь + создал новую ветку
5 июн 08, 17:41    [5766624]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Anton Demidov
VoDA
Yo.!
вы имеете ввиду субд на жава ? их возможности сегодня сильно не дотягивают до оракла 80х, особенно в области тяжелых обработки
Конечно они не дотягивают. Тут главное, что легко можно натыкать еще нод и параллельно обрабатывать данные на множестве систем. Тогда получается или один мега-Oracle или много маломощьных Java машинок. Но Java-app будут масштабироваться линейно в отличии от одной Oracle.
А как они будут синхронизировать свои БД? Или это не важно!?

приведу цитату:
Anton Demidov
VoDA
Если связанности нет или она "слабая", то можно крутить все на раздельных серверах.
Именно так. Я этот вариант держу "про запас" на случай катастрофической нехватки ресурсов. Впрочем, учитывая стоимость лицензии на Oracle Enterprize Edition, может быть дешевле купить более быстрый сервер. Для меня лицензия уже была в наличии - мигрировали со старого Sun Fire V880.

Из нее я сделал вывод что зависимости нет или она "слабая". То есть либо синхронизации в принципе нет, либо она есть но не играет существенной роли в решении задачи

Пример: после обработки 1Gb данных нужно записать 1kb в общую БД. в данном случае существенная часть нагрузки именно обработка, но не сохранение результатов.

PS могу не угадать, ибо проект не мой ;)
5 июн 08, 17:47    [5766671]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
VoDA

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

у вас жава-девелоперы карежут структуру данных продакшен систем !? а DBA вообще нет!??? т.е. ораклом и db2 рулят девелоперы !?!

VoDA

в общем все равно. вопрос что стоит дороже одна строка на PL/SQL + разработчик + лицензии + etc ИЛИ 10 строк на Java + разработчик + etc (лицензионных плат здесь нет, и цена разработчика может быть меньше).

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

VoDA

Во первых не только Oracle. Во вторых можно проводить обработку на апп сервере ВООБЩЕ без СУБД! это вопрос архитектуры.

утопия, вы представляете какие ресурсы ораклом было вложено в разработку ядра субд только в оптимизатор (алгоритмы расчета коста, методы доступа, алгоритмы джоинов, мультиблочное чтение). это примерно то же, что в принципе высадить людей на марс можно и на МИГе, он тоже высоко поднимается.
5 июн 08, 17:49    [5766688]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
VoDA
Anton Demidov
VoDA
Если связанности нет или она "слабая", то можно крутить все на раздельных серверах.
Именно так. Я этот вариант держу "про запас" на случай катастрофической нехватки ресурсов.

Из нее я сделал вывод что зависимости нет или она "слабая". То есть либо синхронизации в принципе нет, либо она есть но не играет существенной роли в решении задачи

Пример: после обработки 1Gb данных нужно записать 1kb в общую БД. в данном случае существенная часть нагрузки именно обработка, но не сохранение результатов.

PS могу не угадать, ибо проект не мой ;)
Не угадал - я имел в виду кластер (Oracle RAC). У меня пишется несколько тысяч строк как результат обработки файла.
5 июн 08, 18:03    [5766793]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 [9] 10 11 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить