Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
onstat-

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


Тут всё достаточно просто. Список, на самом деле, даже с бытовой точки зрения понять проще, чем дерево. Это же линейная вещь. И алгоритмы, соответственно, должны быть проще (сам их не пишу, но с точки зрения здравого смысла, наверное, так).

По каким критериям таблица(список) делятся между процессами
и сколько их будет тоже вопрос.


Таблица делится между всеми виртуальными процессами (VAMP - virtual access module process) путём хэширования значения индексной группы столбцов.
Количество VAMP задаётся при конфигурировании системы.
Например, у меня сейчас в наличии двухпроцессорная машина с десятью зеркальными парами, каждрй из которых занимается отдельный VAMP (то есть, их 10).
Соответственно, в моей конфигурации каждая таблица (обычная или индексная) распределяется путём хэширования между этими 10 единицами параллелизма.


Как блокируется таблица для многопользовательского доступа?


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


Как производится в ставка нового индексного значения?


Путём хэширования индексного столбца (столбцов) определяется на какой VAMP пойдёт эта запись. Дальше она туда шлётся и добавляется к индексной таблице.


Для меня пока вопросов больше чем ответов,
в первую очередь потому что это не логично.
Я конечно могу чего то недопонимать.


На самом деле всё довольно логично, если немного вникнуть.
Процитирую кусочек статьи, может, это поможет понять, что и как:

Структуры, используемые для индексирования
Первичный индекс (Primary index)
В СУБД Терадата имеется два типа первичных индексов: уникальный первичный индекс (Unique Primary Index) и неуникальный первичный индекс (Non Unique Primary Index). Как известно, индексы используются для быстрого извлечения строк из таблиц БД, при этом можно избежать полного сканированиявсей таблицы.

Первичный индекс в СУБД Терадата - это механизм, использующий алгоритм хэширования, для поставки каждой строки таблицы БД конкретному виртуальному процессору АМР, а также применяемый для быстрого извлечения строк. Это позволяет большинство операций с БД выполнять очень быстро. В любой таблице БД имеется уникальный или неуникальный первичный индекс. Далее, при доступе к строке по первичному индексу или при вставке строки, используя некий "зашитый" алгоритм хэширования, система прогоняет через него значение первичного индекса. На выходе получается некое число из 32-х бит (т.н. Row hash). Первые 16 бит, называемые hash bucket, определяют, к какому виртуальному процессору AMP пойдет вставляемая строка. Значение hash bucket варьируется от 0 до 65535. Данные значения равномерно распределены между всеми АМР в системе. Таким образом, каждый АМР знает, какие значения hash bucket к нему относятся.

Если все значения колонки первичного индекса уникальны или почти уникальны, то данные будут равномерно распределены между всеми АМР. Все, что требуется от администратора БД, - это правильно выбрать колонку (или колонки) под первичный индекс.

Существует два уровня индексирования хэш-кодов. Первый уровень хранится в памяти. Это гарантирует, что в наихудшем с точки зрения оптимизации случае, при обращении к одной строке потребуются всего две операции ввода/вывода. При кешировании ввода/вывода обеспечивается высокая вероятность того, что индекс второго уровня попадет в кеш-память, и что блок данных также окажется в памяти. Такой механизм хранения данных гарантирует, что при вставке или изменении строк не будут увеличиваться накладные расходы, связанные с выполнением этих операций (наличие хэш-цепочеки, block extensions и т.п.). Кроме того, работают специальные фоновые задачи, которые по мере необходимости устраняют фрагментацию.

Помимо возможности быстрого доступа к одной строке, хэшированные структуры сортируются по хэш-кодам и оптимизируются для использования алгоритмом Hash Merge Join. Если таблица соединяется по первичному индексу, то не требуется каких-либо действий для подготовки самой таблицы к этой операции - алгоритм соединения непосредственно считывает строки таблицы.

Вторичные индексы (Secondary index)
В СУБД Teradata используются два типа вторичных индексов: уникальные и неуникальные вторичные индексы. Данные в колонке (или в колонках), объявленных как вторичный индекс, поставляются в алгоритм хэширования. Получающийся на выходе Row Hash, указывает на строки в индексной подтаблице, в которой в свою очередь хранится индентификатор (Row ID) базовой строки. Таким образом, как и в случае первичных индексов, для быстрого поиска строк по вторичным индексам используется алгоритм хэширования.

Различие между уникальными и неуникальными вторичными индексами, в общем заключатся в том, что строки уникальных вторичных индексов глобально распределены между всеми АМР и извлекаются по тому же принципу, что и строки по первичному индексу. В этом случае как правило задействуются 2 виртуальных процессора АМР, так как строка базовой таблицы принадлежит одному АМР, а строка индексной подтаблицы другому АМР. В случае неуникальных вторичных индексов, строки индексной подтаблицы и соответствующие строки базовой таблицы принадлежат одному АМР. Таким образом, при доступе к строке по неуникальному вторичному индексу, всем АМР системы посылается сообщение-запрос о наличии строк в индексной подтаблице с заданным значением. Если АМР не имеет таких строк в индексной подтаблице, то в базовую таблицу он не пойдет.




С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 17:59    [895156]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
Нода не нужна. А то что она в базу писала нужно и как ты это вытащишь что закомичено что нужно откатить, если ты не хочешь получить нецелостные данные.
Нужно делать RECOVERY черным по белому написано в документации.


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

автор
Опять же есть Mutual takeover. Когда рабочие ноды могут взять ноды с упавшей машины, с понижением производительности.


сколько этот процесс ("взять") занимет времени ?
19 авг 04, 18:10    [895188]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Константин согласись что большой недостаток Teradata это железо производства только NCR, кстати почему у них все время количество процессоров в узле уменьшается в 3600 помоему 16 было, а сейчас в 5300 2 кажется??? SMP на 4 процессорах не плохо смотрится.


Не соглашусь. Универсальность всегда означает снижение производительности. Терадата досконально "знает" на какой железке она работает. Она знает скорость процессоров, скорость обмена данными с дисками, скорость интерконнекта, количество единиц параллелизма и учитывает эту информацию при оптимизации запросов. Поэтому и достигает такой высокой производительности.
Не уверен, что остальные СУБД учитывают параметры конкретной железяки.
А разве DB2 работает производительнее всего не на платформе DB2?


3600 - сильно. Это довольно древняя машина. В 5100 ещё было по 16 процессоров в узле. Последняя модель - не 5300, а 5380, но в нём тоже два проца на узел.
Ответ довольно очевиден - SMP, как ты правильно заметил, нормально масштабируется только до четырёх процессоров. Почему два - не знаю. Но, наверное, умные инженеры из Teradata делали соответствующие расчёты, которые показали, что это более оптимальный вариант. Может быть, гипертрединг как-то влияет на это решение. Не могу сказать.
Ты же знаешь, наверное такую компанию Netezza. Они вон однопроцессорные ноды ваяют, вроде бы. Кстати, на процессорах IBM, по-моему. Тоже, чвои причины на это имеют.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 18:17    [895214]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
А разве DB2 работает производительнее всего не на платформе DB2?

Читать

А разве DB2 работает производительнее всего не на платформе IBM?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 18:26    [895229]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Nikolay Kulikov
Константин согласись что большой недостаток Teradata это железо производства только NCR, кстати почему у них все время количество процессоров в узле уменьшается в 3600 помоему 16 было, а сейчас в 5300 2 кажется??? SMP на 4 процессорах не плохо смотрится.
Поддерживаю. Своя СУБД на своих же серверах - не это ли причина малой распростаненности Терадата?
19 авг 04, 18:26    [895231]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
Не соглашусь. Универсальность всегда означает снижение производительности. Терадата досконально "знает" на какой железке она работает. Она знает скорость процессоров, скорость обмена данными с дисками, скорость интерконнекта, количество единиц параллелизма и учитывает эту информацию при оптимизации запросов. Поэтому и достигает такой высокой производительности.
Не уверен, что остальные СУБД учитывают параметры конкретной железяки.
А разве DB2 работает производительнее всего не на платформе DB2?
Константин, согласитесь, что когда вендор "привязывает" к себе клиента и по железу, и по софту, это мало кому нравится. Ведь далее появляется возможность диктовать цены и т.д...
19 авг 04, 18:39    [895268]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
А разве DB2 работает производительнее всего не на платформе IBM?
Думаю, что производительнее всего работает там, где умные DBA ее лучше настраивать и юзать умеют :-) ...
19 авг 04, 18:46    [895283]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2 Константин Лисянский:

Db2 хорошо работает и на не IBM.
1 место TPC-C price/perfomance - DB2 Linux на железке от HP.
2 место 100GB TPC-H - DB2 Windows на каких-то китайцах.
19 авг 04, 18:52    [895303]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Поддерживаю. Своя СУБД на своих же серверах - не это ли причина малой распростаненности Терадата?


