Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
up
http://infocenter.sybase.com/help/topic/com.sybase.dc00768_1501/html/ase_ce_ug/ase_ce_ug3.htm

ого, действительно shared-disk cluster. и блокировки и кеш синхронизует, красота

2sysmaster
если появится - будет интересно посмотреть.
11 янв 08, 19:31    [5142790]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
снова RAC опередел самую навороченную smp железячку
4 ноды Oracle/Sun Fire X4470, 4 Xeon X7560 processors / 32 cores показали 221020 SAPS
IBM Power System 780, 8 Processors / 64 Cores паказал 202180 SAPS

ЗЫ. крупнее 780, System 795 с 256-cores как я понял только пару дней назад начали продавать.
22 сен 10, 12:39    [9480911]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
кстати у RAC response time уже лучше чем у smp:
Average dialog response time: 0.86 seconds (RAC)
Average dialog response time: 0.98 seconds (IBM)
22 сен 10, 12:43    [9480946]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Бредятина
Guest
vybegallo
Yo!!
2vybegallo

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


Да это я уже понял. Грабель вы еще и издали не видали. Жвль, что действительно специалисты по RAC себя не обнаруживают - хотелось послушать людей от сохи, теоретиков мне и коллеги ЧАЛа больше чем достаточно.


Естественно. Вы же не способны ни один вопрос обсуждать по существу:) А с людьми от сохи, конечно, удобнее обсуждать форму, а не содержание:) Один человек от сохи расскажет почему лучше А (потому что в глаза не видел B), а другой - наоборот:)
24 сен 10, 19:06    [9499463]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
Почитал, остался в непонятках --- какой прок от обсуждения "абстрактной" масштабируемости, если разные задачи ведут себя совершенно по-разному при переходе с одной ноды на кластер, при росте кластера, да даже и просто при добавлении ядер. Более того, у нас были "бредовые" с точки зрения любого учебника случаи, когда "кластер" из 8 нод на одном восьмиядерном ящике и 1/8 памяти для каждой ноды обгонял просто "нормальную" базу на той же машине.

А вообще у нас самый большой экспериментальный кластер был 200*(Quad Xeon / 16Gb RAM), сейчас самый большой постоянно доступный публично --- 8 * (2*Quad Xeon / 32Gb RAM). Virtuoso Cluster Edition, разумеется. Исходя из того, что в Оракле не глупее нас люди сидят, не предвижу никаких необычных проблем, скажем, с RAC на 32-64 машинах.
30 сен 10, 23:23    [9533902]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
iv_an_ru
Более того, у нас были "бредовые" с точки зрения любого учебника случаи, когда "кластер" из 8 нод на одном восьмиядерном ящике и 1/8 памяти для каждой ноды обгонял просто "нормальную" базу на той же машине.

Согласитесь, это всё же означает, что в "нормальной" базе стоит что-то докрутить (хотя бы автоматическое распадание на восемь восьмушек).
2 окт 10, 21:01    [9542604]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
softwarer
iv_an_ru
Более того, у нас были "бредовые" с точки зрения любого учебника случаи, когда "кластер" из 8 нод на одном восьмиядерном ящике и 1/8 памяти для каждой ноды обгонял просто "нормальную" базу на той же машине.
Согласитесь, это всё же означает, что в "нормальной" базе стоит что-то докрутить (хотя бы автоматическое распадание на восемь восьмушек).
Рацуха, конечно, интересная, осталось только придумать, как при смене профиля загрузки то распадаться на восьмушки то слипаться назад, и всё это не прерывая обслуживание клиентов.
2 окт 10, 23:28    [9543116]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67525
Блог
В общем-то можно, но вряд ли это оптимальный путь. А вот где, почему и начиная с какого предела "нормальная" база тормозит по сравнению с "восьмушками" - имхо стоит тщательно изучить.
2 окт 10, 23:37    [9543164]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
iv_an_ru
Более того, у нас были "бредовые" с точки зрения любого учебника случаи, когда "кластер" из 8 нод на одном восьмиядерном ящике и 1/8 памяти для каждой ноды обгонял просто "нормальную" базу на той же машине.

