Дедофорум Z
     
powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [закрыт для гостей] / Что делать с кучей данных из разных источников?
11 сообщений из 36, страница 2 из 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
20.07.2022, 10:37
| Ответить | Цитировать | Написать  
Что делать с кучей данных из разных источников?
    #94228
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дед-ПапыхтетПривилегированный пользователь
Участник
Просто Трёп  11.07.2022, 14:00
[игнорируется]
84682
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
1. Простой. Один замер - один показатель.
2. Двойной. Один замер - два показателя.
3. Сложный. Один замер - от 4 до 20 показателей.

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

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

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

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

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

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

Тогда одно измерение будет одна запись во второй таблице и сколько там измерений в третьей.
...
Изменено: 21.07.2022, 14:58 - IT-Христ
Рейтинг: 0 / 0
21.07.2022, 14:57
| Ответить | Цитировать | Написать  
Что делать с кучей данных из разных источников?
    #95347
Дед-Папыхтет
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дед-ПапыхтетПривилегированный пользователь
Участник
Просто Трёп  20.07.2022, 16:49
[игнорируется]
94234
Дед-Папыхтет  20.07.2022, 16:34
[игнорируется]
94228
Просто Трёп  11.07.2022, 14:00
[игнорируется]
84682
Есть несколько источников, с которых с разной периодичностью берутся показатели. Показатель, в общем-то, один, просто число.
Источники разных типов.
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
21.07.2022, 17:46
| Ответить | Цитировать | Написать  
Что делать с кучей данных из разных источников?
    #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
21.07.2022, 17:51
| Ответить | Цитировать | Написать  
Что делать с кучей данных из разных источников?
    #95387
cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cat2Привилегированный пользователь
Участник
[игнорирует гостей]
Гесты и игнорируемые идут по CSS
Просто Трёп  21.07.2022, 14:51
[игнорируется]
95069
cat2  21.07.2022, 13:33
[игнорируется]
94984
Продолжайте жрать кактус
Костя, а че ты смеешься? Вот у тебя 20 замеров, сделанные единовременно. 90% селектов по этим замерам будут делаться так:
Код: SQL
1.
селект все 20 замеров где время битвин трам-пам-пам
Причем возвращаться будут тысячи строк. Остальные 10% - это возможно аналитика через курсоры. Хотя вряд-ли она будет на скуле, скорее в стороннем приложении.
У тебя нет мысли, что лучше все-таки сделать таблицу с 20-ю столбцами, чем хранить все в одном столбце?
Ну сделать в предлагаемой мною системе в таблице "Замер" индекс по полю "ЗамерДатаВремя" и все летать будет.
Вы же упорно пытаетесь оптимизировать работу безграмотно построенной базы.
Лучше один раз напрячься и переделать базу, чем годами тащить унаследованные ошибки проектирования
...
Рейтинг: 0 / 0
21.07.2022, 18:41
| Ответить | Цитировать | Написать  
11 сообщений из 36, страница 2 из 2
  2  все
Форумы / Microsoft SQL Server [закрыт для гостей] / Что делать с кучей данных из разных источников?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
ReSQL.ru, Чоткий форум, Чат Кролика       Пашэ: Рисунки, Чат       Деда: Фотоальбом, Встречи
Закрыть
start [/forum/topic.php?fid=17&gotonew=1&tid=2996]:
 0ms
get settings:
 22ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 43ms
get topic data:
 13ms
get first new msg:
 9ms
get forum data:
 4ms
get page messages:
 765ms
get tp. blocked users:
 2ms
others: 35ms
total:  914ms
созд. / загр.: 914ms
x
x
Закрыть


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