Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
Почему не стоит строить хранилище данных на базе MS SQL Server 200x? Очень много слышал и слышал как гнутся пальчики в сторону Sybase и Oracle, но почему никто вразумительно объяснить не мог.

Присоединяйтесь, если интересна дискуссия.
8 сен 06, 10:23    [3109299]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895

man_555

Почему не стоит строить хранилище данных на базе MS SQL Server 200x? Очень много слышал и слышал как гнутся пальчики в сторону
Sybase и Oracle...

Ссылку можно увидеть?


Posted via ActualForum NNTP Server 1.3

8 сен 06, 10:31    [3109368]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
man_555
Почему не стоит строить хранилище данных на базе MS SQL Server 200x? Очень много слышал и слышал как гнутся пальчики в сторону Sybase и Oracle, но почему никто вразумительно объяснить не мог.

Присоединяйтесь, если интересна дискуссия.

дык, в mssql2k нету элементарных вещей типа нормального партионинга, materialized view т.п. без которых DWH строить затруднительно, а mssql2k5 только появился.
8 сен 06, 10:36    [3109420]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
RENaissance
Member

Откуда: Муром->Москва
Сообщений: 10895

To Yo.!!
Откуда Вы взяли, что в MSSQL2000 нет секционированных и материализованных представлений??? Рекомендую Вам более внимательно почитать
BOL.


Posted via ActualForum NNTP Server 1.3

8 сен 06, 10:43    [3109484]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
Ну а чем так хороши материализованные view? Насколько я понимаю, они в принципе денормализуют базу, а если такое появляется, значит в систему закрался дефект.
8 сен 06, 11:27    [3109853]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
RENaissance

To Yo.!!
Откуда Вы взяли, что в MSSQL2000 нет секционированных и материализованных представлений??? Рекомендую Вам более внимательно почитать
BOL.


не первый год замужем :)

partitioning
секционирование позволяет большие структуры базы данных (таблицы, индексы) разбить на меньшие кусочки. Оракл предлагает несколько методов для различных сценариев:
- Range partioning
- Hash partitioning
- List partitioning
- range-hash and range-list composite partitioning

также существует 3 типа partitioned indexes:
- local index, т.е. индекс на партицию.
- global partitioned index, такой индкс разбивается на секции по другим правилам нежели сама таблица.
- global non-partitioned index, такой индекс не разбивается на секции хотя таблица разбита.
- всевозможные комбинации partitioned и non-partitioned с таблицами. partitioned таблица может иметь partitioned и non-partitioned index также как и non-partitioned с таблица может иметь partitioned и non-partitioned index.

MSSQL2K не поддерживает секционирование в том смысле как его понимает индустрия. вместо таблиц он использует partitioned views. partitioned views соединяет секции горизонтально из таблиц на разных серверах. Диапозоны для каждой секции прописываются в CHECK констреинте, а view использует UNION ALL чтоб склеить секции в единый результрующий набор.

В MSSQL2K два типа partitioned views - local partitioned view и distributed partitioned view. локальный - все таблицы-партиции находятся на одном инстансе, дистрибутед - как минимум одна таблица вынесена на другой инстанс.

Когда оракл импользует глобальный индекс в OLPT задаче, он обращается к одному индексу чтоб выяснть на которой партиции находится запись, не важно какой метод применялся для секционирования. У MSSQL2K если в запросе не прописано которую партицию использовать серверу приходится просматривать все партиции. Это делает затруднительным использывание партиций в real-world OLTP задачах, ведь когда используются дистрибутед партиции - серверу необходимо прочесать все инстансы.


2man_555
матвью это чуток другое, у сиквела есть indexed view, так сказать слабое подобие левой руки:
http://triffids.googlepages.com/MSSQL2005_ORACLE10g_compare.pdf

In MSSQL 2000 the materialized views have been limited in the means of data types and functions available.
MSSQL 2005 still has a significant list of restricted functions and aggregations. The Indexed View in MSSQL still has a lot of limitations as compared with the Oracle one. For example, the Indexed View definition could not contain the following very useful aggregations, functions and options, namely derived table (sub query in FROM list), reference to another view, DISTINCT, EXISTS, NOT EXISTS, self-join, expressions on aggregate results (e.g. SUM(x)+SUM(x)), STDEV, STDEVP, VAR, VARP, AVG, Subquery, SUM on nullable expressions and UNION.
8 сен 06, 11:53    [3110093]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
mat.views только материализуют представления... они не денормализуют базу Это проектировщик делает.

по поводу ХД - зависит от железа, имхо...
можете сходить на TPC (TPC-H), это тестирвоание как раз серверов для ХД и посмотреть, кто и как себя чуствует.
В общем, видно, что все лидирующие СУБД достаточно спокойно работают в качестве ХД...
а Yo не слушайте... он плохо знает SQL Server
8 сен 06, 11:55    [3110116]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
2AAron

а можно поинтересоватся, что общего вы нашли у DWH и TPC-H ? ;)
8 сен 06, 11:58    [3110151]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
AAron
mat.views только материализуют представления... они не денормализуют базу Это проектировщик делает.


Да, сморозил... Но какой смысл вводить представление, если таблицы и так денормализуются? ;-) Увлечение сиёй приблудой говорит только о том, что ХД как-то криво проектировалось... нет?
8 сен 06, 15:04    [3111776]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
SeaGate
Member

Откуда: Новосибирск
Сообщений: 1728
man_555
AAron
mat.views только материализуют представления... они не денормализуют базу Это проектировщик делает.


Да, сморозил... Но какой смысл вводить представление, если таблицы и так денормализуются? ;-) Увлечение сиёй приблудой говорит только о том, что ХД как-то криво проектировалось... нет?

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

Вводится не представление, а материализованное представление, почувствуйте разницу.
8 сен 06, 15:26    [3111957]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
SeaGate
Создается впечатление, что Вы не совсем представляете себе, для чего же собственно нужны материализованные представления, и в чем их преимущество, относительно использования базовых таблиц.


Да, видимо я плохо учил уроки в школе... для увеличения производительности? Насколько мне помнится есть два подхода: кэшировать и индексировать.

Но как бы то ни было, что тогда под собой подразумевает представление? Таблицу фактов или измерение (dimension)?
8 сен 06, 16:28    [3112401]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
man_555

Да, видимо я плохо учил уроки в школе... для увеличения производительности? Насколько мне помнится есть два подхода: кэшировать и индексировать.

Но как бы то ни было, что тогда под собой подразумевает представление? Таблицу фактов или измерение (dimension)?

подозрительная у вас была школа
Kyte

Материализованные представления — средство повышения производительности для
хранилищ данных и систем поддержки принятия решений, которое многократно уско-
ряет выполнение запросов, обращающихся к большому количеству (сотням тысяч или
миллионам) записей. Говоря упрощенно, они позволяют за секунды (и даже доли се-
кунд) выполнять запросы к терабайтам данных. Это достигается за счет прозрачного ис-
пользования заранее вычисленных итоговых данных и результатов соединений таблиц.
Предварительно вычисленные итоговые данные обычно имеют очень небольшой объем
по сравнению с исходными данными.
Предположим, в компании имеется база данных продаж, в которую загружены све-
дения о миллионах заказов, и необходимо проанализировать продажи по регионам (весь-
ма типичный запрос). Будут просмотрены все записи, данные — агрегированы по реги-
онам с выполнением необходимых вычислений. С помощью материализованного
представления можно сохранить итоговые данные продаж по регионам и обеспечить
автоматическую поддержку этих данных системой. При наличии десяти регионов про-
даж итоговые данные будут состоять из десяти записей, так что мы будем обращаться
не к миллиону фактических записей, а только к десяти. Более того, при выполнении
несколько измененного запроса, например об объеме продаж по определенному регио-
ну, ответ на него тоже можно получить по этому материализованному представлению.
8 сен 06, 16:37    [3112451]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
Yo.!!


а Вы пальцы гнёте или просто повторяете то, что уже другие сказали? ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ. Индексация в ХД не хуже с этим справляется.
8 сен 06, 16:54    [3112575]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
man_555

а Вы пальцы гнёте или просто повторяете то, что уже другие сказали? ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ. Индексация в ХД не хуже с этим справляется.


да ? а подумать головой ? ну совсем чуток !
сильно тебе индекс поможет на запросе типа "итоговые данные продаж по регионам " по табличке в пару милиардов записей ?

ЗЫ. а у mssql и с индексами беда.
8 сен 06, 17:05    [3112673]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
SeaGate
Member

Откуда: Новосибирск
Сообщений: 1728
Yo.!!
man_555

а Вы пальцы гнёте или просто повторяете то, что уже другие сказали? ПОВЫШЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ. Индексация в ХД не хуже с этим справляется.


да ? а подумать головой ? ну совсем чуток !
сильно тебе индекс поможет на запросе типа "итоговые данные продаж по регионам " по табличке в пару милиардов записей ?

ЗЫ. а у mssql и с индексами беда.

Yo!!, можно поподробней про m$sql и индексы? Коллекционирую минусы данной СУБД.
8 сен 06, 17:21    [3112757]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
Если такое требуется пользователям, то не проще ли будет создать новую таблицу и не нагружать ХД на поддержку всех MV? По крайней мере для того, чтобы ручками вносить изменения в ХД нужны веские основания.

Сомнительно, что для миллиарда записей не используется нечто вроде фабрики данных.

ЗЫ Про индексы приведи статью, где сравнивается - поверю.
Сколько места сжирает MV?
8 сен 06, 17:24    [3112776]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
2SeaGate

Type of index Oracle Database 10g/SQL Server 2005
B-tree indexes Yes / Yes
B-tree cluster indexes Yes / No
Hash cluster indexes Yes / No
Reverse key indexes Yes / No
Bitmap indexes Yes / No
Bitmap join indexes Yes / No
Function-based indexes Yes / No
Domain indexes Yes / No
Index-organized tables Yes / Yes (clustered indexes)
8 сен 06, 17:25    [3112785]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
man_555
Если такое требуется пользователям, то не проще ли будет создать новую таблицу и не нагружать ХД на поддержку всех MV? По крайней мере для того, чтобы ручками вносить изменения в ХД нужны веские основания.

почитайте лит-ру, у вас представления о MV на уровне деского сада. отдельная табличка с агрегатами это типа жевачка вместо сварки, хотя может конечно где-то и прокатит ...

man_555
Сомнительно, что для миллиарда записей не используется нечто вроде фабрики данных.

wtf ? витрина что-ли ?
8 сен 06, 17:33    [3112845]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
man_555
Member

Откуда: Рига
Сообщений: 272
Yo.!!
[quot man_555]wtf ? витрина что-ли ?
Ну, в результате, да.

Спасибо, про MV почитаю, видимо, действительно не понимаю.

Ну почему "жевачка"? Только обоснованно.
8 сен 06, 17:58    [3112989]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
man_555

Ну почему "жевачка"? Только обоснованно.

от того, что вы сделаете такую табличку оптимизатор не станет ее использовать для оптимизации планов.
вгот книжечка
http://anatolix.naumen.ru/Books/KyteOracle?v=kvq
там есть раздел по матвью.
8 сен 06, 18:09    [3113050]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Yo!! Красиво поешь. Только DW workload достаточно предсказуемый и хорошо вписывается в MPP архитектуру разделяй и властвуй, которую Oracle не любит.
А большое количество разнородных индексов усложняют жизнь оптимизатору, не будешь же ты в DW каждый запрос тюнить.
8 сен 06, 20:50    [3113488]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Yo.!!
Guest
Nikolay Kulikov
Yo!! Красиво поешь. Только DW workload достаточно предсказуемый и хорошо вписывается в MPP архитектуру разделяй и властвуй, которую Oracle не любит.

шутить изволите ?
This white paper describes how Oracle's parallel technology fully exploits the
power of IBM's HACMP/6000 clusters and RS/6000 MPP technology.
December 1996

Nikolay Kulikov
А большое количество разнородных индексов усложняют жизнь оптимизатору, не будешь же ты в DW каждый запрос тюнить.

индексы осложняющие жизнь оптимизатору ? :) такой фичи в оракле еще не слышал.
8 сен 06, 21:43    [3113607]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
Vadim_Maximov
Member

Откуда: Москва
Сообщений: 3571
Yo.!!
индексы осложняющие жизнь оптимизатору ? :) такой фичи в оракле еще не слышал.
браво!!!
8 сен 06, 21:48    [3113627]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
man_555
Если такое требуется пользователям, то не проще ли будет создать новую таблицу и не нагружать ХД на поддержку всех MV?

Нет, не проще. Больше хлопот, меньше надежность. Можно сказать так: все, что можно сделать методом "новую таблицу", можно сделать при использовании MV (который по сути и есть таблица). В то же время возможности, предоставляемые MV, делать руками либо сложно (я имею в виду QUERY REWRITE), либо напряжно, ненадежно и просто незачем.

man_555
По крайней мере для того, чтобы ручками вносить изменения в ХД нужны веские основания.

Безотносительно сути утверждения - не понимаю, как оно связано с MV.

man_555
Сомнительно, что для миллиарда записей не используется нечто вроде фабрики данных.

Таки что это?

man_555
ЗЫ Про индексы приведи статью, где сравнивается - поверю.

Дык документация. По MSSQL - какие индексы есть там. По Oracle - какие индексы есть там.

Впрочем, если Вас утешит, если мне не изменяет память, в b-tree индексах MSSQL была пара незначительных преимуществ перед соответствующими оракловыми.

man_555
Сколько места сжирает MV?

Столько, сколько потребует таблица с теми же данными.
8 сен 06, 22:02    [3113669]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Warehouse. Почему не стоит?  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
man_555
Почему не стоит строить хранилище данных на базе MS SQL Server 200x? Очень много слышал и слышал как гнутся пальчики в сторону Sybase и Oracle, но почему никто вразумительно объяснить не мог.

Присоединяйтесь, если интересна дискуссия.


Может и стоит, но IMHO, если об'емы данных поболее 5гб и пальчики гнутся в сторону Sybase IQ, то это правильно. Плюсы, которые я вижу:

- скорость и простота поддержки системы
- экономия на железе, база не раздувается
- все автоматом проиндексировано и нет особой мороки с ad-hoc отчетами
- в силу скорости, нет проблем с большим числом пользователей
- простой SQL и не надо париться с ОЛАП спецификой
- быстрая загрузка даннных.
8 сен 06, 23:43    [3113922]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить