ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / 40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
12 сообщений из 37, страница 2 из 2
  2  все
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417511
DmitryS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmitryS
Гость
Я прошу прощения - разобраться в терминологии лень. Могу сказать, что на практике встречались кубы с 80 млн. фактов (MS AS) и порядка 25 измерений (в среднем "по больнице" - 200 членов). С DC мерами в т.ч. Работают вполне адекватно. Действительно очень много с точки зрения производительности дали BOL и MSDN. Ссылок не помню, так как читалось довольно давно.
По общим вещам: на мой взгляд, надо стремиться к
а) максимальному упрощению запросов, откидываемых при процессинге;
б) избегании беготни по огромным измерениям;
в) перетряски PC измерений.
Это то, что бьёт очень сильно.
Каким образом? Рубить требования, проектировать хранилище (как следствие, закачку - это значительно может уменьшить сложность MDX-выражений), играться с разделяемыми измерениями, извращаться c MDX - дело конкретного проекта.
Владимир элементарно прав в том, что написать за один пост "как сделать всех счастливыми" невозможно. Попытка обобщения проблем есть в книжках Споффорда и Кимбала. Всех ли это лечит?
...
Рейтинг: 0 / 0
20.02.2004, 20:30
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417538
Моша
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Моша
Гость
To: backfire

> A ssilochkoi ne podelites? Poslednee chto ya nashel o distinct count eto

Рекоммендую также прочитать
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/optimize/ANSvcsPG.asp

Опубликованный в июне 2003. Это вообще полезная whitepaper про оптимизации производительности и там есть специальный раздел посвющенный Distinct Count.
...
Рейтинг: 0 / 0
20.02.2004, 21:34
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417540
DmitryS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DmitryS
Гость
А что касается "коммерциализованности" форума, то тут проблема следующего характера: вопросы делятся на три категории:
1. Вопросы "ленивые". А как ещё назвать вопросы, которые сводятся к тому, чтобы получить в ответ название стандартной MDXовской функции? Проще, зачастую BOL почитать. Да и быстрее. Типичный вопрос - про ValidMeasure например. На такие мне, если честно, отвечать не хочется.
2. Вопросы "сложные". Вываливается громадный MDX или описание проблемы с просьбой помочь. Когда есть настроение и время голову поломать - тогда можно. А так - нужно же, продумать, желательно проверить etc.
3. Вопросы технические - " у меня выкинуло такую -то ошибку". Тут как повезёт - либо сталкивался, либо - нет.
Т.е., либо вопрос идиотский и раздражает, что автор ленится сам его решить, либо вопрос сложный и нужно время, чтобы проверить. Тут дело в специфике отрасли и продукта в частности. На мой взгляд, тут творчества, что ли больше, чем в обычных транзакционных системах. Там больше техник:-)
...
Рейтинг: 0 / 0
20.02.2004, 21:42
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417657
Mosha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mosha
Гость
Да еще забыл добавить, что большинство проблем связанных с Distinct Count затронутых в этой дискуссии решено в следующей версии Analysis Services под кодовым названием Yukon.
Цитирую информацию опубликованную на Technet по ссылке
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/next/DWSQLSY.asp

1. Производительность

Query performance for Distinct Count measures is improved by up to several orders of magnitude, for appropriately partitioned cubes.

2. Проблема с агрегированием по произвольным диапазонам

Rex пишет:
> Что никоим образом не отменяет связанных с ними проблем. В частности, невозможности получать данные по произвольным диапазонам измерений.
Аудитория ждёт информации по тюнингу и продвинутой (пред)агрегации.

Jurii пишет:
> Правильно ли я понимаю, что Вы имеете в виду ситуацию, когда показатель на основе Distinct Count (например, Количество клиентов) легко считается для каждого дня, месяца, года, но его нельзя посчитать за произвольный период времени с даты по дату?

Technet отвечает:
Distinct count measures are also much improved in “Yukon”. A distinct count measure can now be defined on string data, and queries can be defined that will perform a Distinct Count over an arbitrary set. Analysis Services 2000 performed distinct counts only on the predefined hierarchical structure.

Также я бы хотел ответить Владимиру на следующие комментарии:

> Вообще говоря, специалистам из Microsoft стоит принести свои извинения за невнятную позицию относительно темы distinct count. Почти год Micrsoft не мог даже внятно ответить на вопрос "агрегаты distinct count настоящие или виртуальные?".

Приношу извинения за документацию если она не отвечает внятно на этот вопрос.

> Теперь правда открывалась. MS AS единственный OLAP-сервер в мире умеющий делать настоящие агрегаты distinct count, но эта агрегация стала работоспособной только после SP

Я бы хотел немножко поправить это высказывание. Агрегации distinct count были "настоящими" с момента выпуска продукта. Я предполагаю что Владимир столкнулся с багом имплементации в какой-то определенной ситуации и этот баг был починен в одном из Service Packs.
...
Рейтинг: 0 / 0
21.02.2004, 10:20
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417713
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
То Моша.

Если вы Моша Пасуманский, то я очень очень рад, что на нашему скромненькому форуму уделил внимание один из ведущих разработчиков МS AS (в том числе и его будущей версии)
...
Рейтинг: 0 / 0
21.02.2004, 13:16
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417726
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
То Моша

Да еще забыл добавить, что большинство проблем связанных с Distinct Count затронутых в этой дискуссии решено в следующей версии Analysis Services под кодовым названием Yukon.

Лучше какие не решены? Чтоб нам не сильно расслаблятся

1. Производительность

Query performance for Distinct Count measures is improved by up to several orders of magnitude, for appropriately partitioned cubes.

Разделы куба останутся все так же привилегией владельцев Entrprise версии или будут доступны простым смертным. (Из версии с красным штампиком канадской провинции на заставке это не определить :-( )

2. Проблема с агрегированием по произвольным диапазонам

Ну наконец-то, а то МДХ такю лажу в 2К версии поставляет - он просто арифметически суммирует значение мер для элементов slicer, а не считает distinct count, для slicer по некольким элементам одного измерения. Из-за этого мы были вынуждены отказаться от distinct count вообще, ибо для MDX клиента долно быть абослютно параллельно на какой аггрегационной функции базируется мера. Не говоря уже о том, что половина функции MDX принципиально не работает c distinct count мерами.

В итоге в версии 2К мы решаем проблемы с distinct count на уровне DWH, слава богу у SQL проблем c distinct count нет, а в OLAP грузим уже предрасчитанные данные из DWH.

Technet отвечает:
Distinct count measures are also much improved in “Yukon”. A distinct count measure can now be defined on string data .
Правильно. Не все же используют в качестве ключей int(bigint), есть кто и char, а есть кто и GUID (MS CRM).

Приношу извинения за документацию если она не отвечает внятно на этот вопрос.

Очень бы хотелось, чтобы в Yukon, уровень документации по OLAP достиг как минимум уровня доки по SQL.

Теперь позвольте пару слов без протокола.:-) По результатам знакомства с программой у которой красный штампик канадской провинции на заставке.

ADOMD.NET. Как я понимаю работать с объектом Catalog и все что в нем есть (CubeDefs и далее ...) еще более самоубийственно с точи зрения производительности чем в нынешней версии MS AS и надо переориентироваться на stateless MDX. Или я не прав.

Есть еще море вопросов по Канадской провинции, но это тема отдельного топика или если вы позволите e-mail.
...
Рейтинг: 0 / 0
21.02.2004, 14:03
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417985
Ирина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ирина
Участник
backfire
ADOMD.NET. Как я понимаю работать с объектом Catalog и все что в нем есть (CubeDefs и далее ...) еще более самоубийственно с точи зрения производительности чем в нынешней версии MS AS и надо переориентироваться на stateless MDX. Или я не прав.



Смотря какие об'екты Вас интересуют, если кубы, измерения, уровни, то однозначно нужно пользовать об'ектами метаданных. Если members, то вопрос спорный, зависит от размера уровня. Скоро выйдет новая версия Adomd.Net и в ней будет больше возможностей избежать самоубийства и на members, правда можно поспорить, что зная свои данные Вы сможете послать лучший MDX запрос.

Ирина


----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights
...
Рейтинг: 0 / 0
22.02.2004, 11:55
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32417996
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
То Ирина

Я имел ввиду members и user defined properties.
Что вы поразумеваете под скоро? Вместе с Юконом (через полтора-два года) или по-раньше?

Что поразумевает adomd.net при работе с MS AS 2K - warpper вокуг тормозного OLEDB MD, тогда чем он будет лучше Interop для ADOMD? Своевольностью и непредсказуемостью Pivot Table Services мы уже сыты по горло - хрен редьки не слаще.

Или это будет native .net клиент для XMLA? То есть клиентская машина не должна отягощаться установкой Pivot Table Services?
...
Рейтинг: 0 / 0
22.02.2004, 12:13
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32418104
Ирина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ирина
Участник
Скоро - это скоро, совсем скоро, раньше Юкона. Это будет managed client для xmla.


