Сравнение 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 натюнить забыл, а там в запросах сортировки :(

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

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

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

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

Выдержка:

Краткие заключения:
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 неожиданно показывает плохой результат. Хотя очень хорошая
маштабирумость в с ростом клиентских потоков, в отличии от других СУБД.

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

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

> Выдержка:

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

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

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

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`);

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

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

>Плз. подскажи какие нужно поставить
>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), то серверу поплохеет.подбирается экспериментально.

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

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

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

2Bizon

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

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

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

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

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

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

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

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

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

да вот пальцы не пролазят, и особенно часто задевают 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

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

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

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

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

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

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

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

>да вот пальцы не пролазят, и особенно часто задевают 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 - только селекты ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

немного тут:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2Bizon

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

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

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

cpu_tuple_cost

cpu_index_tuple_cost

cpu_operator_cost

2 anonymous1:

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

2 anonymous2:
cpu_tuple_cost
cpu_index_tuple_cost
cpu_operator_cost
Что ?

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

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