Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
подскажите какие схемы существуют для масштабирования небольшой но очень активно используемой(многими клиентами) базы данных (100k записей) ? другими словами - как организовать базу(систему) для хранения 100k записей так, чтобы при увеличении количества серверов (не кластер) линейно(или почти) увеличивалась мощность (N клиентов / 1 секунду, все клиенты более-менее одинаково активны) просьба не флеймить и не писать "все зависит от конкретной задачи", интресует общее, пусть и не самое оптимальное, решение. заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 19:43 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
активно используемой как для чтения так и записи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 19:44 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Привет, vazhnecki! Ты пишешь: vazhnecki v> активно используемой как для чтения так и записи 100к - фигня. Клиентов сколько? -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 19:48 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
100k записей, если там нет огромных блобов, означает что все записи будут постоянно находится в оперативной памяти. При более менее правильно сделанных таблицах, правильном построении архитектруы приложения, нормальных запросах, выдержит, думаю на большинстве СУБД, сотни конкурентных пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 20:13 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
записей ~100000 конкурентных пользователей ~10000 .. в этом то вся сложность и закючается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 20:53 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
авторподскажите какие схемы существуют для масштабирования небольшой но очень активно используемой(многими клиентами) базы данных (100k записей) ? существует несколько схем. автордругими словами - как организовать базу(систему) для хранения 100k записей так, чтобы при увеличении количества серверов (не кластер) линейно(или почти) увеличивалась мощность (N клиентов / 1 секунду, все клиенты более-менее одинаково активны) необходимо правильно организовать. авторпросьба не флеймить и не писать "все зависит от конкретной задачи", интресует общее, пусть и не самое оптимальное, решение. замечено, что на глупые вопросы обычно получают глупые ответы ... если нужны умные ответы сформулируй задачу, железо и субд и клиентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 22:08 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Yo! не мусари бессмысленными сообщениями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2004, 22:24 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
записей в базе ~100k конкурентных и очень активных пользователей ~10k с пиками до 50k это значит что 1 сервер пусть и настроенный как часы не может тянуть сразу всех пользователей сервер1 linux, pentium 2GHz, 1Gb памяти, scsi веник 100Gb сервер2 linux, pentium 2GHz, 1Gb памяти, scsi веник 100Gb сервер3 linux, pentium 2GHz, 1Gb памяти, scsi веник 100Gb сервер4 linux, pentium 2GHz, 1Gb памяти, scsi веник 100Gb между серваками сетка 100Mbit .. или даже 1Gbit через роутер клиенты - пусть это будут просто юзеры коннектящиеся к базе (через систему) и делающие sql запросы на чтение/запись база - postgresql/mysql/firefox к примеру, все на этапе проектирования пока и если есть варианты то я выслушаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2004, 03:05 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
>все на этапе проектирования пока и если есть варианты то я выслушаю Это очень хорошо, что всё на этапе проектирования и просто здоров, что Вы нас выслушаете... но всё-ж таки, чего проектируем? Чего делаем-то? подходы то и правда разные могут быть.... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2004, 13:32 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
а клиенты на чем сделаны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2004, 15:32 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
я смотрю теоретиков тут 0.0 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.10.2004, 22:16 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
>я смотрю теоретиков тут 0.0 :) отчего же, теоретики есть, и неслабые... просто.... сотрясать воздух ради сотрясения воздуха... для зачем? решать задачу в общем виде - такое только математики любят. ИнженерА решают конкретные практические задачи. P.S. Вот и пошло сотрясание воздуха :-) Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 12:45 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
затем чтобы знать какие есть способы вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 18:23 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
> линейно(или почти) увеличивалась мощность JMS. Imho и серверА пошустрее бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 18:34 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
проектировать так, чтобы определенная группа юзеров обращалась только к своим данным, и вот эти группы разносить по серверам. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 19:12 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
lockyпроектировать так, чтобы определенная группа юзеров обращалась только к своим данным, и вот эти группы разносить по серверам. Posted via ActualForum NNTP Server 1.1 а вот если нельзя ! если каждый юзер каждым своим запросом изменяет 50% данных таблицы, что делать в этом случае ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2004, 02:12 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
а вот если нельзя ! если каждый юзер каждым своим запросом изменяет 50% данных таблицы, что делать в этом случае а можно огласить весь список требований? Потому что неудобно догадываться, что же нужно. На текущий момент лично мне кажется, что наилучшим выходом был бы не scale-out, а scale-up. А вот некоторые (не будем тыкать пальцем) могут заявить, что нужна 3-х звенка. И может быть будут правы. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2004, 13:37 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
2vazhnecki что за задача ? вариант 1: oracle RAC, дрого но вытянет и 100к юзеров на таком железе. вариант 2: если позволяет задача - организовать механизм очереди, т.е. один быстрый процесс создает очередь заданий второй процесс разгредает очередь. вариант 3: загнать 4 сервера и взять нормальный 64-бит сервер побольше памяти и не извращатся без надобности. говорили что SUN дает 8 головый сервер по цене 4х голового, но с 4 процами, вырастаешь они тебе "включают" остальные 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2004, 15:12 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
считайте что у задачи самые жесткие и самые неоптимизируемые условия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2004, 23:05 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
Yo!2vazhnecki что за задача ? вариант 1: oracle RAC, дрого но вытянет и 100к юзеров на таком железе. вариант 2: если позволяет задача - организовать механизм очереди, т.е. один быстрый процесс создает очередь заданий второй процесс разгредает очередь. вариант 3: загнать 4 сервера и взять нормальный 64-бит сервер побольше памяти и не извращатся без надобности. говорили что SUN дает 8 головый сервер по цене 4х голового, но с 4 процами, вырастаешь они тебе "включают" остальные 4. вариант 2 - не понимаю, как это работает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2004, 23:09 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
2 vazhnecki do u upgrade smth like www.mheart.ru ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2004, 02:39 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
очень похоже что именно mheart.ru и есть. http://uptime.netcraft.com/up/graph/?host=www.mheart.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2004, 02:47 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
слава зы2 vazhnecki do u upgrade smth like www.mheart.ru ? нет, там по идее все оптимизируется и разделяется без проблем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2004, 14:42 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
>вариант 2 - не понимаю, как это работает ? типа монитора транзакций на маинфрейме, когда всех юзеров одновременно система обработать не может делают так: все юзера очень быстро пишут в тибличку(и) заданий, дальше другой процесс(ы) берет по одному заданию и выполняет. т.е. клиент дал за дание и отвалил, его задание помещается в очередь и позже будет выполнено. >считайте что у задачи самые жесткие и самые неоптимизируемые условия заниматся ерундой - лениво, давай задачу, найду решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2004, 17:05 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
задача - движок онлайн игры, база будет испоьзоваться для хранения промежуточных значений и пересчета ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2004, 02:55 |
|
||
|
вопрос по 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 |
|
||
|
вопрос по scalabiliy
|
|||
|---|---|---|---|
|
#18+
MasterZiv процессор запросов и сам по себе загибаться будет на такой нагрузке. Можно раз в день, в периоды наименьшей нагрузки, последовательно пройтись по всем ХП, пометить каждую для перекомпиляции и запустить с наиболее часто встречающимися параметрами. Тем самым убирается возможное отрицательное влияние первого запуска с нехарактерными параметрами, и убирается отрицательное влияние компиляции под нагрузкой, когда у процессора запросов получаются плохие планы из-за того что у него мало ресурсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 11:55 |
|
||
|
|
start [/forum/topic.php?all=1&fid=32&tid=1546180]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
137ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 468ms |
| 0 / 0 |