Сергей, ещё раз повторюсь - среди клиентов Teradata 200 компаний имеют хранилище данных свыше 1 терабайта. Мы именно такие объёмы здесь и обсуждаем, не так ли?
Найдите мне другого производителя, у которого столько же клиентов с такими хранилищами. И мы уже будем говорить о том, что Oracle - не такая распространённая система или DB2. И тот факт, что порядка 150 компаний перешли с Oracle на Терадату тоже должен о чём-то говорить, не так ли?

Ещё раз - Терадата имеет очень конкретное позиционирование - корпоративные хранилища данных большого объёма. И там Терадату побить очень сложно. Что подтверждает практика и согласуется с мнениями аналитиков.


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


Где-то прочитал (сейчас ссылки нет под рукой, поверьте на слово, пожалуйста, я вроде бы не давал пока повода не верить мне), что у Терадаты наиболее лояльная клиентская база, что подтверждает тот факт, что Терадата клиентам нравится.

В конце концов, клиент получает законченное решение, которое:
1. Высокопроизводительно
2. Легко масштабируется
3. Отказоустойчиво
4. Просто в администрировании

Что ещё нужно?



С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 19:01    [895329]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Константин,

1. Высокопроизводительно
2. Легко масштабируется
3. Отказоустойчиво
4. Просто в администрировании

Я это и про DB2 сказать могу. И добавить дешевле чем Тeradata. Oracle и DB2 можно оценить по официальным сайтам, где на Teradata примерный price list. Не является ли его отсутсвие политикой давления на текущих заказчиков???

P.S. Надо заканчивать эту лавочку иначе опять свалимся во flame
19 авг 04, 19:10    [895356]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Nikolay Kulikov
P.S. Надо заканчивать эту лавочку иначе опять свалимся во flame
Угу, согласен. Когда на www.tpc.org в top 10 по TPC-H появится хоть один FDR-отчет по Терадата, можно будет говорить конкретнее...
19 авг 04, 19:19    [895374]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
автор

автор

Нода не нужна. А то что она в базу писала нужно и как ты это вытащишь что закомичено что нужно откатить, если ты не хочешь получить нецелостные данные.
Нужно делать RECOVERY черным по белому написано в документации.

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

Просто в БД ничего не бывает. Ты утверждаешь что после синхронизации GCS выжившие узлы стразу начинают работать и в параллель запусается процесс востановления.
Расскажи что будет если измененную страницу прочитает раньше не процесс восстановления, а обычная транзакция. И что будет в другом случае когда транзакция зафиксированна на умершем узле, а данные еще не в файлах БД, они в журналах.

автор

автор

Опять же есть Mutual takeover. Когда рабочие ноды могут взять ноды с упавшей машины, с понижением производительности.


сколько этот процесс ("взять") занимет времени ?


Я привел данные меньше минуты.
19 авг 04, 19:24    [895383]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Николай
И добавить дешевле чем Тeradata


Наколай, ты не знаешь цен на Терадата в России и Украине.
Поэтому лучше не надо так.
Потому что это не факт.

Сергей
Угу, согласен. Когда на www.tpc.org в top 10 по TPC-H появится хоть один FDR-отчет по Терадата, можно будет говорить конкретнее...


Гораздо эффективнее custom benchmark на данных клиента, поскольку все тесты TPC заранее известны и к ним легко подготовится. Это никакой не ad-hoc, а заранее известный набор запросов.

Ещё раз повторюсь - если у Вас серьёзные намерения выбрать подходящую платформу - организуйте официальный тендер. Можно с бенчмарком.

Наколай прав - лавочку надо закрывать. Флейм неизбежен ...

Лучше давайте обсуждать технические вопросы. Я готов отвечать на вопросы по Терадате.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 19:47    [895431]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Сергей Тихонов
Nikolay Kulikov
P.S. Надо заканчивать эту лавочку иначе опять свалимся во flame
Угу, согласен. Когда на www.tpc.org в top 10 по TPC-H появится хоть один FDR-отчет по Терадата, можно будет говорить конкретнее...


Oго... они же были там больше года? 1 место на 10 Тб.

Незнание - не сила. Сам предпочитаю IQ, нo TD оцень достойный соперник.
19 авг 04, 19:48    [895434]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Сам предпочитаю IQ, нo TD оцень достойный соперник.


Ещё бы :)
Много раз удавалось TD побить?


А "от туда..." это откуда, если не секрет? Вроде бы где-то видел, что не Sybase. Но, я так понимаю, что близко где-то?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 19:56    [895447]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
_Dog
Oго... они же были там больше года? 1 место на 10 Тб.

Незнание - не сила. Сам предпочитаю IQ, нo TD оцень достойный соперник.

Покажите мне, где тут Терадата?
19 авг 04, 20:00    [895452]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Teradata заявила что TPC-H это слишком просто и сняла результаты.
Константин, я как-то беседовал с одним консультантом в Англии по поводу Teradata года два назад. И он жаловался на то что если ты грузишь данные в БД на низком уровне то нужно дропать-пересоздавать Join Indexes (MQT, MaterializedView) в новой версии не поменялось???
19 авг 04, 20:07    [895466]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Teradata заявила что TPC-H это слишком просто и сняла результаты


TPC-H Benchmark:
8 таблиц
В данных отсутствует перекос
9 одновременных пользователейц на системе в 10 ТБайт

Реальные системы (WalMart и SBC) я описал выше.

Для примера ещё раз:
SBC - более 12 800 таблиц.
Сотни тысяч запросов в день.

Для бенчмарка у Терадаты существует лаборатория, где в год проводится порядка 80 бенчмарк-тестов на реальных данных клиентов. Если есть такое жаление - могу посодействовать в организации такого бенчмарка.
Гораздо эффективнее куцых тестов на 8 таблицах.

Деньги, сэкономленные на (недешёвых) тестах TPC Терадата вкладывает в R&D.
Видимо, другие компании могут себе позволить выбрасывать миллионы на эти тесты, Терадата использует средства более эффективно.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 20:41    [895501]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Константин, я как-то беседовал с одним консультантом в Англии по поводу Teradata года два назад. И он жаловался на то что если ты грузишь данные в БД на низком уровне то нужно дропать-пересоздавать Join Indexes (MQT, MaterializedView) в новой версии не поменялось?


В Терадате есть несколько утилит загрузки данных. Самая быстрая - Fastload, действительно, накладывает ограничение на наличие индексов. Если есть необходимость грузить в таблицы с индексами, можно это делать разными способами. Иногда, действительно, лучше подропать индексы и пересоздать после загрузки. Всё зависит от количества загружаемых данных.

Можно, вообще, утилитой TPump в режиме on-line данные грузить.

Что делает возможным посроение активного хранилища данных.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 20:44    [895508]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Константин,

TPC - это правила игры. Да он не оптимален, но дает хоть какое-то представление о системах и БД.

Ну я тоже могу закинуть 10 инсталяций DB2 больше 20ТБ c туевой хучей конкурентных пользователей и запросами такими что 5 терабайт во временном пространсве мало :). Это не показатель.
И там будет и telco и retail, но это опять все маркетинг.

А по поводу техники в DB2 можно на низком уровне грузить данные без пересоздания MQT (Join Indexes) в online :)
19 авг 04, 21:04    [895535]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
.[/quot]Много раз удавалось TD побить? .[/quot]

:) самому - нет. Просто не так часто встречаемся :)

Но как говорят, у приятеля моего приятеля есть знакомый ... в общем 2 недавних европейских случая знаю, телко и банк (Ето не означает, что их всего 2 и есть :) - насколько я знаю, на некоторых рынках ТД/Сайбейс - 50:50.

По идее, не думаю, что сама по себе ТД база часто встречается отдельно от ЕDW oт ТД. Или я неправ?

По крайней мере, там где я сам встречался с ТД, речь шла не о самой базе, а о ЕDW модели данных, которая DB independent (как и Сайбейсовский IWS) - т.е. может стоять на Оракле, ИБМ, да и на том же IQ. Но ето отдельный разговор.

Посмотреть изнутри - хотелось бы, надеюсь еще увижу/встречусь а то и поработаю :) Интерестная компания, интерестная философия продаж, интерестные теоретики - большой challenge выиграть в равной борьбе.

BusinessIntelligence - одна из тем которой интересуется моя компания.

Ладно, все, кончаю флейм. Сорри.
19 авг 04, 21:23    [895557]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Nikolay Kulikov

TPC - это правила игры. Да он не оптимален, но дает хоть какое-то представление о системах и БД.


Пилотный проект дает еще лутшее представление. Посмотрите tcp-c - MS forever? :)
19 авг 04, 21:40    [895585]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Смотрите внимательнее...
В пилотном проекте очень часто бывает NDA.
19 авг 04, 22:18    [895620]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Nikolay Kulikov
Смотрите внимательнее...
В пилотном проекте очень часто бывает NDA.

Нус, всегда бывает. Вы правы. Но победитеь тендера нередко получает право на public Success Story.
19 авг 04, 22:52    [895649]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Nikolay Kulikov
Смотрите внимательнее...
В пилотном проекте очень часто бывает NDA.


аааа, посмотрел внимательнее, действительно, ИБМ появился. Ура, не люблю монополистов :)!
19 авг 04, 22:57    [895651]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 10 [11] 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить