|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Andrew Lesnichenko 2:5020/400 27 Aug 2002 09:57:14
To : Tolik Tentser
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
Tolik Tentser wrote:
> Hi, Andrew Lesnichenko!
>
>>- Если MS на тестах показал производительность ххх ххх tpc-c per min,
>>это не значит, что и вы на своей задаче добъетесь того же. Аналогично и
>>с Sun, IBM и пр..
>
> Разумеется. Это лишь показывает пиковую производительность (читай -
> масштабируемость) платформы. О чем мы и говорим. Мы же не
> масштабируемость 1С обсуждаем, а какие рамки, скажем Интел ставит
> передо мной, как перед разработчиком.
>>Я хорошо отношусь к этому тесту, если его результаты корректно
>>используются. Результаты же, показанные MS (в смысле абсолютной цифры)
>>настолько неприменимы для обоснования производительности MSSQL на
>>реальных задачах, как и результаты теста Linpack ...
>
> Почему ?
По тому же, почему для компонентов (процессора, коммутатора, шины,
дисков) есть понятие пиковой производительности и регулярной. Пиковая
производительность достижима только в исключительных случаях и в
короткий момент времени. Поэтому перед вами, как перед разработчиком,
Интел ставит совсем другие рамки, а вовсе не те, что в рекордных цифрах
tpc-c. И рекордные цифры, это вовсе не масштабируемость ... Их в вашей
реальной работе никогда не будет ...
>>Давайте, чтобы разговор был предметным, будем называть цифры.
>>Итак, ваш тезис заключается в том, что можно увеличить суммарный
>>ввод/вывод для одной базы, поставив несколько серверов со своей дисковой
>>подсистемой. Я ничего не напутал ?
>
> Совершенно верно.
Цифры-то где ?
>>>>>Hет, не обязательно. Иногда совокупностью ПРОСТЫХ объектов управлять
>>>>>проще, чем одним СЛОЖHЫМ. А стоит кластер из простых компьютеров часто
>>>>>HАМHОГО меньше одного большого.
>>>>
>>Только в том случае, если этих ПРОСТЫХ объектов окажется мало. Скажем,
>>два-три. Если вам придется следить за несколькими десятками, это будет
>>сложнее.
>
> Остается обратиться к теории управления, гласящей, что сложность
> системы определяется не только количеством компонентов, но и:
>
> - их разнообразием
> - количеством связей между ними
>
> В системах из множества простых компьютеров мы имеем много простых
> одинаковых элементов, каждвй из которых связан лишь с главным и
> независим от остальных. Т.е. грубо говоря - N элементов и N связей
>
> В одной сложной системе мы имеем M элементов (причем разных) и,
> предполагая, что каждый связан с каждым - M! связей.
Hеправильно. Hет никакой разницы 2 или 20 процессоров. Hет никаких
связей каждого с каждым. Есть только пути от контроллеров к внешней
дисковой подсистеме.
> В итоге - N*2 вполне может оказаться меньше, чем M! + M даже при N > M
Поэтому, этот тезис выбрасываем за его неверностью.
> Одна сложная машина с кучей процессоров, контроллеров и т.п. -
> запросто может оказаться сложнее в управлении чем 32 простых.
Одна машина будет проще, потому что у вас один экземпляр ОС (со всеми ее
настройками), один экземпляр программы (в смысле СУБД), один экземпляр
данных со всеми вытекающими последствиями в виде backup'а и пр.. В
случае консолидированного хранения (на выделенной дисковой системе)
проще и экономичнее делать защиту от отказов (на уровне storage'а),
перераспределять дисковое пространство, делать backup и пр..
--
Andrew Lesnichenko
--- ifmail v.2.15dev5
* Origin: Mobile TeleSystems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
