Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
Привет!
Существуют ли в природе такая универсальная СУБД (особый заказной вариант Oracle, DB2 или что-то еще), которую можно купить за деньги и которая могла бы работать на кластере, состоящем из тысяч и десятков тысяч машин (например, PC)? Или же сейчас ничего подобного не существует в природе в принципе? Меня интересует именно универсальная СУБД, для которой я мог бы разрабатывать приложения, а не сомнительная возможность провести переговоры с фирмой "xxx" о разработке ими уникального решения soft + hard "под ключ" под мою конкретную задачу за "n" миллиардов $... :)
29 авг 06, 19:47    [3068536]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32898

Привет, sysprg!
Ты пишешь:

sysprg
состоящем из тысяч и десятков тысяч машин (например, PC)?
курсовой проект?
или диссертация?
хотя, какая нах разница...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

29 авг 06, 19:53    [3068550]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
Мимопроходящий
курсовой проект?
или диссертация?
хотя, какая нах разница...
Нет, просто важно узнать текущее состояние дел. Есть что сказать по существу?
29 авг 06, 21:04    [3068731]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
Сомневаюсь. Такой кластер для "универсальных задач" дико неэффективен, а следовательно "универсальную СУБД" под него вряд ли кто-либо писал.
29 авг 06, 21:14    [3068761]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
softwarer
Сомневаюсь. Такой кластер для "универсальных задач" дико неэффективен, а следовательно "универсальную СУБД" под него вряд ли кто-либо писал.
В перспективе кластерам с тысячами сравнительно слабых узлов все равно нет альтернативы, но спасибо за информацию о том, что сейчас этим никто не занимается. Я так и подумал посмотрев сайты основных производителей СУБД, однако информация на них всех организована таким образом, что толком понять что же у них есть и главное - каковы технические ограничения этих систем - очень тяжело.
Получается, что сейчас для задач с очень большим потоков запросов нет альтернативы "самопальным" решениям. Уже есть немало интересных задач, с решением которых заведомо не справится одна машина и даже кластер на какие-нибудь 64 ноды (предел того, что я вычитал на сайтах). :(
29 авг 06, 21:27    [3068783]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ппм
Guest
у db2 "предел" 1024 ноды
купите больше лицензий - вам забесплатно скомпиляют скоко надо
29 авг 06, 21:44    [3068810]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ппм
Guest
а супер-вера в кластера с возрастом проходит
29 авг 06, 21:45    [3068811]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
sysprg
В перспективе кластерам с тысячами сравнительно слабых узлов все равно нет альтернативы,

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

sysprg
Уже есть немало интересных задач, с решением которых заведомо не справится одна машина и даже кластер на какие-нибудь 64 ноды (предел того, что я вычитал на сайтах). :(

Немало, если говорить об абсолютных числах. Но всякие Earth Simulator - не настолько частые и простые задачи, чтобы имело смысл пытаться подвести под них универсальную платформу.

sysprg
Получается, что сейчас для задач с очень большим потоков запросов нет альтернативы "самопальным" решениям.

При чем тут большой поток запросов и СУБД?
29 авг 06, 21:49    [3068821]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
А у Гугла разве не такой зверь стоит? Правда назвать ЭТО "универсальной СУБД" никак невозможно.

--
Антон
Per rectum ad astrum
29 авг 06, 22:21    [3068884]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
ппм
у db2 "предел" 1024 ноды
купите больше лицензий - вам забесплатно скомпиляют скоко надо
Насколько я знаю, DB2 использует "sharing nothing" архитектуру, когда никакие данные не разделяются между нодами, соответственно каждый запрос отправляется для обработки на каждую из нод кластера, а ответы объединяются - у каждой ноды часть данных и только все они вместе могут выполнить нетривиальный запрос.
Получается, что работы на каждую ноду приходится меньше (так как данных каждой ноде приходится обрабатывать меньше - они ведь раскиданы по тысячам нод). Но так или иначе каждая нода вовлечена в любой поисковый запрос.
Если я правильно понял описание архитектуры IBM и это так, то подобное решение не всегда подходит - если, скажем, у меня миллион запросов в секунду, то мне не так страшно (может быть), что у меня большие выборки за этими запросами (они могут быть маленькими!) , сколько страшно то, что я не хочу каждую ноду грузить обработкой всех запросов (миллиона штук в секунду).
А до начала выполнения запроса заранее еще не ясно, где именно лежат нужные (штучные) страницы данных, затронутых этим запросом - поэтому в sharing nothing архитектуре запрос транслируют на все ноды (на всякий случай).
Или это не так в DB2?
30 авг 06, 03:01    [3069204]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
softwarer
sysprg
Получается, что сейчас для задач с очень большим потоков запросов нет альтернативы "самопальным" решениям.

При чем тут большой поток запросов и СУБД?
Предположим, мне нужно решить типично СУБДшную задачу многокритериального поиска на очень-очень большой базе данных к которой поступает миллион запросов в секунду.
Я не могу заранее поделить эти запросы между компьютерами для индивидуального исполнения только на одной машине, так как потенциально запрос может потребовать доступа к записям, лежащим на другом компьютере. Задача "разумного" разделения записей по машинам так, чтобы не было запросов, требующих данных, лежащих на нескольких машинах сразу - даже теоретически неразрешима...
Чтобы справится с таким потоком запросов мне нужна СУБД, которая не просто делит данные между, скажем, тысячей узлов, но которая умеет выполнять запрос на отдельном узле, даже если данные затронутые этим запросом не локализуются в рамках этого одного-единственного узла.
30 авг 06, 03:19    [3069207]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
sysprg
Предположим, мне нужно решить типично СУБДшную задачу многокритериального поиска на очень-очень большой базе данных к которой поступает миллион запросов в секунду........

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

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

Могу повторить, что на наличие универсальных решений подобного рода я бы не рассчитывал; слишком уж это зависит от специфики конкретной задачи.
30 авг 06, 08:47    [3069352]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
Dimitry Sibiryakov
Member

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

sysprg

Предположим, мне нужно решить типично СУБДшную задачу
многокритериального поиска на очень-очень большой базе данных к которой
поступает миллион запросов в секунду.

Для начала ответь (для себя в том числе) на два вопроса:
1) Очень-очень большая БД это сколько террабайт и откуда возьмется такая
прорва данных;
2) Кто и как будет посылать миллион запросов в секунду.

