|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013Да, примерно так. Только хэш-функцию надо позамысловатее, а то будет конфликт у 1*10 + 0 и 0*10 + 10 Тут имелась ввиду формула такая col1[l_returnflag*l_linestatus_cnt+l_linestatus], где l_linestatus_cnt -- количество различных значений переменной l_linestatus, а десятка взята из предположения, что много статусов ни к чему. anton2013Еще мы не знаем сколько у нас будет сгруппированных значений, поэтому col1 ... col17 должны быть std::map. Мы не можем утверждать, что не знаем, не обсуждая вопрос чтения данных, мы бы могли статистику в базе хранить по столбцам для каждой таблицы и на данном этапе выполнения запроса (подсчёт с группировкой) всё знать, а std::map заполнять при вставке данных, выстраивая звезду и храня в строках ссылки на индексы из мапы. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:29 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013rstudioТогда исправьте 800 гб в своем тесте на 200 гб и отметьте, что конкретно эти данные особой природы могут быть сжаты. Любой тест, это царство точных цифр. А у вас сейчас торчит в начале теста "база 800 гб" которая по сути ниочем не говорит, потому что тест не использует даже половины этих данных. 800 GB - это объем первоначальных данных который загружается в базы данных. А уж количество читаемых данных зависит от движка. Если Oracle должен будет прочитать 800 GB, то Sybase IQ, например, считает гораздо меньше. У MS SQL Server 2014 количество считываемых данных будет зависеть от конфигурации, данные могут храниться как колонками так и рядами. 800 гб в вашем тесте ниочем не говорит. Это может быть и 800 терабайт и 800 петабайт. Тоесть эта цифра ниочем, если в вашем тесте движок не читает эти данные и не использует. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:35 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms . 6 миллионов = 200 мс 6 млрд = 20 секунд У вас на GPU 37 секунд. Зачем испльзовать GPU ?? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:39 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013поэтому col1 ... col17 должны быть std::map. Есть вещи и побыстрее чем стд мап. Но там правда бенчмарки правда не рисованые. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:42 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013Ещё не вижу группировки по строкам Группировка есть, просто в каждой строке одни и теже значения и поэтому все группируется в одну строку. Без понимания природы данных, развивать пример не имеет смысла. Возможно по условию l_shipdate <= 19980902 подходит только несколько строк, тогда и запрос будет копеечным. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:50 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых КотиковДля этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки. тест и так аналогичный, поскольку хоть аленка, хоть киселенка будет сканить всю таблицу, попутно высчитывая показатели. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:53 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudio29 Белых КотиковДля этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки. тест и так аналогичный, поскольку хоть аленка, хоть киселенка будет сканить всю таблицу, попутно высчитывая показатели. У тебя те три переменные либо в регистре, либо в кеше первого уровня, то есть никогда не покидают процессора за всё время расчёта. А память перекачать тоже время занимает. И вот тут уже возникает интересный вопрос, что эффективнее -- качать из обычной оперативки в процессор, либо загнать в GPU и там посчитать. Хотя тест очень хорошо показал, что производительности самого процессора достаточно для выполнения задачи, весь затык в скорости чтения оперативки. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 15:00 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudioanton2013У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms . 6 миллионов = 200 мс 6 млрд = 20 секунд У вас на GPU 37 секунд. Зачем испльзовать GPU ?? Вы же не будете каждый писать программы на С для вычисления SQL выражений. Да и быстрее получается с gpu(у вас ошибка в вычислениях). На самом деле этот запрос весьма труден для многих баз данных, фильтр отбрасывает < 5% записей поэтому индексы использовать нельзя. Сканирование констант в кэше CPU действительно быстро, но попробуйте то же самое с 6 миллиардами 8-байтных значений ( только одна колонка займет почти 50 GB памяти). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 15:05 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых КотиковУ тебя те три переменные либо в регистре, либо в кеше первого уровня, то есть никогда не покидают процессора за всё время расчёта. Там без разницы. Если сделать массив значений и оттуда их читать, в оперативной памяти, всеравно все хорошо ложится на конвеер процессора. Он блоками загружает по несколько мегабайт, прогнозирует следующий адресс и в несколько потоков микропроцессора выполняет. Такова природа выполнения этого запроса, он предсказуем и хорошо ложится на конвеер предсказаний. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 15:05 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013rstudioпропущено... 6 миллионов = 200 мс 6 млрд = 20 секунд У вас на GPU 37 секунд. Зачем испльзовать GPU ?? Вы же не будете каждый писать программы на С для вычисления SQL выражений. Да и быстрее получается с gpu(у вас ошибка в вычислениях). На самом деле этот запрос весьма труден для многих баз данных, фильтр отбрасывает < 5% записей поэтому индексы использовать нельзя. Сканирование констант в кэше CPU действительно быстро, но попробуйте то же самое с 6 миллиардами 8-байтных значений ( только одна колонка займет почти 50 GB памяти). rstudioЗачем испльзовать GPU ?? Если у вас на ЖПУ вычисляется 37 секунд, а программа на Си без всяких ЖПУ делает это за 10 секунд максимум ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 15:10 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Тоесть на самом деле задача звучит примерно так. 98% Зависит от дисковой подсистемы 2% Зависит от процессора. Вы говорите. Вычеркиваем дисковую систему, она в тесте не используется, вот меряем сам обсчет данных, пытаемся оптимизировать несчастные 2%. Ок. Вот пример где на Си программка на ЦПУ считает за 10 секунд, без учета работы дисковой подсистемы. Зачем было использовать ЖПУ, где получилось 37 сек. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 15:16 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Что-то не получается 4 секунды. Вот ваш код с таймингом Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 16:39 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#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.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 16:50 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Результаты в зависимости от компиляторов, осей и конфигурации железа могут варьироваться в пределах 50%. Еще раз вопрос. Зачем использовать ЖПУ ? Какой выиграш это дает в процентах ? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 17:42 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиков, Ты в своем говнокоде используешь тяжелую операцию для процессора, взятие с остатком "%". Если переделать на обычный сдвиг, то получается 18 секунд. (Винда, и5 проц). // testc.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <iostream> #include <ctime> #include <string.h> #define DATA_WINDOW_SIZE 0xFFFFFF int main(int argc, char* argv[]) { int l_returnflag = 0; int l_linestatus = 0; int col1; int col2; int col3; int col4; __int64 col5; __int64 col6; __int64 col7; int l_quantity = 10; int l_extendedprice = 10; int l_discount = 1; int l_tax = 1; __int64 count = 0; int l_shipdate = 100; int *a_prices = new int[DATA_WINDOW_SIZE]; clock_t start_clock = std::clock(); memset(a_prices, 0, sizeof(int) * (DATA_WINDOW_SIZE + 1)); for(; count < 6000000000; count++) //l_shipdate <= 19980902 { if(l_shipdate <= 19980902) { //col1 col1 += l_quantity; //sum(l_quantity) as sum_qty, col2 += a_prices[count & DATA_WINDOW_SIZE]; //sum(l_extendedprice) as sum_base_price, col3 += l_extendedprice * (1 - l_discount); // sum(l_extendedprice * (1 - l_discount)) as sum_disc_price, col4 += l_extendedprice * (1 - l_discount) * (1 + l_tax); //sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, col5 += l_quantity; //avg(l_quantity) as avg_qty, col6 += l_extendedprice; //avg(l_extendedprice) as avg_qty, col7 += l_discount; //avg(l_discount) as avg_qty, } } col5 /= count; col6 /= count; col7 /= count; std::cout << "Затрачено времени в секундах: " << (std::clock() - start_clock) / CLOCKS_PER_SEC << std::endl; std::cout << "Результат агрегации:" << std::endl; std::cout << " " << col1 << ' ' << col2 << ' ' << col3 << ' ' << col4 << ' ' << col5 << ' ' << col6 << ' ' << col7 << std::endl; return 0; } ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 17:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
В процентах ? Вы посчитайте, чтобы у вас результаты были правильные, а потом сравните ваше время и время на других серверах, это и будет разница в процентах ради которой фирмы покупают дорогое железо. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 17:58 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013В процентах ? Вы посчитайте, чтобы у вас результаты были правильные, а потом сравните ваше время и время на других серверах, это и будет разница в процентах ради которой фирмы покупают дорогое железо. Фирмы покупают дорогое железо, чтобы увеличить например RAM. В этот RAM может влезть терабайтная база целиком и без сжатия. И GPU тут нипричем. На вашу систему, увы все упрется в дисковую систему. Но и если время дисковой системы вычесть, выиграша не видно вообще от использования GPU ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:03 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudioanton2013У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms . 6 миллионов = 200 мс 6 млрд = 20 секунд У вас на GPU 37 секунд. Зачем испльзовать GPU ?? Извините, я наверное, что-то пропустил. А откуда 37 секунд взялось? По ссылке запрос 77 секунд работает. Вы как-то выделили время расчётной части или протестировали запрос у себя? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:18 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudio, Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно. А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:20 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013rstudio, Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно. А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu. Наверное, они и ядра GPU лицензировать в софте будут А на радеоне эта база не работает? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:22 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиков, Да там всё с арифметикой плохо, 200 ms * 1000 будет 200 секунд а не 20. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:23 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиковanton2013rstudio, Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно. А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu. Наверное, они и ядра GPU лицензировать в софте будут А на радеоне эта база не работает? Только на Nvidia к сожалению. Под радеоном нет библиотек типа ModernGpu и Thrust. Да я и базой её особо не называл бы. Скорее исследовательский проект. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:27 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиковrstudioпропущено... 6 миллионов = 200 мс 6 млрд = 20 секунд У вас на GPU 37 секунд. Зачем испльзовать GPU ?? Извините, я наверное, что-то пропустил. А откуда 37 секунд взялось? По ссылке запрос 77 секунд работает. Вы как-то выделили время расчётной части или протестировали запрос у себя? Да, недоглядел. 77 секунд с ЖПУ ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:30 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013rstudio, Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно. А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu. Вы опять ушли в маркетинговый булшит. Вам уже вдесятый раз ответили, что использование в СУБД ЖДИПу нецелесообразно. По крайней мере для 95% задач. И сказали причину - узкое место СУБД это дисковые системы ввода/вывода. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:34 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013, Я бы рекомендовал не хватать с неба звезд. А переписать хотябы тотже std::map на GPU. По крайней это будет честное ИнМемори и честные тесты с соизмиримой функциональностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:36 |
|
|
start [/forum/topic.php?fid=35&msg=38642678&tid=1552360]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
149ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 258ms |
0 / 0 |