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

Откуда:
Сообщений: 1255
Константин Лисянский
А что делать, если один большой шкаф с тучей процов и памяти перестанет работать :-\\?


Курить бамбук :) И ждать пока его починят.


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


Когда кластер завалится , вы тоже узнаете всю правду, только вряд ли это вам уже поможет.
:)
16 авг 04, 16:48    [884994]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
Курить бамбук :) И ждать пока его починят.
Позволю себе пошутить: это кредо TeraData или ваше личное ;-) ?
16 авг 04, 16:49    [885003]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
EugeneS
Когда кластер завалится , вы тоже узнаете всю правду, только вряд ли это вам уже поможет. :)
Ну, это все к тому же вопросу: scale-up (увеличение мощности одного узла) или scale-out (наращивание количества узлов)?
16 авг 04, 16:55    [885019]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Сергей Тихонов
EugeneS
Когда кластер завалится , вы тоже узнаете всю правду, только вряд ли это вам уже поможет. :)
Ну, это все к тому же вопросу: scale-up (увеличение мощности одного узла) или scale-out (наращивание количества узлов)?


Я надеюсь вы не подразумеваете двух-узловую конфигурацию?
16 авг 04, 17:01    [885048]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
в оракле ноды можно подключать на лету, нагрузка распределяется тоже на лету, в shared nothing - как я понимаю нужно размазывать бд ручками.

db2 cluster vs RAC
http://www.oracle.com/technology/products/database/clustering/pdf/RACvDB2.pdf
16 авг 04, 17:09    [885075]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
вот еще взгляд от оракла:
http://www.oracle.com/technology/deploy/performance/pdf/FederatedvsClustered.pdf
16 авг 04, 17:11    [885083]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Позволю себе пошутить: это кредо TeraData или ваше личное ;-) ?


Личное. Шутка.

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


При добавлении узла в Терадате система сама перераспределяет данные. Автоматически. В плане ручек - надо будет запустить процесс реконфигурации после добавления узла. Об этом уже писал Павел Новокшонов выше.



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

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


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

PS.а такое умеют mssql & db2 ?
16 авг 04, 18:41    [885377]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

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


Ещё раз повторю то, что писал немного выше:


Если необходимо добавить новый узел, то нужно взять маленькие кусочки от каждого куска таблицы с каждого присутствующего узла и переместить эти кусочки на новый узел.
Скажем, если у нас было 10 узлов, на каждом из которых хранилось по 110 записей, то при добавлении одиннадцатого узла мы берём по 10 записей с каждого узла, складываем, и кладём на новый узел. Получаем 11 узлов, на каждом из которых хранится по 100 записей.



Таким образом, перераспределяется только часть данных, которая идёт на вновь подключённый узел.


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



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

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

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


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


Статью пока не прочел, но и без нее понятно, каким образом в теории можно повысить отказоустойчивость кластера. Вопрос денег. Сколько это будет стоить, какие порядки денег для озвученного вами варианта с обеспечением отказоустойчивости каждого узла кластера?
16 авг 04, 21:15    [885644]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Сергей Тихонов
EugeneS
Только начиная с 9i у него появился Cache Fusion , который позволяет передавать болоки не через диск , а по интерконнекту между кэшами отдельных узлов.
Замечательно, уже даже Oracle 10g есть...
EugeneS
Использование кластера от Oracle (shared-disk) подразумевает использование очень не слабой дисковой подсистемы
ИМХО, когда речь идет о больших объемах данных, это и так понятно. Тут что с Oracle, что без него...
EugeneS
Любая оказоустойчивость подразумевает дубляж.
То наличие двух хостов , двух дисковых подсистем.
Нормально. Взрослые дисковые стойки и так имеют в себе дублирование компонентов, далее идем по архитектуре SAN и топологиям - два SAN-свича, два HBA в каждый сервер. И приходим к ситуации no single point of failure

А что делать, если один большой шкаф с тучей процов и памяти перестанет работать :-\\?


Для Оракла вам фактически нужно иметь 2 таких SAN'a желательно разнесенных удаленно в разные датацентры. И разумеется всю инфраструктуру, которая обеспечит прозрачное переключение на другой датацентр
16 авг 04, 21:19    [885652]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
killed
Для Оракла вам фактически нужно иметь 2 таких SAN'a желательно разнесенных удаленно в разные датацентры. И разумеется всю инфраструктуру, которая обеспечит прозрачное переключение на другой датацентр
Ну, это уже из разряда катастрофоустойчивых систем. Об этом пока речь не идет... ;-)
16 авг 04, 22:23    [885720]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
16 авг 04, 23:17    [885797]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Yo!
вот еще взгляд от оракла:
http://www.oracle.com/technology/deploy/performance/pdf/FederatedvsClustered.pdf
Прочитал. В принципе, достаточно аргументированное и серьезное сравнение СУБД. Иногда правда с маленькими перегибами, но у кого их нет... ;-)

