Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Код: 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. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 22:01 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
я имел ввиду 8,72 суток ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 22:06 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Shanga, 1 LEFT JOIN должен быть ... или знак в ON поменяй 2 достаточно одного условия ISNULL(zone01.val , 0) <> 0 (это если на ЛЕФТ поменяешь) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 22:55 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
court, Пробовал, результат практически идентичен... ((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:00 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
даа, и почему джоин по val ? джойни по ID (это ж ПК, надеюсь ?) Или val не уникальный ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:00 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Shanga, у вас "зоны" видимо цифровые, раз вы их сравниваете по >, но почему именно знак больше непонятно. Этот вот кусок Код: sql 1. 2. у вас val может быть null? Зачем вы null превращаете в 0 и потом сравниваете с нулем когда есть конструкция is not null? Это лишние операции конвертации, которые вам совсем не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:19 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Т.к. выборка каждой зоны из одного и того же массива то надо данные различать (они не должны повторяться) Для этого знак ">", можно знак "<" иначе данные могут дублироваться Пример: [dbo].[Zones] 1276, 5684, 3254, 4323, 1589, 412, 893, 8543... и так 60шт при SELECT > будет 412, 893, 1276, 1589, 3254, 4323, 5684, ... 893, 1276, 1589, 3254, 4323, 5684, 8543... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:32 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, В случае, когда будут задействованы последние значения [dbo].[Zones] ос тавшиеся зоны будут NULL Пример: [dbo].[Zones] ...1276, 5684, 3254, 4323, 1589, 412, 893, 8543 zone01.val = 3254 zone02.val = 4323 zone03.val = 5684 zone04.val = 8543 (данные закончились) zone05.val = NULL zone06.val = NULL zone07.val = NULL zone08.val = NULL zone09.val = NULL zone10.val = NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:36 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, ISNULL очень быстрая операция, практически сравнимая с IS NOT NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2018, 23:38 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Изменил, не помогает... ((( SELECT zone01.val, zone02.val, zone03.val, zone04.val, zone05.val, zone06.val, zone07.val, zone08.val, zone09.val, zone10.val FROM [dbo].[Zones] AS zone10 LEFT JOIN [dbo].[Zones] AS zone09 ON zone09.ID < zone10.ID LEFT JOIN [dbo].[Zones] AS zone08 ON zone08.ID < zone09.ID LEFT JOIN [dbo].[Zones] AS zone07 ON zone07.ID < zone08.ID LEFT JOIN [dbo].[Zones] AS zone06 ON zone06.ID < zone07.ID LEFT JOIN [dbo].[Zones] AS zone05 ON zone05.ID < zone06.ID LEFT JOIN [dbo].[Zones] AS zone04 ON zone04.ID < zone05.ID LEFT JOIN [dbo].[Zones] AS zone03 ON zone03.ID < zone04.ID LEFT JOIN [dbo].[Zones] AS zone02 ON zone02.ID < zone03.ID LEFT JOIN [dbo].[Zones] AS zone01 ON zone01.ID < zone02.ID WHERE zone01.val IS NOT NULL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 00:01 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Shanga, Наверное я не очень понимаю задачу. Судя по числу 75 394 027 566 вам нужны сочетания (все комбинации по 10 элементов из множества 60 элементов). При соединении с правилом B n >A n что случится с вариантами, когда A n <B n ? Сдается мне вы получите разное количество элементов. AB12765684 3254 4323 15895684854332545684 4323 854343235684 854315895684 3254 4323 85434121276 5684 3254 4323 1589 412 893 85438931276 5684 3254 4323 1589 893 85438543 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 00:06 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Условие ">" или "<" покрывает все возможные комбинации (без дубликатов) Порядок не важен, важны лишь уникальные карты Зон Пример: 1 2 3 4 5 1 2 3 1 2 4 1 2 5 1 3 4 1 3 5 1 4 5 2 3 4 2 3 5 2 4 5 3 4 5 идентичны (в моем случае) 5 4 3 2 1 5 4 3 5 4 2 5 4 1 5 3 2 5 3 1 5 2 1 4 3 2 4 2 1 3 2 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 05:06 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Я наверное к вечеру не очень понимаю. У вас данные отсортированные? Иначе у меня получается вот такое 1 2 3 5 4 123 125 124 135 134 15 235 234 245 35 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 05:26 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizza, Сортировка не проблема можно с ней, а можно и без нее по ID главное уникальность комбинации 134 15 именно для таких случаев у меня проверка на NULLL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 05:43 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Здесь только 4, а не 10. Но суть одна.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:18 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Во-первых, пока ты писал название поста тебя почему-то глючило несколько раз, в конце вообще на английский переключился. Суть в том, что BIG DATA тут вообще ни при чём. BIG DATA - это кластеры, хадуп и пр. Во-вторых, я вообще не понимаю, зачем ты используешь Right join, позволяющий работать с NULL-полями и тут же пишешь "но только не NULL", причём череж зопу - путём конвертации в ноль. Убери все проверки на NULL и замени все RIGHT JOIN на INNER JOIN. Он будет подразумевать обязательный не-null. В-третьих, В целом, у меня ощущение, что тут БД вообще не пахнет. Надо писать какой-нибудь внешний модуль, который нагенерирует тебе столько значений. Тут C++ и распараллеливание нужно. Вот, у меня были сложные запросы - они возвращали миллионы записей (не миллиарды), при этом в результате оптимизации выяснялось, что где-то можно индексы вставить, от нескольких сотен тысяч записей отказаться, что-то редко изменяемое предварительно агрегировать по ночам либо триггерами в отдельную таблицу или столбцы и т.д. Т.е. там был простор для оптимизаций. У тебя здесь банально - нагенерировать все сочетания без повторений 10 элементов из 60. SQL для этого не стоит использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:18 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizzaу вас val может быть null? Зачем вы null превращаете в 0 и потом сравниваете с нулем когда есть конструкция is not null? Это лишние операции конвертации, которые вам совсем не нужны.Условие Код: sql 1. эквивалентно следующему Код: sql 1. Причём это условие превращает запрос в SARGable ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:19 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
iapPizzaPizzaу вас val может быть null? Зачем вы null превращаете в 0 и потом сравниваете с нулем когда есть конструкция is not null? Это лишние операции конвертации, которые вам совсем не нужны. Условие Код: sql 1. эквивалентно следующему Код: sql 1. Причём это условие превращает запрос в SARGable бред какой-то. 1. Как раз то выражение, которое ты идентифицировал словом условие , делает его не оптимизируемым ("не саргблеа") банально из-за использования функции. 2. Первое и второе выражения не являются эквивалентными, поскольку Код: sql 1. эквивалентно Код: sql 1. 3. Почему нельзя вместо Код: sql 1. написать Код: sql 1. чтобы как раз оно стало оптимизируемым? Я уверен, что val не содержит скалярных нулей. 4. Нафига писать сначала right join, который разрешает использование null, а затем тут же запрещать использование null какими-то условиями? (кажется, я уже писал про это, но ты проигнорировал). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:36 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Charles Weyland, бред какой-то Код: sql 1. и это не равно zone01.val !=0? как же так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:43 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Charles Weylandбред какой-тоПолегче! Charles WeylandПочему нельзя вместо Код: sql 1. написать Код: sql 1. Потому что результат этих выражений разный в WHERE различаются результаты булевых выражений TRUE и NOT TRUE. Если zone01.val IS NULL, то zone01.val<>0 возвращает UNKNOWN, то есть NOT TRUE. Таким образом, NULL фильтруется и без всякого ISNULL(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 10:55 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
iap, А можно пояснить? Имеет ли преимущества выражение Код: sql 1. в случае, когда не подразумевается 0 как возможное знание (насколько я понял у тс это используется именно для фильтрации null от outer joinов) ? А в случае, если возможны и null и 0 это выражение лучше чем два @ <> 0 and @ is not null? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 11:08 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Возможно недопонимаю постановку , но запрос ТС неправильный (взять на 4 ) : Запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. вернет меньше комбинаций,чем Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Возможно в последнем запросе нужно написать Код: sql 1. 2. 3. чтобы результаты были идентичными ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 11:10 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
PizzaPizzaiap, А можно пояснить? Имеет ли преимущества выражение Код: sql 1. в случае, когда не подразумевается 0 как возможное знание (насколько я понял у тс это используется именно для фильтрации null от outer joinов) ? А в случае, если возможны и null и 0 это выражение лучше чем два @ <> 0 and @ is not null?Однако, если не равно 0, то автоматически IS NOT NULL. Отдельное IS NOT NULL - лишнее. Что касается именно функции ISNULL(), то сервер во многих случаях умеет использовать индексы и в случае её применения. Но полный перечень таких случаев я дать не могу. Общее правило - по возможности не накладывать ограничение на функцию от поля, а стараться накладывать его на само поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 11:16 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
iapЧто касается именно функции ISNULL(), то сервер во многих случаях умеет использовать индексы и в случае её применения. Но полный перечень таких случаев я дать не могу.Вот, например, если в таблице прописано, что поле NOT NULL, то сервер реагирует на ISNULL(поле,...) так, как будто никакого ISNULL() нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 11:20 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Charles Weyland, Да, я уже думал о другой платформе для генерирования, но уж слишком большой результат 75 394 027 566 и он будет расти т.к. количество зон, будет расти. Пока не нашел ничего подходящего... ((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 17:42 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Shanga, какая Вам разница - сколько суток? Эта таблица заполняется один раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 18:35 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
75 394 027 566 сочетаний из 60 по 10. Объем таблицы при длине сгенерированной строки 50 (например) - примерно 4Тб. Тут юмор какой-то обсуждают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2018, 19:49 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Вкратце, идея состоит в уменьшении количества Nested Loops при обработке больших объемов. Для этого создаем промежуточную таблицу, в которой уже есть упорядоченные пары значений: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Для простоты используем только 2 таблицы в декартовом произведении, но можем использовать и больше. Затем при помощи данной таблицы пар получаем запрос вида: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. результаты которого можно сохранять в нужном формате. Не совсем ясна необходимость хранения столь большого массива комбинаций в материализованном виде, также смущают сложности, которые обязательно возникнут при добавлении новых зон, ибо добавление всего одной зоны к уже имеющимся 60 увеличит объем хранимой информации на 20%. Т.е. 4 ТБ становятся 4.8 ТБ, 62 зоны - 5.7 ТБ, и так далее. Опять же, объем индексов тоже будет расти, как и сложность в обслуживании данной таблицы. Естественно, часть проблем можно решить используя COLUMNSTORE, но, ИМХО, имеет смысл рассмотреть варианты с представлениями или процедурами/функциями для реализации данного функционала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2018, 01:10 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
BalbidonЕстественно, часть проблем можно решить используя COLUMNSTOREВроде же columnstore практ. бесполезен на уникальных столбцах, не? А здесь, как я понял, будут уникальные значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2018, 07:54 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Ennor Tiegael, Строки уникальны - это да. Ну а в столбцах будут миллиарды повторений из 60+ уникальных значений, так что, мне кажется, COLUMNSTORE - самое оно. Особенно для первых столбцов эффект должен быть хорош, т.к. в первом столбце будет всего 60+ групп, вместо 75 миллиардов повторяющихся значений. К сожалению, я не нашел никаких деталей реализации COLUMNSTORE COMPRESSION в SQL Server, но даже если там простой RLE алгоритм, должно работать весьма эффективно. Если бы это была HPE Vertica или AWS Redshift, то первые 9 столбцов можно было бы определить как RLE/Runlength, а последний как Dictionary, что в сумме дало бы очень серьезный эффект сжатия. Но это оффтоп... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2018, 22:05 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
я всё-таки не пойму, если тебе нужны просто комбинации - то почему ты не используешь просто какой-нибудь язык программирования, который бы тебе эти комбинации нагенерировал? А вообще, у меня главный вопрос - какова конечная цель всех этих комбинаций? Что ты с ними будешь делать? Просто если ты хочешь их пронумеровать и обращаться по номеру - имеет смысл написать формулу, которая сопоставляла бы комбинацию с номером и высчитывала её по мере запросов. Запросил комбинацию номер 12435 - и эта формула тебе её выдала. Если ты хочешь распечатать и на стенку повесить - то надо написать прогу на C++, она в блокнот всё выдаст - и печатай. Если ты хочешь на экран пользователю (зачем-то) выводить -то можно, опять же, высчитывать ровно те, которые нужно отобразить, игнорируя остальные. Если ты хочешь полученную таблицу INNERJOIN с какой-то другой - то это абзац. Что-то не то у тебя с проектированием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2018, 10:49 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Balbidon, А, вы имели в виду хранить каждое значение последовательности в своем столбце? Тогда может быть, но писать джойны к такому будет больно. Я-то полагал, что речь идет и некоей свертке или хэше, и тут columnstore вряд ли что-то даст, значения-то уникальные. Даже если сделать ключ tinyint (60 элементов поместятся без проблем), а хэш соответственно binary(10)... не, все равно фигня какая-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2018, 10:50 |
|
||
|
Оптимизация рабаты с BIG DATA
|
|||
|---|---|---|---|
|
#18+
Ennor Tiegael, Джойны к таблице с COLUMNSTORE индексом ничем не отличаются от джойнов к таблице без оного в плане синтаксиса. Планы же в первом случае будут даже более эффективными, т.к. порядок столбцов может быть любым и других индексов не потребуется. А как раз без COLUMNSTORE придется создавать помимо кластерного (не обязательно, но лучше иметь) еще и по некластерному на каждый столбец. Charles Weyland, Поддержу однозначно. Но все-таки академический интерес данная задача представляет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2018, 23:43 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1688760]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
1ms |
| others: | 269ms |
| total: | 428ms |

| 0 / 0 |
