Большинство современных баз данных позволяют объединить несколько отдельных серверов в кластер.

отсюда



Справедливости ради стоит заметить, что не только DB  умеют объединятся в кластер но и сервера приложений. 

хотел написать про такой вариант, но потом задумался, а на сколько удобно делать выборки через хранимые процедуры?
нда, если бизнес логика реализована и выполняется в процедурах дб то это правильно, удобно и довольно быстро, но что если вернуть надо не 1 или 0, а целую таблицу значений? как это у вас было реализовано?



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

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

Сталкивался со смешанной логикой (часть на хп, основная часть в приложении) - честно говоря она меня напрягла. Много повторений. Не ясность какая-то, что на чём реализовывать и тп.

Добавлено через 6 минут и 26 секунд
Вот, кстати, читаю: NoSQL

v2v, 
AntonSaburov, 


А как обстоят дела с правами доступа в случае с хранимыми процедурами?

Т.е.  есть процедура, которая селектит данные из таблицы1 и апдейтит таблицу2. Есть пользователь1 у которго есть доступ к процедуре. Должен ли у пользователя1 быть доступ на селект из таблицы1 и апдейт для таблицы2 ? 




serger, 


Не, сам не создавал   Но видел кластер из 3х MS SQL. По заверениям администраторов DB - такая схема обеспечивала прирост производительности по сравнению с одним сервером примерно в 2 раза (но не уверен, что они это сами измерили, в не взяли данные из рекламной брошюры    ). 

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


в оракле вроде должен. про mysql боюсь соврать, но тоже наверное должен.



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


Это сообщение отредактировал(а) v2v - 11.12.2009, 16:56

Спасибо.
Нет, ну ПРАВИЛЬНАЯ архитектура решит большинство проблем. Но кто ж её такую делает, да ещё и сразу.. И ещё я всё таки "наивно полагал", что всё-таки система сама должна распределить задачи, между нодами, только успевай их подключать..   

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


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


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

что касается запросов данных в процедурах, то этого делать не обязательно, можно использовать sql для получения данных на форме из resultset.

Это сообщение отредактировал(а) DimW - 11.12.2009, 14:22

А с какого ракурса я должен все рассматривать? Хочу рассматривать 3х и 2х звенную архитектуру с ракурса защиты от несанкционированного доступа. И считаю, что 3х звенка в этом плане предпочтительней. 


Насчет логика в BD против логики в апликэйшен сервере - тут столько факторов, что спорить по этому поводу бессмысленно.

Например:

1. наличие специалистов.
2. стоимость
3. историческая архитектура системы
и т.д.

Кстати, вопрос стоимости весьма интересен - производительность чего выгодней наращивать в конкретной системе - сервера приложений или сервера DB?

нет, не должен(в случае с оракл).


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

эх. Вы прокоментировали фразу выдернутую из контекста. Я не утверждаю что нельзя обойтись только ХП, но мне кажеться это совсем не удобным. Для каждого запроса надо написать свою обёртку в виде Хп. В 2 раза больше кода. Но это ещё куда не шло, а представьте что вам надо извлечь 
не 100 записей, а допустим 100К. Одной хваткой вытянуть из базы не удастся, надо реализовывать постраничнкую подкачку: ждбс для запросов предоставляет стандартный понятный механизм, а как быть с процедурами? Опять таки надо накручивать сложную лишнюю логику выборки без которой можна было бы обойтись.
Но я полностью поддерживаю хп подход. Бизнес-логику которая обновляет/удаляет/вставляет записи в более чем одну табличку надо выполнять на уровне хп.


да, на практике это оказалось не столь эффективно.

так я тоже, поэтому я чуть ниже об этом сказал 

Если так, то вместе с возможностью создавать VIEW и назначать права на доступ к ним в теории мы можем обеспечить неплохую защиту данным.




Ну, в случае 3х звенной архитектуры сервер с DB может принимать запросы только с ip апликэйшен сервера.
Правда, тут мы имеем другие неприятных моментов связанных с тем, что апп сервер должен иметь доступ ко всей информации с которой он работает, например, нужно не допустить возможность SQL инъекции.

Это сообщение отредактировал(а) Vasay - 11.12.2009, 16:53

Вот видео «Проблемы масштабирования интернет-проектов: когда, как и почему возникают, как с ними бороться».
Там в общих чертах про масштабирование. В принципе почти то что мне хотелось узнать. (мало деталей)
http://javatoday.ru/2009/03/siw-2009-video/

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

господа, а с каких пор наличие в приложении асинхронных запросов к апп серв. стало определять его как - "толстое" приожение?
время лекции - [15:50].
досмотрел до середины, на мой взгляд отвратительная лекция, ни о чем...

serger, и чем же скажем вот эта статья, хуже этой гoвнo-лекции?!...