Ирина

----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights
...
Рейтинг: 0 / 0
22.02.2004, 19:27
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32425601
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
о Mosha

Technet отвечает:
Distinct count measures are also much improved in “Yukon”. A distinct count measure can now be defined on string data, and queries can be defined that will perform a Distinct Count over an arbitrary set. Analysis Services 2000 performed distinct counts only on the predefined hierarchical structure.

BackfireНу наконец-то, а то МДХ такю лажу в 2К версии поставляет - он просто арифметически суммирует значение мер для элементов slicer, а не считает distinct count, для slicer по некольким элементам одного измерения.
Да, мой восторг по поводу distinct count был к сожалению преждевременен.
Ваша цитата из TechNet явно прждевременна. Это мягко говоря "не соответсвует действительности".

Создайте в "Adventure Works" на поле FactSales.ProductKey меру [Product Key]
задав тип аггрегации DistinctCount и выполните следующий запросик.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
with

set [Set0] as 
[Customer].[Customer Geography].[All].[Germany].children

member [Customer].[Customer Geography].[MemberAggregate0] as
aggregate([Set0])

member [Customer].[Customer Geography].[MemberAggregate1] as
aggregate([Customer].[Customer Geography].[All].[Germany].children)

member [Customer].[Customer Geography].[MemberAggregate2] as
aggregate({
[Customer].[Customer Geography].[All].[Germany].Bayern,
[Customer].[Customer Geography].[All].[Germany].Hamburg,
[Customer].[Customer Geography].[All].[Germany].Hessen,
[Customer].[Customer Geography].[All].[Germany].Saarland,
[Customer].[Customer Geography].[All].[Germany].[Nordrhein-Westfalen]
})

member [Customer].[Customer Geography].[MemberSum0] as
sum([Customer].[Customer Geography].[All].[Germany].children, [Measures].currentmember)

select {
  [Order Time].[Calendar Time].[All],
  [Order Time].[Calendar Time].[All].&[ 2002 ],
  [Order Time].[Calendar Time].[All].&[ 2001 ],
  [Order Time].[Calendar Time].[All].&[ 2003 ]
} on columns,
crossjoin ({
  [Customer].[Customer Geography].[All].[Germany],
  [Customer].[Customer Geography].[MemberAggregate0],
  [Customer].[Customer Geography].[MemberAggregate1],
  [Customer].[Customer Geography].[MemberAggregate2],
  [Customer].[Customer Geography].[MemberSum0],
  [Set0]
},{[Measures].[Product Key]}) on rows 
from [Adventure Works]


Для убедительности даже результат приведу

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
                                All     2002 	   2001     2003 
Germany             Product Key  158      53 	   18 	  128 
MemberAggregate0    Product Key	#Error #Error #Error #Error
MemberAggregate1    Product Key	 158      158 	   158 	  158 
MemberAggregate2    Product Key	#Error #Error #Error #Error
MemberSum0          Product Key	 654      139 	   45 	  471 
Bayern              Product Key	 115      21 	   8 	      74 
Hamburg             Product Key	 122      24 	   7 	      92 
Hessen              Product Key	 137      33 	   11 	  99 
Nordrhein-Westfalen Product Key	 135      25 	   8 	      97 
Saarland            Product Key	 145      36 	   11 	  109
...
Рейтинг: 0 / 0
01.03.2004, 01:17
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32425793
Mosha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mosha
Гость
To: backfire

Я не могу вести обсуждение Yukon в открытом форуме, потому что Beta 1 была распространена под NDA. Все что я могу - это цитировать информацию уже опубликованную на MSDN. Напоминаю Вам, что поскольку Вы тоже находитесь по действием этой NDA, то пожалуйста тоже воздержитесь от обсуждения деталей Yukon на sql.ru.

Я с удовольствием отвечу на этот и любые другие Ваши вопросы связанные с Yukon в microsoft.beta.yukon.analysisservices.olap
...
Рейтинг: 0 / 0
01.03.2004, 10:17
| Ответить | Цитировать | Написать  
40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
    #32425846
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир Штепа
Участник
To Mosha

K sozhalenizu ya ne dopuschen "k telu imperatora"

A moshap@use.net i moshap@hotmail.com ne rabotazut.
...
Рейтинг: 0 / 0
01.03.2004, 10:47
| Ответить | Цитировать | Написать  
12 сообщений из 37, страница 2 из 2
  2  все
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / 40-миллионики под MS AS уже стали нормой, 2-3 млрд. скоро будут нормой.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]