|
вопрос по scalabiliy
|
||
|---|---|---|
Участник
Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщения: 2 792 |
||
| 02.11.2004, 12:39 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Внутренний голос подсказывает, что нужно применять не промышленную субд, а С++ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 10:04 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Alexey ShВнутренний голос подсказывает, что нужно применять не промышленную субд, а С++ ИМХО сложновато... Даже если заранее известно про сортировку и поиск, что где и как будет выбираться из данных, все равно... 10000 клиентов, которые еще и пишут в базу постоянно... По сути придется разрабатывать свой сервер. С блокировщиком проблем не оберешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 12:39 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
>база будет испоьзоваться для хранения промежуточных значений и пересчета а почему не колбасу ? зачем хранить промежуточные значения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 12:47 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
тут как раз и нужно использовать несколько серверов приложений - а база должна быть одна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 15:43 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
gardenmanтут как раз и нужно использовать несколько серверов приложений - а база должна быть одна. это само собой, только один такой сервер не потянет базу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 21:06 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Можно использовать многозвенку. В сервере приложений посылать запросы к БД через очередь сообщений. Сделать кеш для получения актуального состояния записей. Такой механизм еще и не требует дорогого железа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2004, 18:48 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
да ему бд вообще не нужна, у него данных нет. ему вполне хватит пара писюков и breaklyDB для промежуточных расчетов. просто чел не всилах даже задачу сформулировать влт и занимается херней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2004, 18:56 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
в общем проще сделать кластер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2004, 18:58 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
есть такой параметр в требованиях как колво транзакций в секунду? а то на кол-во подключений/кол-во записей ничего не понятно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2004, 19:28 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
gardenmanесть такой параметр в требованиях как колво транзакций в секунду? а то на кол-во подключений/кол-во записей ничего не понятно... почему никто раньше не спросил ? :) 10000 пользователей, каждый делает в среднем 1 запрос в секунду и соответственно желает получить ответ на свой запрос в течение 1 секунды не более. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2004, 23:36 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Если есть требование на максимальное время отклика - т.е. система должна работать в режиме близкому к реал-тайму - то без сервера приложений, очередей сообщений и кеша не обойтись. Кластер не поможет, так как время отклика БД недетерминированно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2004, 12:10 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Если требование не на максимальное время отклика, а скажем "в 80% случаев время отклика не более ...", то можно напрямую c БД работать, без очередей сообщений. При этом надо аккуратно подходить работе с базой данных - я сейчас делаю сервер приложений + БД, для приложения с ~10000 пользователеми, особых проблем не встречаю. БД - MS SQL2k. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2004, 12:18 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
если кол-во записей в БД невелико (вопрос еще, а нужно ли хранить логи) то подойдет практически любая БД, потому как все нужные записи наверняка влезут в кэш. А вот с сервером приложений (наверняка нужно будет сделать из них нечто вроде кластера) - придется действительно подумать очень основательно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2004, 12:36 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
vazhnecki , 10k одновременно работающих (если они реально работают) пользователей - это очень серьезно. И если это реально полное OLTP, то не смотря на то, что записей мало, я думаю, надо кластер ставить. Но это практически только Oracle и DB2, более на сколько я знаю кластеры никто и не поддерживает. PosgreSQL вряд ли даже близко стоит подпускать к такому. Плюс, по соотношению записей к пользователям, я полагаю, что будет еще достаточно актуальной задача решения вопросов concurrency. Еще есть мысль, что СУБД в этой задаче не нужна вообще, т.е. неверно спроектирована архитектура системы, но это уже надо извини ее знать, а это только ты сам знаешь. P.S. Я , конечно, могу быть и не прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2004, 17:29 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Еще andsm очень грамотное замечание дает, по поводу близости к RealTime. Обоими руками согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2004, 17:30 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Короче, любая СУБД очень плохо держит нагрузку вида "10000 чел. и каждый фигачит по запросу в секунду". И промышленные СУБД типа MSSQL Oraclе особо впереди здесь не будут - чем сложнее оптимизатор, тем дольше он оптимизирует. Так что для такого очень нужен промежуточный слой, который запросы (не SQL) принимать будет и серверу СУБД только то, что требует изменения данных посылать будет. Подумай хорошо, я не зря тебе три письма в топик написал. Я сам когда-то такое делал - систему торгов писал на бирже Санкт-Петербург на MSSQL. Это реально вешалка, они теперь там городят кучу каких-то промежуточных серверов, собирающих запросы и данные туды-сюды пересылают. Ужас, в общем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2004, 17:38 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Yo! вариант 3: загнать 4 сервера и взять нормальный 64-бит сервер побольше памяти и не извращатся без надобности. говорили что SUN дает 8 головый сервер по цене 4х голового, но с 4 процами, вырастаешь они тебе "включают" остальные 4. Ну стоит у нас этот SUN, но извини загрузка у него на два порядка меньше , и то не так чтобы все довольны скоростью были (хотя грех конечно жаловаться). Я это к тому, что "большим" сервером эту проблему не решить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2004, 17:41 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
А почему сразу "не кластер"? Ведь единственное, что есть линейно масштабируемое - это кластер SQL серверов. Другое дело - как этот кластер организовать... 1) SQL сервер - который крутится весь в ОЗУ - должен выдержать 10000 пишущих транзакций в секунду, если предельно упростить эти транзакции. - пусть каждая транзакция пишет килобайт - то 10 мегабайт\в секунду записывать, не так много. 2) а на чтение - каждый из SQL серверов в отдельности работает - так что 10000/N_SQL_серверов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 16:47 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
vazhnecki gardenmanесть такой параметр в требованиях как колво транзакций в секунду? а то на кол-во подключений/кол-во записей ничего не понятно... почему никто раньше не спросил ? :) 10000 пользователей, каждый делает в среднем 1 запрос в секунду и соответственно желает получить ответ на свой запрос в течение 1 секунды не более. Запрос на что? на чтение? на запись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 17:02 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Любитель кластеровА почему сразу "не кластер"? Ведь единственное, что есть линейно масштабируемое - это кластер SQL серверов. Отвечу. Любая СУБД выполняет запросы. Для выполнения запроса нужно выполнить достаточно много разных действий, которые являются накладными расходами. Самый яркий пример - это компиляция и оптимизация запроса. Это при серьезной нагрузке ОЧЕНЬ существенно, СУБД только этим и будет заниматься. Вопрос - а надо ли это для работы приложения ? Может последние данные , которые нужно отдать клиентам, можно просто хранить в памяти и весело отдавать клиентам, не беспокоя сервер ? Кластер в СУБД тоже можно конечно организовать, но вот только если ... будет нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 19:20 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
MasterZivСамый яркий пример - это компиляция и оптимизация запроса. Это при серьезной нагрузке ОЧЕНЬ существенно, СУБД только этим и будет заниматься. Если использовать параметризованные запросы, или ХП да еще с прописанными владельцеми и with binding, то MS SQL тратить на компиляцию время почти не будет. Я читал описание случая когда на работающей под большой нагрузкой системе (MS SQK2k) обнаружили серьезное падение производительности из-за блокировок компиляции ХП при неизменности схемы. Но ведь исправляется это просто, а если заранее готовить базу к большим нагрузкам, писать код с учетом этого, то подобных проблем не возникнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 22:22 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
авторНу стоит у нас этот SUN, но извини загрузка у него на два порядка меньше , и то не так чтобы все довольны скоростью были (хотя грех конечно жаловаться). фишка большого железа том что если у тебя нагрузка увеличется на порядок то все останутся давольны ... простенький sql запрос не будет исполнятся быстрей хоть 128 процов ему натыкай. ЗЫ. прочитайте всю ветку, у человека нет данных, ему не нужена взрослая субд со сторед процедурами, материализед вью и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2004, 11:40 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
MasterZiv Любитель кластеровА почему сразу "не кластер"? Ведь единственное, что есть линейно масштабируемое - это кластер SQL серверов. Отвечу. Любая СУБД выполняет запросы. Для выполнения запроса нужно выполнить достаточно много разных действий, которые являются накладными расходами. Самый яркий пример - это компиляция и оптимизация запроса. Это при серьезной нагрузке ОЧЕНЬ существенно, СУБД только этим и будет заниматься. Вопрос - а надо ли это для работы приложения ? Может последние данные , которые нужно отдать клиентам, можно просто хранить в памяти и весело отдавать клиентам, не беспокоя сервер ? Кластер в СУБД тоже можно конечно организовать, но вот только если ... будет нужно. в DB2 запрос хранится в базе данных в откомпилированном виде. И план доступа по нему уже построен. Престроить план можно командочкой REBIND. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2004, 13:40 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Попутно возник вопрос (из любопытства) - есть ли какой либо SQL сервер - простейший (самый простой, почти игрушечный, который умеет select and unsert) - который можно было бы иметь в исходниках и измываться над ним (переделывать под себя)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2004, 14:32 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
andsm Если использовать параметризованные запросы, или ХП да еще с прописанными владельцеми и with binding, то MS SQL тратить на компиляцию время почти не будет. Я про это знаю, но исходный товарищь ни про СУБД, ни про то, какие запросы будут (будет ли это вызовы SP или AD-HOC) не сказал. Да и возможности SP тут все равно преувиличены - да, оно быстрее, но все равно избежать пере-оптимизации на 100% нельзя. процессор запросов и сам по себе загибаться будет на такой нагрузке. Я писал систему торгов именно на MSSQL, и именно на процедурах (все). И никакого эффекта - все равно мощи не хватает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 10:57 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32780290&tid=1546180]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
129ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 456ms |
| 0 / 0 |
