Я думаю еще и Юра не согласится с пользой хинтов.

И правильно сделает. Зачем они нужны, если есть хороший оптимизатор. Вижу, Вам этого не понять, поскольку Вы к ним уже привыкли.
Вспомните основной принцип декларативного языка SQL - надо сказать базе ЧТО делать, а не КАК это делать. Ну, да ладно об этом. К тому же, похоже, он частично согласился ради политкорректности :)

Для чистого OLAP'щика это раздражающий фактор. Никой Imputu не сделать DWH так как сделает спец в TSQL, даже с 3х летним опытом.

Я - не чистый олапщик, Impromptu - вообще не OLAP-средство.
Простой генератор отчётов. В Альфабанке сначала на нём начали отчёты делать, но когда поняли, что мало-мальски сложный запрос с его помощью сделать невозможно, перешли на ручное написание SQL. Ох, и геморрой это, я Вам скажу отлаживать SQL. Поэтому я больше полагаюсь на тулзы, которые хорошо генерируют SQL. Мне это как-то удобнее. Хотя и SQL могу написать когда нужно.
Про спец с 3х-летним опытом скажу так - если тулза позволяет нормально генерирть SQL, а оптимизатор его нормально переваривает, то этот спец с тулзой за один день сделает отчётов гораздо больше, чем без тулзы за месяц.


Спец с 5 летним опытом сделает заточенный DWH c использованием хинтов и др. особенностей MS SQL так, что он будет работать в 1,5-2 раза быстрее.

Не исключаю, что каста танцующих с бубнами - это особые люди и простым смертным до них далеко :))

Это по-моему вторая серия по Oracle на 200 млн. фактов. Приведите пример SQL-запроса. Чудес на свете не бывает.

Там, по-моему, не было разговора про 200 миллионов фактов. Запрос надо поднять. Покопаюсь, когда найду приведу за руку в пример :)


Это воспринимать как оправдание слабости индексирования Терадаты? Счастливо вам full-сканом найти элемент в измерении на 2 млн. абонентов.

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

Давайте проведём небольшой экскурс в мир индексов Терадаты.

Бывают следующие виды индексов:
1. PI - первичные (хэш-индексы, используются для равномерного распределения данных по AMPам и для быстрого доступа по столбцам, определяющим PI).
Бывают:
а. PPI - Partitioned Primary Index (помимо хэш-партишионга можно дальше их разбить по какому-то условию, иногда это помогает повышать производительность, иногда - нет). Про PPI можно почитать здесь .
б. NPPI - Non-Partitioned Primary Index - обычные дальше не разбиваются
Бывают:
а. Уникальными
б. Неуникальными

В итоге получаем четыре комбинации - UPPI, UNPPI, NUPPI, NUNPPI.
Работа с ними ведётся по-разному.

2. Вторичные индексы - Secondary Index
Хранятся в виде суб-таблиц так же, как и обычные таблицы. Как я уже писал, двоичные деревья не используются.
Бывают:
а. Уникальные - USI
б. Неуникальные - NUSI
Соответственно, обрабатываются по-разному.

3. Джойн-индексы.
Напоминают Materialized View и агрегированные таблицы, поскольку физически хранят предварительно соединённые таблицы, порезанные вертикально (т.е. не все столбцы, а наборы столбцов). Соответственно, предназначены для повышения производительности частых операций соединения и агрегирования.
Бывают:
а. Многотабличные
б. Однотабличные

4. Хэш-индексы.
Опять-таки предназначены для ускорения операций соединения, но являются однотабличными.

Как видите, с индексами всё в порядке.
Поддерживается динамический bitmapping индексов (то есть, если их несколько с низкой селективностью, а в комбинации они становятся высокоселективным индексом, то из них делается bitmap-index - похожая фича есть в AS/400).
Поддерживается также компрессия индексированных значений (напоминает то, как это делается в Sybase IQ).


Пожалуй, так. Может, ещё что забыл. Вспомню - напишу.


К слову любонытно, какие у вас впечатления от производительности этих серверов. Я заметил, что в списке нет Oracle. Любопытно, что у нас MS SQL и Oracle это сервера номер один, затем Sybase и Interbase, все отсальное крайне редко. Под DB2 делали только один раз пока работали на IBM, сервер надо сказать понравился. Но спецов по нему ноль в РФ, потому и не игрок.

Oracle забыл написать. Был один не очень удачный проект. Кстати, на Cognos тоже. В части Oracle когда написал один запрос, формирующий таблицу фактов из нормализованной стрктуры и запустил - ждать пришлось долго. В конце пришлось его побить штук на 20 маленьких запросов. Только тогда загрузка нормально заработала. Непосредственно в базу запросов не было, был только процессинг кубов Cognos, который длился несколько часов, а кубик просто озастывал, поскольку измерение клиент было довольно разветвлённым и с большим количеством категорий.
Возможно, в то время руки не оттуда росли, не знаю, но повторный прокол с Cognos заставил отказаться от него в пользу Microstretegy.

Юрий, сорри за антирекламу, но это правда из жизни.

AS/400 понравился. Завалить удалось всего два раза :)
Там есть определённые архитектурные особенности, которые ограничивают применение AS/400 как платформы для хранилищ данных. Мне кажется, IBM больше позиционирует DB2/RS6000 в массивно-параллелной конфигурации как платформу для серьёзных хранилищ. Представители IBM поравят меня, если я ошибаюсь.
Sybase ASE на мой взгляд не дотягивает до платформы для хранилищ. Sybase позиционирует IQ в этих целях. Посмотрим, как это направление будет у них развиваться.
Interbase - сами понимаете, игрушечная СУБД, да не обидятся на меня её поклонники :)



С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Jurii:

Я ожидал этого ответа. Вы очень предсказуемы. И Ваше желание защитить лббимый продукт, ссылаясь на криворукость внедренцев вполне естественная реакция.
К тому времени я уже обучился продуктам Cognos и сдал экзамен на сертификат Cognos BI Author.

Я не списываю с себя ответственности за тот проект, соответствующие выводы были сделаны. Но и всю ответственность на себя тоже не беру. Если и так, то ошибка - это выбор неподходящего продукта для решения конкретной задачи. Ну, не подошёл Cognos для решения той задачи, что делать? Ну, не является он универсальным средством для решению любых задач...

Просьба не начинать рассказ о блохе...


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Владимир:

Владимир, а каким образом общаются друг сдругом узлы кластера MS?
Используется локальная сеть и протокол TCP/IP или имеются специализированные протоколы, которые настроены именно под специфику СУБД?

Иными словами это не совсем то что обсуждает Константин - full-time транзакционный кластер

Я обсуждаю массивно-параллельную систему. Это немного не то, что кластер, хотя для простоты мы здесь пока их приравниваем. Я пока до конца не понял, как работает кластер MS.
Что происходит, например, если в запросе требуется агрегирование данных из разных узлов? Как обрабатывается такой запрос?


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Гликоген:

ребята, время feature-based рыночного позиционирования прошло, теперь позиционируются только брэнды :)

Возможно, это и так, однако кроме этого позиционируются целостные решения, а не только движки.


MS, конечно, с трудом, но поднимается и вытесняет конкурентов из high-end-ниш...
Им бы имело смысл производить High-end SQL Server 2000, переупакованный под другим брэндом и стоящий в 10 раз дороже - тогда бы и народ недоверчивый потянулся :))

Не исключено, что так. Свежий отчёт META Group показывает кто лидер, а кто - преследователь.


Почему считается, что SQL Server не может быть хорошим и масштабируемым только потому, что его дедушка был для мелких предприятий? :)


Вопрос философский. Почему люди одних семей всегда были графами, а другие - крепостными? Иногда довольно трудно преодолеть влияние окружения, в котором находишься.
Возьмите те фичи, которые были в Терадате с самого начала. Многие из них появились в других СУБД сравнительно недавно. Разрыв достаточно большой получается.
Почему Жигули не стали машиной high-end класса? Может, наследие сказывается?


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Владимир:

Спасибо, прочитал.

Статья написана как ПОПУЛЯРНАЯ, многое сильно упрощено
Ага, точно. Самое главное немного напрягает вольность обращения с термином "хранилище данных". То, что там построено не напоминает мне хранилища данных в привычном для меня смысле этого слова, поскольку многих атрибутов хранилища я не увидел. В частности, упоминается о том, что суррогатные ключи не надо использовать, история изменений не хранится, а переписывается, система позиционироуется для ответа на определённый узкий круг вопросов (не отрицаю, что она это решает), а не на произвольные вопросы.
Реляционная база используется исключительно для наполнения кубов. Понятно, что производительность кубов будет нормальная, если всё настроить.

MS SQL 2000 в зависимости от ваших запросов автоматически вычисляет на каком сервере лежат нужные данные и обращается именно к нему

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

Прошу воспринимать как конструктивную критику, а не как наезд :)


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Владимир:

То что в статье называется DWH это скорее что-то похожее на витрину данных
Да, я это и хотел написать. Именно витрина.

Полный DWH дальше в центральном офисе, но он как правило "спит" и качается дельтой
Почему спит? Должен работать. Уволить :)


При работе юзеров, конечно кластер не используется

Потому что если юзеры начнут к нему делать запросы, мало ему не покажется. Думаю, так. Что будет, если юзер начнёт джойнить таблицы, хранящиеся на разных узлах кластера?

Пример интересный, но не демонстрирует мощи кластера MS.
Вот, если есть кластер, к которому сложные запросы Ad Hoc от многих пользователей одновременно поступают, на это интересно было бы посмотреть.

P.S. Нарыл сравнение нескольких поставщиков хранилищ данных . Читайте на здоровье. Про MS там тоже хорошее есть. Да, и про всех остальных.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

в результате рулит тот, кто лучше и быстрее удовлетворяет потребности бизнеса, а не тот, кто предложит лучшую архитектуру кластеринга :)

Да нет. Рулит тот, кто откат больше сделает :)
Человеческий фактор всегда на первом месте, потом уже техника.


С уважением,
Константин Лисянский
http://lissianski.narod.ru