промасштабировался дальшеiv_an_ruПроцы заняты полезным делом. Но если ставить эту конкретную задачу на один ящик с терабайтом ОЗУхи, то считайте сами --- 50 гигафактов в сжатых колонках, примерно по 6 байт на факт, дадут 300 гигабайт.
А запросы тратят CPU больше всего на индексный поиск, агрегацию, скалярные функции или на внутренние нужды?Это уж от запросов зависит, ну и хранимки сами по себе тоже жрут хорошо, тем более что есть ведь и такие "длинные" функции, как применение XSLT или обогащение HTML-ного документа дополнительными сылками.
промасштабировался дальшеiv_an_ruТем более, что они хотят на нём прогнать BSBM / BIBM / TPC-H / RDF-H, и нам совсем не улыбается увидеть публичные отчёты с издевательски большими $/QMpH и $/QphH.

Если они это IBM, то ничего удивительного :)Нет, не IBM, хотя тоже три буквы. Как отчёты опубликуют, так можно будет и сказать, кто.

модель представления данных iv_an_ru , кстати у вас виртуоза это СУБД с вертикальным хранением RDF, блокировочник и с кластером архитектуры MPP(shared nothing)?Да, это "жёсткий" блокировочник и shared nothing cluster, версии до седьмой умеют только горизонтально хранить, седьмая (пока ещё не общедоступная) умеет и вертикально хранить (причём не только RDF :). Ну а главный источник доходов --- виртуальная схема, в которой для разработчика приложений нет разницы между таблицами, хранящимися на самой виртуозе и таблицами, лежащими на присоединённых серверах других вендоров.

модель представления данныхА что значит "жесткий" блокировочник? :)Он даже не пытается как-то переупорядочить транзакции, чтобы уменьшить число роллбэков или сделать ещё что умное. Как результат, среди транзакций полная "дедовщина" --- если случается дедлок, то всегда откатывается та транзакция, которая к этому моменту захватила меньше данных, без каких-либо "смягчающих обстоятельств". Для защиты от слишком блокирующих запросов есть "anytime query" --- можно указать, что запрос не должен нормально выполняться дольше такого-то времени, по достижении таймера у запроса возникает иллюзия, что все таблицы внезапно "опустели", и он волей-неволей возвращает частичный результат. Зато при необходимости транзакции могут длиться часами, хорошо бегают распределённые транзакции и checkpoint проходит совершенно незаметно для всех транзакций.

модель представления данныхКстати у вас каждая нода владеет своим куском данных и не может передавать их на владение другой ноде как в Oracle RAC, поэтому необходимость в синхронизации блокировок есть только между дублирующими серверами?Совершенно верно. При этом есть возможность эскалации блокировок (автоматической замены многих строковых одной страничной) + возможность создавать частичные индексы + для маньяков возможность на уровне приложения писать в разные индексы таблицы отдельными операторами. Всё это снижает затраты на синхронизацию.

модель представления данныхiv_an_ru возможность создавать частичные индексы + для маньяков возможность на уровне приложения писать в разные индексы таблицы отдельными операторами. Всё это снижает затраты на синхронизацию.
Частичные индексы - это partial index по диапазонам так понимаю.Это когда в индексе есть только некоторые из колонок primary key, напр.

В таком варианте если будет поиск по таблице с условием S=const, то сначала в RDF_QUAD_SP будут найдены все P, которые встречаются в RDF_QUAD вместе с данным значением S, и потом уже будут поиски в P,S,O,G по двум первым заданным колонкам.
А если только G известно, то ищем G в RDF_QUAD_GS, потом S в RDF_QUAD_SP, потом P и S в P,S,O,G c проверкой G. При этом неполные индексы настолько малы, что ложатся в память, а полных индексов всего два вместо четырёх.

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


Упрощение взаимодействия по идее должно сильно повысить масштабируемость.

Кстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?[/quot]

модель представления данныхУпрощение взаимодействия по идее должно сильно повысить масштабируемость.
Ещё б совпадали "упрощение для машины" и "упрощение для разработчика" :(
модель представления данныхКстати, примерно во сколько раз получается выигрыш в производительности от применения вертикального хранения, в 2, 5, 10, 100?Выигрыш там в памяти. На если после этого активное подмножество начинает целиком умещаться в память, а диск только обновления пишет, то и по скорости выигрыш образуется.

Я вот тут подробней рассказывал, правда не совсем СУБДшникам: Облако и куб: RDF в аналитической базе данных , и тут в конце тоже ссылки на русскоязычные конспекты по RDF/SPARQL .

модель представления данныхНа сколько я понял для RDF было отставание в 3 раза от реляционной модели, а после применения работ Абади стало примерно равно?
...
Раньше реляционные сжимались лучше, а сейчас при вертикальном хранении данные сжимаете и насколько хорошо они сжимаются относительно реляционной модели?
При старом "горизонтальном" хранении TPC-H масштаба 1G ложился в 140000 страниц, RDF-H того же масштаба жрал 630000 страниц.
При новом "вертикальном" хранении тот же TPC-H усох до 90000 страниц, а RDF-H --- до 250000 страниц.

модель представления данныхИ "производительность по RDF-H наконец-то оказалась сравнима с производительностью TPC-H" уже с учетом того, что в реляционной модели также применили вертикальное хранение или в реляционной оно не дает заметного выигрыша?
RDF никогда не догонит "классику" по масштабируемости и по скорости. Но он не догонит на тех задачах, на которых классические методы _применимы_. Когда в базе знаний что-то сделать _можно_, а в базе данных --- _нереально_, уже как-то не важно, во сколько раз база данных была бы быстрее, будь это реально. В итоге будущее, безусловно, за гибридами, чтобы разработчики приложений могли для каждого куска использовать наиболее подходящую комбинацию инструментов.
Ну а пока сообщество старательно делится на СУБД-шников и СУБЗ-сников. Это такой же идиотизм, как если бы строители делились на сторонников использования одних только кирпичей и сторонников использования одного только цементного раствора --- и это после изобретения нормальной кладки :)

RDF-H --- это как раз тест, показывающий самый плохой случай для RDF, если сравнивать с классикой. Методы разгона TPC-D (и теперь TPC-H) полировались десятилетиями, и это ровно то, для чего SQL и создавался в первую очередь. В то же время тупой экспорт этих данных в RDF-H и "лобовой" перевод запросов из SQL в SPARQL не демонстрирует никаких преимуществ базы знаний, они разрабатывались для другого.

модель представления данныхКстати, а почему вы говорите "К тому же эта мера ускоряет чтение с жёсткого диска, но не снижает требований к размеру ОЗУ." В чем проблема хранить в ОЗУ сжатые данные?Чтобы и в памяти хранить сжатые данные, надо многократно разжимать их большими кусками. Это не только расходует время само по себе, но и забивает кэш процессора, что чревато падением производительности остального кода буквально на порядок.

модель представления данныхВ принципе да. Здесь вопрос в том насколько действительно большой разрыв в производительности систем хранения и исполнения. И насколько неоднородно идет обращение к данным.
Если к одним данным идет в 100 раз больше запросов чем к другим, то да.
Если достаточно однородно, то в любом случае расжать из ОЗУ будет быстрее чем поднять с диска.
Когда-то давно, когда для "крутых персоналок" стандартом были 2 мегабайта ОЗУ, продавал я одну расчётную софтинку, которая просила возмутительные 4 мегабайта ОЗУ. Потом вылез у меня конкурент, который стал как раз сжимать данные, и для многих задач стал укладываться в обычные 2 мегабайта. Обычная задачка у меня обсчитывалась за обеденный перерыв, у него --- за ночь.
Закопал я "вражину" простым демпингом. Если клиент ворчал, что вот люди и на двух считают, и его задача действительно со сжатием влезала в 2 мега, то я обещал ему при покупке моей программулины подарок --- недостающие два мега.

...тогда я пообещал себе, что никогда не буду пытаться сжимать память...

модель представления данных iv_an_ru , я согласен, хорошая метафоричная история.
Но допустим доступ к дисковому массиву 600 МБс, доступ к памяти четырехканальной 40 000 МБс, итого примерно 100 раз. Допустим всего ОЗУ 64 ГБ, допустим половина под дисковый кэш (32 ГБ).
Что лучше, иметь доступ к 32 ГБ со скоростью 40 000 МБс (в 100 раз), или к 64 ГБ со скоростью 4 000 МБс (в 10 раз)?
Причем мы говорим именно про дисковый кэш, а не всю память сжимать-разжимать ;)
И причем 600 МБс это последовательные IO к диску, а случайные 60 МБс, т.е. разница будет нет 100 и 10, а 1000 и 100 раз ;)
Рассмотрим грустный пример. Нужно вам сделать index lookup, взять целое поле по целому ключу, 160 байт на одну строку таблицы, 50 строк в странице.

Несжатая память: вы двоичным поиском дёргаете 8 слов плюс девятое слово-значение, и перед тем "нулевое" слово --- версия индекса, с которой создавалась страница и всякие флаги. Трафик 10 64-битных строк кэша проца, readonly.

Сжатая память: вы разжимаете 8 килобайт (т.е. 1000 строк кэша проца) в 16 килобайт (ещё 2000 строк, причём записи, за что NUMA подтормозит дополнительно). Итого только непосредсвенные затраты на трафик в 400 раз больше --- из 4000 перелопаченных строк реально понадобятся только 10. Такой КПД приводит к тому, что условные 40 000 МБс принесли полезных данных всего-то 100МБс, что удручающе похоже на приличный массив дисков.
А ещё мы нагадили в кэш проца, ну и вообще проц заняли "чем попало", потеряв в скорости.

Получается, что для сжатых страниц дискового кэша в памяти надо завести ещё кэш разжатых страниц. И снабдить всё это подобающими мьютексами (на которых тоже будут случаться тормоза).
Оно того не стоит, чесслово.

Вывод. Если денег на ОЗУ жестоко не хватает, то нужно ещё немножко урезать ОЗУ, а на сэкономленное купить SSD.

модель представления данныхiv_an_ru в 16 килобайт (ещё 2000 строк, причём записи, за что NUMA подтормозит дополнительно).

А тут NUMA подтормозит в предположении, что проц может писать не в свою память или из-за выяснений куда писать?Из-за распространения "разметки загрязнений", чтобы другие процессоры пометили строку в кэше как устаревшую, если она содержит данные из свежезаписанного куска памяти.
модель представления данныхiv_an_ruИтого только непосредсвенные затраты на трафик в 400 раз больше --- из 4000 перелопаченных строк реально понадобятся только 10. Такой КПД приводит к тому, что условные 40 000 МБс принесли полезных данных всего-то 100МБс, что удручающе похоже на приличный массив дисков.

В принципе да, только если уж говорим про кэш проца, то это уже не 40 000 МБс и 100 МБс, а на пару порядков больше :)
Но в любом случае конечно index lookup здесь не выиграет.
А вот index scan вполне бы мог ;)Мы говорим про чтение в кэш проца из памяти, а не регистров из кэша. А index scan на большом масштабе... Если что-то не работает _ваапще_, то уже не важно, с какой именно скоростью оно не работает :) Вот на некоторых графических задачах действительно "index lookup" по "плиткам" изображения, там да, успешно сжимают именно память. Классический пример --- RIP на типографских фотовыводителях, особенно постскрипта.

отличие RDF от EAV iv_an_ru ,
А в чем отличие RDF от EAV или это синонимы?RDF --- это стандартизованный (потому переносимый) вариант EAV-представления. Я на одном семинаре рисовал разные варианты представления классического "мира кубиков" . Из всех вариантов просто победил самый ограниченный, зато дешёвый :)

модель представления данныхiv_an_ru А index scan на большом масштабе... Если что-то не работает _ваапще_, то уже не важно, с какой именно скоростью оно не работает :)
А вот это не совсем понял.С ростом базы обычно падает доля предикатов, которые давали бы значения в некоторых коротких диапазонах. Или фильтрация даёт почти уникальные (в масштабе базы) значения, и они оказываются раскиданы очень далеко друг от друга, или фильтрация оставляет такое количество значений, что их за разумное время обработать невозможно вообще --- за время обхода базы либо данные устареют, либо ответ уже не будет нужен, либо осёл/дрессировщик/падишах помрёт. Немудрячий запрос "сумма стоимостей междугородных звонков за сегодня" прекрасно сработает на сырых данных офисной АТС, но невозможен для China Mobile.

(набрал длинный ответ, но случайно нажал Ctrl-A вместо Shift-A, и продолжил набор :(

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