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

Откуда:
Сообщений: 15
В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся.

https://github.com/antonmks/Alenka/blob/master/monster.md
5 май 14, 20:46    [15976113]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
А с TJ7 есть сравнение?
6 май 14, 00:29    [15976687]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
anton2013
В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся.

https://github.com/antonmks/Alenka/blob/master/monster.md

Это типа конкуренция TCP? Не плохо бы хотя бы фотку этой Аленки. Кто знает, может тогда в чем-то бы и превзошли TCP в плане привлекательности.
6 май 14, 08:37    [15977147]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Опечатка: TCP, следует читать как TPC
6 май 14, 08:40    [15977155]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
я кстати в свое время не хуже тест предлагал
4853
6 май 14, 09:56    [15977481]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
Yo.!
Guest
anton2013
В статье сравниваются 4 сервера от IBM, HP и т.д. по скорости выполнения простого запроса. Также сравниваются цены серверов и баз данных с упором на дороговизну MS SQL Server 2014. Затем идет сравнение с базой данных с использованием gpu. Статья на английском, но кому надо - разберётся.

https://github.com/antonmks/Alenka/blob/master/monster.md

а где там сервера сравнивали ? ссылка верная ? та что дана ведет на детский сад сравнивший один поток одного процессора...
7 май 14, 20:55    [15987857]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9882
Вам смешно, а у нас вроде так заказчик собирается СХД (система хранения данных) перед покупкой сравнивать.

Разные сервера, разные настройки Oracle. Залили БД и сравнили... СХД...

Сейчас пытаюсь понять, каким именно SELECT'ом они СХД сравнивать будут ))) что бы нужные таблички в 60 Gb buffer pool Oracle положить ))) Наше СХД будет самым быстрым! Я в это верю )))
8 май 14, 12:52    [15990680]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Leonid Kudryavtsev
Наше СХД будет самым быстрым! Я в это верю )))

Думаю, что тот человек, который этот запрос в database firewall загонит легко переплюнет ваше СХД по скорости. :)
8 май 14, 13:26    [15991048]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
tanglir
Member

Откуда:
Сообщений: 28966
Alexander Ryndin
А с TJ7 есть сравнение?
Про Стебелёк не забываем :)
11 май 14, 17:23    [16000336]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

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

Сколько уже автору обьяснять, что узким местом базы есть скорость вычитки с винтов.
При базе в 800 гиг чтобы вложится в пресловутые 80 секунд нужно читать
10 гиг в секунду.

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

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

Сколько уже автору обьяснять, что узким местом базы есть скорость вычитки с винтов.
При базе в 800 гиг чтобы вложится в пресловутые 80 секунд нужно читать
10 гиг в секунду.

Тачки стоимость в один лям могут себе позволить загнать всю базу в рам и добиться таких результатов,
а вот автор Киселенки за 1700 уе с ССДшниками - врядли.



Зато он может нехилый такой SN кластер собрать.
14 май 14, 22:08    [16017982]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
Вообще, в GA-890FXA-UD7 можно воткнуть три RevoDrive 350 - PCI Express (PCIe) SSD, что даст 5400 мегабайт в секунду на чтение, чего, учётом возможного сжатия в два раза должно хватить для достижения требуемых показателей.
14 май 14, 22:28    [16018069]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
29 Белых Котиков
Вообще, в GA-890FXA-UD7 можно воткнуть три RevoDrive 350 - PCI Express (PCIe) SSD, что даст 5400 мегабайт в секунду на чтение, чего, учётом возможного сжатия в два раза должно хватить для достижения требуемых показателей.


если бы у бабушки были яйца то она была бы дедушкой.
В заявленую цену 1700 уе никак не вписываются "три RevoDrive 350 - PCI Express (PCIe) SSD".
На счет сжатия, тоже терзают мутные сомнения.
Короче меряли непонятно что, непонятно как и непонятно зачем.
И это чтото не сходится даже по банальной скорости чтения с дисков, не говоря уже о какихто там вычислениях.
14 май 14, 23:02    [16018262]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого.
А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных.
15 май 14, 10:52    [16019651]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

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

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

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого.
А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных.


Тогда исправьте 800 гб в своем тесте на 200 гб и отметьте, что конкретно эти данные особой природы могут быть сжаты.

Любой тест, это царство точных цифр. А у вас сейчас торчит в начале теста "база 800 гб" которая по сути ниочем не говорит, потому что тест не использует даже половины этих данных.
15 май 14, 13:01    [16020634]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
anton2013
База колоночная, поэтому для запроса не нужно читать все 800 GB. Нужные колонки занимают около 200 GB и при сжатии 1:4 помещаются в 64 GB оперативной памяти. 64 GB можно купить относительно недорого.
А следующим узким местом после чтения данных становится способность базы данных их обработать. И здесь на ведущие места выдвигаются базы типа VectorWise или MS SQL Server 2014 которые способны эффективно использовать современные процессоры с векторной обработкой данных.