Posted via ActualForum NNTP Server 1.3

30 авг 06, 09:32    [3069485]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ппм
Guest
sysprg
Насколько я знаю, DB2 использует "sharing nothing" архитектуру, когда никакие данные не разделяются между нодами, соответственно каждый запрос отправляется для обработки на каждую из нод кластера, а ответы объединяются - у каждой ноды часть данных и только все они вместе могут выполнить нетривиальный запрос.
Получается, что работы на каждую ноду приходится меньше (так как данных каждой ноде приходится обрабатывать меньше - они ведь раскиданы по тысячам нод). Но так или иначе каждая нода вовлечена в любой поисковый запрос.
Если я правильно понял описание архитектуры IBM и это так, то подобное решение не всегда подходит - если, скажем, у меня миллион запросов в секунду, то мне не так страшно (может быть), что у меня большие выборки за этими запросами (они могут быть маленькими!) , сколько страшно то, что я не хочу каждую ноду грузить обработкой всех запросов (миллиона штук в секунду).
А до начала выполнения запроса заранее еще не ясно, где именно лежат нужные (штучные) страницы данных, затронутых этим запросом - поэтому в sharing nothing архитектуре запрос транслируют на все ноды (на всякий случай).
Или это не так в DB2?

В целом так, но не совсем.
Да, правильное партиционирование - ключ к высокой производительности. Цель - избавится от межнодового обмена и повысить паралельность.

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

Нет, не все запросы будут раскидыватся по всем нодам - если данные запроса на ноде, к которой присоеденен клиент, то запрос выполняется только локально. Отсюда два следствия - первое, если это "большой" запрос, ну например, с агрегирующими функциями, и т.д, то он будет будет выполнятся медленнее, чем если бы данные были на разных узлах и зпрос выполнялся на всех, и второе - если запрос "мелкий", ну там insert/update/delete одной строки, то он явно будет выполнен быстрее в случае, если эти строки на ноде, куда мы присоеденились.

Есть функция DB2PARTNUM или что-то типа того, которая возвращает номер норды по переданному ей ключу партиционирования. Используя ее можно построить "маршрутизатор" (где-то валялся такой для java) запросов, не требующих распаралеливания. Ну, в принципе, этого достаточно для написания приложения, в котором запросы, требующие обработки больших массивов данных будут выполнятся на всех нодах, а не требующие - на одной.
Но можно сделать и более красиво, на основе SOA. Тогда собственно база будет всего лишь сервис, к которому обращаются потребители, а ESB будет маршрутизатором запросов.
Длительность выполнения отдельно взятого запроса увеличится (все-таки промежуточные уровни появятся), но пропускная способность всей системы вырастет.
И еще - на текущий момент нет такой реальной потребительской задачи, которая не может быть выполнена в рамках одного SMP сервера топ-класса.
Гипотетические "а вот если..." не являются реальной задачей.
30 авг 06, 12:46    [3070630]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
pavelvp
Member

Откуда:
Сообщений: 673
1) пусть человек озвучит объём данных
2) расскажет кто, как и зачем будет посылать эту прорву запросов
3) в каком количестви и как данные будут добавляться и обновляться

После этого можно будет дальше разговаривать.
Может ему не нужен нафиг никакой мега-кластер...
30 авг 06, 13:05    [3070757]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30278
см. соседний топик того же автора, "многкритериальный поиск..." - это продолжение.
30 авг 06, 17:06    [3072700]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
softwarer
Для описания прямого решения этой задачи на кластере слабых машин "помрет" - очень слабое слово. Поскольку означает примерно следующее: миллион раз в секунду прорва данных должна прокачиваться из места постоянной дислокации к узлу, пытающемуся обработать очередной запрос. Если обрабатывать запрос на одном узле, прокачивать туда придется в худшем случае всю базу.
Поэтому ясно, что во-первых, разные запросы должны обрабатываться разными узлами, а во-вторых, должна существовать эффективная система индексации (это ключевая сложность), благодаря которой узел вытаскивал бы в свою память как можно меньше страниц с данными с других узлов. Тогда при большом количестве узлов даже поток в один миллион запросов не будет чем-то страшным и нереальным. Ведь в среднем каждый узел будет отдавать и получать намного меньше страниц с данными - тысячи, десятки тысяч, но не миллионы.
30 авг 06, 19:02    [3073423]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
sysprg
Member

Откуда:
Сообщений: 66
ппм
Да, правильное партиционирование - ключ к высокой производительности. Цель - избавится от межнодового обмена и повысить паралельность.

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

Нет, не все запросы будут раскидыватся по всем нодам - если данные запроса на ноде, к которой присоеденен клиент, то запрос выполняется только локально.
Согласен, это внушает оптимизм и возможно DB2 - наиболее подходящая реально работающая платформа для моей задачи. Хотя теоретически Oracle RAS более продвинутая архитектура, однако в реальности они не демонстрируют в работе больших кластеров (сноска - или я об этом не знаю и не нашел информации) и потому есть сомнения в том, что их система масштабируется, несмотря на хорошую теоретическую задумку.

ппм
Есть функция DB2PARTNUM или что-то типа того, которая возвращает номер норды по переданному ей ключу партиционирования. Используя ее можно построить "маршрутизатор" (где-то валялся такой для java) запросов, не требующих распаралеливания. Ну, в принципе, этого достаточно для написания приложения, в котором запросы, требующие обработки больших массивов данных будут выполнятся на всех нодах, а не требующие - на одной.
Тоже спасибо за информацию!

ппм
И еще - на текущий момент нет такой реальной потребительской задачи, которая не может быть выполнена в рамках одного SMP сервера топ-класса.
Гипотетические "а вот если..." не являются реальной задачей.
Тут позволю себе в корне не согласиться с Вами - дело в том, что такой задачи пока что "нет" именно потому, что люди ставят себе задачи ограничивая свою фантазию возможностями современных серверов. Но если снять это ограничение - тогда возникают интереснейшие задачи, которые чисто теоретически вполне реальны, просто под них СЕЙЧАС нет инженерно проработанных решений. И ВОЗМОЖНО такие задачи как раз и станут движком, который запустит создание СУБД нового поколения - если кто-то возьмется за их решение и сможет хоть как-то показать другим, что двигаться в эту сторону - реально.
30 авг 06, 19:14    [3073490]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Позвольте заметить, что Oracle RAC задумывался прежде всего как средство повышения надежности, а не производительности. У Оракла узлы кластера обращаются к единому хранилищу данных. При падении каких-либо узлов система остаётся способной отвечать на запросы в отличие от DB2 и MSSQL, где с потерей узла теряется часть данных на нём хранившихся.
Если посмотреть на tpc.org для OLTP, то видно, что кластерные конфигурации постились туда в последний раз в 2003 году. IBM вообще убрала свои результаты (по крайней мере я их не нашел для TCP-C).

