Сравнение RDBMS в OLTP readonly тестах

Re: Сравнение RDBMS в OLTP readonly тестах

кто-нибудь может сконвертировать это чудо во что-нибудь более народное - хтмл, текст или просто запостить сюда основное?

Re: Сравнение RDBMS в OLTP readonly тестах

PostgreSQL 8 / EnterpriseDB 8:

max_connections = 300
shared_buffers = 50000 # min 16, at least max_connections*2, 8KB each
effective_cache_size = 48000 # typically 8KB each
lc_messages = 'en_US' # locale for system error message strings
lc_monetary = 'en_US' # locale for monetary formatting
lc_numeric = 'en_US' # locale for number formatting
lc_time = 'en_US' # locale for time formatting

чувак work_mem натюнить забыл, а там в запросах сортировки :(

ed (11.07.2005 16:05:50)

Re: Сравнение RDBMS в OLTP readonly тестах

Требяю тестов MS SQL Server!

Re: Сравнение RDBMS в OLTP readonly тестах

>Сравниваются MySQL 5.0.7 / InnoDB, MySQL 5.0.7 / MyISAM, Oracle 10g,

А нафига сравнивать хомяка с носорогом?

Sun-ch (11.07.2005 16:12:15)

Re: Сравнение RDBMS в OLTP readonly тестах

да и shared_buffers и effective_cache_size криво натюнины для 4 Gb RAM, что за лажа ?

ed (11.07.2005 16:16:44)

Re: Сравнение RDBMS в OLTP readonly тестах

Выдержка:

Краткие заключения:
1.
MySQL 5.0 / InnoDB показывает лучшый результат,
Oracle 10g медленнее на 6.5%
PostgreSQL 8 медленнее на 23.47%
MySQL 5.0 / MyISAM медленнее на 43.18%
EnterpriseDB 8 медленнее на 46.02%
2.
Oracle 10g показывает лучшую CPU маштабируемость с коэффициентом 3.83 (в
сравнении 4 HyperThreading CPU c 1 CPU),
EnterpriseDB 8 с коэффициентом 3.64
MySQL 5.0 / InnoDB – 3.44
PostgreSQL 8 – 3.26
MySQL 5.0 / MyISAM – 2.47
3.
MySQL 5.0.7-standard быстрее чем MySQL 4.1-standard на 9.25%
4.
MySQL 5.0 / MyISAM неожиданно показывает плохой результат. Хотя очень хорошая
маштабирумость в с ростом клиентских потоков, в отличии от других СУБД.

Остальное надо смотреть в оригинале.

the_one (11.07.2005 16:16:47)

Re: Сравнение RDBMS в OLTP readonly тестах

Плз. подскажи какие нужно поставить
shared_buffers
effective_cache_size
work_mem

Bizon (11.07.2005 16:19:18)

Re: Сравнение RDBMS в OLTP readonly тестах

> Выдержка:

спасибо, приятно все-таки, что есть люди уважающие читателей.

Re: Сравнение RDBMS в OLTP readonly тестах

Не увидел, как создавалась база ораклиная, какие там таблицы, какие индексы... Параметры запуска Оракла - это конечно хорошо, но мало :(

Vond (11.07.2005 16:26:03)

Re: Сравнение RDBMS в OLTP readonly тестах

Таблица для всех СУБД одинаковая

CREATE TABLE `sbtest` (
`id` int(10) unsigned NOT NULL,
`k` int(10) unsigned NOT NULL default '0',
`c` char(120) NOT NULL default '',
`pad` char(60) NOT NULL default '',
PRIMARY KEY (`id`),
KEY `k` (`k`);

Bizon (11.07.2005 16:28:35)

Re: Сравнение RDBMS в OLTP readonly тестах

для четырех гиг я бы поставил:

shared_buffers = 131072 # 1 Gb
effective_cache_size = 262144 # 2 Gb
work_mem = 131072 # 128 Mb

ed (11.07.2005 16:29:51)

Re: Сравнение RDBMS в OLTP readonly тестах

>Плз. подскажи какие нужно поставить
>shared_buffers
>effective_cache_size
>work_mem

shared_buffers ~ 1/4..1/2 от общего количества памяти.
effective_cache_size ~ 2/3 от общего количества памяти.
work_mem - в зависимости от объёма данных. у меня 1/8 от ram. нужно учитывать то, что действие этого параметра распространяется на каждую сессию. т.е. если у тебя 100 запросов просят по max(work_mem), то серверу поплохеет.подбирается экспериментально.

AlexGor (11.07.2005 16:34:06)

Re: Сравнение RDBMS в OLTP readonly тестах

А база как создавалась?

Vond (11.07.2005 16:34:24)

Re: Сравнение RDBMS в OLTP readonly тестах

По сцылке не ходил, но в новость чё-то не воткнул. Как OLTP может быть readonly?

Ron (11.07.2005 16:37:05)

Re: Сравнение RDBMS в OLTP readonly тестах

К сожалению как создавалась база не могу ответить - создавал не я.
Скорее всего все было по-умолчанию.
Какие имеено параметры интересуют, попробую уточнить.

Bizon (11.07.2005 16:38:01)

Re: Сравнение RDBMS в OLTP readonly тестах

2Bizon

выложи statpack report для оракла, иначе это очередной тест васи пупкина, который полезной информации не несет.

Re: Сравнение RDBMS в OLTP readonly тестах

а чо за work_mem ? может sort_mem ?

barmaglot (11.07.2005 16:46:29)

Re: Сравнение RDBMS в OLTP readonly тестах

>а чо за work_mem ? может sort_mem ?

это postgresql8. там именно work_mem.

AlexGor (11.07.2005 16:49:04)

Re: Сравнение RDBMS в OLTP readonly тестах

Имхо, выборка из одной таблицы - очень искусственный тест.
Тем более - таблица сравнима по размеру с оперативкой.
Тем более - только чтение. Неудивительно что MySQL всех порвал.
Думаю, *Base/Paradox тоже могли бы неплохо себя проявить ;)

Re: Сравнение RDBMS в OLTP readonly тестах

>выложи statpack report для оракла, иначе это очередной тест васи пупкина, который полезной информации не несет.

А что именно тебя интересует в результатах статпак-репорта для одной таблицы? Или пальцЫ в дверь не пролазят? :)

Re: Сравнение RDBMS в OLTP readonly тестах

ЛучшЫй результат... мда... фтопку такие результаты.

Re: Сравнение RDBMS в OLTP readonly тестах

>А что именно тебя интересует в результатах статпак-репорта для одной таблицы? Или пальцЫ в дверь не пролазят? :)

да вот пальцы не пролазят, и особенно часто задевают mysqlшиков :)

меня интересует:
Redo size
Logical reads
Block changes
Redo size
Logical reads
Block changes
Physical reads
Physical writes
User calls
Parses
Hard parses
Sorts
Logons
Executes
Transactions
Physical reads
Physical writes
User calls
Parses
Hard parses
Sorts
Logons
Executes
Transactions

и еще пара сотен цифр из репорта, надеюсь это не слишком сложная задача для объективных сравнивателей

Re: Сравнение RDBMS в OLTP readonly тестах

а SQL базы данных вообще могут работать быстро? У меня не получается вытаскивать из базы по сети больше 100 запросов в секунду... При этом сеть и процессор сервера с базой не загружены и на половину. В чем может быть причина?

petrosha (11.07.2005 17:53:15)

Re: Сравнение RDBMS в OLTP readonly тестах

>В чем может быть причина?
что за субд ? причины:
I/O
блокировки/эскалация
маленький cache
маленький sort area

и еще пара десятков менее очевидных.

Re: Сравнение RDBMS в OLTP readonly тестах

Вообщем порчитал и даже поначалу пытался там комментировать, но потом вчитался и понял, что нехрен там даже и отвечать.

Кстати: >Маштабирумость по клинтским потоком:

"Кто пойдёт за клинским?" (с) реклама

Re: Сравнение RDBMS в OLTP readonly тестах

>да вот пальцы не пролазят, и особенно часто задевают mysqlшиков :)

>меня интересует:
>Redo size
>Logical reads
Млин.. по сат-н-пейст экзамен сдан. По умению думать - нет. Не из той таблицы селект делал чтоли? почему имена статистик повторяются? :)

Теперь попробуй подумать
Redo size - только селекты, можешь прикинуть сколько redo?
Logical reads
Block changes - только селекты ...
Redo size
Logical reads
Block changes - только селекты ...
Physical reads
Physical writes - только селекты ...
User calls -
Parses - при совершенно одинаковых запросах сколько будет парсов?
Hard parses
Sorts
Logons - автор пишет сколько сессий работает в тесте, что-то еще?
Executes - .. аналогично
Transactions
Physical reads
Physical writes - только селекты ...

Я уж даже не спрашиваю - какие выводы ты собираешься делать их этой статистики.

Re: Сравнение RDBMS в OLTP readonly тестах

>Я уж даже не спрашиваю - какие выводы ты собираешься делать их этой статистики.

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

Re: Сравнение RDBMS в OLTP readonly тестах

Если коротко - бред.
Причем бред назчинается с сочетания OLTP (On-Line Transaction Processing) и read-only

