Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
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 май 14, 14:29    [16021329]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
rstudio
Тогда исправьте 800 гб в своем тесте на 200 гб и отметьте, что конкретно эти данные особой природы могут быть сжаты.

Любой тест, это царство точных цифр. А у вас сейчас торчит в начале теста "база 800 гб" которая по сути ниочем не говорит, потому что тест не использует даже половины этих данных.


800 GB - это объем первоначальных данных который загружается в базы данных.
А уж количество читаемых данных зависит от движка. Если Oracle должен будет прочитать 800 GB, то Sybase IQ, например, считает гораздо меньше. У MS SQL Server 2014 количество считываемых данных будет зависеть от конфигурации, данные могут храниться как колонками так и рядами.


800 гб в вашем тесте ниочем не говорит. Это может быть и 800 терабайт и 800 петабайт.
Тоесть эта цифра ниочем, если в вашем тесте движок не читает эти данные и не использует.
15 май 14, 14:35    [16021377]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms.


6 миллионов = 200 мс
6 млрд = 20 секунд

У вас на GPU 37 секунд.
Зачем испльзовать GPU ??
15 май 14, 14:39    [16021412]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
поэтому col1 ... col17 должны быть std::map.


Есть вещи и побыстрее чем стд мап.
Но там правда бенчмарки правда не рисованые.
15 май 14, 14:42    [16021436]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
Ещё не вижу группировки по строкам


Группировка есть, просто в каждой строке одни и теже значения и поэтому все группируется в одну строку.
Без понимания природы данных, развивать пример не имеет смысла.
Возможно по условию l_shipdate <= 19980902 подходит только несколько строк, тогда и запрос будет копеечным.
15 май 14, 14:50    [16021494]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
29 Белых Котиков
Для этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки.


тест и так аналогичный, поскольку хоть аленка, хоть киселенка будет сканить всю таблицу, попутно высчитывая показатели.
15 май 14, 14:53    [16021525]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
rstudio
29 Белых Котиков
Для этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки.


тест и так аналогичный, поскольку хоть аленка, хоть киселенка будет сканить всю таблицу, попутно высчитывая показатели.


У тебя те три переменные либо в регистре, либо в кеше первого уровня, то есть никогда не покидают процессора за всё время расчёта. А память перекачать тоже время занимает. И вот тут уже возникает интересный вопрос, что эффективнее -- качать из обычной оперативки в процессор, либо загнать в GPU и там посчитать.

Хотя тест очень хорошо показал, что производительности самого процессора достаточно для выполнения задачи, весь затык в скорости чтения оперативки.
15 май 14, 15:00    [16021574]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
rstudio
anton2013
У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms.


6 миллионов = 200 мс
6 млрд = 20 секунд

У вас на GPU 37 секунд.
Зачем испльзовать GPU ??


Вы же не будете каждый писать программы на С для вычисления SQL выражений.
Да и быстрее получается с gpu(у вас ошибка в вычислениях).
На самом деле этот запрос весьма труден для многих баз данных, фильтр отбрасывает < 5% записей поэтому индексы использовать нельзя. Сканирование констант в кэше CPU действительно быстро, но попробуйте то же самое с 6 миллиардами 8-байтных значений ( только одна колонка займет почти 50 GB памяти).
15 май 14, 15:05    [16021604]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
29 Белых Котиков
У тебя те три переменные либо в регистре, либо в кеше первого уровня, то есть никогда не покидают процессора за всё время расчёта.


Там без разницы. Если сделать массив значений и оттуда их читать, в оперативной памяти, всеравно все хорошо ложится на конвеер процессора. Он блоками загружает по несколько мегабайт, прогнозирует следующий адресс и в несколько потоков микропроцессора выполняет. Такова природа выполнения этого запроса, он предсказуем и хорошо ложится на конвеер предсказаний.
15 май 14, 15:05    [16021610]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
rstudio
пропущено...

6 миллионов = 200 мс
6 млрд = 20 секунд

У вас на GPU 37 секунд.
Зачем испльзовать GPU ??


Вы же не будете каждый писать программы на С для вычисления SQL выражений.
Да и быстрее получается с gpu(у вас ошибка в вычислениях).
На самом деле этот запрос весьма труден для многих баз данных, фильтр отбрасывает < 5% записей поэтому индексы использовать нельзя. Сканирование констант в кэше CPU действительно быстро, но попробуйте то же самое с 6 миллиардами 8-байтных значений ( только одна колонка займет почти 50 GB памяти).


rstudio
Зачем испльзовать GPU ??

Если у вас на ЖПУ вычисляется 37 секунд, а программа на Си без всяких ЖПУ делает это за 10 секунд максимум ?
15 май 14, 15:10    [16021650]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
Тоесть на самом деле задача звучит примерно так.

98% Зависит от дисковой подсистемы
2% Зависит от процессора.