--
Антон
Per rectum ad astrum
30 авг 06, 20:29    [3073715]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ggv
Member

Откуда:
Сообщений: 1810
да нет же, не для повышения надежности делался RAC (imho), если читать оракловый сайт.
RAC - это софтверная попытка реализации хардверных возможностей mainframe, и поэтому не состоятельна, а попросту бредовая, на числе узлов более четырех.
У того же оракла есть более дешевые средства повышения отказоустойчивости.
И опять же нет- по поводу пропадания данных, расположенных на засбоившей ноде. Mutual Takeover еще никто не отменял, так что данные будут "подхвачены" другой нодой, естественно с "элегантной деградацией" производительности.
Но обеспечение отказоустойчивости, доступности и безопастности при тысячах узлов - само по себе нетривиальная задача, хоть при рисовании воздушных замков обычно пропускаемая :)

По поводу ограниченности мышления - ой, вряд ли :)
Если бы кто увидел, что это даст денех - уже бы и задачу сформулировали, и ученых напрягли :)
Так что нет такой задачи, а если она есть, но прибыли не принесет - то ее значит нет, задача разряда гипотетических :)
30 авг 06, 20:43    [3073734]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Почитал про Mutual Takeover :)
лучше уж это, чем совсем ничего (HADR то оказывается не поддерживает кластер)
Вот только при падении одного узла его инстанс поднимается на другой ноде, которая теперь будет работать за двоих. Отсюда либо дикий свопинг, либо урезание распределения памяти, чтоб двоим хватило. А урезали память (раза в два) - вскорости получили ошибку "количество допустимых блокировок достигло максимума". И что - вторая нода фактически тоже перестаёт работать?

P.S.
меня всегда радуют ваши посты про mainframe - заряд хорошего настроения на весь день.

--
Антон
Per rectum ad astrum
30 авг 06, 23:40    [3074168]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ggv
Member

Откуда:
Сообщений: 1810
а вы попробуйте, с mutual takeover, особенно на V9.1
Ваше умозлоключение не оправдается.
Но про sysplex вы ничего не знаете, и не видели, что, впрочем, не удивительно [подредактировано модератором]
31 авг 06, 12:31    [3076061]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
трудно жить
Guest
Помню году так в 96, писали статьи что 4-х процессорного пентиум-про достаточно чтобы обрабатывать в реальном времени все финансовые операции небольшого государства типа бельгии, а теперь выясняется что есть широкие потребности в системах с 1000-ми серверов? Не верю (с) не мой.
31 авг 06, 21:49    [3079344]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
ппм
Guest
точно - писали, я тоже читал :)
1 сен 06, 09:18    [3079996]     Ответить | Цитировать Сообщить модератору
 Re: Существует ли СУБД для многомашинного кластера?  [new]
cardholder
Guest
Dimitry Sibiryakov

sysprg

Предположим, мне нужно решить типично СУБДшную задачу
многокритериального поиска на очень-очень большой базе данных к которой
поступает миллион запросов в секунду.

Для начала ответь (для себя в том числе) на два вопроса:
1) Очень-очень большая БД это сколько террабайт и откуда возьмется такая
прорва данных;
2) Кто и как будет посылать миллион запросов в секунду.
Posted via ActualForum NNTP Server 1.3


http://usa.visa.com/about_visa/newsroom/press_releases/nr257.html

Annually, Visa's global payment system handles more than 40 billion transactions, and processes payments in excess of $1.7 trillion (USD). Some 21,000 financial institutions and more than 20 million merchant locations are connected to VisaNet worldwide, and rely on Visa's payment systems to conduct commerce in 136 countries.
12 сен 06, 11:57    [3123127]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить