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

Откуда: Москва
Сообщений: 607
Мой собственный опыт. Если залезешь и посмотришь в мой профайл то поймешь что я в IBM и работаю, только не в отделе маркетинга :)

И самая большая жопа в HA это определение того что другой узел точно умер.
У тебя что shared disk что shared nothing должны это определять. Потому как тебе полюбому надо делать recovery, что делала умершая нода можно понять только по log'am для приведения БД в consistent state. Не знаю как в 10-ке в 9-ке точно надо было читать REDO logs.
19 авг 04, 11:29    [893124]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
т.е. вы сертифицированый oracle DBA ? ;)

если я правильно понял вы пытаетеcь убедить что откат транзакций упавшей оракловой ноды сопастовим с полного востановлением инстанса ноды дб2 ? оракловый RAC переживет потерб бойца, а shared-nothing обязан востановить ноду.
19 авг 04, 11:39    [893179]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
EugeneS


Я вот недавно с одним знакомым общался , у него были проблемы на win32 платформа с Oracle тоже.
Проблема выглядит примерно так.
Поскольку реализация Oracle под Windows мультитредовая , а не мультизадачная как в Unix-like cистемах,то Oracle под Windows -это один процесс , который не может адресовать больше чем 4GB памяти, пользовательские сессии - это треды внутри этого процесса, следовательно число сессий ограничено таки 4GB.
В Unix же пользовательский серверный процесс - у каждого свой ( в Dedicated mode ) и каждый процесс может адресовать 4GB памяти.
Собственно это и есть причина почему 32 разрядность не так давит в Unix-like системах.
Но однозначно для вас 64-bit система - это решение.


Теоретически это возможно,
но процессам нужно обмениваться информацией это возможно
1.через разделяемую памаять
2. pipe
3.диск. (это не рассматриваем).

Прикиньте производительность вашей сесии и всего oracle
если он таблицу, индексы начнет тащить через pipe.
Мы кажется вопросы двойной буферизации уже обсуждали.
и продолжать думаю не стоит.
То есть используется доступ через разделяемую память и семафоры.
Системные вызовы shm* всеравно ограничены разрядностью платформы.
Так, что глобально это ничего не решает.

с уважением, onstat-

ps я тоже unix люблю больше.
19 авг 04, 12:34    [893504]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
nkulikov
Guest
Я не сертифицированный но документации и материалов читаю много. В том числе и по Oracle :)

Расскажи как будет переживать потерю бойца RAC? Что он будет делать со страницами которые изменил где-то в БД упавший узел?? Eму совсем не надо делать восстановление??? Если да - за счет чего это достигается опиши механизмы????
19 авг 04, 12:41    [893545]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Что значит подавляющее? значит есть есть версия терадаты 64 бит.
Я обращаю ваше внимание на 64 разрядное приложение, а не возможность работать 32 разрдному серверу терадаты на 64 разрядной платформе.
А это очень большая разница.


Teradata Database Version 2 Release 5.1 for 32-bit W2K and MP-RAS and 64-bit HP-UX and WS03.


Память очень даже причем, если у вас на индексные деревья
нехватает памяти о чем можно дальше говорить. А на join-ах >100 милионных
таблиц вы обязательно с этим столкнетесь.


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

По поводу джойнов 100-миллионных таблиц. В Терадате есть алгоритм nonsort-merge join, который не требует предварительной сортировки (поскольку данные всегда хранятся отсортированными по значению хэш-значения), поэтому память для сортировки не нужна.

Кстати, в соседнем форуме я приводил результаты своих упражнений с таблицами с более 100 млн записей.
Почитайте здесь, может будет интереснро.


Если мы говорим о паралелизме, то лучше RISK платформы я не знаю.
Там паралелизм заложен аппаратно.

Здесь, мне кажется, Вы слишком низко опускаетесь. Кроме аппаратного параллелизма должен ещё быть программный. Можно говорить о разных видах приложений - например, приложения, ориентированные на паралельные вычисления - это одно, приложения, ориентированные на параллельную обработку данных (СУБД) - немного другое.


Я также незнаю промышленно
выпускаемых сейчас 32 разрядных RISK систем.


Полно таких. Intel StrongARM, например. Да, ещё куча всяких других.


IHMO SMP на Intel32 платформе производительность ограничена
частотой системной шины в случае работы с большими объемами данных(в кешах процессров ничего не задерживается).


Любой SMP, а не только Intel страдает потерей линейной масштабируемости при количестве процессоров более 4. Это, на мой взгляд, основная проблема SMP при обработке больших объёмов данных.
Для преодоления этого ограничения существует архитектура MPP.
А данные в кэше для DSS-приложений не имеют такого критического значения, как для OLTP. Об этом коллеги уже говорили выше.

Хорошая у нас дискусия, однако.


Да, надеюсь, что и полезная тоже.

Кстати, прошу обратить внимание на посты Павла Новокшонова. У него единственного из всех здесь присутствующих есть очень солидный опыт работы с хранилищем терабайтного объёма и нехилой нагрузкой.
Поспрашивайте его поподробнее о том, как это всё работает.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
19 авг 04, 12:50    [893613]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
Расскажи как будет переживать потерю бойца RAC? Что он будет делать со страницами которые изменил где-то в БД упавший узел?? Eму совсем не надо делать восстановление??? Если да - за счет чего это достигается опиши механизмы????

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

http://www.oracle.com/technology/products/database/clustering/pdf/rac_building_ha_rel2.pdf

Database Recovery in ORAC environment
The Database Instance relies on all of these components to implement instance
recovery for failed instances, in addition to handling normal database operations.
When a database instance or a node in the cluster fails, Oracle cluster database
needs to do recovery for the database just as it does for a single instance database.
Since other nodes in the cluster is still providing services to the clients, Oracle
cluster database makes sure the recovery time is as little as possible through
concurrent recovery operations.
The global cache service (GCS) maintains global cache resources status to insure
the consistency of database. If a node fails, it needs to rebuild the global cache
resource information. Recovery cannot start until the GCS finishes rebuilding the
information. Effectively, the whole database is “frozen” during this time. Since the
cache resources for database blocks are distributed among the cluster nodes, the
time needed for rebuilding GCS information is minimized. Only the cache
resources that reside or are mastered by the GCSs on the failed nodes need to be
rebuilt or re-mastered. This phase takes only a few seconds on average.
Furthermore, Oracle9i uses a two-pass database recovery scheme, where the first
pass of redo log scan decides data blocks to recover and then the second pass
only accesses the marked blocks to speed up instance crash recovery. Oracle9i,
can initiate the first pass of this recovery process concurrently with GCS rebuild
process. After the first pass, database is made available for service for data blocks
that are not impacted by the failure.
Oracle9i also gives you the ability to specify the amount of time a recovery should
take, which eliminates potential problems caused by uncertainty about time
needed for recovery.
19 авг 04, 12:59    [893671]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Константин Лисянский


Любой SMP, а не только Intel страдает потерей линейной масштабируемости при количестве процессоров более 4. Это, на мой взгляд, основная проблема SMP при обработке больших объёмов данных.


Можно ссылочку?

Для преодоления этого ограничения существует архитектура MPP.

В IQ архитектура Мultiplex позволяет решить эту задачу на простом SMP, не усложняя систем I/O, намного дешевле.
19 авг 04, 13:10    [893731]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Константин Лисянский


Память очень даже причем, если у вас на индексные деревья
нехватает памяти о чем можно дальше говорить. А на join-ах >100 милионных
таблиц вы обязательно с этим столкнетесь.


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


DSA архитектура informix делает тоже самое там есть технология PDQ
которя паралелит все операции.
С точки зрения скорости индексного поска дерево гораздо выгоднее чем список(таблица), На это есть соответствующие выкладки,
ссылок под руками нет. Для меня это само собой разумеещееся.
В качестве примера посмотрите на библиотеку STL С++.


Константин Лисянский


По поводу джойнов 100-миллионных таблиц. В Терадате есть алгоритм nonsort-merge join, который не требует предварительной сортировки (поскольку данные всегда хранятся отсортированными по значению хэш-значения), поэтому память для сортировки не нужна.


Зато память нужна для хранения хеша который по размеру соизмерим с обьемом индекса. В принципе это индексное объединение таблиц, только по искуственному индексу(хешу). Принципиальных отличий я не вижу.

Константин Лисянский

Кстати, в соседнем форуме я приводил результаты своих упражнений с таблицами с более 100 млн записей.

Почитайте здесь, может будет интереснро.


Спасибо, Обязательно загляну.

Константин Лисянский

Если мы говорим о паралелизме, то лучше RISK платформы я не знаю.
Там паралелизм заложен аппаратно.


Здесь, мне кажется, Вы слишком низко опускаетесь. Кроме аппаратного параллелизма должен ещё быть программный. Можно говорить о разных видах приложений - например, приложения, ориентированные на паралельные вычисления - это одно, приложения, ориентированные на параллельную обработку данных (СУБД) - немного другое.


DSA & PDQ меня полностью устраивают в качестве програмной реализации
паралелизма обработки баз данных.

Константин Лисянский


IHMO SMP на Intel32 платформе производительность ограничена
частотой системной шины в случае работы с большими объемами данных(в кешах процессров ничего не задерживается).


Любой SMP, а не только Intel страдает потерей линейной масштабируемости при количестве процессоров более 4. Это, на мой взгляд, основная проблема SMP при обработке больших объёмов данных.
Для преодоления этого ограничения существует архитектура MPP.
А данные в кэше для DSS-приложений не имеют такого критического значения, как для OLTP. Об этом коллеги уже говорили выше.


Я не видел реализации MPP для интел,
наверное потому что аппаратная часть подгуляла :)
Помоему MPP работает только на РИСКах.
Мне про DSS тяжело судить потому что у меня чистый OLTP ( 500Gb)
и практического опыта в DSS таких обьемов нет.
Мне кажется, что если мою базу превратить
в DSS и нарезать OLAP кубов
по критерия необходимым для бизнеса база вырастет до 3 Tb.
Лишних пару миллионов на аналитику реководство не дает,
но это их проблемы.
А опыт наверное появится на другой работе .

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

Откуда: Москва
Сообщений: 902
Dog_
В IQ архитектура Мultiplex позволяет решить эту задачу на простом SMP, не усложняя систем I/O, намного дешевле.


У меня есть небольшие сомнения на этот счёт - по-моему IQ позволяет достичь scale-up, то есть, добавив новый сервер, повысить количество пользователей/запросов, которые обрабатываются параллельно. А как у него насчёт speed-up? Можно ли добавлением нового сервера повысить скорость выполнения запроса (линейно)? И если да, то за счёт чего?
В MPP понятно за счёт чего достигается и scale-up и speed-up. А вот IQ - не очень понятно.


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

Откуда: Москва
Сообщений: 902
С точки зрения скорости индексного поска дерево гораздо выгоднее чем список(таблица), На это есть соответствующие выкладки,
ссылок под руками нет. Для меня это само собой разумеещееся.


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

Использование таблиц даёт определённые преимущества, а именно - возможность обрабатывать индексы параллельно. Как распараллеливается обработка древовидных индексов я, честно сказать, не знаю, поэтому сравнить, наверное, не смогу.

автор
Зато память нужна для хранения хеша который по размеру соизмерим с обьемом индекса. В принципе это индексное объединение таблиц, только по искуственному индексу(хешу). Принципиальных отличий я не вижу.


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

Я не видел реализации MPP для интел,
наверное потому что аппаратная часть подгуляла :)
Помоему MPP работает только на РИСКах.


1. Терадата MPP работает ТОЛЬКО на Intel.
2. Что значит подгуляла?
3. Ещё раз - нет :)



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

Откуда:
Сообщений: 1255
onstat

Теоретически это возможно,
но процессам нужно обмениваться информацией это возможно
1.через разделяемую памаять
2. pipe
3.диск. (это не рассматриваем).

Прикиньте производительность вашей сесии и всего oracle
если он таблицу, индексы начнет тащить через pipe.
Мы кажется вопросы двойной буферизации уже обсуждали.
и продолжать думаю не стоит.
То есть используется доступ через разделяемую память и семафоры.
Системные вызовы shm* всеравно ограничены разрядностью платформы.
Так, что глобально это ничего не решает.

с уважением, onstat-
ps я тоже unix люблю больше.



Ну так у Oracle обмен происходит насколько я
понимаю через shared memory и семафоры.
Я просто констатировал факт насчет Win платформы.

Я даже и не пытаюсь сравнивать 32-бит и 64-бит.
У 32-бит систем просто нет никаких шансов.
19 авг 04, 14:20    [894080]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Константин Лисянский

Любой SMP, а не только Intel страдает потерей линейной масштабируемости при количестве процессоров более 4. Это, на мой взгляд, основная проблема SMP при обработке больших объёмов данных.
Для преодоления этого ограничения существует архитектура MPP.
А данные в кэше для DSS-приложений не имеют такого критического значения, как для OLTP. Об этом коллеги уже говорили выше.

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


Ну вообще-то не только MPP.
Это не единственная возможность, есть еще NUMA.
Если правильно понимаю, то Sun хоть и говорит, что у него SMP на 128 проц, реально это все же NUMA.

Ну и второй подход интеграция нескольких процессорных ядер на одном чипе.
Тут пока IBM чемпион.
19 авг 04, 14:29    [894132]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Константин Лисянский
Dog_
В IQ архитектура Мultiplex позволяет решить эту задачу на простом SMP, не усложняя систем I/O, намного дешевле.


У меня есть небольшие сомнения на этот счёт - по-моему IQ позволяет достичь scale-up, то есть, добавив новый сервер, повысить количество пользователей/запросов, которые обрабатываются параллельно. А как у него насчёт speed-up?


Замечание очень хорошее. Прямой ответ(теоретически) - нет. В реальности,
1. С IQ никогда не вставала задача speed-up, т.к. когда имеешь ответ на любой запрос <1сек ... хх сек, это обычно устраивает. Необходимость ХХ-ХХХк$ инвестиций, как и тюнинга - отпадает. Добиться скорости на начальном этапе в памках <хх сек для 90+% запросов - можно. Потом эту скорость просто надо сохранить.

2. Все кейсы, в которых учавствовал начинались при объеме данных в Оракле/МССКЛ/Сайбейсе порядка 50-300Гб(на 2-4CPU). IQ, с 1CPU/Интел с этим объемом справляется хорошо (п.1). Теперь у клиентов базы 100-300Гб (в стандартной RDBMS было бы ~500Gb..>1Tb). То, что писет сам Сайбейс (победы на ХХТБ базах, 500тб база и т.д.) - не трогаю.

3. IQ позволяет начать с 1CPU (п.1), надо - добавить еще CPU; надо - добавить еще один нод или поставить SUN рядом с Интел сервером. При этом скорость останется в рамках п.1. Какой MPP на 1-2CPU?

Вообще, обычно чадо смотреть - чего надо достичь (скорость ответов, размер базы, число юзеров), а потом смотреть на железо. I'm lucky, с доброй половиной вопросов типа кластеры, РАЦ и т.п. встречаться не приходится. Обычные вопросы - 1-2?4? CPU, число юзеров? SAN или RAID? Интел/СУН/Линух-Юних? фронтэнд (каждый фронтэнд по разному использует ресурсы), где данные, ЕТL, и т.д.
19 авг 04, 15:24    [894435]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
EugeneS
onstat

Теоретически это возможно,
но процессам нужно обмениваться информацией это возможно
1.через разделяемую памаять
2. pipe
3.диск. (это не рассматриваем).

Прикиньте производительность вашей сесии и всего oracle
если он таблицу, индексы начнет тащить через pipe.
Мы кажется вопросы двойной буферизации уже обсуждали.
и продолжать думаю не стоит.
То есть используется доступ через разделяемую память и семафоры.
Системные вызовы shm* всеравно ограничены разрядностью платформы.
Так, что глобально это ничего не решает.

с уважением, onstat-
ps я тоже unix люблю больше.



Ну так у Oracle обмен происходит насколько я
понимаю через shared memory и семафоры.
Я просто констатировал факт насчет Win платформы.

Я даже и не пытаюсь сравнивать 32-бит и 64-бит.
У 32-бит систем просто нет никаких шансов.


А shared memory для 32бит ограничена где-то в районе 1.8 G.
19 авг 04, 15:41    [894504]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
_Dog
Замечание очень хорошее. Прямой ответ(теоретически) - нет. В реальности,
1. С IQ никогда не вставала задача speed-up, т.к. когда имеешь ответ на любой запрос <1сек ... хх сек, это обычно устраивает. Необходимость ХХ-ХХХк$ инвестиций, как и тюнинга - отпадает. Добиться скорости на начальном этапе в памках <хх сек для 90+% запросов - можно. Потом эту скорость просто надо сохранить.


Может и так. Но есть правило Парето. В данном случае можно его сформулировать так: "80% ценных решений принимаются на основе 20% запросов". В целом, чем сложнее запрос, тем более точная информация получается, и тем точнее можно принимать решения. Это я веду к тому, что вот эти самые оставшиеся 10% запросов в Вашем случае могут захотеть ускорить. А возможности нету...


2. Все кейсы, в которых учавствовал начинались при объеме данных в Оракле/МССКЛ/Сайбейсе порядка 50-300Гб(на 2-4CPU). IQ, с 1CPU/Интел с этим объемом справляется хорошо (п.1). Теперь у клиентов базы 100-300Гб (в стандартной RDBMS было бы ~500Gb..>1Tb). То, что писет сам Сайбейс (победы на ХХТБ базах, 500тб база и т.д.) - не трогаю.


1 CPU = availability - ???
Можно, наверное, датамарт некритичный к остановам и сбоям сделать, но корпоративное хранилище данных - вряд ли.


3. IQ позволяет начать с 1CPU (п.1), надо - добавить еще CPU; надо - добавить еще один нод или поставить SUN рядом с Интел сервером. При этом скорость останется в рамках п.1. Какой MPP на 1-2CPU?


Опять-таки, это для витрин данных решение. Где высокая надёжность и как она обеспечивается?


Вообще, обычно чадо смотреть - чего надо достичь (скорость ответов, размер базы, число юзеров), а потом смотреть на железо. I'm lucky, с доброй половиной вопросов типа кластеры, РАЦ и т.п. встречаться не приходится. Обычные вопросы - 1-2?4? CPU, число юзеров? SAN или RAID? Интел/СУН/Линух-Юних? фронтэнд (каждый фронтэнд по разному использует ресурсы), где данные, ЕТL, и т.д.


Я рад за Вас. Дай Бог, чтобы всё нормально продолжалось.


Да, кстати, ещё что-то там с транзакционеностью было вроде бы не очень хорошо у IQ. По-моему, он не очень хорошо умеет апдейты делать.
Это так?

А ещё слышал, что с утилитами у него не очень здорово - всё надо руками делать. Какие у разработчика есть инструменты - план запроса можно посмотреть (графически), индекс-визарды есть какие-нибудь, средства мониторинга базы данных, средства управления ресурсами СУБД (для разных пользователей разные ресурсы чтобы выделялись), средства администрирования какие?


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

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

The global cache service (GCS) maintains global cache resources status to insure
the consistency of database. If a node fails, it needs to rebuild the global cache
resource information. Recovery cannot start until the GCS finishes rebuilding the
information. Effectively, the whole database is “frozen” during this time. Since the
cache resources for database blocks are distributed among the cluster nodes, the
time needed for rebuilding GCS information is minimized. Only the cache
resources that reside or are mastered by the GCSs on the failed nodes need to be
rebuilt or re-mastered. This phase takes only a few seconds on average.


Имеем вся БД недоступна пока идет восстановление ноды. Few seconds это сколько ??? В shared nothing восстановление потерянной ноды это тоже few seconds.

ftp://ftp.software.ibm.com/software/data/pubs/papers/10sfailover.pdf
http://www-106.ibm.com/developerworks/db2/library/techarticle/dm-0407nikolopoulou

Это правда результаты без DPF (Distributed Partition feature)

Но с ней не на много больше.

Примерные результаты

Fail detection time = FD
Resource Takeover time = RT
DB2 Start time = DS
DB2 Recovery time = DR

                FD    RT    DS   DR  TOTAL
AIX w/DPF       20    15    4    2   41
AIX wo/DPF      10    8     4    2   24
Linux w/DPF     14    6     12   10  42
Linux wo/DPF    13    9     4    8   34       
HP-UX wo/DPF    2     27    2    2   35
Ну еще есть и за 10 на lifekeeper, но в ущерб производительности [/src]
P.S. Все вышесказанное моя личная точка зрения.
19 авг 04, 16:28    [894741]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Константин Лисянский


Может и так. Но есть правило Парето. В данном случае можно его сформулировать так: "80% ценных решений принимаются на основе 20% запросов". В целом, чем сложнее запрос, тем более точная информация получается, и тем точнее можно принимать решения. Это я веду к тому, что вот эти самые оставшиеся 10% запросов в Вашем случае могут захотеть ускорить. А возможности нету....


Это решает заказчик - 10 или меньше. ROI вложения в дополнительный нод длия получения ответа за 1 минуту вместо 2-х...??? Для моих клиентов ХХк$ это деньги.

До сих пор ни одной проблемы небыло.

1 CPU = availability - ???
Можно, наверное, датамарт некритичный к остановам и сбоям сделать, но корпоративное хранилище данных - вряд ли.


До сих пор ни одной проблемы небыло. Надо (есть деньги) - можно сделать HA любого уровня.
EDW его HA- отдельная тема. IQ ee не боится :)


Опять-таки, это для витрин данных решение. Где высокая надёжность и как она обеспечивается?


не о том речь, IQ ето может, ТДата нет.

Да, кстати, ещё что-то там с транзакционеностью было вроде бы не очень хорошо у IQ. По-моему, он не очень хорошо умеет апдейты делать.
Это так?


Ну и IQ (как и ТД) - не OLTP базы. По поводу проблем - очень широкии вопрос. Какой DWH без апдейтов. Пока всюду есть.

А ещё слышал, что с утилитами у него не очень здорово - всё надо руками делать.


Сложно сказать что имеете ввиду.

Какие у разработчика есть инструменты - план запроса можно посмотреть (графически),

да

индекс-визарды есть какие-нибудь, средства мониторинга базы данных


Сайбейс считает что есть :) Я не очень согласен :) Но в новои версии (будет очень скоро) все есть.

, средства управления ресурсами СУБД (для разных пользователей разные ресурсы чтобы выделялись),


средства администрирования какие?


Да, стандартный Central+ISQL.
19 авг 04, 16:39    [894807]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Константин Лисянский

С точки зрения скорости индексного поска дерево гораздо выгоднее чем список(таблица), На это есть соответствующие выкладки,
ссылок под руками нет. Для меня это само собой разумеещееся.


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

Использование таблиц даёт определённые преимущества, а именно - возможность обрабатывать индексы параллельно. Как распараллеливается обработка древовидных индексов я, честно сказать, не знаю, поэтому сравнить, наверное, не смогу.


Одни просесс(процессор) берет одну ветку, другой другую,
третий третью. При этом блокировка происходит только на уровне ветки.
То есть процессы друг друга не блокируют. Вставки
строк в таблицу происходят паралельно, если значения ключей индекса
не пересекается на одной ветке дерева, ( имеют разные значения индексного ключа).

Как быть с разделением доступа к данным индекса между процессами
в случае списка мне неизвесно, но алгоритм там явно сложнее.
По каким критериям таблица(список) делятся между процессами
и сколько их будет тоже вопрос. Как блокируется таблица для многопользовательского доступа?
Как производится в ставка нового индексного значения?
Для меня пока вопросов больше чем ответов,
в первую очередь потому что это не логично.
Я конечно могу чего то недопонимать.

Константин Лисянский

автор
Зато память нужна для хранения хеша который по размеру соизмерим с обьемом индекса. В принципе это индексное объединение таблиц, только по искуственному индексу(хешу). Принципиальных отличий я не вижу.


Не совсем так. Хэш как индекс хранить не надо. Хэш - это функция.
Другое дело, что хэш-значение входит в ROWID и хранится вместе с записью -это так. Но первичный хэш-индекс никогда не хранится, а вычисляется.
[/quot ]

То есть вы имеете ввиду кластерный индекс.
Тогда на вставке удалении вы потеряете в 10 крат.
Как быть с другими индексами? связка таблиц делается не обязательно по
первичному ключу.

Константин Лисянский

[quot ]Я не видел реализации MPP для интел,
наверное потому что аппаратная часть подгуляла :)
Помоему MPP работает только на РИСКах.


1. Терадата MPP работает ТОЛЬКО на Intel.
2. Что значит подгуляла?
3. Ещё раз - нет :)



MPP это апаратная платформа, кто именно производит такое железо
на чипах intel . Какие процессора и чипы используются,
какие ОС работают ?
Если можно ссылки.

С уважением, onstat-
19 авг 04, 16:40    [894809]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
Имеем вся БД недоступна пока идет восстановление ноды. Few seconds это сколько ??? В shared nothing восстановление потерянной ноды это тоже few seconds.


да но есть небольшая разница - в shared nothing нада к каждой ноде по standby серверу ... ??
19 авг 04, 16:50    [894866]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Имеем вся БД недоступна пока идет восстановление ноды. Few seconds это сколько ???

Few - это обычно меньше десяти ;-))

БД недоступна не пока идет восстановление ноды, а "until the GCS finishes rebuilding the information". Синхронизация GCS - это операции с памятью и интерконнектом. Прошла синхронизация, дальше восстановление упавшего нода другим не мешает.
19 авг 04, 17:00    [894911]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

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

MPP это апаратная платформа, кто именно производит такое железо
на чипах intel . Какие процессора и чипы используются,
какие ОС работают ?
Если можно ссылки.


Можно:
Железяки здесь.
ОС:
1. NCR UNIX MP-RAS (он же AT&T SVR4)
2. W2K
3. В следующем году обещают Linux поддерживать.
4. Есть ещё версия для WS03 и HP-UX (это я уже писал выше). Но это, по-моему, только в SMP на любых сертифицированных платформах.

Железо производит NCR.

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

Откуда: Москва
Сообщений: 607
Ну-ну...
автор
Recovery cannot start until the GCS finishes rebuilding the
information.


А кэш не начнет синхронизироваться пока не определим что боец умер. Это как минимум 10 секунд. Синхронизация а потом recovery... Может быть приведем какие нибудь более менее официальные результаты??? Я могу найти презентацию с Oracle User Group где один из заказчиков Oracle говорит что у него время failover это 51 sec....
19 авг 04, 17:35    [895059]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
еще раз ораклу эта нода не нужна, он без нее обойдется, а дб2 обязан каждую ноду дублировать.
19 авг 04, 17:43    [895087]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

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

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

Еще раз говорю каждую ноду дублировать не надо. Можно как в RAID 3 - одна нода дублирует 4-ре. Опять же есть Mutual takeover. Когда рабочие ноды могут взять ноды с упавшей машины, с понижением производительности.
19 авг 04, 17:55    [895141]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 9 [10] 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить