Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Высоконагруженные проекты и запросы  [new]
st_st
Member

Откуда: Tasm 5.0
Сообщений: 2392
Сильно ли тормозят хранимые процедуры, по сравнению с обычными запросами из web-приложения? Почему ebay отказался от процедур и сложных запросов в пользу простых запросов внутри скриптов и обработки данных на веб-серверах? Получается базы жутко тормозят и гораздо быстрее перекинуть данные на web-сервер и обработать, чем предоставить это субд?
5 янв 10, 18:08    [8150124]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
st_st
Member

Откуда: Tasm 5.0
Сообщений: 2392
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
за 2006 год, oracle.

No business logic in database
- No stored procedures
- Only very simple triggers (default value population)
Move CPU-intensive work of applications
- Referential integrity
- Joins
- Sorting
Extensive use of prepared statements and bind variables
5 янв 10, 18:19    [8150162]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54761

st_st

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Им не хватило процессорной мощи их сервера, а распараллелить работу на
кластер они не смогли или не захотели. В результате отказались от
серверного кода. JErik на их месте пошёл дальше и избавился от сервера
как такового.

Posted via ActualForum NNTP Server 1.4

5 янв 10, 18:23    [8150174]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Yo.!
Guest
видимо посчитали, что оптимизатор субд слишком наворочен и слишком сложен, у них ограниченное кол-во запросов и наверно им показалось эффективней отказаться от универсального оптимизатора и зашить руками свои запросы.

2Dimitry Sibiryakov
на сколько я помню у них как раз крупнейший оракловый RAC на 16 и 8 нод, правда подозреваю только для аналитики
5 янв 10, 18:46    [8150233]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
автор
Получается базы жутко тормозят и гораздо быстрее перекинуть данные на web-сервер и

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

в таких случаях производительность каждой части нужно четко регулировать, в том числе перекидывая часть функционала и на клиентский браузер.
5 янв 10, 19:42    [8150364]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
st_st
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
за 2006 год, oracle.

No business logic in database
- No stored procedures
- Only very simple triggers (default value population)
Move CPU-intensive work of applications
- Referential integrity
- Joins
- Sorting
Extensive use of prepared statements and bind variables


А теперь, вопрос: Что здесь делает Oracle (или любая другая клиент\серверная СУБД)?
5 янв 10, 23:29    [8150958]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kdv
при данной архитектуре системы, трехзвенной по факту, и особенно конкретной нагрузке, было бы глупо всю обработку логики кидать на сервер


Всю, это простите, какую!? Действительно, есть некая часть нагрузки, которую можно параллелить средним звеном. Но, извините, именно транзакионную часть, Вы как хотите, но никак не распараллелите на среднем уровне.

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


Да хоть 958 звеньев по середине. В любом случае СУБД (RAC или аналогичные решения) должна поддержать все это хозяйство.

ЗЫ. Давненько не всплывали темы про N-звенки...
5 янв 10, 23:38    [8150979]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
pkarklin
А теперь, вопрос: Что здесь делает Oracle (или любая другая клиент\серверная СУБД)?

Рискну предположить, что выступает в роли тупого транзакционного отказоустойчивого хранилища, способного перемалывать груду примитивных запросов.
Угадал?
5 янв 10, 23:39    [8150981]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Рискну предположить, что выступает в роли тупого транзакционного отказоустойчивого хранилища, способного перемалывать груду примитивных запросов.
Угадал?


Рискну спросить: что для "тупого отказоустойчигого хранилища" проще перемолоть:

EXEC MakeClientOrder ... --куча параметров

или

SELECT...

INSERT...

UPDATE...

SELECT...

UPDATE...

INSERT ...

...

UPDATE...

INSERT...
5 янв 10, 23:51    [8150992]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
pkarklin
Но, извините, именно транзакционную часть, Вы как хотите, но никак не распараллелите на среднем уровне.

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

Кроме того, не вижу особой связи между транзакционностью и бизнес-логикой. Какая разница, запустить пакет PL/SQL, или выполнить обработку в транзакции в среднем звене? Или что, на Оракле нельзя писать без PL/SQL ? Или PL/SQL намертво привязан к транзакциям?

Собственно, "распараллеливание транзакционной части" на среднем звене не требуется и разумеется из СУБД вынесено быть не может. Но речь как раз о том, чтобы кроме как транзакциями и изменением данных Оракл не грузить, и чтобы вычислениями занималось среднее звено, а не Оракл.
6 янв 10, 00:01    [8151012]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
pkarklin
Рискну спросить: что для "тупого отказоустойчигого хранилища" проще перемолоть:

EXEC MakeClientOrder ... --куча параметров

или

SELECT...
INSERT...
UPDATE...