Вот тебе чистый С++ код, моделирующий вычислительную часть твоего запроса.
6 млрд типо строк. Без учета работы дисков.

int _tmain(int argc, _TCHAR* 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 ;
	
	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;

	printf("%d %d %d %d %d %d %d", col1, col2, col3, col4, col5, col6, col7);

	return 0;
}


У меня получилось 4 секунды.
Чистый NoSQL рулит. Смотри что у тебя там в аленке тормозит )
15 май 14, 13:30    [16020897]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
rstudio
Member [заблокирован]

Откуда: net.pikosec.com
Сообщений: 3580
Выводы:
1. Вычислительной задачи там на 4-5 секунд и без всяких GPU.
2. Основной затык, типичный для СУБД в дисковой системе.
15 май 14, 13:34    [16020932]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
Так оно всё либо в регистрах лежит, либо в кеше процессора. А вот попробуй теперь в скорость чтения DDR упереться (12 Гб/с на DDR3)
15 май 14, 13:40    [16020983]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

Откуда: ИТ-бог. Мне доверяют 30 человек.
Сообщений: 2860
Для этого надо сделать массив в 100 мегов и циклически выбирать из него строки через деление по модулю от числа строк в массиве. Тогда тест будет аналогичным тесту алёнки.
15 май 14, 13:47    [16021021]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

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

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


800 GB - это объем первоначальных данных который загружается в базы данных.
А уж количество читаемых данных зависит от движка. Если Oracle должен будет прочитать 800 GB, то Sybase IQ, например, считает гораздо меньше. У MS SQL Server 2014 количество считываемых данных будет зависеть от конфигурации, данные могут храниться как колонками так и рядами.
15 май 14, 13:52    [16021059]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

Откуда:
Сообщений: 15
У вас вычисления на константах, попробуйте на массивах с реальными данными. Ещё не вижу группировки по строкам, а это довольно cpu-интенсивная часть. Если кому интересно, в интернете есть программа для реального вычисления этого запроса на языке С. Если мне не изменяет память, то вычисления для 6 миллионов записей занимали 200 ms.
15 май 14, 14:04    [16021150]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
29 Белых Котиков
Member

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


С учётом числа значений будет примерно так

			
//col1
			col1[l_returnflag*10+l_linestatus] += l_quantity;      //sum(l_quantity) as sum_qty,
			col2[l_returnflag*10+l_linestatus] += l_extendedprice;    //sum(l_extendedprice) as sum_base_price,
			col3[l_returnflag*10+l_linestatus] += l_extendedprice * (1 - l_discount); // sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
			col4[l_returnflag*10+l_linestatus] += l_extendedprice * (1 - l_discount) * (1 + l_tax); //sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
			col5[l_returnflag*10+l_linestatus] += l_quantity; //avg(l_quantity) as avg_qty,
			col6[l_returnflag*10+l_linestatus] += l_extendedprice; //avg(l_extendedprice) as avg_qty,
			col7[l_returnflag*10+l_linestatus] += l_discount; //avg(l_discount) as avg_qty,
15 май 14, 14:10    [16021202]     Ответить | Цитировать Сообщить модератору
 Re: Сравниваем скорость SQL-запроса на суровых серверах  [new]
anton2013
Member

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


С учётом числа значений будет примерно так

			
//col1
			col1[l_returnflag*10+l_linestatus] += l_quantity;      //sum(l_quantity) as sum_qty,
			col2[l_returnflag*10+l_linestatus] += l_extendedprice;    //sum(l_extendedprice) as sum_base_price,
			col3[l_returnflag*10+l_linestatus] += l_extendedprice * (1 - l_discount); // sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
			col4[l_returnflag*10+l_linestatus] += l_extendedprice * (1 - l_discount) * (1 + l_tax); //sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
			col5[l_returnflag*10+l_linestatus] += l_quantity; //avg(l_quantity) as avg_qty,
			col6[l_returnflag*10+l_linestatus] += l_extendedprice; //avg(l_extendedprice) as avg_qty,
			col7[l_returnflag*10+l_linestatus] += l_discount; //avg(l_discount) as avg_qty,


Да, примерно так. Только хэш-функцию надо позамысловатее, а то будет конфликт у 1*10 + 0 и 0*10 + 10.
Еще мы не знаем сколько у нас будет сгруппированных значений, поэтому col1 ... col17 должны быть std::map.
15 май 14, 14:20    [16021272]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить