|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Andrew Lesnichenko 2:5020/400 26 Aug 2002 17:14:25
To : Tolik Tentser
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
s.ru> <71t9musmaikib2dv04tr30m76d4vf1eu8f@4ax.com> <3D65E5F0.4020309@mts.ru>
s.ru> <okicmus9k2kdfhnudnq1smujnse2sc40am@4ax.com> <3D6651A4.7010607@mts.ru>
s.ru> <ntkcmuo4g2tucldr28srbm8jj686kmpsln@4ax.com> <3D66590E.9080602@mts.ru>
s.ru> <doremuc3l5vptma9rvd3k2higb22vjff4t@4ax.com>
From: Andrew Lesnichenko <les@mts.ru>
Tolik Tentser wrote:
> Hi, Andrew Lesnichenko!
>
>>Видите ли ... как бы так, повежливее выразиться ... подобное чтение
>>задача дискового массива, а вовсе не хостов ... Размазываете свои данные
>>по дискам и не нужно огород городить ... И следить за расположением
>>данных задача не SQL-сервера, и даже не операционной системы ...
>
> У дискового массива тоже есть ограничения как на пропускную
> способность, так, равно, и на количество одновременно обрабатываемых
> запросов.
Давайте, чтобы разговор был предметным, будем называть цифры.
Итак, ваш тезис заключается в том, что можно увеличить суммарный
ввод/вывод для одной базы, поставив несколько серверов со своей дисковой
подсистемой. Я ничего не напутал ?
>>>>И кроме того, как мы выяснили, Микрософт кластеров делать не умеет :-).
>>>
>>>Ага, лучше всего об этом написано на www.tpc.org в разделе TPC-C -
>>>clustred
>>
>>Hу давайте еще тесты Linpack приведем в аргументирование скорости работы
>>базы данных. Этот тест настолько уже далек от реальных проблем ...
>
> Ты можешь предложить другой достаточно объективный и общепризнанный ?
> Кстати, твой любимый Оракл тоже там же играет.
Я хорошо отношусь к этому тесту, если его результаты корректно
используются. Результаты же, показанные MS (в смысле абсолютной цифры)
настолько неприменимы для обоснования производительности MSSQL на
реальных задачах, как и результаты теста Linpack ...
>>>>Обязательно. Управлять меньшим кол-вом объектов проще и вероятность
>>>>ошибки значительно ниже.
>>>
>>>Hет, не обязательно. Иногда совокупностью ПРОСТЫХ объектов управлять
>>>проще, чем одним СЛОЖHЫМ. А стоит кластер из простых компьютеров часто
>>>HАМHОГО меньше одного большого.
Только в том случае, если этих ПРОСТЫХ объектов окажется мало. Скажем,
два-три. Если вам придется следить за несколькими десятками, это будет
сложнее.
--
Andrew Lesnichenko
--- ifmail v.2.15dev5
* Origin: Mobile TeleSystems (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
