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

Откуда:
Сообщений: 585
Yo.!
на тхредах работает лишь 9.5 UDB, который только только появился, т.е. в продакшене вообще их единицы. по 9.5 я не готов разговаривать, может там в связи с тхредами все изменилось, но до 9.5 запускались отдельные процессы на каждый конект, вы с этим не согласны ?
Под Linux, кажется, до 9.5 так и было - точно не помню. Под Windows и AIX - уже давно трединг-модель.
5 июн 08, 19:39    [5767140]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn
Под Linux, кажется, до 9.5 так и было - точно не помню. Под Windows и AIX - уже давно трединг-модель.


не было, до 9.5 все было в точности как у оракла, треды только под виндой и вот только в 9.5
Prior to Version 9.5, IBM® provided a multithreaded architecture on Windows® operating systems only. Version 9.5 provides the benefits of a multithreaded architecture on other operating systems.
5 июн 08, 19:57    [5767184]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SOAWAR
Member

Откуда:
Сообщений: 100
[quot tygra]Но могу и пояснить: вне зависимости от нагрузки, логика должна находиться на сервере СУБД и работать с данными должна СУБД.[quot tygra]

Мы предпочитаем следующую архитектуру
(СУБД) - (Сервер приложений и веб-сервер (Объектная модель предметной области, Бизнес-логика, Представления (ORM) (Кэш))- (webклиент)
При выборе хороших решений при реализации архитектуры имеем следующие плюсы:
1. Выбор любой реляционной СУБД как хранилища сменой провайдера ORM. Изменение в одной строчке – и используется другая СУБД.
2. Понятный с точки предметной области код благодаря работе с объектной моделью: вы работаете не на уровне SQL, а на уровне классов. По объектной модели создается автоматом структура БД, с которой ORM самостоятельно общается с СУБД на SQL. Код бизнес-логики в терминах объектной модели предметной области. Интеллисенс в среде разработки.
4. Иные прелести наличия и работы с объектной моделью, например возможности построения в приложении универсальных фильтров по сущностям с использованием рефлексии.
5. Масштабируемость: стало больше пользователей - добавь еще серверов приложений. Стали запросы потяжелее - укрепляй СУБД. Если надо можно вынести и распределить кэш.
6. Доступность - все через веб-клиент, поэтому никаких инсталляций клиентов. Зашел на сайт и работай себе. LiveCD и вперед!
Нас это все устраивает и с точки зрения "красоты" кода и с точки зрения производительности. Естественно все с умом, ибо с любой архитектурой можно наломать дров так, что все преимущества станут недостатками.
5 июн 08, 20:22    [5767232]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
2. оторвоность данных от логики приводит к невозможности полноценно сопровождать код. в оракле при изменении структуры данных, процедуры которых коснулись изменения пометятся инвалидными и будут защищены от запуска. внешняя жава же запустит поломанный код, не подозреваю об изменения в субд и вывалится с экспшеном лишь когда наткнется на ошибочный SQL. последствия не предсказуемы.
3. очень медленно разработка, то что делается в pl/sql одной конструкцией в жава десятки строк, плюс очень многословный язык, разработчик вынужден строчить мегобайты кода.
4. медленно - если это внешний апп сервер, то лишние расходы на память и транспортировку данных, если это в ядре субд (только оракл такое имеет) - много подводных камней и слабая обкатоность решений.

2. Это верно для любого dynamic SQL - запрос заранее не известен, в PL/SQL с произвольным запросом (из строки) будут те же косяки.
В стандарте Java есть SQLJ, т.е. embedded (static) SQL - текст запроса пишется в коде программы и прогоняется прекомпилером. При этом DB2 для него генерит pakage, сам запрос и его уже готовый план хранятся на сервере, в программе - только его вызов, синтаксис проверяется при разработке. Любые изменения схемы отслеживаются - программа с невалидным pakage просто свалится с ошибкой, по результатам runstat и reorg pakage можно перекомпилить вообще не трогая программу. То же верно и для C-шного embedded SQL, который я активно использую.
3. Программа пишется хорошо и бысто на любом хорошо знакомом языке, и медленно - на остальных :) Java отлично стандартизован и читабелен.
4. DB2 такое умеет тоже, причем давно, с 8-ки кажется. На мой взгляд, весьма достойная замена PL/SQL, если уж именно для бизнес-логики (!) чего-то в SQL-PL не хватает. Хотя я такое (именно для ограничений на данные-связи) слабо себе представляю.

