|
Сравниваем скорость 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?fid=35&msg=38752627&tid=1552360]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 179ms |
0 / 0 |