|
|
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Привет всем. Стенд CPU: 1 x Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz (Cores 4, Threads 8) RAM: 4 x 8GB Kingston 9965525-026.A00LF (DIMM Synchronous 1333 MHz (0.8 ns)) SSD: 2 x SAMSUNG MZ7WD480 480GB RAID1 SOFT Есть таблица test Код: 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. Минимальный срез статистики 1 день. статистику просматривать возможно по любому сочетанию полей m1,m2,m3,geo и сортировкой по полям (cs1|cs2). Отношения количество записей сгруппированных по o_id и уникальности записей Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. План запроса с созданием MV Код: 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. Без MV Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. На оригинальной таблице висит триггер которым группируется статистика без m1,m2,m3. В таблицу в среднем происходит 100 инсертов в сек + 10 апдейтов в сек. Желание ускорить выборку по m1,m2,m3 поэтому вопросы 1. Каким образом возможно ускорить запрос(определенное хранение данных)? 2. Возможно денормализация данных неверный шаг? Но это ускоряет вставку, что так же очень важно. 3. Возможно не правильно выбран инструмент для задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 12:13 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Rhim, partitioned table ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 12:17 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Щукина Анна, Оригинальная таблица партицированная по месяцам, но это не спасает от проблемы, добавляется только Append на пол сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 12:28 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
RhimПривет всем. Желание ускорить выборку по m1,m2,m3 поэтому вопросы 1. Каким образом возможно ускорить запрос(определенное хранение данных)? 2. Возможно денормализация данных неверный шаг? Но это ускоряет вставку, что так же очень важно. 3. Возможно не правильно выбран инструмент для задачи? Никаким иструментом вы не ускорите получение 6M строк ни от чего. Есть фиксированный overhead на обработку 1 строки в базе и на передачу ее по сети. У вас уже быстро все работает на самом деле. Приведите реалистичный пример чего вам надо ускорить не отдающий 6M строк. Если же надо именно 6M строк то объясните зачем они вам и что дальше с этим данными происходит. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 12:29 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Нужно сгруппировать к примеру m2,m3 и показать статистику по этим данным отсортированными по окончательным показателям SUM(cs2), дальше с этим срезом работаю постранично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 12:46 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
RhimMaxim Boguk, Нужно сгруппировать к примеру m2,m3 и показать статистику по этим данным отсортированными по окончательным показателям SUM(cs2), дальше с этим срезом работаю постранично. Тогда вам надо анализировать варианты запросов с Limit/offset. Если вы всем 6M строк ответа тянете на клиент - то толку от этого не будет никогда и никак. PS: я не совсем понял смысл приводить запрос генерации matview ? тот же запрос что и обычный + запись в таблицу. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 13:28 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, В MV складываются уже готовые данные и постраничное отображение статистики будет моментальным, к примеру WHERE id > 100 AND d <= 200. Каждый раз обрабатывать 6 млн строк накладно, то есть подготовление данных занимает 14 секунд. Проблемы начнутся когда кто то захочет посмотреть за больший период статистику к примеру 30 млн будут подготавливаться почти минуту с выделением что то около 6GB памяти. Пытаюсь понять как можно хранить уже подготовленные данные, что бы избежать или ускорить запрос с учетом что GROUP BY может быть любое сочетание m1,m2,m3,geo Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 14:06 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
RhimMaxim Boguk, Пытаюсь понять как можно хранить уже подготовленные данные, что бы избежать или ускорить запрос с учетом что GROUP BY может быть любое сочетание m1,m2,m3,geo Всего 15 вариантов сочетаний. Вот и предпросчитать заранее все 15 сочетаний в group by и далее по ним уж генерировать. PS: но вообще генерация matview штука очень тяжелая и дорогая. И делать для каждой новой страниц новый matview будет очень дорого. PPS: в общем случае подобные задачи не решаются быстро. На создание эффективных OLAP систем вообще ресурсов убито очень много, без особого успеха впрочем. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 14:17 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, нет, MV генерируется один раз, затем работа идет с матвьюхой(срезом данных). До момента обновления данных или выбора другого сочетания. Максим я Вас понял, спасибо огромное за консультацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2015, 14:23 |
|
||
|
Оптимизация.
|
|||
|---|---|---|---|
|
#18+
RhimMaxim Boguk, нет, MV генерируется один раз, затем работа идет с матвьюхой(срезом данных). До момента обновления данных или выбора другого сочетания. Максим я Вас понял, спасибо огромное за консультацию. эмуляция олапа. Делай так. Сначала сделай уже сгруппированную витрину (или матвью) с группой m1,m2,m3,geo и sum. После чего если тебе надо группа: m1, m2, sum или m2,geo, sum - то ты группируй уже по первой таблице! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 12:40 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=108&tid=1997885]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
11ms |
get forum data: |
4ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
| others: | 252ms |
| total: | 386ms |

| 0 / 0 |
