alexeyvg, прежде всего спасибо за ответы.

alexeyvg1) Да, система другая. Это не MSSQL, который поставляется в комплекте с железом. PDW в общем несколько по другому программируется.
2) (PDW 2014) Не выпустили ещё.
3) Hadoop там - это просто дополнительная возможность. PDW расчитан на большие хранилища, а там есть такой модный Hadoop - ну вот его туда и впихнули.
Я подозреваю, что 2) следует из 1). У Oracle с Exadata другая история. Бинарники базы данных ничем не отличается от обычного Oracle. Отличая, по сути, в одном параметре, который разрешает или запрещает уникальные функции Exadata. Эти уникальные функции реализованы в Exadata Software.
alexeyvgMS не видит причин делать такие поставки - есть тесное сотрудничество с основными вендорами, у них есть мощнейшие суперсерверы, системы хранения, в т.ч. многоуровневые, у MS есть некие алгоритмы выбра сбалансированного железа для одстижения высокой производительности (не смог быстро найти, не помню точное название).У Orale есть такое. Называется Oracle Optimized Warehouse . Но это совсем не то.

alexeyvg4) "Просто перенести" нельзя, PDW требует отдельных подходов (код нужно менять, и модель днных); как я выше уже написал, PDW - это не поставка MSSQL в комплекте с железом.
А PDW - это именно другой подход к построению хранилищь. Честно говоря, я думал, что Exadata - тоже другой подход, а не комплект желехо+СУБД.Exadata - состоит из обычной СУБД Oracle, железа и главное, Exadata Software (основной profit для хранилища создает именно Exadata Software)

alexeyvgА Oracle Exadata на российском рынке встречали (просто интересно)? ИМХО мало таких систем на рынке. Одно внедрение PDW точно идёт (у моих знакомых), есть ли ещё - не в курсе...Exadat в России уже очень много. Цифры называть не могу, сорри. Публичная информация вот тут есть, например.

Ivan DurakAlexander RyndinИнтересно было посмотреть, как PDW себя ведет при попытке лить и читать данные одновременно. Для многих современных MPP это серьезная проблема.
В чем и кого проблема?Сейчас многие хранилища строится согласно вот такой архитектуре (привожу от Oracle, но то же самое есть и у других вендоров). Ниже картинка.
Если посмотрите, то
- данные льются в stage, в том числе в real-time
- внизу есть такая штука как Analytical Discovery, которая ходит в том числе и к stage
- на рисунке не показано, но есть еще и оперативная отчетность, которая работает с данными, не обработанными ETL, ибо нужно real-time, а на источниках такую отчетность запускать нежелательно
- в больших хранилищах большую часть загрузки стараются делать из stage, наполняемого CDC, а не ETL. Связано это в том числе с режимом 24/7 на источниках. У многих сейчас уже не хватает ночного batch window для полной проливки хранилища, а всем хочется иметь хранилище -1, а не -2.

Вот и возникает потребность одновременно писать данные в stage с помощью того же GoldenGate и параллельно анализировать их в Online Reporting, Discovery, а также без проблем забирать данные в следующие слои хранилища в любой момент времени.

.

Ну да, главное. Exadata спокойно работает в такое режиме, ибо Oracle.

Ivan Durak,

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

По поводу дороговизны хранения на mpp. Минимальная exadata (1/8) уже имеет на борту 72 Tb сырого пространства.

А oltp нагрузка для неё семечки за счёт большого флеш кэша

Ivan DurakВо-первых это етл ни чем не сложнее чем если бы реплика писала нам прямо в mpp !! Он такой же, только источник лежит подальше.Стоп, стоп, стоп. Если я делаю репликацию с помощью GoldenGate, то копию базы плюс историю на Exadata я получаю вообще не делая никакого ETL. 2 дня работы. Вам же, чтобы вынести отчетность на нормальную базу с Intraquery-параллелизмом приходится наворачивать ETL.
Ivan Durak Stage у вас, как я понял, по прежнему на mpp. Он нужен для оперативной отчётности, а значит вряд ли вы там что агрегируете. Отсев ненужных данных делается ещё на источнике при захвате репликацией. Да и железо под вашу реплику вряд ли будет дешёвое.

Железо под оракл или постгрес в разы дешевле чем железо под нетизу или ексадату !! Вам ли не знать.Подождите. Ну вы ведь все равно держите stage на mpp, который является источником для оперативной отчетности? Вы просто впереди ставите еще одну железку, с еще одной базой.

Ivan DurakПо поводу дороговизны хранения на mpp. Минимальная exadata (1/8) уже имеет на борту 72 Tb сырого пространства.
А oltp нагрузка для неё семечки за счёт большого флеш кэша
72 тб не так уж и много, а у какой-нить нитиззы вообще расширение объема не предусмотрено - целиком менять все.
Во-вторых рад за эксадату конечно (хотя опять же не вижу смысла нагружать ее этими онлайн репликами), но пардон в доброй половине mpp даже индексов нет, а апдейты с делитами ложат перформанс в ноль. А у какой0нить вертики и не предусмотрены вообще.Ну я согласен про классические MPP. В них нельзя делать прямую репликацию.
72 ТБ, по моему, очень даже неплохо, если еще и учесть, что холодны данные жмутся поколоночно, что сокращает данные раз 5-8. Не так уж и много на территории бывшего СССР хранилищ такого объема. Да и, опять таки, 72 Тб - это 1/8, которая парой команд превращается в 1/4. Либо в любой другой объем в online.
Ivan Durakа в третьих наша архитектура универсальна и удобна и масштабируема
реплику можно писать и не на один сервер, а хоть на столько сколько источников и даже больше.Обычно универсальность - это обратное сторона низкой производительности.