Для "неокрепших" умов. Любые искуственные тесты не имеют к дейтсвительности ни малейшего отношения. Ключевое слово для поиска в гугеле "оптимизатор" и план исполнения сложного запроса.

ifconfig (11.07.2005 18:42:19)

Re: Сравнение RDBMS в OLTP readonly тестах

> Redo size - только селекты, можешь прикинуть сколько redo?

Смеяться будете, уважаемый анонимус, но я видел селекты, генерящие Redo. Всё дело в динамически создаваемых view было, насколько я помню. И простое указание use_nl вместо того, что в плане стоял hash_join, решало проблему, запрос ускорялся раз в 6-10.

Casus (11.07.2005 18:58:21)

Re: Сравнение RDBMS в OLTP readonly тестах

> Комментарии приветствуются.

Этот тест не то, чтобы ни о чём не говорит, он говорит вообще непонятно что. 300Mb база на диске при оперативке 4Gb. Смешно. Это мы скорость доступа к внутренним структурам DBMS в памяти меряем, правильно? Ну и не понятно, как сочетаются OLTP и ридонли, как уже правильно заметили. Если же речь идёт о DW/DSS, то там объём данных на диске в 10-20 раз превышает объём оперативки минимум. У меня на 4Gb оперативки счастливо живёт база на 400Gb размером (ох и трахался я с настройкой...). Отчёт statspack тут даже не может быть интересен, как и сам тест.

Casus (11.07.2005 19:04:52)

Re: Сравнение RDBMS в OLTP readonly тестах

>Смеяться будете, уважаемый анонимус, но я видел селекты, генерящие Redo.

Смеяться не буду, но на селект посмотрел-бы. Вообще говоря - то что оракл генерит сколько-то редо на многие операции, это одно. Другое - это селект генерил redo пропорционально объему выдаваемых данных? посмотрел бы с удовольствем.

А говоря по существу - ну посмотрите на описание "бенчмарка". Ну там же русским языком написано... ну какие там, блин, hash-join и динамически создаваемые view. Сомневаюсь что там nl хоть один присутствует.

Re: Сравнение RDBMS в OLTP readonly тестах

> Смеяться не буду, но на селект посмотрел-бы. Вообще говоря - то что оракл генерит сколько-то редо на многие операции, это одно. Другое - это селект генерил redo пропорционально объему выдаваемых данных? посмотрел бы с удовольствем.

К сожалению, уже не покажу, специально тестовый случай искать мне просто некогда, Redo было видно по autotrace, и это было самое существенное отличие от запроса с участием Nested Loop, который на холодных данных работал 2 секунды, на горячих 0.8. Запрос с Hash Join работал на холодных данных 12 секунд, на горячих 10. Я приблизительно помню какой запрос искать, но сейчас просто некогда.

Описание бенчмарка меня настолько развеселило, что дочитать его я не смог :)

Casus (11.07.2005 19:58:14)

Re: Сравнение RDBMS в OLTP readonly тестах

Ну в принципе из описания достаточно понять что там одна таблица без foreign key и набор селектов над ней. Ну и еще то что таблица меньше размера оперативки.

То что mysql очень быстр на простых запросах - это только самые юные пионэры не знали. Кстати, в более ранних версиях (типа 3.х), если не ошибаюсь, на простых селектах он обгонял оракл более существенно.

Товарищи пионеры готовы догадаться почему? или нужно пару другую сотен строк статпак-репорта для анализа? ;)

Re: Сравнение RDBMS в OLTP readonly тестах

>что за субд ? причины:

PostgreSQL 7.4 с чем-то и 8...

>I/O >блокировки/эскалация >маленький cache >маленький sort area

Где бы можно про это почитать сверху вниз?:)

petrosha (11.07.2005 20:11:17)

Re: Сравнение RDBMS в OLTP readonly тестах

>Где бы можно про это почитать сверху вниз?:)
в оракловой доке Performance Optimization Guide :) но что то мне подсказывает что до низу ты не дойдешь :)

полезного тут маловато но начать можно отсюда:
http://detail.phpclub.net/store/html/postgresql/

Re: Сравнение RDBMS в OLTP readonly тестах

>Где бы можно про это почитать сверху вниз?:)

немного тут:

http://www.google.com/search?q=ISBN+5-93772-035-0

Re: Сравнение RDBMS в OLTP readonly тестах

>>Требяю тестов MS SQL Server! я тоже хотел бы увидеть тесты Postgresa 8.0 ,ms sql 2000 и interbase ,и oracle как на платформе windows, так и линукс.И утилиты миграции с ms sql на постгрес.Поиск в интернете утилит ничего не дал,хотя кажется для интербейза они конкурс объявляли с призами и было сделано кучу утилит

EasyLinuxoid (11.07.2005 22:57:27)

Re: Сравнение RDBMS в OLTP readonly тестах

Исче я требуйу нормаьных тестов, ато пернули в лужу и пальцы растопырили. Хуета.... ещё бы SELECT DATE() FROM SYSTABLE делали, умельцы и меряли пирформанс... тьху

Re: Сравнение RDBMS в OLTP readonly тестах

Странно, а почему у меня постгрес не запускается при shared_buffers = 4000 (хотя при 3000 все ок)? В системе 2 гига оперативы.

Re: Сравнение RDBMS в OLTP readonly тестах

> Странно, а почему у меня постгрес не запускается при shared_buffers = 4000 (хотя при 3000 все ок)? В системе 2 гига оперативы.
http://www.postgresql.org/docs/8.0/interactive/kernel-resources.html

ed (12.07.2005 4:27:34)

Re: Сравнение RDBMS в OLTP readonly тестах

>Этот тест не то

Можно подумать, на ЛОРе публиковался хоть один тест, не вызвавший нареканий. При чём _всегда_ аргументация одна и та же. Тест искуственный, параметры кривые, данных мало... :D

KRoN73 (12.07.2005 9:00:39)

Re: Сравнение RDBMS в OLTP readonly тестах

>полезного тут маловато но начать можно отсюда: http://detail.phpclub.net/store/html/postgresql/

Это я читал. Производительность не улучшилась сильно. Проблема в том, что все эти твики рассчитаны на большую базу. А у меня база маленькая, но скорость доступа к ней должна быть большая...

petrosha (12.07.2005 9:59:16)

Re: Сравнение RDBMS в OLTP readonly тестах

> Можно подумать, на ЛОРе публиковался хоть один тест, не вызвавший нареканий. При чём _всегда_ аргументация одна и та же. Тест искуственный, параметры кривые, данных мало... :D

Я не понял. Разве в данном случае ценность "теста" чем-то большая, чем возможность потрепаться про оракл в комментах на ЛОР?

Casus (12.07.2005 10:24:56)

Re: Сравнение RDBMS в OLTP readonly тестах

> а SQL базы данных вообще могут работать быстро? У меня не получается вытаскивать из базы по сети больше 100 запросов в секунду... При этом сеть и процессор сервера с базой не загружены и на половину. В чем может быть причина?
> Производительность не улучшилась сильно. Проблема в том, что все эти твики рассчитаны на большую базу. А у меня база маленькая, но скорость доступа к ней должна быть большая...

это в рамках одной сессии ? запросы prepared ?

ed (12.07.2005 11:01:13)

Re: Сравнение RDBMS в OLTP readonly тестах

2 KRoN73.
Похоже что какой бы ни был benchmark, сторонники БД с не найлучшими результатами всегда будут говорить про кривой тест, параметры и т.д.

Bizon (12.07.2005 11:53:54)

Re: Сравнение RDBMS в OLTP readonly тестах

2Bizon

неужеле такая проблема выложить statpack ??
вы хоть переменые биндить догадались ?

Re: Сравнение RDBMS в OLTP readonly тестах

>>Похоже что какой бы ни был benchmark, сторонники БД с не найлучшими результатами всегда будут говорить про кривой тест, параметры и т.д.

Пройдет еще немного времени, и вы забудите такие понятия как "сторонники БД". БД не более чем инструмент в решении тех или иных задач. В коментариях Вам просто намекнули об ошибках (например вы уберите что то одно, или OLTP или read-only, это что-то вроде "сухая" вода)
а также о том, что тест крайне однобок и к реальному приложению имеет точно такое же отношение как гонки формулы 1 к уличному движению.

ifconfig (12.07.2005 12:41:07)

Re: Сравнение RDBMS в OLTP readonly тестах

cpu_tuple_cost

cpu_index_tuple_cost

cpu_operator_cost

Re: Сравнение RDBMS в OLTP readonly тестах

2 anonymous1:

Используются Prepared Statements и bind.
Statpack для какого именно теста? там несколько десятков результатов,
для всех - да, выложить сложно. Полный цикл прогона занимает несколько дней.

2 anonymous2:
cpu_tuple_cost
cpu_index_tuple_cost
cpu_operator_cost
Что ?

2 ifconfig:
Есть другая сторона медали - это рынок и маркетинг СУБД.
Гонки F1 интересны не только для любителей посмотреть гонки, но и для специалистов, на них обкатываются технические новинки, моторы,
шины.

Bizon (12.07.2005 14:04:01)

Re: Сравнение RDBMS в OLTP readonly тестах

выбор по одному индексу из таблицы Selectom через pgsql сишную библиотеку и соотвественно обратно туда складывание update.

petrosha (12.07.2005 14:10:11)