если восьмиядерный ящик был нума то ничего удивительного.
3 окт 10, 02:10    [9543381]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
softwarer
В общем-то можно, но вряд ли это оптимальный путь. А вот где, почему и начиная с какого предела "нормальная" база тормозит по сравнению с "восьмушками" - имхо стоит тщательно изучить.
Да нечего там было изучать. Очень большая база с RDF и много-много юзеров, каждый из которых ковыряется read-only в одних и тех же "очень активных" данных плюс каких-то неповторяющихся "непопулярных". Под Linux, а у него есть противная особенность: просто вход и выход из мьютекса не стоят почти ничего, а вот начало ожидания на мьютексе стоит примерно столько же, сколько целая выборка строки по ключу. В случае кластера проблемы с мьютексами уменьшились настолько, что экономия перевесила даже IPC. Поскольку для такого эффекта нужно, чтобы сервер "лёг на полку", не справляясь с нагрузкой, на практике такой сценарий просто не должен встречаться.

(Потом появились деньги, и вместо одного ящика поставили 8. Как раз вовремя, потому что база подросла до 2.5e10 фактов, ну и юзеров ещё больше стало.)
3 окт 10, 08:41    [9543516]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3945
Yo.!
крупнее 780, System 795 с 256-cores как я понял только пару дней назад начали продавать.
ну вот появился результат теста для 795 - 384330 попугаев
10 окт 10, 18:42    [9583217]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Андрей Панфилов
Yo.!
крупнее 780, System 795 с 256-cores как я понял только пару дней назад начали продавать.
ну вот появился результат теста для 795 - 384330 попугаев


И опять RAC bite the dust ! :)
13 окт 10, 10:36    [9598155]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
Выбегалло

И опять RAC bite the dust ! :)

поставят чуть крупнее ноды и снова будут впереди. например 8-сокетов, а не 4. или как в прошлый раз 6 нод System 780
13 окт 10, 17:21    [9602148]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
Yo.!
поставят чуть крупнее ноды и снова будут впереди. например 8-сокетов, а не 4. или как в прошлый раз 6 нод System 780

как в воду глядел:

740250 saps на 6 x Sun Fire X4800 M2, 8 processors / 80 cores Xeon Processor E7-8870, 2.40 GHz
для сравнения самая большая железячка на сегодняшний момент:
688630 IBM Power 795, 32 Processors / 256 Cores POWER7, 4 Ghz

т.е. RAC всего на 6 копеешных узлах промасштабировался дальше самой большой железячки
14 сен 11, 22:50    [11278402]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
промасштабировался дальше
Guest
Yo.!
Yo.!
поставят чуть крупнее ноды и снова будут впереди. например 8-сокетов, а не 4. или как в прошлый раз 6 нод System 780

как в воду глядел:

740250 saps на 6 x Sun Fire X4800 M2, 8 processors / 80 cores Xeon Processor E7-8870, 2.40 GHz
для сравнения самая большая железячка на сегодняшний момент:
688630 IBM Power 795, 32 Processors / 256 Cores POWER7, 4 Ghz

т.е. RAC всего на 6 копеешных узлах промасштабировался дальше самой большой железячки

Что значит "промасштабировался дальше", кривая масштабирования лежит ниже чем у IBM?
Или в абсолютных величинах при прочих неравных?
14 сен 11, 22:58    [11278425]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
Yo.!
Guest
промасштабировался дальше
Что значит "промасштабировался дальше", кривая масштабирования лежит ниже чем у IBM?
Или в абсолютных величинах при прочих неравных?

в абсолютных. там товарищи в обсуждении выше утверждали, что RAC не сможет потянуть ту нагрузку, какую тянут взрослые SMP. а он не просто потянул, он переплюнул.
14 сен 11, 23:15    [11278450]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
промасштабировался дальше
Guest
Yo.!
промасштабировался дальше
Что значит "промасштабировался дальше", кривая масштабирования лежит ниже чем у IBM?
Или в абсолютных величинах при прочих неравных?

в абсолютных. там товарищи в обсуждении выше утверждали, что RAC не сможет потянуть ту нагрузку, какую тянут взрослые SMP. а он не просто потянул, он переплюнул.

Товарищи сверху много обобщают. В задачах с интенсивным обменом данными действительно SMP пойдет дальше, тут принципиальные особенности. А сравнивать надо на равных CPU, RAM и дисковой подсистеме.
Но если грамотно писать приложение и проектировать базу то в некоторых задачах RAC конечно сможет масштабироваться на сотни узлов.
14 сен 11, 23:30    [11278475]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
промасштабировался дальше
если грамотно писать приложение и проектировать базу то в некоторых задачах RAC конечно сможет масштабироваться на сотни узлов.
Кто б спорил.

Я уже в нескольких топиках по разным поводам описал один свежий кластер у клиента:
120 * (Quad Xeon / 8Gb / 10 * 1Tb HDD) +
144 * (2 * Quad Xeon / 16Gb / 2 * 128Gb SSD) +
8 * (4 * 10-core / 1024Gb ) +
хороший инфинибанд,

Что из подзадач совсем хорошо по горизонтали раскидывается --- пихается в первую группу кластера, что похуже --- во вторую, что совсем никак (матерные обходы графов, скажем) --- на 8 самых толстых айбиэмовых ящиков. Попытки обойтись без этих 8 ящиков радости не принесли, хотя программеры там, уж поверьте на слово, _очень_ грамотные.
15 сен 11, 00:10    [11278527]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
промасштабировался дальше
Guest
iv_an_ru
промасштабировался дальше
если грамотно писать приложение и проектировать базу то в некоторых задачах RAC конечно сможет масштабироваться на сотни узлов.
Кто б спорил.

Я уже в нескольких топиках по разным поводам описал один свежий кластер у клиента:
120 * (Quad Xeon / 8Gb / 10 * 1Tb HDD) +
144 * (2 * Quad Xeon / 16Gb / 2 * 128Gb SSD) +
8 * (4 * 10-core / 1024Gb ) +
хороший инфинибанд,

Что из подзадач совсем хорошо по горизонтали раскидывается --- пихается в первую группу кластера, что похуже --- во вторую, что совсем никак (матерные обходы графов, скажем) --- на 8 самых толстых айбиэмовых ящиков. Попытки обойтись без этих 8 ящиков радости не принесли, хотя программеры там, уж поверьте на слово, _очень_ грамотные.

Я так понимаю это единый гетерогенный виртузоный кластер, с инфинибандом 40 Гбит/сек.
А у вас как организован протокол обмена данными по инфинибанду, это RDMA, который действительно Direct через контроллер памяти в обход CPU?
И каков у вас характер нагрузки требующий айбиэмовские ящики, он диктует повышенные требования к маленьким задержкам или большой пропускной способности?
15 сен 11, 13:42    [11281103]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
iv_an_ru
пропущено...
Кто б спорил.

Я уже в нескольких топиках по разным поводам описал один свежий кластер у клиента:
120 * (Quad Xeon / 8Gb / 10 * 1Tb HDD) +
144 * (2 * Quad Xeon / 16Gb / 2 * 128Gb SSD) +
8 * (4 * 10-core / 1024Gb ) +
хороший инфинибанд,

Что из подзадач совсем хорошо по горизонтали раскидывается --- пихается в первую группу кластера, что похуже --- во вторую, что совсем никак (матерные обходы графов, скажем) --- на 8 самых толстых айбиэмовых ящиков. Попытки обойтись без этих 8 ящиков радости не принесли, хотя программеры там, уж поверьте на слово, _очень_ грамотные.

Я так понимаю это единый гетерогенный виртузоный кластер, с инфинибандом 40 Гбит/сек.

Он единый и гетерогенный, но под виртуозой там будет очень немного, порядка 16 "средних" ящиков, порядка 600Gb на дисках. Остальное --- разнообразные софтинки клиента, в основном самописные.
А у вас как организован протокол обмена данными по инфинибанду, это RDMA, который действительно Direct через контроллер памяти в обход CPU?
Мы только системные вещи юзаем, какой-то специальной поддержки именно инфинибанда в Виртуозе нет (равно как и "разумных" сетевых карт, SAN и т.п.). В наше оправдание могу сказать, что мы не мучаем ни IPC ни сеть кучами мелких пакетов, у нас туда-сюда бегают преимущественно большие буферы, причём процессы общаются "каждый с каждым", без "централизованных затыков".
И каков у вас характер нагрузки требующий айбиэмовские ящики, он диктует повышенные требования к маленьким задержкам или большой пропускной способности?
Я б так сказал: для каждого отдельного юзера важна как можно меньшая латентность, если задача векторизуется плохо, то время выполнения будет прямо пропорционально латентности. Мы б рады были взгромоздить всё на один толстый ящик вместо табуна более мелких, но тогда процы будут забиты, а две трети дорогущей памяти ящика будут простаивать вообще. Выходит, что 16 "средних" ящиков будут и дешевле и (для правильно написанных хранимок) ненамного хуже.

Если юзеров много, то они "сообща" могут, конечно, и сеть перегрузить, но на практике нам даже двух гигабитных эзернетов хватает, чтобы восьмиядерный ящик не простаивал, загрузка вроде 1 min avg load user 670% sys 50% wa 2% id 0% получается легко. Если взять обычный "комодный кластер" из 6--8 восьмиядерных "комодных" ящиков с дублированием (т.е. 6--8 пар ящиков с идентичными фрагментами БД на дисках в каждой паре), то на каждой дешёвой интеловской мамке для рабочих станций обнаружится аккурат два порта по 1000. Можно взять два "комодных" 16-портовых свича по $130 с внутренней пропускной 32Gb/sec (или 24-портовых с внутренней 48Gb/sec), в один воткнуть все eth0 всех ящиков, в другой все eth1, и на этом всё (не считая аплинков и ящика для бэкапов). При этом, скажем, если расковырять 16-портовый свич, то обычно обнаружится, что это фактически два 8-портовых свича, соединённых двухпортовым свичом, поэтому в каждой паре идентичных ящиков первый ящик надо воткнуть в порт с 1 по 8, а второй --- с 9 по 16, минимизируя число мелкосхем, которые будут добавлять латентность (и риск убить пакет вообще).
15 сен 11, 15:26    [11281998]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
iv_an_ru, а можно узнать что за задачи решаются?
15 сен 11, 16:02    [11282267]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
промасштабировался дальше
Guest
iv_an_ru,
1. Т.е. айбиэмовские ящики не под вашу систему брались?
2. Здесь понятно, движение в сторону гибкости, а не специализации. Предположительно значит задача не ставит необходимость в низколатентном доступе к большому количеству узлов для каждого запроса, при большом количестве запросов или пользователей. А получить все данные скопом в принципе выход.
У вас через "преимущественно большие буферы" между узлами данные передаются скопом для одной записи, таблицы, запроса или нескольких запросов за один раз?
3. Процы забиваются из-за ожиданий на мьютексах или из-за чего? Просто я ещё ни разу не видел что-бы используя СУБД память простаивала. Собственно всегда используется под кэш дисковой подсистемы.


Низкая латентность между узлами важна при низколатентном доступе пользователей по спец. протоколам или при сильном размазывании данных, т.е. большом количестве серверов.
Допустим каждый простой запрос требует сбора данных с 20% серверов. Тогда не используя специализированных средств передачи между узлами получим общее падение производительности до 20%. (Здесь конечно принимаем крайний случай когда нагрузка на межнодовый запрос равна нагрузки простого запроса пользователя)
Теперь если запросов не только много, но они ещё и относительно тяжелые, то потребуется сильнее размазывать данные. А значит увеличивая количество серверов сбор данных будет увеличиваться с 20% до 100%. Что и будет означать предел масштабирования.
Дублирование серверов же хорошо для read only и плохо для write.

Ну и оверхеды различных протоколов по сравнению с RDMA Infiniband конечно не маленькие. Латентность на RDMA можно достичь до 10мкс.
15 сен 11, 17:07    [11282721]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
SergSuper
iv_an_ru, а можно узнать что за задачи решаются?
конкретно эта инсталляция будет под базу знаний, порядка 50 гигафактов, плюс RDB2RDF из некоторых "посторонних" баз данных. Эти "посторонние" базы скоро будут мигрировать с расположенного рядом "старого" кластера в этот "новый", после чего "старый" кластер плюс его standby вместе станут standby-ем для критической части "нового". Данные там в основном узко-специально-научные, поэтому являются для меня абсолютно тёмным лесом, даже если куски попадаются мне на глаза :)
15 сен 11, 17:29    [11282880]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20368
iv_an_ru,
1. Т.е. айбиэмовские ящики не под вашу систему брались?
Нет, под толстые симуляции.
2. Здесь понятно, движение в сторону гибкости, а не специализации. Предположительно значит задача не ставит необходимость в низколатентном доступе к большому количеству узлов для каждого запроса, при большом количестве запросов или пользователей. А получить все данные скопом в принципе выход.
У вас через "преимущественно большие буферы" между узлами данные передаются скопом для одной записи, таблицы, запроса или нескольких запросов за один раз?
Для нескольких запросов (или ответов на них) в ходе исполнения одного или нескольких запросов.
3. Процы забиваются из-за ожиданий на мьютексах или из-за чего? Просто я ещё ни разу не видел что-бы используя СУБД память простаивала. Собственно всегда используется под кэш дисковой подсистемы.
Процы заняты полезным делом. Но если ставить эту конкретную задачу на один ящик с терабайтом ОЗУхи, то считайте сами --- 50 гигафактов в сжатых колонках, примерно по 6 байт на факт, дадут 300 гигабайт. На диске будет вдвое больше, 600 гигабайт, потому что для каждой страницы будут лежать её копия до последнего чекпойнта плюс текущая версия, но буферизовать даже в идеальном случае всего 300 гигабайт. Остальные 700 гигов надо было бы бы отдать под что-нибудь, но avg load под "нас" хотелось бы от 60 и выше, а ядер и так всего 40.
Если б нам на растерзание дали ящик, скажем, с 80 ядрами и 384 гигами ОЗУхи, мы б не отказались, а так совсем неразумно по деньгам.
Тем более, что они хотят на нём прогнать BSBM / BIBM / TPC-H / RDF-H, и нам совсем не улыбается увидеть публичные отчёты с издевательски большими $/QMpH и $/QphH.
Ну и оверхеды различных протоколов по сравнению с RDMA Infiniband конечно не маленькие. Латентность на RDMA можно достичь до 10мкс.
Заплатят за допиливание --- прикрутим тот быстрый IPC, который они выберут. С удовольствием. Тем более что наш протокол восстанавливает ошибки сам, ему от нижнего слоя достаточно "UDP" без гарантий доставки и сохранения порядка, а не целого "TCP".
15 сен 11, 17:49    [11283053]     Ответить | Цитировать Сообщить модератору
 Re: Поговорим о масштабировании  [new]
промасштабировался дальше
Guest
iv_an_ru
Процы заняты полезным делом. Но если ставить эту конкретную задачу на один ящик с терабайтом ОЗУхи, то считайте сами --- 50 гигафактов в сжатых колонках, примерно по 6 байт на факт, дадут 300 гигабайт.

А запросы тратят CPU больше всего на индексный поиск, агрегацию, скалярные функции или на внутренние нужды?

iv_an_ru
Тем более, что они хотят на нём прогнать BSBM / BIBM / TPC-H / RDF-H, и нам совсем не улыбается увидеть публичные отчёты с издевательски большими $/QMpH и $/QphH.

Если они это IBM, то ничего удивительного :)
15 сен 11, 18:36    [11283428]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить