|
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) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/2080976f6b82.html, оценка из 5, голосов 10
|