Считая, что внутре хранимки находится та же самая последовательность селектов/инсертов/упдейтов - рискну предположить, что тупому отказоустойчивому хранилищу примерно одинаково. На то оно и тупое.
6 янв 10, 00:12    [8151036]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kdv
такое впечатление что Вы не писали трехзвенных систем, или никогда в жизни не видели электронных магазинов.


Спасибо. Я ждал примерно такого пассажа.

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


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

kdv
Кроме того, не вижу особой связи между транзакционностью и бизнес-логикой. Какая разница, запустить пакет PL/SQL, или выполнить обработку в транзакции в среднем звене? Или что, на Оракле нельзя писать без PL/SQL ? Или PL/SQL намертво привязан к транзакциям?


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

kdv
Собственно, "распараллеливание транзакционной части" на среднем звене не требуется и разумеется из СУБД вынесено быть не может. Но речь как раз о том, чтобы кроме как транзакциями и изменением данных Оракл не грузить, и чтобы вычислениями занималось среднее звено, а не Оракл.


А тут, собственно, никто и не спорит. Часть "вычислений", действительно, можно вынести на средний уровень и распараллелить (чем, собственно, и пользуемся). Но есть часть транзакционной нагрузки, которую, к сожалению, ну никак на среднем звене не распараллелить.
6 янв 10, 00:23    [8151059]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Считая, что внутре хранимки находится та же самая последовательность селектов/инсертов/упдейтов - рискну предположить, что тупому отказоустойчивому хранилищу примерно одинаково. На то оно и тупое.


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

Ваша последовательность действий накатывания обновлений на "систему"? Естественно, это кластер, как минимум NLB на среднем уровне...
6 янв 10, 00:32    [8151071]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 pkarklin
ЛП
Считая, что внутре хранимки находится та же самая последовательность селектов/инсертов/упдейтов - рискну предположить, что тупому отказоустойчивому хранилищу примерно одинаково. На то оно и тупое.


Это если посмотреть со стороны "тупого хранилища"

Т.е. протоколируем консенсус по поводу того, что со стороны тупого хранилища примерно параллельно?
Оч хорошо.

(потерями на передачу, парсинг и компиляцию отдельных инструкций пренебрегаем

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

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

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

Ваша последовательность действий

Да ну бросьте. Я не умею лечить по фотографии, тем более при отсутствии оной.
Если отвечать в стиле заданного вопроса, то последовательность действий очень простая - взять да обновить.
6 янв 10, 01:44    [8151149]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
an0nym
Member

Откуда:
Сообщений: 7076
kdv
такое впечатление что Вы не писали трехзвенных систем, или никогда в жизни не видели электронных магазинов. Я осмелюсь напомнить, что в массовых эл. магазинах, пусть и не таких "нагрузоустойчивых", чаще всего используется MySQL с движком вообще без транзакций.

Скажите, что вы шутите...
6 янв 10, 09:57    [8151348]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
an0nym
Скажите, что вы шутите...

- Да-да и ПлоХоПлюшка там рулят всех.
6 янв 10, 10:38    [8151424]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
st_st
Member

Откуда: Tasm 5.0
Сообщений: 2392
Вобщем понятно в общих чертах, для разгрузки oracle, решили перенести обработку на сторону web-приложений. Получается в их случае перебрасывать множество данных простыми запросами на сервер приложений для последующей их обработки выходит быстрее, чем делать это например хранимыми процедурами с выводом конкретного результата. Можно было наверное увеличить количество серверов баз данных и снизить нагрузку, но пошли другим путём.

Кстати, а хранимые процедуры используют в вебе на крупных проектах? В России почти всё пишется на php + my sql и запросы составляются внутри php-страниц, о существовании процедур многие даже не подозревают.

Насчёт интернет-магазинов, крупнейший в мире amazon.com тоже на oracle, но пока не находил информации как у них там с запросами всё устроено.

А так конечно, в основном везде php + mysql, форумы, cms, интернет-магазины (oscommerce к примеру), пишут запросы внутри php-страниц и не задумываются ни о каких процедурах.

Имеет ли смысл выделяться из общего потока и работать только с процедурами? Понятно, что уровень безопасности возрастает (для взломщика невидна схема данных и нельзя изменить сам запрос), а скорость работы сайта?

Ещё один интересный сайт - myspace.com, помню когда-то был мировым лидером толи по количеству посещений, толи по отдаваемому трафику. Там asp.net + ms sql server, велика вероятность использования процедур, но пока тоже не встречалось не подтверждение ни опровержение этого предположения.
6 янв 10, 13:34    [8151897]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
st_st
В России почти всё пишется на php + my sql и запросы составляются внутри php-страниц, о существовании процедур многие даже не подозревают.

Потому их, сайтеги, и щелкают как орехи...
А в суриозных - только за слово ПыхПых - отстреливают... на месте.
6 янв 10, 13:42    [8151921]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
автор
Получается в их случае перебрасывать множество данных простыми запросами на сервер приложений для последующей их обработки выходит быстрее, чем делать это например хранимыми процедурами с выводом конкретного результата.


Для абстрактных данных и абстрактной их обработки ничего не "получится". Решение надо находить в каждом конкретном случае.

автор
Вобщем понятно в общих чертах, для разгрузки oracle, решили перенести обработку на сторону web-приложений.


Еще раз повторюсь. Часть нагрузки (в основном RO нагрузка) можно вынести на средний уровень и баллансировать там. Но в любом случаем саму процессинговую часть, "меняющую данные" в хранилище, никуда не унести.

автор
Кстати, а хранимые процедуры используют в вебе на крупных проектах?


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

автор
А так конечно, в основном везде php + mysql, форумы, cms, интернет-магазины (oscommerce к примеру), пишут запросы внутри php-страниц и не задумываются ни о каких процедурах.


Какая то у Вас не полная математическая индукция. Даже этот форум не на пхп и не на майскуле.

автор
Имеет ли смысл выделяться из общего потока и работать только с процедурами?


Хотите посоревноваться с лидерами этой отрасли рунета - "выделяйтесь и работайте".

автор
Там asp.net + ms sql server


Как уже было сказано выше - не только там.
6 янв 10, 13:53    [8151960]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
GrayStrannik
Member

Откуда: Москва
Сообщений: 82
an0nym
kdv
такое впечатление что Вы не писали трехзвенных систем, или никогда в жизни не видели электронных магазинов. Я осмелюсь напомнить, что в массовых эл. магазинах, пусть и не таких "нагрузоустойчивых", чаще всего используется MySQL с движком вообще без транзакций.

Скажите, что вы шутите...
В массовых эл. магазинах на самом деле используется MySQL с движком вообще без транзакций. И с этим нет проблем, потому что транзакция там умещается в один неконкурентный запрос. Даже один из крупнейших интернет-магазинов Болеро на своём сайте официально пишет, что 2-3% заказов заканчиваются отказом в товаре - у них нет своего склада, нет информации по наличию на чужих складах товара и им в транзакции нечего резервировать. Такова жизнь: проблема с отсутствием транзакций поглощается куда большей проблемой с физическим учётом наличия товара на складе.
6 янв 10, 14:11    [8152015]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
an0nym
Member

Откуда:
Сообщений: 7076
GrayStrannik,

движок MYSQL без транзакций подразумевает под собой еще и отсутствие FK...
6 янв 10, 14:14    [8152024]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
GrayStrannik
Member

Откуда: Москва
Сообщений: 82
pkarklin
Какая то у Вас не полная математическая индукция. Даже этот форум не на пхп и не на майскуле.
И много Вы знаете российских форумов, под которыми не MySQL?
6 янв 10, 14:15    [8152030]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
GrayStrannik
В массовых эл. магазинах на самом деле используется MySQL с движком вообще без транзакций. И с этим нет проблем, потому что транзакция там умещается в один неконкурентный запрос.


Давайте определимся с терминологией. Под термином "массовый" Вы понимаете кол-во интернет-магазинов или, все-таки, число клиентов одного интернет-магазина?

GrayStrannik
Даже один из крупнейших интернет-магазинов Болеро на своём сайте официально пишет, что 2-3% заказов заканчиваются отказом в товаре - у них нет своего склада, нет информации по наличию на чужих складах товара и им в транзакции нечего резервировать.


Гм... Ну, значит, расти им еще и расти. Ни склада своего нет, ни данных о наличии у поставщиков, ни данных о... Кстати, принятие заказа (транзакция) <> резервирование товара под него (еще одна транзакция).

GrayStrannik
Такова жизнь: проблема с отсутствием транзакций поглощается куда большей проблемой с физическим учётом наличия товара на складе.


Ну, если "учет наличия товара на складе" для кого-то проблема...
6 янв 10, 14:29    [8152066]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
GrayStrannik
И много Вы знаете российских форумов, под которыми не MySQL?


Мне глубоко наплевать на статистику распределения СУБД по Российским форумам. Не потому, что они, Российские, а потому, что они форумы, и не имеют, за очень редким исключениме отношения к сабжу: "Высоконагруженные проекты".
6 янв 10, 14:41    [8152100]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
igorekk
Member

Откуда: Москва
Сообщений: 316
Di_LIne
st_st
В России почти всё пишется на php + my sql и запросы составляются внутри php-страниц, о существовании процедур многие даже не подозревают.

Потому их, сайтеги, и щелкают как орехи...
А в суриозных - только за слово ПыхПых - отстреливают... на месте.

Facebook? :)

PS. Правда там не MySQL, там вообще Cassandra.
6 янв 10, 15:43    [8152290]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить