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

А вообще у нас самый большой экспериментальный кластер был 200*(Quad Xeon / 16Gb RAM), сейчас самый большой постоянно доступный публично --- 8 * (2*Quad Xeon / 32Gb RAM). Virtuoso Cluster Edition, разумеется. Исходя из того, что в Оракле не глупее нас люди сидят, не предвижу никаких необычных проблем, скажем, с RAC на 32-64 машинах.

softwareriv_an_ruБолее того, у нас были "бредовые" с точки зрения любого учебника случаи, когда "кластер" из 8 нод на одном восьмиядерном ящике и 1/8 памяти для каждой ноды обгонял просто "нормальную" базу на той же машине.Согласитесь, это всё же означает, что в "нормальной" базе стоит что-то докрутить (хотя бы автоматическое распадание на восемь восьмушек).Рацуха, конечно, интересная, осталось только придумать, как при смене профиля загрузки то распадаться на восьмушки то слипаться назад, и всё это не прерывая обслуживание клиентов.

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

(Потом появились деньги, и вместо одного ящика поставили 8. Как раз вовремя, потому что база подросла до 2.5e10 фактов, ну и юзеров ещё больше стало.)

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

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

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

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, минимизируя число мелкосхем, которые будут добавлять латентность (и риск убить пакет вообще).

SergSuperiv_an_ru, а можно узнать что за задачи решаются?конкретно эта инсталляция будет под базу знаний, порядка 50 гигафактов, плюс RDB2RDF из некоторых "посторонних" баз данных. Эти "посторонние" базы скоро будут мигрировать с расположенного рядом "старого" кластера в этот "новый", после чего "старый" кластер плюс его standby вместе станут standby-ем для критической части "нового". Данные там в основном узко-специально-научные, поэтому являются для меня абсолютно тёмным лесом, даже если куски попадаются мне на глаза :)

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".