|
|
|
прошу совета по масштабируемости системы
|
|||
|---|---|---|---|
|
#18+
Есть OLTP-система состоящая из двух основных частей данные и поддержка пользователей(сессии,логирование действий), логика находится на стороне БД(определение доступности данных для пользователей и тп), сейчас стоит задача придать масштабируемость системе, сейчас остановились на 2ух способах: 1.разнести данные и поддержку пользователей на разные сервера БД(из плюсов теоретически в дальнейшем при росте количества ользователей можно будет просто добавить сервер подержки пользователей из минусов сложно спрогнозировать рост производительности при добавление дополнительного сервера, придется вынести логику из БД, нельзя обеспечить целосность даных средствами БД), 2.маштабировать за счет добавления полных копий серверов(из минусов необходимость синхронизировать сервера из плюсов практически ничего не надо менять, линейный рост производительности при добавлении сервера)... прошу прокоментировать =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2006, 11:28 |
|
||
|
прошу совета по масштабируемости системы
|
|||
|---|---|---|---|
|
#18+
Способ 2 не только улучшает масштабируемость но надёжность системы. Если удасться обойти проблемы репликации данных и вложить деньги в оборудование, то это очень перспективный способ. Способ 1 реализовать значительно сложнее, хотя можно посмотреть например в сторону не 3х звенных, а кластерных решений. Например Oracle Real Application Cluster. Можно оба способа комбинировать. Необходимо оценить нагрузку на компоненты системы. Например в способе 1 увеличение числа модулей поддержки пользователей может пропорционально увеличить нагрузку на БД, и вы снова столкнётесь с проблемой масштабируемости СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2006, 11:48 |
|
||
|
прошу совета по масштабируемости системы
|
|||
|---|---|---|---|
|
#18+
alecseyсейчас стоит задача придать масштабируемость системе Первый вопрос, который я бы задал - почему сейчас масштабируемости нет? Уверены ли Вы, что ресурсы "одномашинной" конфигурации исчерпаны? Уверены ли Вы, что оправдано идти на архитектурную перестройку и задача не может быть решена локальной оптимизацией? Если уверены - есть ли в вашей команде достаточно авторитетный специалист по используемой БД, который согласился с этой уверенностью? alecsey1.разнести данные и поддержку пользователей на разные сервера Сомнительно, мне кажется. Разносить стоит "редко взаимодействующие" агрегаты; здесь же, насколько я понимаю, любое действие пользователя аукнется на двух серверах. В результате затраты на их взаимодействие имеют хорошие шансы оставить другие тормоза далеко за флагом. alecsey2.маштабировать за счет добавления полных копий серверов Не обязательно полных. В принципе это путь к распределенной системе, в том числе к географически распределенной. Хорошее решение в своих условиях, делал и доволен. Но достаточно трудоемкое - либо нужно хорошо сделать, либо уйма сил будет уходить на администрирование и поддержку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2006, 12:14 |
|
||
|
прошу совета по масштабируемости системы
|
|||
|---|---|---|---|
|
#18+
softwarerПервый вопрос, который я бы задал - почему сейчас масштабируемости нет? Уверены ли Вы, что ресурсы "одномашинной" конфигурации исчерпаны?ресурсы "одномашинной" конфигурации далеко не исчерпаны, но заказчик хочет иметь возможность при желании повысить число обслуживаемых клиентов в 50-70 раз без модернизации приложения, а это уже нереально для одной машины(супер сервера не рассматриваем тк выходят за рамки стоимости решения) 2 mcureenab , softwarer спасибо за коментарии кое что уложилось в моей голове) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2006, 11:02 |
|
||
|
прошу совета по масштабируемости системы
|
|||
|---|---|---|---|
|
#18+
я бы все так и попытался первым шагом вынести логику поддержки пользователей(сессии,логирование действий) в сервисный слой - в отдельный компонент (remoting к примеру или webservice какой) и масштабировать уже этот компонент локально(пулами или многопоточностью) или по серверам. По-крайней мере поддержку пользователей гораздо проще вычленить чем остальную бизнес-логику. ... впринципе, можно и на уровне БД разделить. Например, если mssql - то пусть процедуры поддержки пользователей долбятся за данными к линкованному/ым серверу/ам. Кластерные решения также можно рассмотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2006, 12:18 |
|
||
|
|
start [/forum/topic.php?fid=33&msg=33983576&tid=1549307]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
150ms |
get topic data: |
30ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 27ms |
| total: | 312ms |
| 0 / 0 |
