Comments 21
Картинка интересна: слон и сам мокрый (хотя сухопутный зверь), и дельфин менее покрыт водой (хотя водоплавающий). Душевная картинка: «бесполезная забота».
старший инженер службы технической поддержки и специалист по маркетингу сравнивают как PostgreSQL и MySQL справляются с миллионами запросов в секунду.
Специалист по маркетингу тоже крайне важен в оценке производительности систем )
Специалист по маркетингу тоже крайне важен в оценке производительности систем )
Это перевод статьи из блока компании где я работаю. Вот оригинал:
Сорри, планшет отправил комментарий неоконченный. Это перевод статьи из блога компании где я работаю. Вот оригинал: https://www.percona.com/blog/2017/01/06/millions-queries-per-second-postgresql-and-mysql-peaceful-battle-at-modern-demanding-workloads/ Настя там в роли ведущего, она ничего не тестировали. Тестировала я и Александр Коротков из PostgreSQL Professional. То есть идея была в том, что специалист по PostgreSQL и MySQL совместно работают на одинаковом железе. Чтобы не было такого: «Света взяла постгрес из коробки и у неё он какой-то тормозной» и аналогично с другой стороны.
Ну и, кстати, я видела очень крутые исследования сейлзов (продавцов), которые потом тру девелоперы в своих презентациях показывали. Так что не вижу ничего плохого или странного в том, что специалист по маркетингу что-то тестирует. Хоть в данном случае у Насти была другая роль.
Специалист по СЕО по твоему не может быть в прошлом хорошим инженером?)
Ребят, вы, конечно, молодцы. Но где указание, что это перевод? Где ссылка на блог компании Percona, где пост был изначально опубликован? Где прямое явное указание в начале текста на то, что PostgreSQL тестировали специалисты именно по нему, а именно компания PostgreSQL Professional?
Там же, где и всегда?
Света, информация о том, что это перевод, и его авторстве указана согласно гайдлайнам хабра с момента публикации статьи. Ссылку плейнтекстом добавил в начало, что ни у кого никаких сомнений не возникало. Перевод мы обсуждали и согласовывали с Настей еще задолго до начала работ по нему.
Информация о том, что тестирование PG проводил Александр, указана в первом же абзаце перевода вашей статьи, мы здесь ни на грам ничего не изменили. Авторство блогпоста на сайте перконы принадлежит тебе и Насте, что мы и указываем во вступлении. Александр автором статьи на сайте Percona не значится.
Информация о том, что тестирование PG проводил Александр, указана в первом же абзаце перевода вашей статьи, мы здесь ни на грам ничего не изменили. Авторство блогпоста на сайте перконы принадлежит тебе и Насте, что мы и указываем во вступлении. Александр автором статьи на сайте Percona не значится.
Спасибо за статью! Позвольте мне изложить свой вывод, а вы по возможности исправьте, если где-то заблуждаюсь.
— максимальная производительность БД достигается при равенстве логических ядер количеству параллельных потоков запросов;
— разница производительности MySQL и PostgreSQL в «тюнингованных» системах порядка 2%;
— PostgreSQL тюнинговать технически сложнее (нужно добавлять патч), для MySQL достаточно поколдовать с настройками;
— В разгоне БД первостепенное значение имеет скорость дисковой системы, а не количество ядер;
— Наибольший эффект при оптимизации скорости БД даёт рефакторинг структуры базы и оптимизация запросов, нежели смена СУБД с одной на другую.
P.S. Немного завис в начале статьи, когда увидел, что 12 ядер выдали такой же результат, как мои 4 на дефолтных настройках. Замерил IOPS — у меня чтение/запись 43k/40k в отличие от авторских 33k. Списал на то, что я измерял на реальном проекте, а не на авторских скриптах.
P.P.S. Я, конечно понимаю, мастеркласс и всё такое… Реально не вижу разницы, кроме как технической между этими двумя СУБД (из статьи). Интересно было бы увидеть эти же графики в этих же режимах на более слабой машине. А так информации мало на мой взгляд.
— максимальная производительность БД достигается при равенстве логических ядер количеству параллельных потоков запросов;
— разница производительности MySQL и PostgreSQL в «тюнингованных» системах порядка 2%;
— PostgreSQL тюнинговать технически сложнее (нужно добавлять патч), для MySQL достаточно поколдовать с настройками;
— В разгоне БД первостепенное значение имеет скорость дисковой системы, а не количество ядер;
— Наибольший эффект при оптимизации скорости БД даёт рефакторинг структуры базы и оптимизация запросов, нежели смена СУБД с одной на другую.
P.S. Немного завис в начале статьи, когда увидел, что 12 ядер выдали такой же результат, как мои 4 на дефолтных настройках. Замерил IOPS — у меня чтение/запись 43k/40k в отличие от авторских 33k. Списал на то, что я измерял на реальном проекте, а не на авторских скриптах.
P.P.S. Я, конечно понимаю, мастеркласс и всё такое… Реально не вижу разницы, кроме как технической между этими двумя СУБД (из статьи). Интересно было бы увидеть эти же графики в этих же режимах на более слабой машине. А так информации мало на мой взгляд.
разницы нет, т.к. думаю тесты простые. Стоит взять более сложные и специализированные кейсы — и сразу же начнется проявлятся разница, причем в зависимости от узконаправленности теста будет впереди как одна так и другая система. (См. кейс убера )
2% — это погрешность всё-таки. Насчёт патча — это конкретный ворклод. Наверняка и для MySQL можно найти такой даже сейчас, что только патчить. PS — у да, там и ворклод, и скорость диска имеют значение.
Две хорошо оптимизированные базы, работающие по одной схеме и на одном железе будут показывать сравнимые результаты. На чтении скорость будет зависеть от того, сколько данных помещается в кеш и какова скорость чтения диска, на записи какова скорость записи на диск. Ни чего удивительного, что результаты похожи.
Сейчас гораздо важнее простота администрирования и разворачивание кластера на множестве серверов, а не скорость работы одного мега-сервера. Если у перконы, без опыта, я развернул кластер за час и он работал из коробки, без танцев с бубнами, то с постгрёй у меня уже 3 девопса, не меньше двух недель каждый, пытались построить кластер и результат я могу оценить на три с минусом.
Это мой опыт, может у кого-то он другой. Я лишь хочу сказать, что все эти тесты в статье оторваны от жизни, протестируйте скорость разворачивания, скорость работы и стабильность кластеров из баз данных.
Сейчас гораздо важнее простота администрирования и разворачивание кластера на множестве серверов, а не скорость работы одного мега-сервера. Если у перконы, без опыта, я развернул кластер за час и он работал из коробки, без танцев с бубнами, то с постгрёй у меня уже 3 девопса, не меньше двух недель каждый, пытались построить кластер и результат я могу оценить на три с минусом.
Это мой опыт, может у кого-то он другой. Я лишь хочу сказать, что все эти тесты в статье оторваны от жизни, протестируйте скорость разворачивания, скорость работы и стабильность кластеров из баз данных.
Вы совершенно правы поддерживаю!
Вечно придумывают искусственные тесты, что бы показать свою крутость.
А реальное, большинство интересуют другие проблемы.
Вечно придумывают искусственные тесты, что бы показать свою крутость.
А реальное, большинство интересуют другие проблемы.
У МарияДБ кластера есть проблема (Галера). При двух нодовом кластере возникают проблемы репликаций,
Низкоуровневый Деадлок. resource deadlock avoided
То что postgre нужно 3 девопса, Это больше проблема наследия Линуха. Где каждый параметр должен прописываться в conf файле.
Поддержка Firebird такая же сложная если не хуже! Но на то и нужен Opensource, Когда Вам не гарантируют сервис Enteprise баз данных. На то он и Opensource, за удобство нужно платить конторе которая создает это удобство!
В принципе были планы к ним и перейти. Просто с чего-то начинать же нужно. В статье именно поэтому подробно описываются трудности, с которыми мы столкнулись
innodb_buffer_pool_size=128000M
innodb_buffer_pool_instances=128 #to avoid wait on InnoDB Buffer Pool mutex
innodb_buffer_pool_instances: Multiple innodb buffer pools introduced in InnoDB 1.1 and MySQL 5.5. In MySQL 5.5 the default value for it was 1 which is changed to 8 as new default value in MySQL 5.6. Minimum innodb_buffer_pool_instances should be lie between 1 (minimum) & 64 (maximum). Enabling innodb_buffer_pool_instances is useful in highly concurrent workload as it may reduce contention of the global mutexes.
Те это значение, согласно документации, не может быть более 64
Да и согласно этой статьи http://dimitrik.free.fr/blog/archives/2012/10/mysql-performance-innodb-buffer-pool-instances-in-56.html
Больше, не всегда значит лучше
Sign up to leave a comment.
Миллионы запросов в секунду: мирная битва между PostgreSQL и MySQL при сегодняшних требованиях к рабочим нагрузкам