|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся. https://github.com/antonmks/Alenka/blob/master/monster.md ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2014, 20:46 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
А с TJ7 есть сравнение? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 00:29 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся. https://github.com/antonmks/Alenka/blob/master/monster.md Это типа конкуренция TCP? Не плохо бы хотя бы фотку этой Аленки. Кто знает, может тогда в чем-то бы и превзошли TCP в плане привлекательности. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 08:37 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Опечатка: TCP, следует читать как TPC ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 08:40 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
я кстати в свое время не хуже тест предлагал 4853 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2014, 09:56 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся. https://github.com/antonmks/Alenka/blob/master/monster.md а где там сервера сравнивали ? ссылка верная ? та что дана ведет на детский сад сравнивший один поток одного процессора... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2014, 20:55 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Вам смешно, а у нас вроде так заказчик собирается СХД (система хранения данных) перед покупкой сравнивать. Разные сервера, разные настройки Oracle. Залили БД и сравнили... СХД... Сейчас пытаюсь понять, каким именно SELECT'ом они СХД сравнивать будут ))) что бы нужные таблички в 60 Gb buffer pool Oracle положить ))) Наше СХД будет самым быстрым! Я в это верю ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2014, 12:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevНаше СХД будет самым быстрым! Я в это верю ))) Думаю, что тот человек, который этот запрос в database firewall загонит легко переплюнет ваше СХД по скорости. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2014, 13:26 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Alexander RyndinА с TJ7 есть сравнение?Про Стебелёк не забываем :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2014, 17:23 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Аленку в самый раз переименовать в Киселенку Сколько уже автору обьяснять, что узким местом базы есть скорость вычитки с винтов. При базе в 800 гиг чтобы вложится в пресловутые 80 секунд нужно читать 10 гиг в секунду. Тачки стоимость в один лям могут себе позволить загнать всю базу в рам и добиться таких результатов, а вот автор Киселенки за 1700 уе с ССДшниками - врядли. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2014, 21:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudioАленку в самый раз переименовать в Киселенку Сколько уже автору обьяснять, что узким местом базы есть скорость вычитки с винтов. При базе в 800 гиг чтобы вложится в пресловутые 80 секунд нужно читать 10 гиг в секунду. Тачки стоимость в один лям могут себе позволить загнать всю базу в рам и добиться таких результатов, а вот автор Киселенки за 1700 уе с ССДшниками - врядли. Зато он может нехилый такой SN кластер собрать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2014, 22:08 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Вообще, в GA-890FXA-UD7 можно воткнуть три RevoDrive 350 - PCI Express (PCIe) SSD, что даст 5400 мегабайт в секунду на чтение, чего, учётом возможного сжатия в два раза должно хватить для достижения требуемых показателей. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2014, 22:28 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых КотиковВообще, в GA-890FXA-UD7 можно воткнуть три RevoDrive 350 - PCI Express (PCIe) SSD, что даст 5400 мегабайт в секунду на чтение, чего, учётом возможного сжатия в два раза должно хватить для достижения требуемых показателей. если бы у бабушки были яйца то она была бы дедушкой. В заявленую цену 1700 уе никак не вписываются "три RevoDrive 350 - PCI Express (PCIe) SSD". На счет сжатия, тоже терзают мутные сомнения. Короче меряли непонятно что, непонятно как и непонятно зачем. И это чтото не сходится даже по банальной скорости чтения с дисков, не говоря уже о какихто там вычислениях. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.05.2014, 23:02 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого. А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 10:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого. А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных. Всё-таки согласен. Если рейд из 10 SSD стоит 1000 долларов, пусть автор соберёт этот рейд и проведёт тест до конца. А то какая-то ерунда выходит The SQL runs in just 77 seconds (disk time excluded. Why is it excluded? Because even with a cheap disk subsystem it becomes insignificant. Raid setup of 10 SSD (USD 1000) would read the compressed data in under 10 seconds). И, к тому же, на MSSQL 8 интелловских ксеонов за 47 секунд и вычитали, пускай из памяти и запрос посчитали. А тут куча ядер теслы и на две трети дольше без вычитки. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 12:08 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Хотя, с другой стороны интелловский процессор стоит 170000*8 = 1360000 рублей http://storserv.ru/catalog/servery/Komplekt-serv-platform/CPU/CPU-Intel-Xeon-E7-series-LGA1567/e74870.html , а Nvidia GTX Titan 40000 рублей. То есть, разница в цене будет в 34 раза. Вычитку правильно исключили, потому что в тестах сервер всё равно данные из кеша берёт, так что можно сравнить производительность именно процессора, но за 10 секунд оно не вычитает. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 12:19 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого. А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных. Тогда исправьте 800 гб в своем тесте на 200 гб и отметьте, что конкретно эти данные особой природы могут быть сжаты. Любой тест, это царство точных цифр. А у вас сейчас торчит в начале теста "база 800 гб" которая по сути ниочем не говорит, потому что тест не использует даже половины этих данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:01 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого. А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных. Вот тебе чистый С++ код, моделирующий вычислительную часть твоего запроса. 6 млрд типо строк. Без учета работы дисков. Код: 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.
У меня получилось 4 секунды. Чистый NoSQL рулит. Смотри что у тебя там в аленке тормозит ) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:30 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Выводы: 1. Вычислительной задачи там на 4-5 секунд и без всяких GPU. 2. Основной затык, типичный для СУБД в дисковой системе. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:34 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Так оно всё либо в регистрах лежит, либо в кеше процессора. А вот попробуй теперь в скорость чтения DDR упереться (12 Гб/с на DDR3) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:40 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Для этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:47 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudioТогда исправьте 800 гб в своем тесте на 200 гб и отметьте, что конкретно эти данные особой природы могут быть сжаты. Любой тест, это царство точных цифр. А у вас сейчас торчит в начале теста "база 800 гб" которая по сути ниочем не говорит, потому что тест не использует даже половины этих данных. 800 GB - это объем первоначальных данных который загружается в базы данных. А уж количество читаемых данных зависит от движка. Если Oracle должен будет прочитать 800 GB, то Sybase IQ, например, считает гораздо меньше. У MS SQL Server 2014 количество считываемых данных будет зависеть от конфигурации, данные могут храниться как колонками так и рядами. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 13:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:04 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. С учётом числа значений будет примерно так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:10 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиковanton2013Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. С учётом числа значений будет примерно так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Да, примерно так. Только хэш-функцию надо позамысловатее, а то будет конфликт у 1*10 + 0 и 0*10 + 10. Еще мы не знаем сколько у нас будет сгруппированных значений, поэтому col1 ... col17 должны быть std::map. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 14:20 |
|
Сравниваем скорость 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 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
rstudio, Гляньте на то что IBM делает с gpu и хранилищами данных : http://on-demand.gputechconf.com/gtc/2013/presentations/S3190-GPU-Heavy-Lifting-Data-Warehouse.pdf Если кому-нибудь интересно, могу опубликовать результаты Star Query Benchmark на моём стареньком PC и сравнить с аналогичными результатами для IBM BLU (это аналитическая супер быстрая база сделанная в IBM) на топовом железе. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 18:51 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Кстати, для вычисления хешей всяких ASIC PCIный бы больше подошёл. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:03 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
На топовом железе вся база влазит в РАМ. А это значит, что наконецто узкое место СУБД может быть не диски, а сами вычислительные мощности. Потому, возможно, ИБМ и есть что ковырять в этом направлении на топовом железе. Вы же упираетесь на дешевом железе в скорости оборота шпинделей винтов, сик тайм головок винчестера и прочьих радостей. Потому ковырять чтото там, попытка оптимизировать доли процентов. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:04 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Всё-таки ASIC рвут видеокарты на задачах расчёта хешей. То есть, добавление возможности использовать такой модуль для сравнения данных и для hash join ов было бы весьма полезным. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:11 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
В Оракле тоже узкие места это не только скан, но и сортировка и сам джойн. Можно в v$session_longops проверить. Соответственно, устройство для мгновенной сортировки всего было бы полезно. Жаль, что нельзя свои модули для выполнения операций над данными в СУБД встраивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:14 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Хотелось бы общий движок СКЛный, где ткнул на любое место плана запроса и подключил свой алгоритм в виде библиотеки. Там бы можно было любые эксперименты проводить. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:17 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
29 Белых Котиков, В основном для баз данных используют FPGA, они конфигурируемые. Пара коммерческих баз данных : KickFire и Netezza Я знаю ребят в Цюрихе которые этим занимаются : http://www.systems.ethz.ch/projects/avalanche Охотно берут к себе интересующихся. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2014, 19:20 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton201329 Белых Котиков, В основном для баз данных используют FPGA, они конфигурируемые. Пара коммерческих баз данных : KickFire и Netezza Я знаю ребят в Цюрихе которые этим занимаются : http://www.systems.ethz.ch/projects/avalanche Охотно берут к себе интересующихся. в нитизе фпга делает только фильтр данных по условию при чтении с дисков. Этого малова-то для революции ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2014, 11:56 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
On 06.05.2014 09:37, vadiminfo wrote: > Это типа конкуренция TCP? Не плохо бы хотя бы фотку этой Аленки. Кто Это и есть один из запросов из TPC-H. Или близкий. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2014, 17:59 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013rstudio, Гляньте на то что IBM делает с gpu и хранилищами данных : http://on-demand.gputechconf.com/gtc/2013/presentations/S3190-GPU-Heavy-Lifting-Data-Warehouse.pdf Если кому-нибудь интересно, могу опубликовать результаты Star Query Benchmark на моём стареньком PC и сравнить с аналогичными результатами для IBM BLU (это аналитическая супер быстрая база сделанная в IBM) на топовом железе. А вот как и обещал сравнение с IBM BLU на запросах к "star schema based" data warehouse : https://github.com/antonmks/Alenka/blob/master/AlenkaBLU.md Заметьте что запросы оптимизированы под SSD storage - база данных знает что данные хранятся на SSD и иcпользует оптимальный вариант доступа. Статья как всегда на английском - если кто-то не читает по английски то и статья ему разумеется не нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 14:15 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013база данных знает что данные хранятся на SSD Откуда она об этом знает? Т.е. кто ей об этом сказал, ибо сервак тупо подключен по FC к SAN, на которой есть массивы из SSD, SAS и SATA. anton2013и иcпользует оптимальный вариант доступа. Каким образом "вариант доступа" коррелирует с типом носителя? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 20:30 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013, авторAlenka Box 1 x Intel i3-4130 (2 cores, 3.4 GHz) 4 x 4 GB DDR3 1 x SATA SSD OCZ Vertex3 (120 GB) 1 x SATA WD Hard Drive (2 TB) 1 x GeForce Titan GPU (6GB of DDR5 memory) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 20:35 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
pkarklinanton2013база данных знает что данные хранятся на SSD Откуда она об этом знает? Т.е. кто ей об этом сказал, ибо сервак тупо подключен по FC к SAN, на которой есть массивы из SSD, SAS и SATA. anton2013и иcпользует оптимальный вариант доступа. Каким образом "вариант доступа" коррелирует с типом носителя? Параметер при запуске программы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 21:32 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013Параметер при запуске программы. Что?! Какой параметр? Вы в курсе того, что Вы несете? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 21:52 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013, Да, и сделайте мне так, чтобы блобы у меня лежали на SATA, не очень оперативные данные лежали на SAS, а очень оперативные лежали на SSD, причем это бы была одна бд с логической точки зрения. Когда Вы со своей наколенной поделкой сможете сделать это - приходите. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.09.2014, 22:04 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
pkarklin, А что вам не ясно ? При запуске программы используете параметер -ssd чтобы указать что данные расположены на SSD. А какой от этого толк - почитайте статью, там довольно понятно написано. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.09.2014, 07:57 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
anton2013А что вам не ясно ? При запуске программы используете параметер -ssd чтобы указать что данные расположены на SSD. А какой от этого толк - почитайте статью, там довольно понятно написано. Чуть раньше я описАл ситуацию, когда данные одной секционированной таблицы записей эдак на 10ки млрд. могут лежать на разных массивах (SATA, SAS, SSD) SAN. Какой "параметр программы" я должен использовать в данном случае? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2014, 23:09 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
pkarklinanton2013, Да, и сделайте мне так, чтобы блобы у меня лежали на SATA, не очень оперативные данные лежали на SAS, а очень оперативные лежали на SSD, причем это бы была одна бд с логической точки зрения. Когда Вы со своей наколенной поделкой сможете сделать это - приходите. Колонко-ориентированные СУБД спокойно это делают. Я с Vertica работаю, там можно как партиции разносить между разными носителями (SSD/SATA/HDFS), так и колонки проранжировать так, чтобы разные колонки на разных носителях хранились. По моему, если не изменяет память, Sybase IQ тоже умеет примерно такое же делать. Ну и другие колонко-ориентированные должны по идее. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2014, 00:54 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
ASCRUSpkarklinanton2013, Да, и сделайте мне так, чтобы блобы у меня лежали на SATA, не очень оперативные данные лежали на SAS, а очень оперативные лежали на SSD, причем это бы была одна бд с логической точки зрения. Когда Вы со своей наколенной поделкой сможете сделать это - приходите. Колонко-ориентированные СУБД спокойно это делают. Я с Vertica работаю, там можно как партиции разносить между разными носителями (SSD/SATA/HDFS), так и колонки проранжировать так, чтобы разные колонки на разных носителях хранились. По моему, если не изменяет память, Sybase IQ тоже умеет примерно такое же делать. Ну и другие колонко-ориентированные должны по идее. колумнсторе тут не причем, так все умеют кто умеет разные партиции на разные тэйблспейсы разносить. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2014, 10:44 |
|
Сравниваем скорость SQL-запроса на суровых серверах
|
|||
---|---|---|---|
#18+
Ivan DurakASCRUSпропущено... Колонко-ориентированные СУБД спокойно это делают. Я с Vertica работаю, там можно как партиции разносить между разными носителями (SSD/SATA/HDFS), так и колонки проранжировать так, чтобы разные колонки на разных носителях хранились. По моему, если не изменяет память, Sybase IQ тоже умеет примерно такое же делать. Ну и другие колонко-ориентированные должны по идее. колумнсторе тут не причем, так все умеют кто умеет разные партиции на разные тэйблспейсы разносить. Column-Store позволяют вынести наиболее критичные колонки, которые чаще всего используют в фильтрах и сортировках, на самые быстрые диски, даже и не трогая никаких партиций. Для MPP Vertica это даже более существенный выигрыш, чем партиционирование, которое используется не для ускорения запросов, а в первую очередь для освобождения быстрых дисков от устаревшей информации и возможности быстро при необходимости перенести или дропнуть большие массивы данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2014, 13:06 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552360]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
35ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 164ms |
0 / 0 |