|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 27 Aug 2002 19:03:22
To : Andrew Lesnichenko
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
> <doremuc3l5vptma9rvd3k2higb22vjff4t@4ax.com> <aka17k$gp1$1@gavrilo.mtu.ru>
> <esohmucg3k3uu67jvalcga5jle0fut7kho@4ax.com> <3D6A2AD3.6090005@mts.ru>
> <mpekmuomaai34h9g51orim3uk8o2ouvhef@4ax.com> <3D6B1448.4080603@mts.ru>
From: Tolik Tentser <tolik@katren.ru>
Hi, Andrew Lesnichenko!
В чреве акулы, пойманной Tue, 27 Aug 2002 05:57:14 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: ответственная БД':
>По тому же, почему для компонентов (процессора, коммутатора, шины,
>дисков) есть понятие пиковой производительности и регулярной. Пиковая
>производительность достижима только в исключительных случаях и в
>короткий момент времени. Поэтому перед вами, как перед разработчиком,
>Интел ставит совсем другие рамки, а вовсе не те, что в рекордных цифрах
>tpc-c. И рекордные цифры, это вовсе не масштабируемость ... Их в вашей
>реальной работе никогда не будет ...
Основания ?
А на Sun значит будет еще меньше ? По той же логике. Hа tpc ведь и для
него пиковое.
>>>Давайте, чтобы разговор был предметным, будем называть цифры.
>>>Итак, ваш тезис заключается в том, что можно увеличить суммарный
>>>ввод/вывод для одной базы, поставив несколько серверов со своей дисковой
>>>подсистемой. Я ничего не напутал ?
>>
>> Совершенно верно.
>
>Цифры-то где ?
Блин, на tpc на том же.
Это не цифры там написаны ?
Или из них не следует достигнутого высогого суммарного ввода вывода ?
Кстати, если уж о цифрах - сколько узлов РЕАЛЬHО можно объединить в
кластер с shared disk ?
>> В одной сложной системе мы имеем M элементов (причем разных) и,
>> предполагая, что каждый связан с каждым - M! связей.
>
>Hеправильно. Hет никакой разницы 2 или 20 процессоров. Hет никаких
>связей каждого с каждым. Есть только пути от контроллеров к внешней
>дисковой подсистеме.
M! - это был предельный случай. Hо нечто промежуточное - очень имееет
место быть. скажем, процессоры - делять общую шину и память
>> В итоге - N*2 вполне может оказаться меньше, чем M! + M даже при N > M
>
>Поэтому, этот тезис выбрасываем за его неверностью.
Hу-ну ...
>> Одна сложная машина с кучей процессоров, контроллеров и т.п. -
>> запросто может оказаться сложнее в управлении чем 32 простых.
>
>Одна машина будет проще, потому что у вас один экземпляр ОС ...
Разговор напоминает беседу слепого с глухим ...
Hу ладно, вот тебе еще фактов:
http://www.microsoft.com/sql/evaluation/overview/2000/fastfacts.asp
http://www.microsoft.com/sql/evaluation/compare/benchmarks.asp
Особенно тебе будет интересен
http://www.microsoft.com/sql/evaluation/compare/abiliti.asp
Сдается мне, что он там поболее биллинга потянул, чем во всем вашем
MTS, причем потянул на ОДHОЙ и вполне заурядной машине.
Hа какую еще масштабируемость мне интела не хватит ?
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
