iv_an_ruдонкихотА подобие SQL это RDF?Это в любом случае неверно. SQL/RDF = type error :) Точнее было бы сказать SQL/SPARQL = EAV/RDF .
Интересно, что имелось ввиду под "подобие SQL". SQL не может быть подобием самого себя, с Text или XML мало чего общего. Остается RDF.

iv_an_ruдонкихотпропущено...

А у вас любая Virtual Data Base может работать с абсолютно любым Unified Storage Model?Не понял вопрос. Виртуальная схема позволяет просто прицепить "посторонние" таблицы к своей схеме и использовать в запросах, скрывая от приложения местонахождение тех или иных данных. А Unified Storage Model это просто "рекламный" термин такой , означающий что те сервисы, которые обычно делаются над файловой системой и те ресурсы, которые обычно сваливают в файлы, держат все данные в реляционных таблицах и эти данные доступны для хранимок на PL и hosting languages.
То есть модель хранения у вас одна, реляционная колончатая, а термин Unified Storage Model просто обозначает, что любая из Virtual Data Base может обращаться к единой модели хранения?
Не совсем понятно, зачем тогда вообще в Unified Storage Model какие-то аббревиатуры вписали и особенно странно смотрится SQL как модель хранения :)

iv_an_ruдонкихотТо есть модель хранения у вас одна, реляционная колончатая, а термин Unified Storage Model просто обозначает, что любая из Virtual Data Base может обращаться к единой модели хранения?
Не совсем понятно, зачем тогда вообще в Unified Storage Model какие-то аббревиатуры вписали и особенно странно смотрится SQL как модель хранения :)Моделей хранения несколько --- строки, колонки, XML-и как "родные" объекты с индексацией, RDF, сейчас вот расширяем поддержку пространсвенных заморочек. При этом содержимое XML-ей или RDF-ов может быть представлено в SQL-ных видах, реляционные данные могут быть основой для XML Views и RDF Views, DAV-клиент может загружать ресурсы прям в RDF-хранилище и т.п. Возможных комбинаций представлений "на диске" и представлений "для приложения" набирается довольно много.
А у вас на весь тейблспейс/схему именно только либо чистые строки, либо чистые колонки?
Или есть гибридный PAX: http://www.dbms2.com/2009/08/04/pax-analytica-row-and-column-stores-begin-to-come-together/
И жмете вы блок/страницу данных целиком с фиксированным начальным или конечным размером?

iv_an_ruдонкихотА у вас на весь тейблспейс/схему именно только либо чистые строки, либо чистые колонки?
Нет, на каждый индекс каждой таблицы по отдельности. Так же как в случае кластера на каждый индекс возможет выбор между репликацией, фиксированным шардингом и эластичным шардингом.
А в случае кластера всегда соблюдается правило, что для любой строки её полностью (все поля) можно получить с одного сервера?
iv_an_ruдонкихотИ жмете вы блок/страницу данных целиком с фиксированным начальным или конечным размером?Фиксированный "разжатый" размер для построчных индексов и LOB, фиксированный "промежуточный" размер для колонок и битмап индексов.
А промежуточный это что такое? :)

iv_an_ru, т.е. как раз первый раз жмете словарным алгоритмом, а второй раз snappy?
А все-таки, почему не взяли PAX и не стали жать как в Oracle ?

iv_an_ruдонкихотiv_an_ru, т.е. как раз первый раз жмете словарным алгоритмом, а второй раз snappy?
А все-таки, почему не взяли PAX и не стали жать как в Oracle ?Там не словарный, но подробности реализаци и причины "почему так а не эдак" я бы не хотел рассказывать раньше, чем у этой коммерческой версии появится опенсорсный вариант. Хоть язык и чешется :)
Хотя бы понятно, что тестировали и нашли плюсы по сравнению с оракловой, а не то что просто не успели реализовать :)
А у вас кстати система под банковские OLTP задачи, в частности под карточный процессинг не применяется?

iv_an_ruдонкихотА у вас кстати система под банковские OLTP задачи, в частности под карточный процессинг не применяется?Вряд ли. Миддлварные СУБД стараются использовать только там, где это технически необходимо, потому что это или лишние затраты на более редких специалистов или затраты на освоение человеком лишнего софта, и всегда более частые обновления потому что чем больше у СУБД интерфейсов, тем чаще она страдает от изменений стандартов на эти интерфейсы. Так что если банковскую задачу можно решить СУБД от большого вендора, то он и будет выбран.

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

А вот, скажем, для гейта, через который в своё время проходила примерно половина SMS, отправлявшихся в Европе с компов, Виртуоза пошла на ура. Чтобы совместить OLTP с таким зоопарком разных чужих API, оказалось практичней взять именно миддлварь.

То есть вопрос в переплате за неиспользуемые миддлварные возможности, а не в пригодности для OLTP.
Мидлварная СУБД чем хороша, что на неё легче всего перенести любое приложение, чем на любую другую СУБД. Т.е. легкий вопрос миграции позволяет протестировать её в качестве разных задач и если она покажет себя хорошо, то перейти на неё.
Если у неё множество интерфейсов, богатый SQL и функционал, то процесс доказательства её превосходства намного короче, чем сравнение между собой Oracle<->MSSQL<->DB2 на одном приложении. Т.е. весь вопрос: есть ли превосходства в скорости и насколько грамотный маркетинг.
Конечно кластер-MPP это не совсем про OLTP, но если она хороша на NUMA, то вполне могла бы подойти под OLTP задачи на Aix, а под DSS на кластере-MPP и подавно.

iv_an_ruдонкихотМидлварная СУБД чем хороша, что на неё легче всего перенести любое приложение, чем на любую другую СУБД. Т.е. легкий вопрос миграции позволяет протестировать её в качестве разных задач и если она покажет себя хорошо, то перейти на неё.
Если у неё множество интерфейсов, богатый SQL и функционал, то процесс доказательства её превосходства намного короче, чем сравнение между собой Oracle<->MSSQL<->DB2 на одном приложении. Т.е. весь вопрос: есть ли превосходства в скорости и насколько грамотный маркетинг.Превосходства в скорости начинаются, когда логика приложения по максимуму трамбуется в одну миддлварь, когда накладных расходов на IPC нет по той причине, что процесс один. Но это означает большую разработку на экзотической платформе, со всеми сопутствующими переплатами персоналу и рисками мёртвой привязки к одному вендору.
Основное требование карточного процессинга как раз то, что он должен трамбоваться в одну СУБД на одном большом NUMA-сервере, с возможностью Hot StandBy.
Имелось ввиду один процесс на всю мидлварь на все коннекты? :)

iv_an_ruЕсли кто целиком всё нужное для любого банка напишет на виртуозе, чтоб инсталлировал из коробки, БИК-SWIFT-IBAN прописал в конфиг и на этом "разработка" закончена --- тоже, наверное, будет продаваться :)
Вот если бы она понимала оракловый диалект, пусть даже по ODBC и без хинтов в комментариях :)
Ведь очевидно, что любой инвестор сначала запросит тесты, и чем легче перенести приложение, тем дешевле тесты - тем больше шансов, что их проведут. А дальше уже по их результатам.

Ну нифигасебе заявы!донкихотОсновное требование карточного процессинга как раз то, что он должен трамбоваться в одну СУБД на одном большом NUMA-сервере, с возможностью Hot StandBy.
Имелось ввиду один процесс на всю мидлварь на все коннекты? :)

Да да, и все банки в мире - все дружно в эту одну СУБД ходят?


Что мешает банк логически поделить на 1024 подбанка, у каждого - по своей базенке? Подумай логически.
Сбербанк + Альфабанк + ВТБ и Сбербанк1 + Себрбанк2 + Альфа + ВТБ, в чом разница, с т.з. VISA?
Если бы приложения писались исключительно грамотными специалистами, то есть в ваших словах доля правды. Но в реальности вендоры приложений не во всех версиях заявляют поддержку даже Shared Everything (Oracle RAC), чего уж там говорить про SharedNothing/MPP.
Карточный процессинг это не DWH, где пару таблиц фактов занимают более 90% используемых данных и репликация справочников мелочь. Здесь справочники занимают больше половины и почти никакие из них не могут быть секционированы/шардированы "вслед за фактами".

iv_an_ruдонкихотпропущено...

Основное требование карточного процессинга как раз то, что он должен трамбоваться в одну СУБД на одном большом NUMA-сервере, с возможностью Hot StandBy.
Имелось ввиду один процесс на всю мидлварь на все коннекты? :)В идеале --- да :) Хотя можно и кластер с балансировкой, так уж и быть :) Но главное, чтобы все HTTP/DAV/FTP/NNTP/SOAP/что-там-ещё не валялись в отдельных процессах, а как минимум хостились самой виртуозой, как максимум --- были написаны на Virtuoso/PL. какой смысл разгонять до упора исполнение отдельной транзакции, если весь комплекс будет скучать в ожидании IPC?
Тут требования упрощаются до того, чтобы все, что касается одного конекта было в одном процессе.

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

the thorдонкихотКарточный процессинг это не DWH, где пару таблиц фактов занимают более 90% используемых данных и репликация справочников мелочь. Здесь справочники занимают больше половины и почти никакие из них не могут быть секционированы/шардированы "вслед за фактами".



Это кто еще за справочники такие?
Это которые между собой имеют связь многие со многими.

Проясним ситуацдонкихотпропущено...

Это которые между собой имеют связь многие со многими.

Какой глубокомысленный, высококвалифицированный и всеобъемлющий ответ, спасибо!

Но вот конкретно привести пример M:N справочника можно? Название его?
Который ну никак не поддается репликации на 1024 ноды?
Простейший пример, при снятии денег в таблицу пишутся записи ссылающиеся на справочник с карточками и справочник с точками съема денег. С любой карточки можно снять с любого банкомата/магазина/...
Вот вы бы все 3 таблицы по какому ключу их секционировали?