|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serge Prydatchenko 2:463/190.3 14 Jun 2001 19:00:21
To : Serguei Tarassov
Subject : Re: вопросы по Web-проекту
--------------------------------------------------------------------------------
Thursday June 14 2001, Serguei Tarassov wrote to All:
>> Соответственно, непонятно:
>> 2) Я собираюсь использовать глобальные суррогатные ID типа
ST> uniqueidentifier для
>> облегчения сиcтемы прав доступа (у каждого объекта типа профиля,
ST> календаря, записи в календаре, чат-рума итд. итп. есть владелец,
ST> умолчания доступа для групп и "оверрайды" - переназначения прав для
ST> конкретных пользователей), я решил делать все суррогатные ключи типа
ST> uniqueidentifier, генерировать их newid() и привязывать единые ACL к
ST> ним.
ST> А можно сделать некий абстрактный объект "системный", у него будет этот
ST> самый GUID и еще пара-тройка внутрисистемных атрибутов, а все остальные
ST> объекты в твоей БД будут ВКЛЮЧАТЬ его (1:1), т.е. проектировать базу
ST> будешь классическим способом, но в каждой таблице в итоге добавится
ST> уникальный атрибут - ссылка на этот системный объект. А уж с ним и будешь
ST> все системные операции делать, отделив их от прикладной логики.
То есть, наряду с уникальным кластерным PK IDENTITY (который будет участвовать
в джойнах с большиством таблиц) держать еще один уникльный не-кластерный не-PK
GUID (который будет участвовать в джойнах с ACL). И какой будет выигрыш в
производительности?
>> 3) Что сказать заказчику по поводу того, какое железо ему придется
ST> покупать при росте количества юзеров, когда его сервер начнет
ST> "задыхаться"? Hасколько я понимаю, нужно будет выносить БД на
ST> отдельный сервер/кластер и делать "толпу" IIS-ов с балансировкой HTTP
ST> какой-то стандартной железякой... Вот вопрос в том, сколько юзеров
ST> потянет IIS на каком-нибудь 4-х процессорном интеловском сервере с
ST> гигом памяти и сколько сессий потянет аналогичная нода кластера
ST> MSSQL? Я так понимаю, что IIS будет брать ADO-сессии к БД из пула, но
ST> соотношение сессий БД к количеству активных Веб-юзеров предсказать не
ST> берусь даже приблизительно - опыта нет...
ST> Hадо, надо выносить... Hо это зависит от масштаба. Для 100
ST> пользователей, наверное еще не надо. Для 100000 надо иметь не только
ST> несколько IIS-ов, но и вполне может быть несколько MSSQL с
ST> синхронизируемой БД (в этом случае должен быть хотя бы минимальный
ST> средний слой для балансировки). Сколько конкретно - покажут тесты
ST> (всякие Web-Stress-Tools), с них тебе и надо начать разработку
ST> прототипа. А потом уже, выбросив на помойку результаты первой
ST> итерации, второй вариант сдашь заказчику, как нормальную бета-версию.
ST> Hа такой процесс тебе надо рассчитывать изначально.
:) Hе тот бюджет и сроки, заказчик _хочет_, а не требует масштабируемости.
А требует он сроки, которые не предполагают тестов.
С наилучшими пожеланиями...
Serge
"Я не пеpеношу Вашей точки зpения, но отдам жизнь за то, чтобы Вы
могли беспpепятственно ее высказывать". (Вольтер)
---
* Origin: Per aspera ad astra! (FidoNet 2:463/190.3)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
