|
|
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПо model - тема сложная. Слишком много вариантов у модельки - итеративная, sequential rules, референсные модели... Куча условностей, влияющих на порядок выполнения. По сути еще один движок, в плане сложности мало уступающий SQL-engine - при практически полном отсутствии исследований/публикаций на тему internals. Black Box. Я до сих пор в прод запустил только одну совсем простую модельку с единственным правилом - без нее было очень сложно решить конкретную задачу.Если не мешать все в кучу, то все достаточно тривиально. Прежде всего модель означает загрузку всего набора данных в PGA для последующих speadsheet-like calculations. При этом создается workarea c operation_type равным 'SPREADSHEET'. Если в модели присутствует аналитика/агрегаты, то ясное дело создаются дополнительные рабочие области для сортировки и прочего. Для обычной моедли правила вполняются столько раз сколько указано в rules. Как правило указано не более одного правила на одну меру. В случае итеративной выполнения правил соотвественно вся кухня выполняется n раз. Правила бывают разного типа (с точки зрения перфоманса тоже), не буду в это счас углубляться. "Условности" косвенно понимаются по плану {ORDERED [FAST] | ACYCLIC [FAST] | CYCLIC}. Референснсные модели не более чем "рюшечка" и в них никакой необходимости вообще нет имхо - можно разрулить дополнительным соединением при получении набора данных для модели. Главный жирный минус - нелинейный рост там, где recursive subquery factoring или PL/SQL solutions имеют линейный (я молчу про случаи когда workarea не влезает в опаративку и уходит в TEMP TS). Думаю я не очень много нового сообщил. :) Вообще работа почти написана, надеюсь в ближйший месяц опубликовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 18:21 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
+ попробовали нагрузочный тест варианта через MODEL 19747142 - оказался в 3 раза быстрее варианта моей адаптации примера Кайта 19743456 и при этом линейно масштабируемым >Главный жирный минус - нелинейный рост там, где recursive subquery factoring или PL/SQL solutions имеют линейный (я молчу про случаи когда workarea не влезает в опаративку и уходит в TEMP TS). dbms_photoshop , можете ли привести примеры / скрипты, чтобы оценить, как этот вариант нагружает систему / когда вылезает в TEMP? вопрос важный, т.к. объемы большие (миллионы строк) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 18:53 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12dbms_photoshop , можете ли привести примеры / скрипты, чтобы оценить, как этот вариант нагружает систему / когда вылезает в TEMP? вопрос важный, т.к. объемы большие (миллионы строк)Странный несколько вопрос. Я ж не знаю вашей конфигурации. Если есть желание, чтоб ушло в темп, можно сделать в сессии примерно следующее Код: plaintext 1. Нагрузочное тестирование тоже звучит несколько странно. Пока будет хватать оперативки и CPU для каждого из процессов все может быть относительно хорошо. А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. Я не совсем согласен с выводами Кайта, как будет время посмотрю детальнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 19:11 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, >А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. вот про это и интерес - есть информация, когда это начинается / как узнать и измерить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2016, 19:49 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Alexus12dbms_photoshop, >А вот с ростом data volumes модель будет все больше уступать альтернативным решениям. вот про это и интерес - есть информация, когда это начинается / как узнать и измерить?Я сказал, что зависит от настроек. Я рассказал про инструментарий и как пользоваться (как узнать и измерить). Я объяснил некорректность вопроса. Ты продолжаешь задавать то же самое. Предполагается, что надо все прожевать и в рот положить? Тест ниже для демонстрации не масштабируемости для задачи Кайта. (мотивацией для нижеследующего было убедиться, что Кайт неправ) Код: plsql 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. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. Первые две итерации PL/SQL проигрывает в пределах погрешности. Потом модель проигрывает в три раза, потом в четыре, потом в пять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 01:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
Еще пару моментов. 1) тестировать вариант с recursive subquery factoring для данной задачи без индекса на таблице - это вообще не серьезно, поэтому я его не включал. 2) если добавить к тесту выше еще одну итерацию (то есть на последней итерации будет 1М строк), результаты выглядят следующим образом. cnt - время выполнения в секундах число строк соответственно 10 000, 100 000 и 1 000 000. В последнем случае начинает уходить в темп для обоих подходов. PL/SQL выполнился за минуту, для модели после получаса выполнения прибил сессию. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 02:23 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, pattern matching Код: plsql 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. Потому как если делать, чтоб был матч на каждую группу I/D то нельзя посчитать rn (она будет в рамках группы, а не всей секции). А если делать матч на всю секцию, то нельзя посчитать "первую запись из последней группы" (будет первая запись в рамках всей секции, а не последней группы). А поскольку в вашем решении во всех аналитических функциях одинаковое окно, то смысла в match_recognize нет. Ну разве что таки можно извратиться и достичь нужного одним match_recognize без аналитики... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 04:01 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 11:07 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopandrey_anonymous,...нельзя посчитать rn (она будет в рамках группы, а не всей секции). Если я ничего не путаю, то по постановке этого не требовалось. rn появился в экспериментах ТС как побочный эффект от sog. ...что касается sog, то вариант, многократно вылизанный на данном форуме, мне как-то больше по душе, чем вариант с asktom... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:33 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousrn появился в экспериментах ТС как побочный эффект от sog У него на это заточена логика. Alexus12затем для каждой строки, где row_number() = 1 ...Речь не про sog. Замечание было по поводу невозможности решения одним pattern matching и без аналитики. Если я неправ - просьба опровергнуть с помощью конкретного решения. Вот и всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:40 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
>затем для каждой строки, где row_number() = 1 мне нужна эта строка для дальнейшей обработки, да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:45 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, слегка изменили ваш вариант отсюда 19743612 получилось так: Код: plsql 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. изменения: 1) во внутреннем запросе в выражении case lead(oper, 1, oper) убран последний oper - поэтому для крайнего значения возвращается null, что приводит к выводу в fv_2 значения _в том числе_ для первой записи первой подгруппы, а не только при смене подгрупп 2) во внешнем : выражение case rn -- when 1 then -- coalesce( -- lag(fv_ ignore nulls) over(partition by PRODUCT, trunc(TIME_ID) order by TIME_ID) -- , first_value(quant) over(partition by PRODUCT, trunc(TIME_ID) order by TIME_ID) заменено на , last_value(fv_2 ignore nulls) over (partition by PRODUCT, trunc(TIME_ID) order by TIME_ID ) lv это протягивает найденные во внутреннем запросе значения fv_2 от первой записи подгруппы на все ее записи в результате код избавился от тормозов, вносимых lag(fv_ ignore nulls) , и масштабируется линейно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2016, 15:56 |
|
||
|
получить первую запись из последней группы
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopОдним только match_recognize решить несколько затруднительно.Все решается элементарно если чуть больше поразмыслить. Код: plsql 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. В решении предполагается, что последняя группа состоит из D. Если это может быть не так - то просто чуть усложняется шаблон. Как выяснилось case/decode в measures всегда возвращают null. Еще баг из той же оперы: 20561938 . Но там one row per match и криво работает nullif. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2017, 22:31 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39324134&tid=1885682]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 497ms |

| 0 / 0 |