ЗЫ
Спасибо за ссылки.
16 авг 04, 23:22    [885800]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?
16 авг 04, 23:26    [885805]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


standby это сервер дублирующий данные, он находится
в состоянии readonly для пользователей все изменения делаются накатыванием журналов в реальном режиме времени с основного сервера.
И в случае аварии основного он в течении нескольких секунд поднимается в режим на полный доступ.
Также нужно учесть что у этого сервера свое дисковое пространство
(оно тоже дублируется).
Oracle & informix это делают с полпинка.
Решение о необходимости такого сервера standby всеравно принимать Вам.
Я, например, без него обхожусь.

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

Откуда:
Сообщений: 1255
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


Не пускать уборщицу в помещение где все это стоит.
Иначе никакой дубляж не поможет.
17 авг 04, 10:24    [886290]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


А если серьезно, то наличие дублирующих компонент совсем не спасает от таких вещей как:
- "маски шоу"
- разгневаные пользователи которым не понравился сервис вашей компании.
- пожары и наводнения.
- просто другие варианты физического уничтожения офиса где все это стоит.
и т.д. и т.п.
17 авг 04, 10:27    [886299]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
EugeneS
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


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


По моим данным в одной из сейсмоопасных стран один комплект дублирующего
оборудования(3-й) стоит в фуре под зданием. В случае форсмажора
трак уезжает в безопасное место и в течении 30 мин через спунтик
продолжает работать в штатном режиме.
Если ниформация того стоит то почему -бы и не купить дополнительный
комплект оборудования & SAT NET фуру тягач и электостанцию.
Вопрос в деньгах.

С уважением, onstat-
17 авг 04, 10:37    [886339]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

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

В DB2 добавлять узлы online пока нельзя. Требуется перезапуск стсемы.
http://www.databasejournal.com/features/db2/article.php/10896_1598301_3

В Db2 обязательно дублировать только узел на котором находится каталог (hot stad by) все остальные могут быть зарезервированными другими рабочими узлами (mutual takeover). Но балансированное резервирование достигается через выделение одной ноды в hot-standby и она указывается как резервная для нескольких

Берем какой-нибудь blade center. и делаем каждый 6 сервер как hot standby или как вам нравится.

P.S. Я болею на частые ответы не ждите ответа
P.P.S. По поводу выполнения запроса несколькими узлами в Oracle (Oracle Paralell Query). Там что-то было не очень красиво. Кажется где-то в документации было написано что Oracle Parallel Query не использует buffer cache, и читает с диска. где-то в Oracle performance tuning guide.
17 авг 04, 15:05    [887594]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


Ну вот навскидку два сценария.
1) Появление bad-блоков.
2) Пользователь по ошибке удалил критичные данные
17 авг 04, 15:12    [887633]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

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

P.P.S. По поводу выполнения запроса несколькими узлами в Oracle (Oracle Paralell Query). Там что-то было не очень красиво. Кажется где-то в документации было написано что Oracle Parallel Query не использует buffer cache, и читает с диска. где-то в Oracle performance tuning guide.


Навскидку вот не припомню такого. С чего бы ему не использовать кэш-буффер?
Он еще дополнительную память помимо кэш-буфера использует для взаимодействия со слейвами. Это да.
17 авг 04, 15:25    [887708]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
killed
Ну вот навскидку два сценария.
1) Появление bad-блоков.
2) Пользователь по ошибке удалил критичные данные
По первому пункту - отпадает, потому что избыточность в массиве + в современных серьезных стойках есть фича, которая вообще прогнозирует отказы винтов и т.д.
По поводу удаления - ИМХО легче решить на уровне протоколирования изменений критичных данных на триггерах.
17 авг 04, 15:48    [887848]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Первый пункт не может отпасть, поскольку ошибки могут быть и на уровне Оракла. Т.е. с точки зрения ОС это может быть вполне корректный блок, с точки зрения Оракла - неконсистентный.
17 авг 04, 16:00    [887901]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
killed
Сергей Тихонов
killed
а вам по-любому, если речь об оракл, придется делать стендбай. Так пусть он будет таким же по качеству, как основная система :)
Не совсем понял.
Если у меня серьезная дисковая стойка, в которой нет single point of failure и массивы на ней построены с избыточностью, плюс дублирование по SAN-свичам, плюс дублирование HBA в серверах, что еще дублировать?


Ну вот навскидку два сценария.
1) Появление bad-блоков.
2) Пользователь по ошибке удалил критичные данные


1. Дисковый контроллер эти вопросы решает автоматически для каждого диска
если собран массив с избыточной целостностью. На каждом диске для этого есть соответствующий объем резервных блоков.

2. Здесь standby не поможет.
Нужно востанавливаться и катить журналы. Можно катить журналы на
standby в ручном режиме но это не чистый standby. Время поднятия системы равна времени наката всех журналов, и standby нельзя использовать ползователям на чтение(информация там не актуальна).

С уважением, onstat-
17 авг 04, 16:04    [887921]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить