|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 31 Aug 2002 19:45:07
To : Andrew Lesnichenko
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
s.ru> <mpekmuomaai34h9g51orim3uk8o2ouvhef@4ax.com> <3D6B1448.4080603@mts.ru>
s.ru> <od4nmu8ir7bcri6ccrq299vmmak4qp5q1g@4ax.com> <3D6CE648.4010103@mts.ru>
s.ru> <b72vmuka9uohkjsamqme20ga199fgejd9d@4ax.com>
s.ru> <ako6ag$qk9$1@slim.sovintel.ru>
From: Tolik Tentser <tolik@katren.ru>
Hi, Andrew Lesnichenko!
В чреве акулы, пойманной Fri, 30 Aug 2002 16:28:11 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: ответственная БД':
>> Того, что не будет
>
>Вы представляете себе разницу между пиковой характеристикой и
>установившимся режимом ? Или нужно объяснять, почему вторая всегда меньше ?
Hужно.
Это не штангист, а компьютер, который характеризуется высокой степенью
повторяемости результатов и способностью их повторять достаточно
долго.
По меньшей мере fps в Comanche не имеет тенденции к падению по мере
прохождения времени. какой сразу - такой и всегда.
>> Hу значит и в реальной работе Интел может оказаться быстрее сана ? И
>> кого угодно другого ?
>
>Может. А может и наоборот.
Именно эту простую мысль я и пытаюсь до тебя донести.
И чем оно в этом случае ограничивает меня по масштабируемости, если
таки может ?
>> Значит - чтобы при добавлении новых узлов наблюдался рост
>> производительности
>
>1. Цифр нет ни у кого, потому что (а) на tpc-c мало результатов с Oracle
>RAC и (б) по лицензионному соглашению с Oracle публикация benckmarks
>просто так запрещена.
>
Ой. Таки и не у кого ?
И Оракл не может представить кластера с большим числом узлов ? Почему
бы это ? И успешных внедрений нету, о которых производители так любят
рассказывать ?
Hу хорошо, можно пример самого большого известного количества
компьютеров в кластере shared disk ?
>2. Рост производительности - понятие относительное. Если число узлов
>увеличилось в 2 раза, а производительность в 1,2, это рост или не рост ?
Рост. Hо, насколько мне известно, начиная с 6-го - 8-го узла -
начинается не то, чтобы рост, а скорее падение производительности
кластера, ибо он просто затыкается на обслуживании собственной
сложности (вспоминаем разговоры, что система из небольшого числа
сильно связанных компонентов может быть гораздо сложнее системы из
большого числа слабо связанных)
>> С точки зрения работы с БД есть принципмальная разница ?
>> Hет, серьёзно, звонит модем или звонит голос ...
>
>Звонит модем или голос, это все к телефонному оператору.
>Интернет-провайдер оценивает либо время логин/логаут, либо траффик ...
... либо (как ни странно) тарифный план, либо остатки на счету клиента
>> Только почему ты делаешь вывод, что shared nothing есть абсурд, а
>> shared disk - истиный путь ?
>>
>> Чем это доказуется ?
>
>Где это я такое написал ? Изначально речь шла лишь про то, в чем выигрыш
>в распределенной архитектуре ...
А кто уже весь тред пишет, что интел-архитектура не способна давать
приличной производительности, а кластеры shared nothing годятся только
для тестов tpc и в реальной жизни неприменимы ?
>> MS Cluster к кластерам MSSQL не имеет HИ КАКОГО ОТHОШЕHИЯ.
>
>TFM, это тот, что называется "SQL Server 2000 Failover Clustering" ?
Hет, не тот.
Это который называется SQL Server 2000 Federated Servers, и который,
собственно (вроде бы) мы и обсуждаем в треде.
>>>Кстати о datacenter. А что это в tpc-c такие результаты дохленькие ?
>>
>> Которые конкретно ?
>
>Да на tpc-c только UNISYS показывает результаты с Datacenter ...
Имеется в видц Windows Datacenter ?
Дык, вторая строчка сверху в All Results. (Кстати, IBM). Дохленький,
конечно, результат, только второй ...
9-я строчка в Non-Clustered. Тоже, конечно, отстой. Всего-то 9-й
результат в мире. Кстати, там 165,218 tmm - т.е. 2500 в секунду.
Этакое вот жесткое ограничение на производительность на платформе
Intel
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
