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

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

Резюмируя - сделали так, потому что так сделали? :)

По теме:
- нежелние писать на PL/SQL (причин тоже может быть много, в т.ч. и разумных)
- нежелание платить Ораклу за дорогие процессорные лицензии (думаю одна из главных причин)
- и т.д.
Но самое главное, похоже, то, что когда все это делалось, Оракле нихрена не масштабировался под такие объемы, и они сделали что-то вроде home-made MPP на его базе.

Yo.!
на сколько я помню у них как раз крупнейший оракловый RAC на 16 и 8 нод, правда подозреваю только для аналитики

Под аналитику там Teradata (EDW > 2Pb) и Greenplum (Data Marts 6.5 Pb). Базы Оракл с такими объемами в природе еще никто не встречал.
6 янв 10, 16:07    [8152374]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30286
Apex
Резюмируя - сделали так, потому что так сделали? :)

именно. я участвовал в паре действительно мрачных специфических проектов, и оптимизация там совершенно своя. И для повышения производительности приходилось делать массу несвойственных обычным клиент-серверным задачам вещей - денормализацию, дублирование данных, разбиение логики, и т.п., причем иногда в извращенном виде, делая насилие над собой :-)
Apex
Оракле нихрена не масштабировался под такие объемы, и они сделали что-то вроде home-made MPP

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

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

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Под аналитику там Teradata (EDW > 2Pb) и Greenplum (Data Marts 6.5 Pb). Базы Оракл с такими объемами в природе еще никто не встречал.


Ну, не 6.5, конечно:

автор
The site's 1 petabyte of data is managed by 440 Microsoft SQL Server instances and resides on 3PAR Utility Storage. When MySpace needed a message queuing and delivery solution to help ensure data changes were correctly and atomically executed on all affected physical database instances, MySpace created an internal solution, called Service Dispatcher, using the Service Broker feature of SQL Server 2005. Service Broker has helped MySpace ensure data integrity across its distributed infrastructure, resulting in a better user experience. Service Broker also helps MySpace developers to roll out new services faster.


http://whitepapers.techrepublic.com.com/abstract.aspx?docid=1097845
6 янв 10, 16:27    [8152434]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
pkarklin
Member

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


Я, как locky, ща тапок в руки возьму...
6 янв 10, 16:28    [8152440]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin


http://whitepapers.techrepublic.com.com/abstract.aspx?docid=1097845

Та... еще бы ютуб в пример привели...

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

Самое интерсное, что все вышеперечисленные приемы (кстасти, зачем вы их перечисляли? рассказать мне о том, что делают, чтобы поизводительность повысить?) не имеют отношения к субжу топика :)

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

Так что, если такую архитектуру и выбирают, то уже когда другого выбора нет, имхо.
6 янв 10, 18:20    [8152854]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 Apex
Основные недостатоки подобной архитектуры:
- необходимо гонять данные между сервером БД и сервером приложений

А что, сервер приложений соединён с сервером БД через GPRS-модем какой-нибудь?

- объем кода, как правило, получается больше, т.к. процедурные расширения все же локаничнее

Это утверждение не соответствует действительности.
Во-первых - процедурные расширения для конкретной СУБД пишутся на фиксированном языке. Иногда очень неудачном (с т.з. именно процедурных расширений, например T-SQL).
Во-вторых - сервер приложений не имеет ограничений на используемый язык и степень его, кхмм, "локаничности"
Не может что-то фиксированное выигрывать у чего-то произвольного. Ни в "локаничности", ни в чём другом.

- большие объемы информации на сервере приложений не шибко пообрабатываешь

Разумеется. Так ведь какую-нибудь мега-аналитику обычно и не крутят апп-серверами

У трехзвенной архитектуры конечно же есть свои недостатки. Но совсем не те, что Вы записали в её "основные недостатки".
6 янв 10, 19:01    [8152984]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ЛП

А что, сервер приложений соединён с сервером БД через GPRS-модем какой-нибудь?

Да хоть 10-ти гигабитный канал.

ЛП

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

Тем не менее, это, даже не очень удачное расширение, интегрировано с конкретной СУБД гораздо теснее, чем любой другой универсальный язык программирования. Лишнее подтвержение тому обилие ORM'ов, которые по своей сложности и глюкавости уже давно соревнуются с самими серверами приложений.

ЛП

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

Ага, оно и видно: J2EE - Java, Zope - Python, .Net - C#, Tuxedo - C\C++... И самое главное, куда не плюнь, все пользуются "свободой выбора".

ЛП

Не может что-то фиксированное выигрывать у чего-то произвольного. Ни в "локаничности", ни в чём другом.

У чего-то произвольно - согласен. Но речь ведь не о чем-то произвольном.

ЛП
У трехзвенной архитектуры конечно же есть свои недостатки. Но совсем не те, что Вы записали в её "основные недостатки".

Просим.
6 янв 10, 20:22    [8153169]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 Apex
Да хоть 10-ти гигабитный канал.

Ну и славненько. Хотя Вам всё-таки иногда лучше жевать.
10-гигабитный канал - это кагбэ поболе, чем стандартные дисковые системы выдают в последовательном чтении. И уже сравнимо с пропускной способностью памяти.
Если вы считаете, что необходимость передачи данных по 10-гигабитному каналу есть недостаток, то всем РСУБД надо утопиццо. Потому что им приходится читать данные из памяти примерно с такой пропускной способностью, а так же с гораздо более медленного харда.

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

Стоп.
Вы говорили про лаконичность и объем кода. Когда Вас носом ткнули в глупость - начали зачем то про интегрированность говорить.
Под дурачка косите? Надеетесь, что никто не заметит?

Лишнее подтвержение тому обилие ORM'ов

Лишнее подтверждение чему?
Обилие ОРМ-ов - это по Вашему лишнее подтверждение лаконичности интегрированных процедурных расширений сиквела?

Просим.

Я правильно понимаю, что привёденные Вами "основные недостатки" дальше обсуждать смысла нет?
6 янв 10, 20:57    [8153220]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
ЛП
2 Apex
Да хоть 10-ти гигабитный канал.

Ну и славненько. Хотя Вам всё-таки иногда лучше жевать.
10-гигабитный канал - это кагбэ поболе, чем стандартные дисковые системы выдают в последовательном чтении. И уже сравнимо с пропускной способностью памяти.
Если вы считаете, что необходимость передачи данных по 10-гигабитному каналу есть недостаток, то всем РСУБД надо утопиццо. Потому что им приходится читать данные из памяти примерно с такой пропускной способностью, а так же с гораздо более медленного харда.

скорость то может и сравнима, да латентность совсем другая. а это гораздо более значительный фактор.
6 янв 10, 21:52    [8153324]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
Alexander Ryndin
скорость то может и сравнима, да латентность совсем другая. а это гораздо более значительный фактор.

Истину глаголешь.
Так РСУБД таки надо утопиццо? Потому что у харда латентность тоже немаленькая (а скорость еще ниже)?
:)
6 янв 10, 22:11    [8153362]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Александр Третьяков
Member

Откуда: Украина, г. Тернополь
Сообщений: 549
pkarklin прав, в высоконагруженных системах боряться за каждую секунду и многое (практически все) кидают на хранимки, и каждый кусок кода шлифуют "как последний раз". Проблема, что часто программисты, не разбираются в тонкостях Базы данных... Это не потому что они тупые, просто не реально знать все (технологий масса...).

P.S.
А мне лично кажется, что Ebay не все говорит про то как у них все сделано... :)
Я бы на их месте, и при их бабле, и при их НАГРУЗКАХ, сделал бы серединку на С (да, да, да), и кластер и разпределение операций по серверах, базу данных с хранимками на Оракл, и не один сервак ... (Вы друзья наверное видели, что начинаеш торговаться за лот и цена уже пошла вверх, а в соседнем окне кидаеш в поиск этот товар, а там цена старая, тоесть таблицы для поиска используются другие и они обновляются через некоторое время)... Мы ушли от темы, и я бы сделал так чтобы этот промежуточный слой вел себя, будто это что-то известное... например виндовс 2008... пусть "любознательные" дети-хакеры поломают голову.

P.S.P.S.
Такие штуки как Ebay - это единичные проекты, в них каждый кусок уникальный и гениальный... И они прям взяли и все нам рассказали, где они что и как делают, что у них как работает, пароли и явки нам дали :). Они свои секреты и алгоритмы берегут как синицу...
6 янв 10, 22:55    [8153462]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
ЛП

Истину глаголешь.
Так РСУБД таки надо утопиццо? Потому что у харда латентность тоже немаленькая (а скорость еще ниже)?
:)

Латенси харда будет в обоих случаях, а вот латенси сети, только в одном. Так что под дурачка тут похоже косите вы. А может и не косите.

ЛП
Вы говорили про лаконичность и объем кода.

Да, я говорил про лаконичность и объем кода.

ЛП
Обилие ОРМ-ов - это по Вашему лишнее подтверждение лаконичности интегрированных процедурных расширений сиквела?

Да, по-моему это лишнее подтверждение лаконичности процедурных расширений. ORM - это попытка упростить работу с SQL-серверами для универсальных языков программирования (будь то Java\C++\C#). Раз они появились, значит работать без них не так то удобно, код получается громоздкий, перегруженный лишними деталями. Возьмите любую ХП (хоть на PL/SQL, хоть на T-SQL) и реулизуйте ее на Java.
И кстати, к вопросу о латенси и OPRM'ах - кэши в последних для чего по-вашему стали делать?
6 янв 10, 23:38    [8153568]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 Apex
Да, я говорил про лаконичность и объем кода.

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

ЛП
Обилие ОРМ-ов - это по Вашему лишнее подтверждение лаконичности интегрированных процедурных расширений сиквела?

Да, по-моему это лишнее подтверждение лаконичности процедурных расширений. ORM - это попытка упростить работу с SQL-серверами для универсальных языков программирования (будь то Java\C++\C#).

Очередную чушь сказал.

ORM это попытка упразднить работу с DML и вообще абстрагироваться от низлежащей реляционной модели.
Надобность в этом возникает вовсе не из-за того, что какой-то там процедурный язык внутре СУБД якобы лаконичен. Совсем наоборот. Было бы оно там лаконично и красиво - писали бы всё внутре СУБД, не смотрели бы в сторону универсальных языков, и не испытывали бы нужды в скрещении нормального универсального языка с выгрызками sql (или избавлении от этих выгрызок посредством ORM).

Что же до "упрощения работы с SQL-серверами", то упрощается эта работа вовсе не путем использования ORM, а использованием примитивных хелперов поверх библиотек работы с данными.

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

Если бы процедурные расширения SQL были хороши, то и не было бы надобности ни в универсальных языках программирования при работе с БД, ни в ORM. Как раз таки писали бы совершенно спокойно на T-SQL (pl-sql, и т.д., и т.п.)
Ан нет, противно.

Возьмите любую ХП (хоть на PL/SQL, хоть на T-SQL) и реулизуйте ее на Java.

Любую ХП я спокойно реализую хоть на джаве, хоть на чем. Особо не напрягаясь.
А вот сколь-нибудь сложный код сделать на T-SQL, с его то двумя операторами WHILE и IF, и проверкой @@error после каждого запроса - буэээ.
Это у меня аллергия на "лаконичный T-SQL код".
7 янв 10, 00:03    [8153641]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцесник
Guest
Тут примерно так получается: вынужден полностью поддержать ЛП, хотя я с ним "категорически не согласен".
Начну с моих акцессных ответов на первоначально поставленные вопросы.

st_st
Сильно ли тормозят хранимые процедуры, по сравнению с обычными запросами из web-приложения?

Хранимые процедуры не "тормозят по сравнению с обычными запросами" ни из web-приложения, ни из какого другого.

st_st

Почему ebay отказался от процедур и сложных запросов в пользу простых запросов внутри скриптов и обработки данных на веб-серверах? Получается базы жутко тормозят и гораздо быстрее перекинуть данные на web-сервер и обработать, чем предоставить это субд?

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

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

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

Пусть мне сказали - пиши такое на акцессе. Нужно быть ъбнутым на своей гордости от умения писать хранимые процедуры, чтобы подвязать пользовательский интерфейс на хранимки против ad-hoc запросов. Образовать грид на View - значит отдать полностью на откуп встроенным средствам
( в моем случае - акцесса) вопросы, связанные на фильтрацией, синхронизацией/рефрешем данных, записью в базу и обновлением. Образовать грид на хранимой процедуре - значит предоставить разработчику возможность гордиться своими умениями выписывать запросы/хранимки на синхронизацию данных и обеспечивать хитроумные возможности (опять через хранимки) по вставке/модификации данных. (Это не упоминая о необходимости обеспечить опысываемость возвращяемых наборов)
Даже если вы ярый сторонник реализации "бизнес-логики" прямо в СУБД, это не обязательно должно означать, что весь код, поддерживающий визуализацию данных, обязательно должен находиться там же - в СУБД?

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


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

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

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

Вот в чем я с ЛП категорически не могу согласиться. Никак.
Так это с тем, что хранилище - тупое. Негоже наделять хранилища человеческими качествами.
7 янв 10, 00:20    [8153679]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
2 сосед-акцесник
Как всегда впечатлён.
Чувствую, что так и буду до конца жизни ключи подавать :)

Вот в чем я с ЛП категорически не могу согласиться. Никак.
Так это с тем, что хранилище - тупое. Негоже наделять хранилища человеческими качествами.

Эээ... позвольте заявить в своё оправдание, что очеловечивание хранилища с моей стороны можно рассматривать как акт социального протеста против (интересно, бывает ли протест за?) наблюдающейся тенденции обожествления этого самого хранилища. Тут же ж эттаа... хранилищу молиться готовы... особенно если оракл написано...
7 янв 10, 03:58    [8154048]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
2 сосед-акцессник.
Ну наконец-то появился кто-то с опытом разработки нагруженных систем :)

Ну, кроме вышеперечисленного (предметная область хорошо горизонтально масштабируется, основной поток новых требований связан с визуализацией) я бы добавил еще парочку характеристик, повлиявших на выбор eBay их архитектуры:
1) Нет потребности в постоянно целостной базе. Да, остаток на конкретном счету - важен. А вот все остальное - вполне может быть какое-то время не целостно. Собственно, eBay так и делает - у них асинхронные демоны поддержки консистентности.
2) Денег жалко :) Т.е. конечно можно было бы использовать партицирование БД от Оракла (или IBM), и получить те же сотни тысяч запросов. Но цена этого решения была бы, мягко говоря, не сопоставима с доходом от транзакции. Меня вообще удивляет, почему для "линейных" серверов (хранящих данные по счетам и по лотам) используется Оракл - по идее, хватило бы и чего-нибудь более дешевого. Впрочем, подозреваю, уровень скидок Оракла тут достигает 99%, а используют младшие редакции.
3) А вообще, архитектура eBay - это замечательный текст для медитации. Открываешь любую страницу - и начинаешь думать, а почему было сделано именно так. Так как они архитектуру 4 раза переделывали, то видны все те грабли, на которые наступали )

Вообще, при текущей стоимости лицензий и программистов, создавать собственные решения для кластеризации и партишонинга имеет смысл где-то с 4-8 серверов (сильно зависит от страны оплаты труда разработчиков и уровня скидок от вендора БД).
9 янв 10, 13:31    [8159683]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
Apex

Основные недостатоки подобной архитектуры:
- необходимо гонять данные между сервером БД и сервером приложений

Э, так если у нас кластер на уровне БД, то гонять данные между серверами - все равно нужно.
Все-таки, предел оперативной памяти для кэшей на уровне сервера БД приходит быстро и стоит дорого - так что одной железкой не обойтись.
А при этом уже нет разницы - гонять данные между серверами БД (как в RAC) или между сервером БД и сервером приложений. Только сервера приложений на пару порядков дешевле (по лицензиям).
Да и у того же RAC довольно быстро наступает предел насыщения (насколько я помню, больше 16 ставить уже не рекомендуют).
Про прочие проблемы (типа разнесения по разным ДЦ, высокая надежность и т.п.) - я уж и не говорю :)


- объем кода, как правило, получается больше, т.к. процедурные расширения все же локаничнее

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


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

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



Так что, если такую архитектуру и выбирают, то уже когда другого выбора нет, имхо.

Да не, в большем числе случаев архитектура выбирается на основе имеющихся кадров. Если куча джавистов - то проще делать трехзвенку с ОРМом, если куча SQLщиков - все будет на хранимках, а уж если куча дельфистов - то вообще все, что угодно.
Но приличного (т.е. создающего поддерживаемый другим джавистом код за приемлимое время и требуемого качества) джависта, как показывает опыт, найти и обучить проще, нежели sqlщика.
9 янв 10, 13:45    [8159710]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
DPH3
Но приличного (т.е. создающего поддерживаемый другим джавистом код за приемлимое время и требуемого качества) джависта, как показывает опыт, найти и обучить проще, нежели sqlщика.

Над проблемой "создания за приемлимое время требуемого качества легкоподдерживаемого кода" уже не один десяток лет думают широколобые дядьки.
Что характерно - думают весьма успешно. С хорошими результатами.
Что печально - результаты думания широколобых дядек уже не один десяток лет пролетают мимо SQL.
Поэтому неудивительно, что sql-щика, создающего легкоподдерживаемый и далее по тексту код, найти сложнее, чем джависта (дотнетовца и т.п.).
Еще сложнее найти такого чудо-девелопера на ассемблере.
9 янв 10, 14:25    [8159793]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
DPH3

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

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

Сама компания Oracle в свое время допустила ошибку, пытаясь засунуть внутрь базы несвойственные ей компоненты (генераторы web-страниц, java-машины, olap-движок и т.д.). Сейчас они таких ошибок уже не допускают. Большие ставки делаются на распределенные кэши уровня серверов приложений, на кластеры серверов приложений, на шардинг(думаете зря Oracle бьется за MySQL?). Не стоит повторять их ошибки и впадать в другую крайность, реализуя все на сервере приложений.

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

Попробуйте прийти в какой-нибудь банк и сказать им, что все их Oracle нужно выкинуть, заменить на MySQL с движком MyISAM, а транзактную целостность реализовать на сервере приложений. Будет нервная реакция. И это правильно - бизнес должен быть инертен, когда дело касается денег.

Кстати, хорошие java- и sql-программисты одинаково ценны. И одинаково трудно учатся. Ведь это годы практики.
9 янв 10, 16:47    [8160053]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
ЛП
Guest
Alexander Ryndin
Какие-то вы, господа, черно-белые. Есть задачи, которые отлично решаются хранимками. Есть задачи, которые принципиально внутри базы решаться не должны. Симбиоз должен быть, а не взаимоисключение. Архитектор в команде нужен, который не будет допускать крайних решений.

Ну да, ну да.
Есть задачи, которые хорошо решаются на ассемблере, в крайнем случае на голом С. Всякие там драйверы видеокарт, к примеру, выводящие изображение на монитор.
Есть задачи, которые хорошо решаются на VB.Net. Всякие там WinForms, выводящие изображение на монитор.
Никакого симбиоза между ними быть не может. Чистое взаимоисключение. Не пишутся видюшные драйвера на VB.Net. Не рисуются формочки на ассемблере.

Есть задачи, великолепно решаемые при помощи SQL. И никаким "процедурным расширениям" там и не место. Есть задачи, великолепно решаемые ОО-языками. И там не место фсякому SQL. Никакого симбиоза, чистой воды взаимоисключение. К архитектору не ходи, все там будем.
9 янв 10, 17:30    [8160115]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
ЛП,

Умолкаю-умолкаю. Уступаю помост гению.
9 янв 10, 21:34    [8160477]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
DPH3
Guest
Alexander Ryndin

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

Э, уж больно большая разница в архитектурах, созданных для команды джавщиков и для команды SQLщиков. Разные риски, разные решения, разные методологии. И сочетать в одном проекте и то и другое (если, конечно, проект меньше 20 человеколет на первом этапе) - дорого и неэффективно.

Пока еще кадры определяют архитектуру - собственно, из-за этого там много нагруженных проектов на MySQL.

[quot]
Есть четкая уверенность, что реализовав что-то на продуктах Oracle (по крайней мере на базе данных) - вы не получите через пару лет смену концепции. Все решения, созданные вами, будут продолжать работать.

Гм, это какой-то новый аргумент. В большей части известных мне проектов Оракл выбирают или потому, что с ним уже имели дело или потому, что "это круто". Производительность и масштабирование актуальны настолько в небольшом числе проектов, что на статистику они не влияют.
А, да, еще затраты на лицензии Оракла можно списать в расходы :) Или добавить в активы. В отличии от зарплат.



Попробуйте прийти в какой-нибудь банк и сказать им, что все их Oracle нужно выкинуть, заменить на MySQL с движком MyISAM, а транзактную целостность реализовать на сервере приложений. Будет нервная реакция. И это правильно - бизнес должен быть инертен, когда дело касается денег.

Гм. В банках используюn Оракл не из-за транзакционной целостности - эти параметры при выборе вендора не слишком значимы :)




Кстати, хорошие java- и sql-программисты одинаково ценны. И одинаково трудно учатся. Ведь это годы практики.

Ну, по моему опыту, хороший sql-дев сейчас дороже (правда, я таких уже давненько не встречал). И качество от лет практики зависит далеко не прямо (далеко не всякая практика идет в плюс). И sql-девов несколько сложнее учить. Сделать хорошего джавщика из студента можно за год, делов-то, процесс налажен. Для sqlщиков, увы, я подобных "фабрик переработки" не видел.
10 янв 10, 01:14    [8161010]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
Yo.!
Guest
DPH3
И sql-девов несколько сложнее учить. Сделать хорошего джавщика из студента можно за год, делов-то, процесс налажен. Для sqlщиков, увы, я подобных "фабрик переработки" не видел.


угу, последний проект пришлось делать на жава+хибер просто по тому что pl/sql девелоперов на пару порядков меньше и стоят на порядок дороже и пока соберешь нормальную команду ...
10 янв 10, 02:31    [8161108]     Ответить | Цитировать Сообщить модератору
 Re: Высоконагруженные проекты и запросы  [new]
сосед-акцесник
Guest
Yo.!
...
угу, последний проект пришлось делать на жава+хибер просто по тому что pl/sql девелоперов на пару порядков меньше и стоят на порядок дороже и пока соберешь нормальную команду ...


не мне, акцесснику судить, но со стороны кажется прмерно так:

цена ява-програмистов падает по мере увеличения их количества. Но цены pl/sql - программистам уже почти нет. Уже ничего они не стоят. Почти.
Сейчас, мое впечатление, средний "vba-программист", имеющий весьма приблизительное представление о предмете, но способный произнести слов "Excel" и опознать его ярлык на десктопе, стоит дороже pl/sql девелопера
Деньги, которые получает ява-программист еще менее vba-шника зависят от того, насколько он в теме, ввиду жаренности самой явы и обширности ассоциированных аббревиатур.

Типа - pl/sql - пердуны - это чтобы поддерживать унаследованные системы.
Vba - ну, VBA никто не знает и знать не желает, чтобы соседи-профессионалы не смеялись.
Да и умер он уже почти достоверно. За это можно и приплатить временно.
А ява-пионэры - это наше все. Соременные технологии и куча терминологии.
Без них и базу данных в осколки не разобъешь по современному и будущему.
Это неважно, пишут ли они что практическое, или "технологии изучают" - священные коровы и временно стоят дороже ввиду того, что нужны абсолютно всем в строго обязательном порядке. Даже если неизвестно - что с ними в точности делать. Без них ярлыки современных технологий со лба спадают. Как-то так.

DPH3
Ну наконец-то появился кто-то с опытом разработки нагруженных систем :)

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

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

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

ЛП
Эээ... позвольте заявить в своё оправдание, что очеловечивание хранилища с моей стороны можно рассматривать как акт социального протеста против (интересно, бывает ли протест за?) наблюдающейся тенденции обожествления этого самого хранилища. Тут же ж эттаа... хранилищу молиться готовы... особенно если оракл написано


:))
Ну, тогда уж несчастным его назови, что-ли.
Раскалывали хранилище на кусочки не предупредив, что с самого начала для того и выбирали, чтобы потом расколоть.

Чуется мне, что через какое-то время, совершив соотвествующую петлю, завершится это тем, что в современных терминах могло бы быть названо монолитным решением.
Будет эта какая-нибудь экзадата шрих энного поколения или диби-два-в-ионосфере - поживем увидим.
10 янв 10, 03:33    [8161166]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить