powered by simpleCommunicator - 2.0.17     © 2024 Programmizd 02
Map
Форумы / Microsoft SQL Server [закрыт для гостей] / Что делать с кучей данных из разных источников?
11 сообщений из 36, страница 2 из 2
Что делать с кучей данных из разных источников?
    #93819
Просто Трёп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Данных мало. всего 2700 строк в результирующей таблице.
Первый запрос - чисто посмотреть на время выполнения селекта из таблицы с одним столбцом, там в 4 раза больше строк.
Последний - селект из таблицы с четырьмя столбцами.
Код: SQL
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.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
---------------------------------------------------------------------------------------------------------------------------------------
print 'simple in -----------------------------------------------------'
set statistics time on

select adt, s_id, tem from tlog
where s_id in (5, 6, 7, 8) and adt > '2022-07-14 10:55:23.400'
order by 1 asc

set statistics time off
---------------------------------------------------------------------------------------------------------------------------------------
print 'joins -----------------------------------------------------'
set statistics time on

select distinct t.adt, t1.tem v1, t2.tem v2, t3.tem v3, t4.tem v4
from tlog t
  left join tlog t1 on t.adt = t1.adt and t1.s_id = 5
  left join tlog t2 on t.adt = t2.adt and t2.s_id = 6
  left join tlog t3 on t.adt = t3.adt and t3.s_id = 7
  left join tlog t4 on t.adt = t4.adt and t4.s_id = 8
where t.adt > '2022-07-14 10:55:23.400' and t.s_id in (5, 6, 7, 8)
order by 1

set statistics time off
---------------------------------------------------------------------------------------------------------------------------------------
print 'pivot with fake aggr -----------------------------------------------------'
set statistics time on

  ;with t as (
  select adt, s_id, tem from tlog where s_id in (5, 6, 7, 8) and adt > '2022-07-14 10:55:23.400'
  )
  select adt adt, [5] v1, [6] v2, [7] v3, [8] v4 from t pivot (max(tem) for s_id in ([5], [6], [7], [8])) P

set statistics time off
---------------------------------------------------------------------------------------------------------------------------------------
print 'case with fake aggr -----------------------------------------------------'
set statistics time on

;with t as (
select adt
  ,case when s_id = 5 then tem end v1
  ,case when s_id = 6 then tem end v2
  ,case when s_id = 7 then tem end v3
  ,case when s_id = 8 then tem end v4
from tlog where adt > '2022-07-14 10:55:23.400' and s_id in (5, 6, 7, 8))
select adt, max(v1), max(v2), max(v3), max(v4) from t
group by adt
order by 1

set statistics time off
---------------------------------------------------------------------------------------------------------------------------------------
print 'optimal -----------------------------------------------------'
set statistics time on

select adt, v1, v2, v3, v4 from l_val4 where adt > '2022-07-14 10:55:23.400' and g_id = 1

set statistics time off
---------------------------------------------------------------------------------------------------------------------------------------
simple in ----------------------------------------------------- (11088 row(s) affected) SQL Server Execution Times: CPU time = 0 ms, elapsed time = 12 ms. joins ----------------------------------------------------- (2772 row(s) affected) SQL Server Execution Times: CPU time = 31 ms, elapsed time = 33 ms. pivot with fake aggr ----------------------------------------------------- (2772 row(s) affected) SQL Server Execution Times: CPU time = 16 ms, elapsed time = 11 ms. case with fake aggr ----------------------------------------------------- (2772 row(s) affected) SQL Server Execution Times: CPU time = 0 ms, elapsed time = 12 ms. optimal ----------------------------------------------------- (2773 row(s) affected) SQL Server Execution Times: CPU time = 0 ms, elapsed time = 6 ms.
Получается, нет ничего быстрее таблицы с количеством столбцов, соответствующим количеству замеров в группе. Но case с фиктивными аггрегациями тоже неплох. А pivot тоже подгружает ЦП, но не так сильно, как join.
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #94228
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Просто Трёп  11.07.2022, 14:00
[игнорируется]
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
1. Простой. Один замер - один показатель.
2. Двойной. Один замер - два показателя.
3. Сложный. Один замер - от 4 до 20 показателей.

Как их хранить? На данный момент есть источники с 1, 2 и 4 показателями. Все хранятся в одной таблице, каждый со своим айдишником (для этого и был нужен пивот). Но вот предстоит добавить источник с 13 показателями. Хочется создать для него таблицу, но это как-то неправильно. Но и пихать его в общую таблицу как-то некомильфо, потому что выборки, если будут использовать этот источник, скорее всего, все 13 показателей и возьмут. И будут их разворачивать пивотом.

Плюс еще непонятно, как формировать выборки по желанию пользователя. Тут или динамический код, или трехзвенка. Вообще жесть.
Типовая задача ETL - загружай из разных источников по расписанию свежие данные в единую БД
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #94234
Просто Трёп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дед-Папыхтет  20.07.2022, 16:34
[игнорируется]
Просто Трёп  11.07.2022, 14:00
[игнорируется]
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
1. Простой. Один замер - один показатель.
2. Двойной. Один замер - два показателя.
3. Сложный. Один замер - от 4 до 20 показателей.

Как их хранить? На данный момент есть источники с 1, 2 и 4 показателями. Все хранятся в одной таблице, каждый со своим айдишником (для этого и был нужен пивот). Но вот предстоит добавить источник с 13 показателями. Хочется создать для него таблицу, но это как-то неправильно. Но и пихать его в общую таблицу как-то некомильфо, потому что выборки, если будут использовать этот источник, скорее всего, все 13 показателей и возьмут. И будут их разворачивать пивотом.

Плюс еще непонятно, как формировать выборки по желанию пользователя. Тут или динамический код, или трехзвенка. Вообще жесть.
Типовая задача ETL - загружай из разных источников по расписанию свежие данные в единую БД
Привет! Рад видеть!
Это понятно, что в единую БД. Сколько столбцов делать в таблице?
Все в один столбец, а потом разворачивать пивотом (или кейсами), или все-таки для групп замеров, которые делаются единомоментно, и будут выбираться потом все скопом, делать много столбцов?
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #94272
PaNik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[игнорирует гостей]
[не активирован]
[неодобрен]
Просто Трёп  20.07.2022, 16:49
[игнорируется]
Дед-Папыхтет  20.07.2022, 16:34
[игнорируется]
Просто Трёп  11.07.2022, 14:00
[игнорируется]
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
1. Простой. Один замер - один показатель.
2. Двойной. Один замер - два показателя.
3. Сложный. Один замер - от 4 до 20 показателей.

Как их хранить? На данный момент есть источники с 1, 2 и 4 показателями. Все хранятся в одной таблице, каждый со своим айдишником (для этого и был нужен пивот). Но вот предстоит добавить источник с 13 показателями. Хочется создать для него таблицу, но это как-то неправильно. Но и пихать его в общую таблицу как-то некомильфо, потому что выборки, если будут использовать этот источник, скорее всего, все 13 показателей и возьмут. И будут их разворачивать пивотом.

Плюс еще непонятно, как формировать выборки по желанию пользователя. Тут или динамический код, или трехзвенка. Вообще жесть.
Типовая задача ETL - загружай из разных источников по расписанию свежие данные в единую БД
Привет! Рад видеть!
Это понятно, что в единую БД. Сколько столбцов делать в таблице?
Все в один столбец, а потом разворачивать пивотом (или кейсами), или все-таки для групп замеров, которые делаются единомоментно, и будут выбираться потом все скопом, делать много столбцов?
Ставь опыты на данных порядка хотя бы несколько млн записей
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #94984
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гесты и игнорируемые идут по CSS
Продолжайте жрать кактус
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95069
Просто Трёп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cat2  21.07.2022, 13:33
[игнорируется]
Продолжайте жрать кактус
Костя, а че ты смеешься? Вот у тебя 20 замеров, сделанные единовременно. 90% селектов по этим замерам будут делаться так:
Код: SQL
1.
селект все 20 замеров где время битвин трам-пам-пам
Причем возвращаться будут тысячи строк. Остальные 10% - это возможно аналитика через курсоры. Хотя вряд-ли она будет на скуле, скорее в стороннем приложении.
У тебя нет мысли, что лучше все-таки сделать таблицу с 20-ю столбцами, чем хранить все в одном столбце?
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95070
Просто Трёп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95073
IT-Христ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы подумал таблицу для исходных данных и таблицу для сводных, наподобие регистра.
В принципе, сделать три таблицы,
Первая это список показателей.
Вторая это измерение, но без чисел
Третья это само измерение, с типом показателя(первая таблица), номером измерения(вторая таблица) и измеренным числом

Тогда одно измерение будет одна запись во второй таблице и сколько там измерений в третьей.
...
Изменено: 21.07.2022, 14:58 - IT-Христ
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95347
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Просто Трёп  20.07.2022, 16:49
[игнорируется]
Дед-Папыхтет  20.07.2022, 16:34
[игнорируется]
Просто Трёп  11.07.2022, 14:00
[игнорируется]
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
1. Простой. Один замер - один показатель.
2. Двойной. Один замер - два показателя.
3. Сложный. Один замер - от 4 до 20 показателей.

Как их хранить? На данный момент есть источники с 1, 2 и 4 показателями. Все хранятся в одной таблице, каждый со своим айдишником (для этого и был нужен пивот). Но вот предстоит добавить источник с 13 показателями. Хочется создать для него таблицу, но это как-то неправильно. Но и пихать его в общую таблицу как-то некомильфо, потому что выборки, если будут использовать этот источник, скорее всего, все 13 показателей и возьмут. И будут их разворачивать пивотом.

Плюс еще непонятно, как формировать выборки по желанию пользователя. Тут или динамический код, или трехзвенка. Вообще жесть.
Типовая задача ETL - загружай из разных источников по расписанию свежие данные в единую БД
Привет! Рад видеть!
Это понятно, что в единую БД. Сколько столбцов делать в таблице?
Все в один столбец, а потом разворачивать пивотом (или кейсами), или все-таки для групп замеров, которые делаются единомоментно, и будут выбираться потом все скопом, делать много столбцов?
Слушай ну замеры типовая структура может я что то у тебя не понимаю обычно

id bigint identity primary key,
dt datetime default getdate(),
counter_id int/smallint
value float/numeric

думаю в эту структуру набор измерений можно запихать весь
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95350
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и.... наверное для этой таблицы можно въебенить колоночный кластерный индекс.

create table measures
(
id bigint not null identity, -- айди замера
counter_id int not null, -- айди прибора измерения, если приборов несколько типа и напряжение и ток, то у этого прибора два counter_id
dt datetime not null default getdate(),
val numeric(10,4) not null
)
create columnstore clustered index ix_measures on measures

здесь в куче этой шляпы колоночный кластерный индекс хорошо влазит - быстрая агрегация будет да и каждое поле проиндексировано, и места мизер будет на диске - очень высокая компрессия. колоночные индексы апдейты не любят, а инсерты отлично переносят, а селекты вашпе бонба, и лярды записей будут вылетать
...
Рейтинг: 0 / 0
Что делать с кучей данных из разных источников?
    #95387
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гесты и игнорируемые идут по CSS
Просто Трёп  21.07.2022, 14:51
[игнорируется]
cat2  21.07.2022, 13:33
[игнорируется]
Продолжайте жрать кактус
Костя, а че ты смеешься? Вот у тебя 20 замеров, сделанные единовременно. 90% селектов по этим замерам будут делаться так:
Код: SQL
1.
селект все 20 замеров где время битвин трам-пам-пам
Причем возвращаться будут тысячи строк. Остальные 10% - это возможно аналитика через курсоры. Хотя вряд-ли она будет на скуле, скорее в стороннем приложении.
У тебя нет мысли, что лучше все-таки сделать таблицу с 20-ю столбцами, чем хранить все в одном столбце?
Ну сделать в предлагаемой мною системе в таблице "Замер" индекс по полю "ЗамерДатаВремя" и все летать будет.
Вы же упорно пытаетесь оптимизировать работу безграмотно построенной базы.
Лучше один раз напрячься и переделать базу, чем годами тащить унаследованные ошибки проектирования
...
Рейтинг: 0 / 0
11 сообщений из 36, страница 2 из 2
Форумы / Microsoft SQL Server [закрыт для гостей] / Что делать с кучей данных из разных источников?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (3): Анонимы (2), Google Bot 1 мин.
Игнорируют тему (1): erbol
Читали форум (2): Анонимы (1), Google Bot 1 мин.
Пользователи онлайн (31): Анонимы (23), Bing Bot, Сталкер, Шоколадный01 1 мин., serg_tmb 1 мин., Google Bot 1 мин., Green 1 мин., Yandex Bot 1 мин., Кусь 5 мин.
x
x
Закрыть


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