powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Задача на Distinct Count для GSM-логов
7 сообщений из 82, страница 4 из 4
Задача на Distinct Count для GSM-логов
    #32587888
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
это я писал чуть вышеЯ таки загрузил 100 млн. строк в Терадату. Выполнил обсуждаемый выше запрос с фильтром на 10 дней и 100 продуктов.
Запрос выполнялся в Терадате 3 минуты 5 секунд.
Запрос на периоде в 30 дней выполнился за 8 минут 34 секунды.
На периоде в 60 дней - за 21 минуту 17 секунд (правда, эксперимент я немного испортил, поскольку в это время ещё что-то делал параллельно с выполнением запроса).
В любом случае, геометрической прогрессии я здесь не вижу.

При этом надо заметить, что процессор был занят в среднем не более, чем на 25 процентов. Основная нагрузка была на диск. Это означает, что, если у меня в наличие будет 4 диска, то я имею возможность сократить время выполнения данного запроса в четыре раза даже, если останусь на одном процессоре. Это оценка довольно грубая, реальный выигрыш от добавления дисков может быть больше.
Если это - дисковый массив из 10 зеркальных пар, то выигрыш будет ориентировочно в 20 раз.

Поднял сервер с Терадатой в скромной конфигурации - 2 процессора, 3 SCSI-диска. Соответственно, 3 единицы параллелизма.
Загрузил 100 миллионов записей.

Вот какие результаты получились на запросах distinct count:

Собственно, запрос:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select count(distinct a11.cust_id)  WJXBFS1
from dmtb_sales a11
	join (select a11.cust_id  cust_id
	from dmtb_sales a11
	where a11.day_id between  1  and  10 
	group by a11.cust_id
	having count(a11.tran_id) between  10  and  50 
	) pa1
	  on  (a11.cust_id = pa1.cust_id)
where a11.day_id between  1  and  10 

Результаты:

На 10 днях запрос отрабатывает за 37 секунд
На 30 днях - за 2 минуты 8 секунд
На 60 днях - за 7 минут 15 секунд

Видно, что на 60 днях разница ровно в 3 раза по сревнению с конфигурацией на ноуте с одним диском. То есть, повышение уровня параллелизма даёт пропорциональный выигрыш.
Соответственно, мои оценки оказались правильными.
Через некоторое время у меня будет сервер немного помощнее. Проведу ещё раз эксперимент, чтобы удебиться в масштабируемости.

Попробую нагенерировать для этого побольше записей.
Интересно, что будет на миллиарде записей?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32588037
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как я уже отмечал выше, нам удалось решить эту задачу на MS AS, введя в эксплуатацию систему с временем отклика 1 секунда. Тем не менее, для себя я сделал поучительные выводы.
1) Сложные запросы поверх 100 млн. записей при построении DWH вытягивает MS SQL нормально, существенно лучше чем 2 года назад. Вероятно это прогресс "железа". Тем не менее на эту технику можно делать ставку.
2) Если ROLAP полность проигрывают MOLAP в оборотных задачах и производных от них, то в сложных вычислениях ROLAP еще боец (вероятно после Юкона это утверждение уже будет не верным). Тем не менее, я сейчас делаю любопытный проектик в ROLAP под MS AS с нелинейкой.
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32588071
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с нелинейкой

что под этим понимается?
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32588544
Владимир Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нелинейка - это значит, что применяются неаддитивные (нелинейные) меры.
Сейчас любопытный кубик выходит с анализом рекламы на TV. Там делается анализ всплесков покупок после рекламы. Забавная задачка.
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32588640
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Конечно "неаддитивные меры" это звучит банально и буднично,
но зачем же народ пугайть "своими" терминами. Вам самим то термин SCD не нравился как то.
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32606392
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В продолжение к предыдущим постам...

Настроил Терадату в конфигурации с 10 зеркальными парами и двумя процессорами. Соответственно, 10 единиц параллелизма. Каждая единица параллелизма (называется AMP - Access Module Processor) работает со своим диском (с зеркальной парой) и, соответственно, со своим кусочком таблицы.
Загрузил 500 млн записей.
Соответственно, на каждом диске лежит 1/10 часть таблицы, то есть 50 млн. записей.

Выполнил запросы, обсуждавшиеся выше.
Получил следующие резцльтаты:

Запрос:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select count(distinct a11.cust_id)  WJXBFS1
from dmtb_sales a11
	join (select a11.cust_id  cust_id
	from dmtb_sales a11
	where a11.day_id between  1  and  10 
	group by a11.cust_id
	having count(a11.tran_id) between  10  and  50 
	) pa1
	  on  (a11.cust_id = pa1.cust_id)
where a11.day_id between  1  and  10 

Результаты:
На 10 днях запрос отрабатывает за 45 секунд
На 30 днях - за 2 минуты 35 секунд
На 60 днях - за 5 минут 25 секунд

Делаем выводы:

Мощность сервера по количеству единиц параллелизма выросла приблизительно в 3,3 раза. Количество данных выросло в 5 раз.
При этом производительность на том же запросе осталась примерно на том же уровне.

Эксперименты продолжаются...


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Задача на Distinct Count для GSM-логов
    #32606964
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Продолжение...

Все эксперименты до данного момента были направлены на попытки посмотреть на производительность Терадаты в плане поддержки железа.
Теперь посмотрим, что можно сделать в плане индексирования.

Построим следующий индекс:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE JOIN INDEX CustTranCntJIdx AS
SELECT
  cust_id,
  day_id,
  count(tran_id) AS tran_cnt
FROM
  dmtb_sales
GROUP BY
  cust_id,
  day_id
PRIMARY INDEX (cust_id, day_id)
;


А теперь выполним наш запрос.
Получаем следующие результаты по скорости:

На 10 днях - 14 секунд
На 30 днях - 41 секунда
На 60 днях - 1 минута 21 секунда

Получили прирост производительности ещё примерно в 3 раза.

Понятно, что не одна секунда, но, очевидно, что время отклика адекватное.
При этом я, всё-таки, остаюсь на реляционной БД без необходимости проектировать, процессить, администрировать и подкручивать кубы. Соответственно, нет дублирования данных, нет необходимости всё это администрировать. И мне не надо писать MDX для данного запроса - SQL очень простой, генерируется автоматически. Преимущества налицо.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
7 сообщений из 82, страница 4 из 4
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Задача на Distinct Count для GSM-логов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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