Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Какая база сможет выдержать около 2000 пользователей онлайн и транзакций где то 1-3 млн. в неделю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 18:33 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Трудно сказать какая база НЕ сможет выдержать заявленные 3 транзакции в секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:01 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
2 стабильность Может он в одной транзакции тыщами/миллионами записей хочет ворочать? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:13 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
стабильностьТрудно сказать какая база НЕ сможет выдержать заявленные 3 транзакции в секунду. а с таким объемом данных MS SQL не загнется через год два??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:39 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
ПодрывУстоев а с таким объемом данных MS SQL не загнется через год два??? У меня справляется, и очень неплохо. Но для того чтобы справлялся, нужно хорошенько продумать структуры базы. Вероятнее всего, потребуется архивирование данных - перенос данных в архивные таблицы/оффлайн БД, и т.п. Если есть возможность архивирования - то все просто, я бы предположил что обычный двухпроцессорный сервер может потянуть всю эту нагрузку, если OLTP транзакции. Иначе - тоже выдержит, но железо нужно куда более дорогое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:46 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
сама структура БД будет небольшая около 10-15 таблиц. Допустим есть 2хпроцессорный хороший сервер, достаточно места и памяти. какова будет скорость для 2000 клиентов онлайн? к концу года ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:52 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Или скажем такую базу разделить на 2 базы. 2000 чел будут работать только со своим участком а чел 10-15 из администрации с другой куда все будет сливаться, так получится и рабочая база меньше и для аналитики база не будет сильно занята? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 19:56 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
ПодрывУстоевсама структура БД будет небольшая около 10-15 таблиц. Допустим есть 2хпроцессорный хороший сервер, достаточно места и памяти. какова будет скорость для 2000 клиентов онлайн? к концу года Все равно не угадаешь! Небольшая, хороший, достаточно - этих даных слишком мало, чтобы выдать скорость! Сколько данных в базе? Сколько выбирается данных средним запросов? Какова сложность среднего запроса? 2000 клиентов вообще или одномоментно? Каково распределение всего перечисленного по времени суток и дням недели? а то, может, у тебя 3 млн. запросов придут за пять минут, а остальную неделю простой будет... И даже после того, как ответишь на эти вопросы, останется много неясного... Имхо, здесь только один путь - сечас ставить условно хороший сервер и, по мере роста нагрузки, прогнозировать насколько его хватит и какой сервер будет при плановой нагрузке. Не забудь после этой экстраполяции сделать запас по производительности сервера, как минимум, втрое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 20:07 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
miksoftИмхо, здесь только один путь - сечас ставить условно хороший сервер и, по мере роста нагрузки, прогнозировать насколько его хватит и какой сервер будет при плановой нагрузке. Не забудь после этой экстраполяции сделать запас по производительности сервера, как минимум, втрое. Такой путь выбирается только при низкой квалификации DBA. Если есть нормальное ТЗ и требования к производительности, то, после создания физической модели, можно с хорошей точностью оценить требования к железу. Имеется множество статей, книг, топиков в Инете, посвященных как раз теме оценки необходимого железа. и влиянию различных факторов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 20:34 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
У меня не SQL, а прямой Cache, и архивировать ничего не нужно. Пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2006, 20:39 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
авторКакая база сможет выдержать около 2000 пользователей онлайн и транзакций где то 1-3 млн. в неделю. мне кажется, что начиная уже от 300 пользователей СУБД надо думать о трехзвенке. Потому что клиент-сервер на 2000 пользователей - это утопия. Тем более, что например линуксы в базовой конфигурации дадут только 600 одновременных коннектов. То есть, не всякая операционка без проблем потянет такое число одновременно активных коннектов (2000). p.s. А 1.5 миллионов транзакций в сутки - Firebird (или Interbase), без проблем, может и больше. И 400-600 пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 10:34 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
> после создания физической модели, можно с хорошей точностью > оценить требования к железу. Да ну? Методику - в студию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 10:47 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
> линуксы в базовой конфигурации дадут только 600 одновременных коннектов. Это как? Какие коннекты куда и почему только 600? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 10:48 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
andsm miksoft Такой путь выбирается только при низкой квалификации DBA. Если есть нормальное ТЗ и требования к производительности, то, после создания физической модели, можно с хорошей точностью оценить требования к железу. Имеется множество статей, книг, топиков в Инете, посвященных как раз теме оценки необходимого железа. и влиянию различных факторов ну а высокой у автора и не видно... не в обиду! да и с моделью пока не все ясно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 12:41 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
guest_20040621Это как? Какие коннекты куда и почему только 600? Не скажу за линуксы, но в Windows NT сокеты очень ресурсоемкие, и 2000 одновременных коннектов по TCP/IP - это реально очень много, хоть для RawIp, хоть для Afd. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 13:07 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
> 2000 одновременных коннектов по TCP/IP - это реально очень много Пул коннектов отменили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 13:27 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
guest_20040621> 2000 одновременных коннектов по TCP/IP - это реально очень много Пул коннектов отменили? а в TCP/IP бывает пул коннектов??? ссылочку на доку или стандарт можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 13:41 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
У моего клиента 600 одновременных сессий, каждая сессия открывает по три коннекта (открывала, пофиксили давно в коде, но клиент пока не мигрировал на новую версию). Итого - примерно 1800 физических коннектов к ораклу 8.1.7 Железо - какой-то DELL с двумя XEONами образца 2000 года на Windows NT 4.0. Памяти у них 3.6 Гига. Типичное OLTP + OLAP. Средняя активность сессий 5-10% Оракл работает в режиме MTS - клиент совершенно счастлив. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2006, 22:57 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
kdvмне кажется, что начиная уже от 300 пользователей СУБД надо думать о трехзвенке. Потому что клиент-сервер на 2000 пользователей - это утопия. Да бросьте. Это утверждение чисто технологически не имеет шанса быть верным. Вы говорите: ни один СЕРВЕР не потянет, поэтому надо ставить СЕРВЕР, который потянет. Получается утверждение с внутренним противоречием. Можно говорить о том, сколько железа надо конкретной БД для скольких пользователей конкретной задачи. Но и только... например, достаточно сильные ребята однажды сказали мне: думаем о трехзвенке, потому что на наших восьмидесяти пользователях MSSQL уже скрипит. Но согласитесь: это нисколько не повод заявлять, что любому проекту с сотней пользователей пора думать о трехзвенке. kdvТем более, что например линуксы в базовой конфигурации дадут только 600 одновременных коннектов. Хм. Можете пояснить, что именно имеете в виду? Я не разбираюсь в линухах, поэтому интересно, что там за ограничение. kdvТо есть, не всякая операционка без проблем потянет такое число одновременно активных коннектов (2000). Хм. 1. Если не потянет такое количество коннектов к базе - с какой стати потянет такое количество коннектов к промежуточному звену? Там что, tcp другой? 2. Это повод ставить более другую операционку, не более того. А по сути - тысячу коннектов в dedicated я знаю, работало. Как раз на линухе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 00:57 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
kdv пишет: > мне кажется, что начиная уже от 300 пользователей СУБД надо думать о > трехзвенке. Или о другой СУБД :) > Потому что клиент-сервер на 2000 пользователей - это утопия. Почему? Скромный Sybase ASA, задвигаемый маркетологами в нишу "small workgroup server", тестировался на нагрузочную способность в ianywhere по заказу одного клиента еще в 2004 году по IBM-овским benchmark-тестам. - Продемонстрирована высокая производительность при 1300 активных коннектах к одной базе с 30 миллионами записей - Результаты превзошли требования теста на 18гб базе при 3900 коннектах (Это они обзывают small to medium sized business environments :) Первоисточник тут: http://www.ianywhere.com/press_releases/microdec_sqlany.html К сожалению, там не указано использовавшееся железо, ОС и спецификации тестов, но тем не менее... Можно, конечно, заявить что это рекламный буклетик, но про 300 пользователей, как повод добровольно создавать себе из ничего проблемы с трехзвенкой ты немного погорячился IMHO. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 01:33 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Для начала неплохо бы уточнить, что конкретно имел ввиду kdv, говоря "3-х звенка" - слишком много, что можно назвать 3-х звенкой, от веб-интерфейса до ОО мапинга. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 05:58 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Хм. Я воспринял письмо kdv как упоминание "настоящей" трехзвенки, а не того, что в принципе можно обозвать этим словом. Речь идет об изменении количества коннектов к базе, то есть как минимум о наличии диспетчера соединений, как минимум чего-то типа ораклового MTS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2006, 08:59 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
У меня 1000 пользователей и миллион транзакций в день - SQL работает без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 17:32 |
|
||
|
Кто знает какая база сможет выдержать ЭТО....
|
|||
|---|---|---|---|
|
#18+
Чего за железо. Какие транзации идут по 35 щтук в секунду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 18:16 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33613028&tid=1553605]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
29ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 268ms |
| total: | 384ms |

| 0 / 0 |