Yo.!
а можно ссылочку на fenced java процедуры ?
Да там же типа "create procedure... language java... (not) fenced..."

Yo.!
не было, до 9.5 все было в точности как у оракла, треды только под виндой и вот только в 9.5
Тады извиняюсь, с AIX очень давно не работал. А у Оракла под *nix'ами тоже тредов нету?
Кстати, в догонку к давнему разговору об Express-C, "старой" 9.1 и фикспаков на нее - на днях очередной (5-й) вышел, вроде еще долгую параллельную поддержку обещают.
5 июн 08, 20:43    [5767296]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
SOAWAR
2. Понятный с точки предметной области код благодаря работе с объектной моделью: вы работаете не на уровне SQL, а на уровне классов. По объектной модели создается автоматом структура БД, с которой ORM самостоятельно общается с СУБД на SQL. Код бизнес-логики в терминах объектной модели предметной области. Интеллисенс в среде разработки.
4. Иные прелести наличия и работы с объектной моделью, например возможности построения в приложении универсальных фильтров по сущностям с использованием рефлексии.
5. Масштабируемость: стало больше пользователей - добавь еще серверов приложений. Стали запросы потяжелее - укрепляй СУБД. Если надо, можно вынести и распределить кэш.

2. Опять СУБД используется как dbf
3. Не разглашается, как коммерческая тайна
4. А вы изучите SQL и будете поражены возможностями "построения в приложении универсальных фильтров по сущностям"
5. Это всё в теории. Практически ни одна СУБД не вынесет издевательства плохим SQL, как её не "укрепляй". Предложение "вынести и распределить кэш" - это вообще что? Если про "вынести" я могу подумать про Oracle TimesTen, то распределение ... вы собрались сами писать реализацию ЭТОГО?

Про №3 была шутка - вы пропустили этот номер у себя
5 июн 08, 22:05    [5767497]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SOAWAR
Member

Откуда:
Сообщений: 100
Anton Demidov

2. Опять СУБД используется как dbf

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

Anton Demidov

3. Не разглашается, как коммерческая тайна

))) 3 вошло в 2. Про бизнес-логику. И я это считаю на самом деле очень важным, потому что именно она самая динамичная, а значит должна быть предельно понятной.

Anton Demidov

4. А вы изучите SQL и будете поражены возможностями "построения в приложении универсальных фильтров по сущностям"

Под универсальностью я подразумевал то, что фильтр сам узнает о том, что может быть предметом фильтрации. Скормите фильтру целевую сущность, а он сам уже во время выполнения увидит какие свойства должны доступны для фильтрации. Замечу, что свойства в свою очередь могут быть сущностями, у которых опять есть свойства, и т.д. Мы довели это до того, что кидаем контрол фильтра на форму, указываем целевую сущность и он работает без единой дополнительной строчки кода. Сам предоставляет пользователю определить критерии исходя из типа свойства. Кстати, там есть и приведение типов - приведение потомка к базовому классу. Без объектной модели, или схемы данных где это все описано это невозможно. Мы предпочитаем, чтобы это было именно в объектной модели, поскольку хотим использовать возможности среды разработки на полную.
Там где вы предлагаете городить скульные конструкции на 2 страницы на каждый случай жизни, мы помещаем свой универсальный фильтр с указанием целевой сущности.
Поэтому очень быстро создаем формы, они лаконичны, в них минимальный и чистый код. И главное - пользователь визуально и структурированно в пять кликов создает критерии фильтрации, скульный эквивалент которых вы будете писать утомительно долго и скорее всего с ошибками. За нас это делает ORM. А мы предпочитаем основное время строить логичную объектную модель предметной области. Она самое главное - все остальное - мишура.

Anton Demidov

5. Это всё в теории. Практически ни одна СУБД не вынесет издевательства плохим SQL, как её не "укрепляй".

С чего вы решили что ORM генерирует плохой sql? Хотя, конечно, кто знает что вы смотрели и сравнивали... То, чем мы пользуемся генерирует очень даже хороший sql. Думаю, что он гораздо лучше, чем написало бы большинство sql-специалистов на этих форумах. Мы, правда, немного оптимизировали внутренности для производительности под себя по-мелочам, но это не считается.

Anton Demidov

Предложение "вынести и распределить кэш" - это вообще что?

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

Anton Demidov

Если про "вынести" я могу подумать про Oracle TimesTen, то распределение ... вы собрались сами писать реализацию ЭТОГО?

прочитайте про кэш, тот который слабосвязный и распределенный

А вообще я полемику закончил, свое мнение высказал. Спасибо за комментарий, отвечать не надо.
6 июн 08, 00:29    [5767832]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Favn

2. Это верно для любого dynamic SQL - запрос заранее не известен, в PL/SQL с произвольным запросом (из строки) будут те же косяки.

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

Favn

При этом DB2 для него генерит pakage, сам запрос и его уже готовый план хранятся на сервере, в программе - только его вызов, синтаксис проверяется при разработке. Любые изменения схемы отслеживаются - программа с невалидным pakage просто свалится с ошибкой, по результатам runstat и reorg pakage можно перекомпилить вообще не трогая программу. То же верно и для C-шного embedded SQL, который я активно использую.

так это же откат в 80-е, эмбедет sql компилирует план запроса в процедуру намертво, т.е. план со временем не меняется. в 90х в оракле появился cost based оптимизатор, когда план строится исходя из статистики и меняется по мере распухания бд в зависимости от актуальной статистики.

c fenced, повторяю, агент это отдельный процесс с отдельным адресным пространством:

The DB2 architecture provides a firewall so that applications run in a different address space from DB2. The firewall protects the database and the database manager from applications, stored procedures, and user-defined functions (UDFs). A firewall maintains the integrity of the data in the databases, because it disables application programming errors from overwriting internal buffers or files of the database manager. The firewall also improves reliability, because application errors cannot crash the database manager.

https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0008930.html

поэтому дб2 и побарабану, что там вне его запускается jvm, C или кабол. в оракле же пользовательские процессы обращаются напрямую в один кусок памяти SGA через shared memory (в Linux).

Favn

Тады извиняюсь, с AIX очень давно не работал. А у Оракла под *nix'ами тоже тредов нету?

как написано на металинке, когда они портировали на NT поняли что процессы в винде не работоспосбны и пришлось переколбашивать под треды. но остальные платформы на процессах.

Favn

Кстати, в догонку к давнему разговору об Express-C, "старой" 9.1 и фикспаков на нее - на днях очередной (5-й) вышел, вроде еще долгую параллельную поддержку обещают.

можно линк ? вы уверены что это официально под express-c ?
6 июн 08, 01:24    [5767896]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Yo.!
Favn
При этом DB2 для него генерит pakage, сам запрос и его уже готовый план хранятся на сервере, в программе - только его вызов, синтаксис проверяется при разработке. Любые изменения схемы отслеживаются - программа с невалидным pakage просто свалится с ошибкой, по результатам runstat и reorg pakage можно перекомпилить вообще не трогая программу. То же верно и для C-шного embedded SQL, который я активно использую.
так это же откат в 80-е, эмбедет sql компилирует план запроса в процедуру намертво, т.е. план со временем не меняется.
Не совсем так. План из Package используется для валидации объектов (добавили индекс или новую колонку в таблицу - всё, invalid). Именно как план он используется как отправная точка для cost-based optimizer-a. У них и bind-peeking есть. Так меня учили на курсах SQL Tuning for DB2 iSeries (5R3 в то время). На DB2 LUW должно быть что-то подобное, хотя с IBM станется - у нас часто правая рука не в ответе за левую (это я ворчу на некоторую несовместимость трёх версий DB2)
6 июн 08, 01:33    [5767906]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Anton Demidov
у нас часто правая рука не в ответе за левую
у них часто правая рука не в ответе за левую.

Чур меня, чур.
6 июн 08, 01:40    [5767912]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Anton Demidov
[Не совсем так. План из Package используется для валидации объектов (добавили индекс или новую колонку в таблицу - всё, invalid). Именно как план он используется как отправная точка для cost-based optimizer-a. У них и bind-peeking есть.

я к тому что если при создании процедуры у меня было 2 записи и зафиксировался план, а через два дня у меня в табличка заполнилась до 2М записей, разве кто-то пересмотрит план ?
6 июн 08, 01:43    [5767914]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Yo.!
Anton Demidov
[Не совсем так. План из Package используется для валидации объектов (добавили индекс или новую колонку в таблицу - всё, invalid). Именно как план он используется как отправная точка для cost-based optimizer-a. У них и bind-peeking есть.

я к тому что если при создании процедуры у меня было 2 записи и зафиксировался план, а через два дня у меня в табличка заполнилась до 2М записей, разве кто-то пересмотрит план ?
Да, оптимизатор DB2/400 пересматривает план как при получении новых статистик, так и при изменении связанных переменных (он их постоянно смотрит). Про поведение DB2 LUW не знаю.
6 июн 08, 02:46    [5767953]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Anton Demidov
SOAWAR
2. Понятный с точки предметной области код благодаря работе с объектной моделью: вы работаете не на уровне SQL, а на уровне классов. По объектной модели создается автоматом структура БД, с которой ORM самостоятельно общается с СУБД на SQL. Код бизнес-логики в терминах объектной модели предметной области. Интеллисенс в среде разработки.
4. Иные прелести наличия и работы с объектной моделью, например возможности построения в приложении универсальных фильтров по сущностям с использованием рефлексии.
5. Масштабируемость: стало больше пользователей - добавь еще серверов приложений. Стали запросы потяжелее - укрепляй СУБД. Если надо, можно вынести и распределить кэш.

2. Опять СУБД используется как dbf
3. Не разглашается, как коммерческая тайна
4. А вы изучите SQL и будете поражены возможностями "построения в приложении универсальных фильтров по сущностям"
5. Это всё в теории. Практически ни одна СУБД не вынесет издевательства плохим SQL, как её не "укрепляй". Предложение "вынести и распределить кэш" - это вообще что? Если про "вынести" я могу подумать про Oracle TimesTen, то распределение ... вы собрались сами писать реализацию ЭТОГО?

Про №3 была шутка - вы пропустили этот номер у себя

Говорить с "объектниками" гиблое дело - объектный подход это единственное, что они знают, и рассказы про логику в СУБД и т.д. это для них все-равно, что рассказы про ядро термоядерных реакторов на Марсе :) Если человек никогде не пил пепси-колу, то рассказать ему ее вкус невозможно :)

-- Tygra's --
Мои фотогалереи тут и тут
6 июн 08, 10:51    [5768810]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Yo.!
Guest
Anton Demidov
Да, оптимизатор DB2/400 пересматривает план как при получении новых статистик, так и при изменении связанных переменных (он их постоянно смотрит). Про поведение DB2 LUW не знаю.

нифига, ембедет на то и ембедет.

Embedded SQL application performance is impacted by these factors because the package is created once when a database might have a certain set of characteristics. These characteristics are factored into the creation of the package run time access plans which define how the database manager will most efficiently execute SQL statements. Over time a database schema and data might change rendering the run time access plans sub-optimal. This can lead to degradation in application performance.

For this reason it is important to periodically refresh the information that is used to ensure that the package run-time access plans are well-maintained.

http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.apdv.embed.doc/doc/c0021166.htm

и в AS/400 те же яйца, имхо потому им и пришлось SQL-PL воротить, что на фоне Oracle/MSSQL такое уже совсем выглядит как технологии 80х.
6 июн 08, 12:03    [5769462]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
tygra
Но могу и пояснить: вне зависимости от нагрузки, логика должна находиться на сервере СУБД и работать с данными должна СУБД. Показывать же эти данные на вебе должен веб-сервер, неважно, отдельно будет апп-сервер, вместе с веб-сервером или как еще. Но данные апп-веб-сервер менять не должен, только передавать туда и сюда и хранить кэши, в обработку и изменение данных он не должен лезть, не его собачье дело, это дело сугубо СУБД.
странно... а у вас СУБД проводит AAA? у нас авторизаций вынесена на АппСервер и делается независимо от СУБД. Пользователей, их роли доступы и т.п. По расчетам архитекторов одно это должно упростить работу системы на 1 000 000 пользователей.

дальше огромные кэши на Апп серверах тоже способствуют разгрузке СУБД от дополнительных запросов. Зачем делать запрос если он же запрашивался минуту назад и есть актуальный результат?

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

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

tygra
В общем, я не вижу проблем с тем, чтобы отдать только СУБД обработку данных, а веб-апп-серверу - только отображение этих самых данных. Надо отойти от стереотипов джавы - вся обработка только на джаве, субд на джаве (ужос то какой!!!)....
6 июн 08, 12:19    [5769588]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
mq
Guest
Yo.!
нифига, ембедет на то и ембедет.

Embedded SQL application performance is impacted by these factors because the package is created once when a database might have a certain set of characteristics. These characteristics are factored into the creation of the package run time access plans which define how the database manager will most efficiently execute SQL statements. Over time a database schema and data might change rendering the run time access plans sub-optimal. This can lead to degradation in application performance.

For this reason it is important to periodically refresh the information that is used to ensure that the package run-time access plans are well-maintained.

http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.apdv.embed.doc/doc/c0021166.htm

Жмите дальше на линк...

Performance of embedded SQL applications

The RUNSTATS command is used to collect current statistics on tables and indexes, especially if significant update activity has occurred or new indexes have been created since the last time the RUNSTATS command was executed. This provides the optimizer with the most accurate information with which to determine the best access plan.

Performance of Embedded SQL applications can be improved in several ways:

Run the RUNSTATS command to update database statistics.
Rebind application packages to the database to regenerate the run time access plans (based on the updated statistics) that the database will use to physically retrieve the data on disk.
Using the REOPT bind option in your static and dynamic programs.
6 июн 08, 12:29    [5769688]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
VoDA
Member

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



Повторю еще раз: есть входящий поток данных в виде архивированных файлов
Да, файлы приходят обработанные zip/gzip/rar/jar/pgp/tar во всевозможных комбинациях. И приходят они как в электронном виде, так и на физических носителях.
Внутри архива файлы содержащие данные в различных форматах
Проблемы в том, что на 200 клиентов приходится 100 различных форматов данных. Файлы могут быть в ASCII или EBCDIC, с символом(-ами) перевода строки и без. Есть уникумы, что шлют EBCDIC файлы с "0x0Ah" кодом.
По самим данным и нужно собирать статистику.

  • Вариант решения: сервер Oracle раскидывает данные на другие компы, где они деарзивируются. Затем парсит их и заливает в свою БД. После чего по этой БД гоняются SQL запросы + PL/SQL алгоритмы. После обработки 1000 строк сохраняются в общую БД / посылаются заказчику.

  • Мое решение: сервера Java разбирают каждый по файлу на себя. Локально его деархивируют, парсят и загоняют в ЛОКАЛЬНУЮ СУБД. По этой БД гоняются SQL запросы + Java алгоритмы. После обработки 1000 строк сохраняются в общую БД / посылаются заказчику.


    Затык и/о конечно будет, но на каждой ноде независимо. Поэтому с ростом количества нод общее и/о системы будет расти линейно!!! И пропускная способность системы будет масштабироваться практически линейно.
    Также цена лицензий на систему под Oracle будет заметно больше нулевой цены лицензий на Java.
  • 6 июн 08, 12:32    [5769709]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

    Откуда: сеРверная пальмира :)
    Сообщений: 4898
    SOAWAR
    5. Масштабируемость: стало больше пользователей - добавь еще серверов приложений. Стали запросы потяжелее - укрепляй СУБД. Если надо можно вынести и распределить кэш.

    Anton Demidov
    5. Это всё в теории. Практически ни одна СУБД не вынесет издевательства плохим SQL, как её не "укрепляй". Предложение "вынести и распределить кэш" - это вообще что? Если про "вынести" я могу подумать про Oracle TimesTen, то распределение ... вы собрались сами писать реализацию ЭТОГО?
    Тут Антон прав. Если стали тяжелыми запросы - нужно менять сами запросы или логику системы.
    На правильных запросах укрепления СУБД практически не нужно, а на кривых - укрепление СУБД уже не помогает. Провал производительности просто ПЦ какой.

    Потому вывод: тяжелые запросы нужно тюнить и переводить в простые (даже сменой логики системы). Но лучше иметь спеца по СУБД который сразу в процессе написания приложения будет чинить кривость архитектуры (которая и вызывает кривые запросы)
    6 июн 08, 12:37    [5769754]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Yo.!
    Guest
    mq

    Жмите дальше на линк...


    ну было бы совсем грустно если бы обновить планы нельзя было бы даже руками. к середине 90х прошлого столетия большинство субд уже умело самостоятельно отслеживать статистику и заботится об актуальности планов ...
    6 июн 08, 12:42    [5769802]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    VoDA
    странно... а у вас СУБД проводит AAA? у нас авторизаций вынесена на АппСервер и делается независимо от СУБД. Пользователей, их роли доступы и т.п. По расчетам архитекторов одно это должно упростить работу системы на 1 000 000 пользователей.

    Права правам рознь. О каким миллионах каких пользователей и какой системы идет речь?
    Да и потом, где и как бы не проверялись права, в любом случае визуально в интерфейсе это делает не СУБД :))

    автор
    дальше огромные кэши на Апп серверах тоже способствуют разгрузке СУБД от дополнительных запросов. Зачем делать запрос если он же запрашивался минуту назад и есть актуальный результат?

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

    автор
    Ок, отлично СУБД занимается только обработкой данных.
    Про счассте если СУБД в роли большого dbf - это тоже фантазии, причем ваши ;) СУБД найдется чем заняться кроме шелухи которая может быть вынесена на приложение.

    Чем же таким? Да и не важно - яговорил о том, что обработкой данных занимается только СУБД. А чем там еще - это неважно.

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

    Чем сложнее? И что сложнее? Я как раз и говорил, что легко натыкать апп-серверов (только они не должны заниматься обработкой данных - это оставим СУБД :))

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

    Повторю еще раз: есть входящий поток данных в виде архивированных файлов
    Да, файлы приходят обработанные zip/gzip/rar/jar/pgp/tar во всевозможных комбинациях. И приходят они как в электронном виде, так и на физических носителях.
    Внутри архива файлы содержащие данные в различных форматах
    Проблемы в том, что на 200 клиентов приходится 100 различных форматов данных. Файлы могут быть в ASCII или EBCDIC, с символом(-ами) перевода строки и без. Есть уникумы, что шлют EBCDIC файлы с "0x0Ah" кодом.
    По самим данным и нужно собирать статистику.

  • Вариант решения: сервер Oracle раскидывает данные на другие компы, где они деарзивируются. Затем парсит их и заливает в свою БД. После чего по этой БД гоняются SQL запросы + PL/SQL алгоритмы. После обработки 1000 строк сохраняются в общую БД / посылаются заказчику.

  • Мое решение: сервера Java разбирают каждый по файлу на себя. Локально его деархивируют, парсят и загоняют в ЛОКАЛЬНУЮ СУБД. По этой БД гоняются SQL запросы + Java алгоритмы. После обработки 1000 строк сохраняются в общую БД / посылаются заказчику.


    Затык и/о конечно будет, но на каждой ноде независимо. Поэтому с ростом количества нод общее и/о системы будет расти линейно!!! И пропускная способность системы будет масштабироваться практически линейно.
    Также цена лицензий на систему под Oracle будет заметно больше нулевой цены лицензий на Java.


  • как только файлики станут больше чем RAM сервера ваш дерби начнет часами бестолково юлозить HDD. прсото потому, что он отстает от оракла на 20 лет. одна сессия дерби попросту не способна эфективно использовать все 4 ядра самого простого из процессоров, не умеет мультиблочного чтения с HDD и прочих элементарных вещей. в результате один сервер с ораклом за счет 20 летней форы и эффективного использования ресурсов сервера обработает несколько файлов просто быстрей, а вам добавление же добавления кол-ва компов не поможет быстрей юлозить HDD.
    6 июн 08, 12:56    [5769930]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    mq
    Guest
    Yo.!
    mq

    Жмите дальше на линк...


    ну было бы совсем грустно если бы обновить планы нельзя было бы даже руками. к середине 90х прошлого столетия большинство субд уже умело самостоятельно отслеживать статистику и заботится об актуальности планов ...

    я к тому что, как улучшить Performance of embedded SQL applications...
    ну и кто мешает "самостоятельно отслеживать статистику" и "заботится об актуальности планов" в данном случаи, если в этом есть необходимость?...
    6 июн 08, 12:57    [5769932]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Yo.!
    Guest
    к стате про оракловые лицензии, тут достаточно взять 5 пользовательских лицензий Oracle SE1 которые потянут аж на $750.
    6 июн 08, 13:02    [5769974]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Yo.!
    Guest
    mq

    ну и кто мешает "самостоятельно отслеживать статистику" и "заботится об актуальности планов" в данном случаи, если в этом есть необходимость?...

    у дба есть более полезные задачи чем руками следить за селективностью тысяч таблиц на десятках серверах.
    6 июн 08, 13:12    [5770057]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    mq
    Guest
    Yo.!
    mq

    ну и кто мешает "самостоятельно отслеживать статистику" и "заботится об актуальности планов" в данном случаи, если в этом есть необходимость?...

    у дба есть более полезные задачи чем руками следить за селективностью тысяч таблиц на десятках серверах.

    ну слушайте,все-таки уже далеко не 90-е :)
    6 июн 08, 13:19    [5770114]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Favn
    Member

    Откуда:
    Сообщений: 585
    Yo.!
    динамический sql появляется в очень редких случаях, когда статическим совсем громоздко выходит.
    так это же откат в 80-е, эмбедет sql компилирует план запроса в процедуру намертво, т.е. план со временем не меняется. в 90х в оракле появился cost based оптимизатор, когда план строится исходя из статистики и меняется по мере распухания бд в зависимости от актуальной статистики.
    Статический sql отличается от динамического именно тем, что запросы (или их часть) известны на стадии компиляции программы. Это как раз позволяет исключить ситуацию, когда
    Yo.!
    оторванность данных от логики приводит к невозможности полноценно сопровождать код
    Т.е. если static используется в PL/SQL - это великое благо, а если в Java/C - откат в 80-е? Что, SQL/PL процедура перекомпилячивается при каждом вызове, или все-таки только по мере необходимости (изменения статистики)? "У нас - доблестные разедчики, а у них - гнусные шпионы"!
    На самом деле, при компиляции Static SQL:
    1. Проверяется на валидность не только синтаксис запросов, но и их соответствие текущей схеме БД.
    2. Запросы удаляются из программы и переносятся на сервер (заносятся в package) вместе с версией этой компиляции, в программе остается только сис. вызов вида "запрос №5, данные вот эти".
    3. По пакаджу строится план запроса на базе текущей схемы и статистики, кот. может быть впоследствии пересмотрен, в т.ч. автоматически.
    Это позволяет:
    1. Выявлять ошибки до запуска программы.
    2. Отслеживать все взаимосвязи программы со схемой и выявлять несоответствие имеющимся программам еще при ее измении. Так же можно отслеживать версионность и запрещать лезть в БД старой версии программы.
    3. Изменять план доступа к компилированному запросу не в произвольное время, а в необходимое, напр. при сборе статистики в периоды сниженной нагрузки.
    4. Не имеет отношения к серв. приложениям, и все же БД может быть макимально защищена от клиента, которому можно дать только права на запуск данной программы. Причем самих запросов в ее теле не будет, т.е. даже при взломе в дебугере там делать нечего - красть пароль бессмысленно, изменять запросы на другие не получится.

    Yo.!
    c fenced, повторяю, агент это отдельный процесс с отдельным адресным пространством
    поэтому дб2 и побарабану, что там вне его запускается jvm, C или кабол. в оракле же пользовательские процессы обращаются напрямую в один кусок памяти SGA через shared memory (в Linux).
    И я повторяю то же самое (fence - огораживать, ограждать, загораживать) :) Не огороженные - not fenced. Для C они работают, уговорили, в одном из процессов ядра, для Java - на той же JVM, кот. использует сервер. И в Оракле, думаю, они обращаются к буферам памяти, как и в DB2, а никак не к i/o процессам, например.

    Yo.!
    как написано на металинке, когда они портировали на NT поняли что процессы в винде не работоспосбны и пришлось переколбашивать под треды. но остальные платформы на процессах.
    О как - пришлось-таки бедненьким. А я-то всегда считал, что тред-архитектура прогрессивнее многопроцессной - как минимум за счет отсутствия переключений контекста :)

    Yo.!
    можно линк ? вы уверены что это официально под express-c ?
    Я уверен, что официально для Express-C фикспаков нет вообще - она unsupported. Но от Express она отличается только файлом лицензии, и фиксы от Express на нее прекрасно встают. И это не хак - Express-C продолжает работать под собственной лицензией (что подтверждает IBM License Manager), Express-ом она от этого не становится, и я не видел в тексте лицензий прямого запрета эти фикпаки накатывать.

    Yo.!

    если при создании процедуры у меня было 2 записи и зафиксировался план, а через два дня у меня в табличка заполнилась до 2М записей, разве кто-то пересмотрит план
    нифига, ембедет на то и ембедет.
    it is important to periodically refresh the information that is used to ensure that the package run-time access plans are well-maintained.
    ну было бы совсем грустно если бы обновить планы нельзя было бы даже руками. к середине 90х прошлого столетия большинство субд уже умело самостоятельно отслеживать статистику и заботится об актуальности планов ...
    У DB2 другая идеология - Оракл , как я понимаю - это интерпретатор, а DB2 - компилятор. Это касается даже динамичеких запросов, для которых опционально тоже (с 8-й версии) можно строить пакаджи, и это ускоряет работу - мощный оптимизатор DB2 на страших уровнях оптимизации может полностью переформулировать запрос, что занимет заметное время. Стали бы в IBM ср. недавно вводить такую функциональность, если она не результативна? Пакаджи позволяют работать оптимизатору (в т.ч. автоматически при включенной автонастройке) в нужные админу периоды, а не когда заблагорассудится или когда запрос уже поступит на выполнение (потенциально - в период высокой нагрузки). А так, при известном времени частичного простоя сервера, можно спокойно собирать статистику, реорганизовывать таблицы и обновлять планы доступа именно в "свободное" время, или после массированного изменения схемы/данных. При этом обычный динамический SQL может работать по умолчанию на более низких уровнях оптимизации, не таких затратных по времени в on-line.
    6 июн 08, 14:04    [5770555]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 [10] 11 12   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить