НиколайОтнюдь DB2 MPP конфигурации поддерживает на всех платформах
Win, Linux (x86,AMD,Power, Itanium), Sun, AIX, HP-UX

ОК.

Я не понимаю почему конкретные параметры железа нельзя учитывать на других платформах

Можно, только для этого код надо будет оптимизировать для каждого сочетания железяка/операционная система.

Всяко легче и более эффективнее писать под что-то одно.


Народ сейчас, похоже, заинтересовала другая тема - "Как вообще массивно-параллельные системы могут быстро работать"?
Видите, какое удивление в студии?



С уважением,
Константин Лисянский
http://lissianski.narod.ru

В современных узлах по 2 интеловских процессора. Раньше было больше.
Например, система 5100 имела узлы по 16 процессоров (Pentium Pro 200).

С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffТо, что они могут работать быстро - не странно. Странно что они могут работать быстро обрабатывая данные так, как вы рассказываеете. :)

Я вот по прежнему не могу понять почему для того чтобы обсчитать какой нибудь агрегат нельзя на каждом узле обсчитать его на основе тах данных, что есть на этом узле. А потом где то сложить промежуточные результаты и окончательно их досчитать.
Вместо этого предлагается сначала выбрать данные по определенному условию, затем взаимно перекачать между узлами, записать там на диски и потом только обсчитать агрегат уже по перегруппированным кускам данных. Вот в этом месте картинка как-то не складывается :)
Почему такая глобальная перекачака данных быстрее, чем выборка на каждому узле и пересылка результатов?

Я по-моему, уже приводил математические выкладки относительно распараллеливания.

Всё основывается на том, что операция сортировки выполняется за время, пропорциональное N*logN, где N- количество записей в таблице.
Операция же перераспределения данных абсолютно линейна, то есть пропорциональна количеству записей в таблице.

Соответственно, разбивая задачу на более мелкие кусочки мы выигрываем на нелинейной части.
Понятное дело, что существует N, при котором будет выгоднее сделать финальную обработку на одном узле, избегая перераспределения. Но это справедливо при небольших значениях N. Это, кстати показывают ребята в статье, ссылку на которую я привёл выше. Ещё раз рекомендую ознакомиться с ней. Это должно помочь снять некоторые вопросы.



С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffПо моему до меня дошло :) По крайней мере, я понял принцип.

Ура! Я объяснял, как мог. Сорри, что с первого раза не сумел.

BirkhoffВсе равно странно, что он работает, но это может быть в сиду непривычности идеи. :)

Сам удивляюсь :)

BirkhoffА вот когда происходят перераспределения данных между узлами - на каждый узел попадает копия данных, которая после отработки запроса удаляется? Или она там сохраняется?
Что произойдет если следующий пользователь захочет выполнить примерно такой же запрос?

Перераспределённая копия таблицы остаётся живой, пока в ней существует необходимость в пределах запроса (или группы запросов, если это multistatement request).

Для другого пользователя таблица будет перераспределяться заново. Ведь за время между двумя запросами она могла измениться, не так ли? Мы же много пользовательскую среду рассматриваем.


2 DimaR:
Я, честно говоря, немного не понял, что Вы хотели показать своим примером.
Поясните, пожалуйста.
Если Вы хотите показать, что для сортировки не используется диск, то попробуйте запустить с десяток таких запросов параллельно, как рекомендует Николай. Посмотрите, что у Вас получится, когда будут переключаться контексты между пользователями. Скорее всего, будет своп на диск в большом количестве. При этом свопится будет вся память процессов. При обратном переключении надо будет это всё опять с дисков читать в память.

В случае, если сортировка использует активно использует диски, в многопользовательской среде это будет работать лучше, поскольку операций чтения и записи будет выполняться меньше.

Это мои соображения. Возможно, я не прав. Если так, поправьте, пожалуйста.

DimaRНу что за аргументы, элементарным страйпингом добивается параллельная работа многих дисков, и что?

Данные мало размазать, их ещё надо параллельно обрабатывать.
Речь идёт о том, что данные должны быть привязаны к единицам параллелизма, а этого, на мой взгляд, простым страйпингом не добиться.

DimaRВопросы стоят о том как параллелятся задачи в террадате, особенно между большим количеством узлов.


Вроде бы, принцип я уже объяснял - равномерно размазываем каждую таблицу путём хэширования между всеми узлами. Чем больше узлов - тем быстрее работает система, поскольку кусочки таблиц, расположенные на каждом узле становятся меньше.

Мы уже обсудили тут и поняли, что распараллеливание позволяет быстрее выполнять операцию сортировки. Эта операция, кстати, является базовой для большинства алгоритмов обработки данных. Например, большинство алгоритмов джойнов основаны на предварительной сортировке данных.

Вот и всё. Остальное, в принципе, детали реализации. Которые, кстати, я готов тоже в меру своих возможностей описать.
Только просьба - задавайте вопросы немного поконкретнее.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffКонстантин,

Спасибо за объяснения.
А есть ли какая нибудь теория, когда внедрение Терадаты опроавдано?
Ведь сейчас уровень железа достиг таких высот, что на обычном 4х процессорном сервере с "обычным" дисковым массивом, большим объемом памяти и "обычной" реляционной базой можно крутить телекомовские объемы данных. А у обычных пользователей запросы и вовсе гораздо проще.
Не получается ли так, что закон Мура сводит на нет преимущества Терадаты в реальных проектах? Вернее сказать, то, что сферы применения найти можно я уверен, но может этих сфер становится меньше?

Внедрение Терадаты оправдано там, где нужно построить хранилище (витрину) данных для эффективной обработки больших объёмов данных, выполнения сложных аналитических запросов в многопользовательской среде, там, где требуется высокая надёжность и хорошая масштабируемость.
Любое более-менее серьёзное хранилище данных выдвигает все эти требования.

Терадата не работает с "необычными" дисковыми массивами. Это стандартные SCSI или FC дисковые массивы. Например EMC, или дисковые массивы NCR (OEM, производителя навскидку не вспомню).

Что такое "обычная" реляционная база данных? SQL стандарта ANSI 99, возможность подключиться по ODBC, JDBC, CLI. Всё это есть в Терадате. Это - обычная реляционная СУБД. Просто она затачивалась под определённые задачи.

Что касается телекомовских объёмов данных и четырёхпроцессорных систем - это, на мой взгляд заблуждение.
Терадатная система в Vodafon Germany весит под 100 тонн. Там что-то порядка 160 узлов. Систему активно используют порядка 4 тысяч пользователей. Сомневаюсь, что "обычная" СУБД на 4-процессорном сервере сможет это всё обрабатывать.

Закон Мура касается скорости процессоров. СУБД - системы, в основном, дисковые (а Терадата - тем более). Там закон Мура не действует (наверное, в силу наличия механических частей). Скорость работы дисков растёт не так стремительно.

Сфера применения Терадаты не только не сужается, но и расширяется.
Скорость роста количества данных на планете опережает темпы развития СУБД. Возьмите, например, технологию RFID. После её введения объёмы данных, генерируемые на всём пути прохождения товара от производителя до потребителя увеличатся, как минимум, на порядок.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

НиколайРеальные телекомовские объемы...

• Approximately 150 million Call Detail Records (CDRs) are loaded daily, and an equivalent number are deleted
• Rolling 60 days of CDR data
• 4.5 Billion transactions per day
• 7,000 customer care users
• Available 24x7x365, never have to REORG


Конфигурацию сервера не подскажете???? :)


А Вы это откуда взяли?



С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffКонечно если взять какой нибудь France Telecom или наш MTS тот же, там будут подобные объемы. Но и там Oracle стоит к примеру. Справляется.

По поводу справляется во Франс Телеком - Вы знаете с чем справляется?


С уважением,
Константин Лисянский
http://lissianski.narod.ru

BirkhoffИ вот еще вопрос.
Если принять во внимание что разослать по ущлам данные и потом пересичтать будет быстрее, чем пересчитать на каждом узле без пересылки, какое результируещее время отлика?
Какой порядок кремени отработки средних запросов? Секунды? Десятки секунд? Минуты? Десятки минут?

Ещё разок взгляните на свой вопрос. Не кажется, что на него мне трудно будет ответить.
На этом форуме, есть только один человек, у которого все запросы за 5 секунд выполняются.

Сами понимаете, всё зависит от того, какие запросы. Например, тактические запросы могут выполняться за доли секунды. Это небольшие запросы типа OLTP, но поступающие в большом количестве.
Бывают сложные запросы, которые могут выполняться минуты, десятки минут и часы.
"Средний запрос" трудно себе представить.
Не пинайте сильно, не смогу на этот вопрос ответить достоверно.


С уважением,
Константин Лисянский
http://lissianski.narod.ru