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

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

OFF: Кстате FC это коммуникационный протокол(читай протокол маршрутизации),
а не протокол работы с перефирийными устройствами.
Поэтому SCSI-FC связка существует всегда при подключении
FC диской системы (реализация FC-SCSI реализована в дисковой стойке или
на контролере диска).
FC - это протокол носитель, который инкапсулирует в себе
протокол более высокого уровня в часности SCSI.
Я не понял, что вы имели ввиду под вариантом "для бедных",
он дешевле чего? и за счет чего?


Да, коряво сказал. Я имел в виду сопряжение с дисками в стойке. Разница в цене. Дешевле за счет использования SCSI-дисков вместо FC-дисков
13 авг 04, 20:10    [881655]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Ребята, мне, как автору топика, все же хотелось бы, чтобы мы обсуждали не преимущества/недостатки страйпинга и уровней RAID, а архитектуру БД. Я вот нашел интересную статью в инете: Clustering for Scalability и предлагаю ее обсудить. Так все-таки: Shared-disk или Shared-nothing ?
15 авг 04, 20:27    [882904]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Здесь 2 линка от Sybase:
The Simplification of Data Warehouse Design
http://www.sybase.com/content/1010008/rcubes_wp_L01496-v2.pdf

A New Data Warehousing Paradigm for User and Data Scalability
http://www.sybase.com/content/1008841/iq_wp_l01411-v2.pdf
15 авг 04, 23:20    [882971]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Кстати, а каким образом в архитектуре IBM DB2 определяется, какой узел (узлы) будут обрабатывать запрос? Каким образом осуществляется балансировка нагрузки на узлы: на уровне СУБД или другого софта? Где почитать можно?
16 авг 04, 10:41    [883372]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Кстати, а каким образом в архитектуре IBM DB2 определяется, какой узел (узлы) будут обрабатывать запрос? Каким образом осуществляется балансировка нагрузки на узлы: на уровне СУБД или другого софта? Где почитать можно?


Если речь идёт о массивно-параллельной архитектуре (shared nothing), то запрос обрабатываться должен одновременно (параллельно) всеми узлами. В этом заключается суть использования архитектуры MPP для СУБД.
Соответственно, балансировка нагрузки должна обеспечиваться на уровне СУБД. По карйней мере, так делается в Терадате. В DB2 должно быть то же самое.

Вот, что IBM пишет в статье:

IBM
Clustering for high availability is a task that can be done by the operating system for any data service like a database. Clustering for scalability requires "smarts" in the database engine as well.


Естественно, база должна быть умной и понимать, в какой среде она работает.
Для эффективной балансировки нагрузки должно выполняться одно важное условие - данные таблиц должны быть равномерно распределены по узлам системы.
Кстати, и availability тоже не только задача операционной системы, но и СУБД должна тоже понимать, что это такое, и как её достичь.


Так все-таки: Shared-disk или Shared-nothing


Для хранилищ данных больших объёмов пока ничего лучше shared nothing не придумали. По крайней мере, пока.



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

Откуда: СПб
Сообщений: 1815
Сергей Тихонов
. Так все-таки: Shared-disk или Shared-nothing ?


А почему "или"? Мне кажется значительно интереснее вариант "и".
Федеративная база с Shared-disk узлами.
Например, имеем кластер о 8-головах и 4 базы данных работающие как федеративная база данных. В чистом Shared-nothing варианте, 4 головы заняты, 4-простаивают в ожидании аварии. Теперь берем смешанный вариант,
над кадой базой по две головы, никто не простаивает, и имеем очень гибкую систему:
1) при аварии одной из голов достаточно переключить пользователей на работающую голову над той-же базой, время восстановления минимально.
2) возможно гибкое перераспределение вычислительной мощности, допустим на ночь передаем дополнительные головы оним узлам( на которых больше нагрузка) днем другим.
3) имеем преимущество федеративного распределения нагрузки по узлам ( базам).

Таким образом мы получаем надежность, скорость восстановления и гибкость при распределении вычеслительной мощности Shared-disk и производительность и распределение нагрузки Shared-nothing.

Данный вариант возможен на Oracle. И я думаю на DB2, если не ошибаюсь на Mainframe ( какойто DB2 поддерживает Shared-disk).
16 авг 04, 11:14    [883477]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Сергей, не получится ли так, что для Вас главным ограничителем окажется бюджет проекта (бюджет будет заставит использовать то или иное решение)?
16 авг 04, 11:19    [883498]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
В чистом Shared-nothing варианте, 4 головы заняты, 4-простаивают в ожидании аварии.


Это не так. В чистом Shared-nothing (каковым IBM объявил только Терадату - см. статью на которую ссылается Сергей) работают все узлы системы. Они полностью равноправны и никакой из них не простаивает в ожидании аварии. Это было бы очень неэффективно. При аварии производительность уменьшается пропорционально количеству потерянных узлов.


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

Откуда:
Сообщений: 1255
Сергей Тихонов
Ребята, мне, как автору топика, все же хотелось бы, чтобы мы обсуждали не преимущества/недостатки страйпинга и уровней RAID, а архитектуру БД. Я вот нашел интересную статью в инете: Clustering for Scalability и предлагаю ее обсудить. Так все-таки: Shared-disk или Shared-nothing ?



Я, все же не понимаю зачем вы пытаетесь решать эту задачу с помощью кластера?

Поскльку у вас смешанная нагрузка 50:50 (OLTP + DSS ), то мне кажется ваше задача должна решаться с использованием аппаратного партицирования.
Я так понимаю оно присутствует у большинства производителей железа.
То есть я все же за железо типа SuperDoom от HP или Sun Fire E25K.
Почему?

1. Минимальный гемор с балансировкой по сравнению с кластерами.
2. Динамическая реконфигурация железа.
Ну необходимо вам сейчас увеличить пропускную способность OLTP части, добавили процессоров, нужно для DSS части опять же оторвали в одном месте добавили в другом.
3. Все так же пока не понятно, это будет одна и таже БД или все же два єкземпляра?
16 авг 04, 11:46    [883602]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
EugeneS
Я, все же не понимаю зачем вы пытаетесь решать эту задачу с помощью кластера?
Потому что это более отказоустойчивое решение. Я хочу совместить Availability и Scalability...
16 авг 04, 13:38    [884123]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
За счет чего shared nothing кластер будет более отказоустойчив? Теряем один нод, что тогда?
16 авг 04, 14:48    [884444]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Вот и мне интересно...
16 авг 04, 14:50    [884451]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
если у нодов - независимые подсистемы ВВ, то по идее потеряете доступ к части данных.
16 авг 04, 15:24    [884579]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Сергей Тихонов
EugeneS
Я, все же не понимаю зачем вы пытаетесь решать эту задачу с помощью кластера?
Потому что это более отказоустойчивое решение. Я хочу совместить Availability и Scalability...


Ага, именно по этому такие ребята, как Visa и EuroPay их не используют.
А используют mainframe-ы.

Дело в том, что кластеринг для СУБД - это такая рекламная компания, для увеличения продаж СУБД, ну прям как Java, NET и другие "звездные продукты".
Шума много, а начнешь выяснять доказательств маловато или не убедительно.
Как говорится в "в мутной воде проще рыбку впоймать" , вот софтверные конторы и поднимаю такую муть, для увеличения доходности.

Пример возмем кластера от Oracle.
1. Только начиная с 9i у него появился Cache Fusion , который позволяет передавать болоки не через диск , а по интерконнекту между кэшами отдельных узлов.
2. Подразумевалось что использование кластеров позволит снизить затраты компании на hardware, при этом почему-то умалчивается что затраты на кластеринг тоже растут. ( Oracle EE стоит 40к на процессор, для того чтобы его использовать в кластерной конфигурации надо еще 20к итого 60к * число узлов. А уж если ван нужно партицирование или еще что-то то эта сумма и того выше).
Идея была конечно хорошей ,но это банальное перераспределение денег.
Тем более многопроцессорные системы вобще-то лучше ведут себя и под нагрузкой и при параллельном доступе, а динамическое партицирование вообще их делает "The best". Недостаток их конечно в больших первоначальных затратах.

3. Использование кластера от Oracle (shared-disk) подразумевает использование очень не слабой дисковой подсистемы, дешевеньким продуктом вы тут не отделаетесь, поскольку дисковая система как раз самое узкое место кластера от Oracle, поэтому в итоге необходимо иметь второй экземпляр дисковой системы для failover-а, иначе при выходе из строя дисковой подсистемы , весь кластер упадет.
4. Еще про отказоустойчивость.
Что вы имеете ввиду? Любая оказоустойчивость подразумевает дубляж.
То наличие двух хостов , двух дисковых подсистем.
Кластеры в минимальной конфиугации этого не продоставляют, скорей лучшим решением является standby БД.

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

Откуда:
Сообщений: 6941
В данном случае нельзя быть и умным и красивым односременно.
В случае shared-disk мы имеем перегрузку(overload) в случае отказа
одной из нод, в случае shared nothing мы будем иметь потерю доступа
к части данных(на время востановления узла) без потери
общей производительности.
Что в данном случае важнее зависит от приложения.
Это аварийная ситуация и как ее обрабатывать
без знания предметной области сказать тяжело.
За немерянные деньги можно заказать систему с полным резервированием,
но при этом часть ресусов будут простиаивать до наступления
аварийной ситуацииb, оправдает ли себя система такой стоимости тоже
зависит от приложения.

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

Откуда: С-Петербург
Сообщений: 2347
автор

Ага, именно по этому такие ребята, как Visa и EuroPay их не используют.


Насколько я помню *конечно может уже неправ* но VISA в Bank Of America стоит на BASE 24, Tandem, NonStop SQL. Да и во многих процесинговых центрах стоит эта система. Типа супер - отказоустойчивая. Именно - кластарная. Как реализована отказоустойчивость - это нужно уже архитектуру смотреть. Можно ведь каждую ноду сдублировать.
16 авг 04, 16:09    [884791]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
c
Guest
Da, a v City Corp - Mainframe's claster..
16 авг 04, 16:12    [884812]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
onstat-
В данном случае нельзя быть и умным и красивым односременно.
В случае shared-disk мы имеем перегрузку(overload) в случае отказа
одной из нод, в случае shared nothing мы будем иметь потерю доступа
к части данных(на время востановления узла) без потери
общей производительности.
С уважением, onstat-


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

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

Ага, именно по этому такие ребята, как Visa и EuroPay их не используют.


Насколько я помню *конечно может уже неправ* но VISA в Bank Of America стоит на BASE 24, Tandem, NonStop SQL. Да и во многих процесинговых центрах стоит эта система. Типа супер - отказоустойчивая. Именно - кластарная. Как реализована отказоустойчивость - это нужно уже архитектуру смотреть. Можно ведь каждую ноду сдублировать.


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

Откуда: Москва
Сообщений: 902
За счет чего shared nothing кластер будет более отказоустойчив? Теряем один нод, что тогда?


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

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

Есть и ещё один механизм - называется dual active. Это когда две системы полностью дублируют друг друга, но работают при этом обе в активном режиме. Но, естественно, это решение для mission critical-приложений.

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


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

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

А что делать, если один большой шкаф с тучей процов и памяти перестанет работать :-\\?
16 авг 04, 16:29    [884894]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

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

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


1. В таком шкафу вы вряд-ли найдете хоть один компонент который не дублируется.
2. Вам ничего не мешает иметь два шкафа, но это уже для случая missio-critical.
16 авг 04, 16:35    [884925]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

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


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


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

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


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


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


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

Откуда: Киев
Сообщений: 787
EugeneS
1. В таком шкафу вы вряд-ли найдете хоть один компонент который не дублируется.
2. Вам ничего не мешает иметь два шкафа, но это уже для случая missio-critical.

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