|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 06 Sep 2002 19:05:22
To : Edward Shevtsov
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
gf1cctce@4ax.com> <al5cum$2mhp$1@serv2.vsi.ru>
<murenu8bjkhm91mbm1is8d2dcpub5ldj92@4ax.com> <al8210$k0o$1@serv2.vsi.ru>
From: Tolik Tentser <tolik@katren.ru>
Hi, Edward Shevtsov!
В чреве акулы, пойманной Thu, 5 Sep 2002 16:51:51 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: ответственная БД':
>> Если факты мешают теории - тем хуже для фактов ?
>>
>Hепрошибаемый ты наш ... ответь аргументировано на эти простые практические
>вопросы. Если "Hет", то почему
>Подавляющее большинство таблиц будут лежать на главном ноде, поскольку сложно
>найти критерий, по которому можно эффективно делить таблицы.
Hет. Потому, что:
- бывает много справочных, редко изменяемых и относительно небольших
таблиц. Их можно держать на каждой ноде и обновлять при обновлении на
главной одной распределенной транзакцией (на главной их может
представлять, например VIEW с триггером INSTEAD OF UPDATE, который все
сделает)
- бывает много таблиц, доступ к которым нужен редко - их можно держать
и на главной, они мало что определяют.
- некоторые таблицы можно вообще убрать с главной на отдельную ноду
целиком (и пусть она только эту таблицу и лопатит)
- потенциально можно просто выделить каждой большой таблице свою
отдельную ноду (группу нод). Оптимизатор MSSQL неплохо
распараллеливает запросы - и выборка данных пойдет параллельно с
нескольких компьютеров, а потом они сольются на главной ноде (на
которой вообще может не быть физических таблиц (опс!))
Это только самые очевидные и простые пути оптимизации. Разумеется, все
это непросто, однако - неоднократно доказано, что грамотный ручной
тюнинг может делать чудеса (хотя и требует хорошего специалиста,
поскольку средний - обычно обглняется оптимизатором)
>А значит _всегда_ бОльший объем работы будет выполняться "главным" нодом.
Hет. По вышеприведенным причинам.
Разумеется, неудачное секционирование может запросто создать кучу
узких мест и в этом смысле кластер shared disk проще. Hо если уж
приспичило получить результаты на пределе возможностей системы - можно
и подумать, все одно - речь идет о решениях в миллионы баксов одного
железа.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
