Mysql vs postgresql

Jun 9, 2016Download as pptx, pdf

0 likes368 views

сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа". Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.

Испытание поединком:
PostgreSQL vs MySQL
Александр Чистяков
Даниил Подольский
inCaller.org

Методика тестирования
• Синтетический паттерн «социальная сеть»

Методика тестирования
• Синтетический паттерн «социальная сеть»
• Пользователи

Методика тестирования
• Синтетический паттерн «социальная сеть»
• Пользователи
• Друзья

Методика тестирования
• Синтетический паттерн «социальная сеть»
• Пользователи
• Друзья
• Сообщения

Методика тестирования
Схема базы, таблица 1
CREATE TABLE users (
user_id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_name VARCHAR(64) NOT NULL
) DEFAULT CHARSET=utf8;
CREATE UNIQUE INDEX users_user_name ON users (user_name);

Методика тестирования
Схема базы, таблица 2
CREATE TABLE messages (
msg_id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
user_id BIGINT,
ctime TIMESTAMP NOT NULL,
message VARCHAR(16384) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE INDEX friends_user_id ON messages (user_id);
CREATE INDEX messages_ctime ON messages (ctime);

Методика тестирования
Схема базы, таблица 3
CREATE TABLE friends (
user_id BIGINT,
friend_id BIGINT,
FOREIGN KEY (user_id) REFERENCES users (user_id),
FOREIGN KEY (friend_id) REFERENCES users (user_id)
) DEFAULT CHARSET=utf8;
CREATE INDEX friends_user_id ON friends (user_id);
CREATE UNIQUE INDEX friends_user_id_friend_id
ON friends (user_id, friend_id);

Методика тестирования
• Пушка
• Самописная

Методика тестирования
• Пушка
• Самописная
• На языке Go

Методика тестирования
• Пушка
• Самописная
• На языке Go
• Тест-план описывается на YAML

Методика тестирования
• Пушка
• Самописная
• На языке Go
• Тест-план описывается на YAML
• Метрики снимаются с пушки с помощью Prometheus

Методика тестирования
• Пушка
• Самописная
• На языке Go
• Тест-план описывается на YAML
• Метрики снимаются с пушки с помощью Prometheus
• Метрики снимаются только с пушки

Стенд
• 4 машины для серверов СУБД
CPU: Intel Xeon E5-2630v3
OS: Ubuntu 14.04-server x86_64
Chasis: Dell R430
RAID level:Perc H730
RAM size: 192GB
HDDs info: 2x960GB SSD

Стенд
• 2 машины для пушек
CPU: Intel Xeon E3-1231v3
OS: Ubuntu 14.04-server x86_64
Chasis: Dell R220
RAM size: 32GB
HDDs info: 2x480GB SSD

Стенд
• 1 машина для метрик
CPU: Intel Xeon E3-1231v3
OS: Ubuntu 14.04-server x86_64
Chasis: Dell R220
RAM size: 32GB
HDDs info: 2x480GB SSD

Стенд
Оборудование
предоставлено компанией

Episode 1: мы запустились
• База пуста
• Конфиг серверов СУБД дефолтный
• Скорость поступления запросов максимальная
(#оченьпопулярныйпроект)
• Одновременных клиентов – сколько база выдержит

Episode 2: пора потюнить
• База НЕ пуста
• Конфиг серверов СУБД оптимизирован
• Скорость поступления запросов максимальная
(#оченьпопулярныйпроект)
• Одновременных клиентов – 128
• Оптимизированные конфиги опубликованы на
https://github.com/inCaller/mysql_vs_postgresql

Episode 3: все, кто хотел, получили
• Количество новых пользователей существенно упало

Episode 4: last in first out
• Выборка messages отсортирована по времени

Episode 5: зачем так много сразу
• Выборка messages лимитирована в размере (100 строк)

Чтобы добиться от системы максимальной производительности, необходимо учитывать структуру данных, с которыми вы работаете. Проблемы возникают, если данные очень неоднородные, и один из способов решения этих проблем - использовать возможности современных реляционных БД для хранения данных в документо-ориентированной форме. Этот подход имеет свои плюсы и минусы, которые будут обсуждаться в докладе на примерах PostgreSQL/MySQL/MariaDB etc. Основные вопросы: * конечно, производительность тех или иных решений и подходов - чего необходимо избегать, а чего бояться не стоит (бенчмарки для разных конфигураций и видов нагрузки); * способы безболезненного переноса данных в такой формат.

За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)Ontico

Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду. И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный? Я решил суммировать мои ответы на эти вопросы в докладе на Highload++. Итак, почему Tarantool такой быстрый? Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы. Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)

Как ускорить MySQL Handler Socket в 9 раз / Александр Яковлев (Мамба)Ontico

РИТ++ 2017, Backend Conf Зал Кейптаун, 5 июня, 11:00 Тезисы: http://backendconf.ru/2017/abstracts/2782.html Мы использовали MySQL Handler Socket в качестве интерфейса к данным пользователей на высоконагруженном проекте Wamba.ru. Почему Handler Socket? Потому что стандартный SQL-интерфейс не выдерживал наши нагрузки. Время шло, нагрузки росли, и в итоге и HandlerSocket перестал справляться. Мы только успевали доставлять и доставлять реплики MySQL, чтобы распределять увеличивающуюся нагрузку между ними. ...

PostgreSQL: практические примеры оптимизации SQL-запросов / Иван Фролков (Po...Ontico

Довольно часто как адинистраторы, так и разработчики жалуются на низкую производительность приложений, работающих с базой данных, и нередко при этом ищут решения возникших проблем с помощью различных настроек как СУБД, так и операционной системы, пренебрегая при этом самым действенным способом - оптимизацией запросов к собственно БД. Тому, как понимать, где же узкие места, и как их можно попробовать избежать на примере PostgreSQL и посвящен этот доклад.

Дмитрий Новиков - Tarantool в BadooMail.ru Group

Современная операционная система: что надо знать разработчику / Александр Кри...Ontico

Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение. Я расскажу про планировщик процессов, дисковый и сетевой ввод-вывод и соответствующие планировщики, управление памятью - как это все в общих чертах работает и как его потюнить.

Что особенного в СУБД для данных в оперативной памяти / Константин Осипов (Ta...Ontico

Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высоко доступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое. Тезисы - http://www.highload.ru/2015/abstracts/1964.html

nginx.CHANGES.2015 / Игорь Сысоев, Валентин Бартенев (Nginx)Ontico

Обзор перспективных баз данных для highload / Юрий НасретдиновOntico

РИТ++ 2017, Backend Conf Зал Кейптаун, 5 июня, 10:00 Тезисы: http://backendconf.ru/2017/abstracts/2773.html В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB. ...

История успеха Яндекс.Почты с PostgreSQL / Владимир Бородин (Яндекс)Ontico

Осваиваем Tarantool 1.6 / Евгений Шадрин (Sberbank Digital Ventures)Ontico

Tarantool - отечественная Opensource NoSQL база данных. В докладе мы обсудим: - Какое место занимают NoSQL базы данных в highload проектах? Почему и для чего вам стоит NoSQL решения? Какие NoSQL решения вы можете использовать? - Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице. Какие основные особенности Tarantool как NoSQL базы данных? Lua как встроенный язык сервера приложений. - Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги. Как установить Tarantool. Первый запуск и основы конфигурирования. Модель данных. Как создавать и работать с хранилищем данных. Как использовать пакеты tarantool. - Узнаем об интересных модулях и фичах Tarantool Чем полезен application server Tarantool http Tarantool queue - Познакомимся с сообществом Tarantool opensource Почему сообщество - это важно? Чем полезны opensource проекты начинающему разработчику?

MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico

Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов. Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks. Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни. Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB. RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.

Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)Ontico

Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache. Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования. В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).

Разработка real-time приложений с RethinkDB / Илья Вербицкий (Независимый кон...Ontico

RethinkDB - это распределенное документо-ориентированное хранилище данных с открытым исходным кодом. Данная система ориентирована на разработку систем обработки данных реального времени, позволяя клиентскому приложению подписываться на изменение тех или иных данных. В данном докладе я бы хотел осветить не только вопросы разработки приложений на базе RethinkDB, но и поговорить о том, как все это работает. Мы поговорим о ReQL (язык запросов), “changefeeds”, индексах, шардинге, репликациях, а также затронем вопросы особенностей проектирования баз данных под данную платформу.

Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico

РИТ++ 2017, Backend Conf Зал Кейптаун, 6 июня, 15:00 Тезисы: http://backendconf.ru/2017/abstracts/2710.html В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.

Поиск наизнанкуNikolay Sivko

Dennis Anikin - Tarantool Case Studies in Mail.Ru GroupMail.ru Group

Денис рассказал о трех кейсах использования Tarantool в Mail.Ru Group - это система аутентификации пользователей, система нотификаций для мобильных приложений и система показа рекламы. Во всех трех кейсах Tarantool является краеугольным камнем распределенной серверной инфраструктуры, которая обслуживает суммарно порядка 100 миллионов пользователей в месяц.

Класс!ная Cassandraodnoklassniki.ru

В этой презентации мы расскажем о своем опыте применения этого хранилища на примере одной из самых высоконагруженных подсистем — хранилища Класс!ов. В данный момент в системе хранится около 50 миллиардов записей о Класс!, что занимает в сумме около 8 Тб. Для того чтобы реализовать такое хранилище пришлось отойти от классического способа работы с Cassandra. Мы расскажем об этом, а также о том, как Cassandra устроена под капотом, её сильные и слабые стороны, какие решения мы принимали и что мы изменили в Cassandra, чтобы сделать наше хранилище более высокопроизводительным и надежным.

10 способов достижения HighLoad'а и BigData на ровном месте / Илья Космодемья...Ontico

Веб-сайт нужно делать так, чтобы о перипетиях его разработки и поддержки бессонными ночами через пару лет можно было рассказать на конференции Highload++, а тамошнюю аудиторию сложно удивить велосипедом с треугольными каменными колесами. Большинство разработчиков свято следуют этому принципу то ли в силу природной любознательности и трудолюбия, то ли по причине отсутствия конференции LowLoad--. Примерно такие мысли приходят в голову практически любому специалисту по хранилищам данных, когда он видит успешный веб-проект, испытывающий стандартные проблемы с базой данных. В этом докладе я расскажу о 10-ти очень распространенных ошибках проектирования и эксплуатации хранилища в веб-проекте — от преждевременного шардирования базы и непродуманной системы архивации ненужных данных до особенностей работы всеми любимых фреймворков. Про каждую из них я расскажу подробно и поделюсь рецептами, как такие ошибки исправлять.

Спасение 6 миллионов файлов в условиях полного ХецнераDaniel Podolsky

pgconf.ru 2015 avito postgresqlМихаил Тюрин

С чего начать внедрение Hadoop в компании. Доклад Алексея Еремихина (Badoo). Badoo Development

Погружение в виртуальную память и большие страницы / Константин Новаковский (...Ontico

РИТ++ 2017, HighLoad Junior Зал Сингапур, 5 июня, 12:00 Тезисы: http://junior.highload.ru/2017/abstracts/2688.html Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими. ...

Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico

В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других. В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий. Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.

MyRocks: табличный движок для MySQL на основе RocksDBSergey Petrunya

Open Source SQL-базы данных вступили в эру миллионов запросов в секунду / Фед...Ontico

Широко распространено мнение, что SQL СУБД обречены быть медлительными и неповоротливыми, поскольку несут груз совместимости с предыдущими версиями. Это расхожее мнение широко эксплуатируется маркетингом NoSQL СУБД. Однако, это не всегда действительно так. Разработка в Open Source сообществе позволяет продукту развиваться достаточно гибко, чтобы отвечать требованиям времени. В MySQL и PostgreSQL – самых популярных Open Source СУБД – недавно были проведены оптимизации для работы на больших серверах, что позволило им выполнять более миллиона SQL-запросов в секунду на одном экземпляре БД. В данном докладе будут рассмотрены конкретные оптимизации, которые позволили добиться таких результатов, которые раньше могли бы показаться фантастическими. И можно сказать, что Open Source СУБД вошли в эру миллионов запросов в секунду.

2014.09.24 история небольшого успеха с PostgreSQL (Yandex)Nikolay Samokhvalov

Хранение данных на виниле / Константин Осипов (tarantool.org)Ontico

В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз. В докладе я расскажу об устройстве нашего нового storage engine: - как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя, - как работает multiversion concurrency control в Vinyl, - основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.

опыт построения и эксплуатации большого файлового хранилищаDaniel Podolsky

Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky

Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру. Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением. Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу. Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть. В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку... Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go? Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего. Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать. Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки. Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время! В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать. Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования. Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение. Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД. Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться. Доклад рассчитан на backend-программистов, как на языке Go, так и на других.

More Related Content

What's hot (20)