PostgreSQL vs MySQL: есть тесты на больших таблицах?

[confguru]

PostgreSQL vs MySQL: есть тесты на больших таблицах?

Уже от 10-го специалиста в этом году слышу что пора переходить на PostgreSQL

Хабралюди поделитесь реальным опытом использования
PostreSQL на базах с таблицами от 30 миллионов записей и больше.

Если нет, планирую в ближайшее время сделать сам, но хотелось бы объективности.

P.S. В версиях PSQL до 7.x - 6 миллионов записей вызывало большую проблемму.

 

[algo]

Ого, а я вот не собираюсь переходить на PostgreSQL с MySQL.
Ваще не собираюсь...

Тесты делал только на конкурентные вставки-удаления-селекты.. Какого плана тебя интересуют результаты ?

 

[confguru]

Тут уже дискуссия
http://www.habrahabr.ru/blog/webdev/8947.html
тест на одинаковом железе и разных настройках

 

[Sad Spirit]

Автор оригинала: admin
P.S. В версиях PSQL до 7.x - 6 миллионов записей вызывало большую проблемму.

Ну б#я, Саша, первая версия 7.x вышла в 2000 году. Когда мысклеводам начинают тыкать в морду недостатками версий всего лишь ~ 2-х летней давности, они почему-то сильно обижаются.

-~{}~ 13.04.07 12:20:

А вообще методика тестов будет сильно зависеть от желаемого результата.

Если желаемый результат --- доказать, что "MySQL-то наш ещё ого-го!", то методика следующая:
1) Обе СУБД используются с настройками по умолчанию
2) В MySQL создаются таблицы MyISAM и тесты проводятся в варианте с одним подключением
3a) Для тестирования берётся приложение изначально написанное и оптимизированное под MySQL, которое криво портируется под PostgreSQL
3b) Вместо полноценного приложения тестируются простейшие запросы (для замечательного примера таковых см. тесты, убедительно показывающие, что SQLite в разы быстрее ваще всех б#я)

Если всё-таки хочется сравнить более-менее реальную производительность, то стоит взять какую-то opensource реализацию стандартных тестов: Database Test Suite, TPC-W Web Commerce Benchmark, нормально настроить обе СУБД под имеющееся железо и как следует это всё погонять. Интересно ещё попробовать выдернуть вилку из розетки при выполнении.

 

[algo]

На селектах у меня мускл где-то в 1.5-2 раза обгонял постгрес стабильно, т.е такой же результат как и на тестах, которые в той дискуссии..

На многих конкурентных инсертах сливал постгресу.

Багов в мускле больше.

Такие результаты вот.

 

[.des.]

algo какие таблицы? на каких селектах? какая версия postgresql?

 

[confguru]

Sad Spirit

Я уже отписал - хочу независимое тестирование
провести пока есть такая возможность... холивара
мне не надо - для этого есть LOR ;-)

P.S. По логике Memcache должен порвать sqllite

 

[algo]

.des.

где-то годик назад был написан тестовый фреймворк.

Он позволяет задавать
1) размер таблицы
2) конкурентность
3) процентное соотношение простейших однострочных select/insert/delete
например, 80% селект , 10% insert 10% delete

Плюс я еще запросы мощные некоторые погонял большие на реальных БД.

1.5-2 раза Mysql 5 быстрее Postgresql 8.2 был на таких тестах. Для меня это прилично.

Много конкурентных апдейтов мускл убивали. Щас хз чето правили в эту степь.
Т.е на практике биллинговую систему из-за этой траблы на мускле на момент теста было делать смерти подобно.

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

Сейчас в своих проектах(типа имхо такое :/) я преимущественно использую MySQL, Oracle.
Место для постгреса здесь вижу только если на Oracle standard финансов не хватает.

 

[Sad Spirit]

Автор оригинала: algo
где-то годик назад был написан тестовый фреймворк.
3) процентное соотношение простейших однострочных select/insert/delete
например, 80% селект , 10% insert 10% delete

Да-да, как раз пункт 3b из моего списка. А почему SQLite не тестировался?

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

На самом деле можно, enable_bitmapscan = off, но:

Сейчас в своих проектах(типа имхо такое :/) я преимущественно использую MySQL, Oracle.
Место для постгреса здесь вижу только если на Oracle standard финансов не хватает.

Вот когда ты в своих проектах используешь Oracle, ты под него пишешь абсолютно так же, как и под MySQL? В чём смысл отказываться от специфических вохможностей СУБД? Про "переносимость" сказки конечно можно задвинуть, но лучше пару реальных причин.

 

[algo]

Sad Spirit

где-то годик назад был написан тестовый фреймворк.
3) процентное соотношение простейших однострочных select/insert/delete
например, 80% селект , 10% insert 10% delete

Да-да, как раз пункт 3b из моего списка.

Я не понимаю, при чем здесь 3b ? Были тесты на различных процентных соотношениях, с различной конкурентностью.

Были произведены как простейшие выборки, так и сложные. Тестовый фреймворк создавался для проверки простейших выборок и НЕ претендует на экстраполяцию результатов на сложные.

Sad Spirit

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

На самом деле можно, enable_bitmapscan = off

"Нельзя" - имеется в виду не технически, а просто нежизненно было бы. Тестировались тюненые конфигурации, насколько у меня хватило умения ессно =).

Sad Spirit
Вот когда ты в своих проектах используешь Oracle, ты под него пишешь абсолютно так же, как и под MySQL? В чём смысл отказываться от специфических вохможностей СУБД?

Фичи есть в всех базах и конкретное приложение решает, насколько они будут полезны. Синтетические тесты - это одна грань, фичи - другая. Цельный взгляд получается. Автор топика просил именно тесты.

 

[Sad Spirit]

Автор оригинала: algo
Я не понимаю, при чем здесь 3b ? Были тесты на различных процентных соотношениях, с различной конкурентностью.

Были произведены как простейшие выборки, так и сложные. Тестовый фреймворк создавался для проверки простейших выборок и НЕ претендует на экстраполяцию результатов на сложные.

Волшебно, а тогда какой вообще смысл в написанном на несколько сообщений выше утверждении

На селектах у меня мускл где-то в 1.5-2 раза обгонял постгрес стабильно

?
Из того, что MySQL быстрее сделает

select * from some_table where some_table_pkey = 1;

совершенно не следует выполнение выборки с 5 соединениями и 2 подзапросами в 1.5-2 раза быстрее. А у меня в приложениях обычно запросы первого вида проблем с производительностью не вызывают и чтения EXPLAIN не требуют, вызывают и требуют почему-то как раз второго.

И второй, бонусный вопрос: зачем писать свой убогий фреймворк, не отражающий работу своего же приложения, когда есть готовые и используемые в той же OSDL?

Фичи есть в всех базах и конкретное приложение решает, насколько они будут полезны. Синтетические тесты - это одна грань, фичи - другая. Цельный взгляд получается.

Я бы всё же хотел получить прямой ответ на прямой вопрос: "Вот когда ты в своих проектах используешь Oracle, ты под него пишешь абсолютно так же, как и под MySQL?"
Если ответ "нет", то какой смысл в тестах, принципиально не использующих фичи --- в реальном приложении-то фичи использоваться будут?


В промышленных тестах вообще тестируется не скорость выполнения сферического запроса

select * from some_table where some_table_pkey = 1;

в вакууме, а скорость связки железо + СУБД + оптимизированное приложение.

 

[algo]

Автор топика спросил про тесты, я ему ответил. Вообще, про тесты РСУБД всегда поднимается флейм, я не вижу смысла его продолжать, тем более в этой теме.

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

 

[Sad Spirit]

Автор оригинала: algo
Мне лично результаты синтетических тестов были полезны для оценки эффективности миграции конкретных приложений.

Я тут пишу тестовый фреймворк для тестирования производительности современных графических адаптеров в игре Doom, запущенной через Dosbox. Ждите от меня в ближайшее время убойной статьи "S3 Virge рвёт GeForce 8800 как Тузик грелку!"

 

[algo]

Sad Spirit, никто ничего подобного не утверждает.

 

[MiksIr]

По поводу скорости, советую обратить внимание на сравнения прироста производительности MySQL vs PostgreSQL на много(-процессорных, -ядерных) системах

 

[Sad Spirit]

Автор оригинала: algo
Sad Spirit, никто ничего подобного не утверждает.

И слава Богам. Но ты так на пальцах объясни --- чем мой синтетический тест хуже твоего?
Ведь когда видеокарточки тестируют, их обычно на игрушках тестируют? Ну и я предлагаю на игрушке. Ты же говоришь, что синтетические тесты помогают делать выбор для реальных предложений, так я и предалагаю на основе скорости Doom'а пущенного под Dosbox'ом выбирать карточку для игры в какую-нибудь Готику 3. А чё?

 

[algo]

Sad Spirit, я не знаю что такое Готика 3, не увлекаюсь игрушками. Это, наверно, где крутая графика?

Синтетические тесты дают различные "срезы" информации о производительности.

Судя по общем настрою твоего сообщения, полагаю что контекст выполнения, выполняемые операции и их соотношения, у Doom/Dosbox и Готика 3 совершенно разные.

Поэтому эта аналогия не применима.

В случае с базами данных ситуация чуть другая...

Допустим, я знаю, что на моих сайтах выполняются такие-то селекты в таком-то количестве, такие обновления, и есть эдакие ботлнеки... Причем все это с известной конкурентностью, пиковой и обычной... Ну и железо у меня есть уже купленное, его характеристики тоже известны.

Есть результаты синтетических тестов, типа что мои селекты в таком окружении будут ботать примерно так-то... За счет наличия новых фич некоторые ботлнеки разрулятся эдак, а за счет отсутствия каких-то фич будет замедление там-то...
Можно прикинуть, как производительность изменится при миграции...