Вы говорите. Вычеркиваем дисковую систему, она в тесте не используется, вот меряем сам обсчет данных, пытаемся оптимизировать несчастные 2%.
Ок. Вот пример где на Си программка на ЦПУ считает за 10 секунд, без учета работы дисковой подсистемы.
Зачем было использовать ЖПУ, где получилось 37 сек.
15 май 14, 15:16    [16021694]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
Что-то не получается 4 секунды.

Вот ваш код с таймингом
#include <iostream>
#include <ctime>

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 ;

    clock_t start_clock = std::clock();

    for(; count < 6000000000; count++) //l_shipdate <= 19980902
    {
        if(l_shipdate <= 19980902)
        {
            //col1
            col1 += l_quantity;      //sum(l_quantity) as sum_qty,
            col2 += l_extendedprice;    //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;
}


К сообщению приложен файл. Размер - 20Kb
15 май 14, 16:39    [16022369]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
Теперь с вычиткой одного столбца данных из оперативки

#include <iostream>
#include <ctime>
#include <string.h>

#define DATA_WINDOW_SIZE 1000000

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 ;

    int *a_prices = new int[DATA_WINDOW_SIZE];    

    clock_t start_clock = std::clock();

    memset(a_prices, 0, sizeof(int) * DATA_WINDOW_SIZE);

    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;
}


К сообщению приложен файл. Размер - 22Kb
15 май 14, 16:50    [16022478]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
Результаты в зависимости от компиляторов, осей и конфигурации железа могут варьироваться в пределах 50%.

Еще раз вопрос. Зачем использовать ЖПУ ? Какой выиграш это дает в процентах ?
15 май 14, 17:42    [16022897]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
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 май 14, 17:52    [16022958]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
В процентах ?
Вы посчитайте, чтобы у вас результаты были правильные, а потом сравните ваше время и время на других серверах, это и будет разница в процентах ради которой фирмы покупают дорогое железо.
15 май 14, 17:58    [16022991]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
В процентах ?
Вы посчитайте, чтобы у вас результаты были правильные, а потом сравните ваше время и время на других серверах, это и будет разница в процентах ради которой фирмы покупают дорогое железо.


Фирмы покупают дорогое железо, чтобы увеличить например RAM.
В этот RAM может влезть терабайтная база целиком и без сжатия.
И GPU тут нипричем. На вашу систему, увы все упрется в дисковую систему.
Но и если время дисковой системы вычесть, выиграша не видно вообще от использования GPU
15 май 14, 18:03    [16023022]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
rstudio
anton2013
У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms.


6 миллионов = 200 мс
6 млрд = 20 секунд

У вас на GPU 37 секунд.
Зачем испльзовать GPU ??


Извините, я наверное, что-то пропустил. А откуда 37 секунд взялось? По ссылке запрос 77 секунд работает. Вы как-то выделили время расчётной части или протестировали запрос у себя?
15 май 14, 18:18    [16023100]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
rstudio,
Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно.
А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu.
15 май 14, 18:20    [16023107]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
anton2013
rstudio,
Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно.
А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu.


Наверное, они и ядра GPU лицензировать в софте будут

А на радеоне эта база не работает?
15 май 14, 18:22    [16023123]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
29 Белых Котиков,

Да там всё с арифметикой плохо, 200 ms * 1000 будет 200 секунд а не 20.
15 май 14, 18:23    [16023131]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
29 Белых Котиков
anton2013
rstudio,
Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно.
А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu.


Наверное, они и ядра GPU лицензировать в софте будут

А на радеоне эта база не работает?


Только на Nvidia к сожалению. Под радеоном нет библиотек типа ModernGpu и Thrust. Да я и базой её особо не называл бы. Скорее исследовательский проект.
15 май 14, 18:27    [16023151]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
29 Белых Котиков
rstudio
пропущено...


6 миллионов = 200 мс
6 млрд = 20 секунд

У вас на GPU 37 секунд.
Зачем испльзовать GPU ??


Извините, я наверное, что-то пропустил. А откуда 37 секунд взялось? По ссылке запрос 77 секунд работает. Вы как-то выделили время расчётной части или протестировали запрос у себя?


Да, недоглядел. 77 секунд с ЖПУ
15 май 14, 18:30    [16023161]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
rstudio,
Кстати, если уж писать код для суммирования l_price то используйте double а не int, иначе переполнение на шести миллиардах значений неизбежно.
А по поводу преимуществ - не у всех есть сотни тысяч долларов на дорогие серверы и лицензии Oracle, поэтому комбинация дешевой памяти и gpu может стать в будущем интересным вариантом. У IBM много research articles по использованию gpu в базах данных и сервера следующего поколения Power8 все поддерживают gpu.


Вы опять ушли в маркетинговый булшит.
Вам уже вдесятый раз ответили, что использование в СУБД ЖДИПу нецелесообразно.
По крайней мере для 95% задач. И сказали причину - узкое место СУБД это дисковые системы ввода/вывода.
15 май 14, 18:34    [16023193]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013,

Я бы рекомендовал не хватать с неба звезд.
А переписать хотябы тотже std::map на GPU.
По крайней это будет честное ИнМемори и честные тесты с соизмиримой функциональностью.
15 май 14, 18:36    [16023207]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить