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

•Transferir como PPTX, PDF•

0 gostou•1,129 visualizações

Кто пишет тезисы, тот и прав, а кто выступает на стороне PostgreSQL, тот прав вдвойне. Когда я (Александр Чистяков) в момент старта очередного нового проекта узнал, что мой старший коллега (Даниил Подольский) хочет использовать MySQL в продакшне, я встал и сказал себе: "Хватит это терпеть!". Вероятно, я сказал слишком громко, потому что Даниил услышал, и мы еще с час обсуждали вопросы применимости РСУБД в современных проектах в общем чате, пугая Заказчика. Тем не менее, нам ничего не оставалось, кроме как договориться о публичном поединке. Мы представим на суд общественности результаты нагрузочного тестирования двух этих замечательных РСУБД, поставленных в одинаковые, но жесткие условия современного веб-проекта. Мы идентифицировали несколько распространенных профилей нагрузки, и написали генератор нагрузки на (не очень) любимом нами языке Golang. В остальном правила поединка просты: правил нет никаких, и я уже придумал пару сценариев использования, на которые MySQL просто не способен!

Engenharia

Испытание поединком:
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 строк)

Mais conteúdo relacionado

Mais procurados

В MySQL 5.7 появился целый ряд новых возможностей, позволяющих использовать MySQL в приложениях и как хранилище JSON-документов, и как реляционную базу данных. В этом докладе мы расскажем о поддержке JSON в MySQL 5.7, а также поговорим о том, когда имеет смысл её использовать, и насколько хорошо она работает. Кроме того, мы остановимся на новом протоколе доступа к MySQL, поддерживающем SQL. Помимо этого, мы рассмотрим CRUD-операции и такие дополнительные функции, как асинхронная коммуникация и пайплайнинг (pipelining). В заключительной части доклада мы расскажем о возможностях MySQL 5.7 в качестве хранилища документов.

MySQL 5.7 - NoSQL - JSON, Protocol X, Document Store / Петр Зайцев (Percona)

Ontico

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

Ontico

Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры. В своём докладе я постараюсь рассказать про: + общую схему связей баз данных между собой и с другими компонентами; + точки отказа и виды аварий, затрагиваемые связи; + бинарную репликацию и архив; + логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки; + скрипт и процедуру переключения при аварии; + планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).

Реализация восстановления после аварий / Сергей Бурладян (Avito)

Ontico

Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native. Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта). Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST. Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач. Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом. Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док

noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов Николай

Ontico

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

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

Ontico

Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей. В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы. И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.

Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...

Ontico

+ Защита данных — это не "одна кнопка", нет годного любому единого решения. Задача всегда диктует выбор средств и решений. + RTO — Recovery Time Objective — максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ. + RPO — Recovery Point Objective — максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные. + Защита на уровне приложений. Приложение лучше всех знает, как защищать и реплицировать свои данные. + Асинхронная репликация — наилучший выход с точки зрения производительности, единственно возможный вариант в случае значительного географического разнесения дата-центров (сотни и более километров). Работает на уровне виртуальных машин. + Метро / "растянутые" кластеры и синхронная репликация — нулевой RPO, минимальный RTO, большие потери производительности и множество ограничений. Но иногда — единственный выход, если уровень приложения не умеет реплицировать данные. + Лучший подход — комбинация из репликации на уровне приложений, асинхронной и синхронной репликации средствами хранилища. + Что есть у Nutanix для решения подобных задач: DR (Async replication), Metro availability cluster, Timestream Backup. + Реализация решения с использованием Nutanix на примере FBI: крупнейший VDI в США. Защищенная, mission-critical инфраструктура на 70 тысяч виртуальных десктопов. Асинхронная репликация дата-центров на 1500 миль, защита данных от катастроф.

Защита данных и датацентров от катастроф. Подход Nutanix / Максим Шапошников ...

Ontico

Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади. В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект. Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно: - какое место в общей производительности базы данных занимает оптимизация запросов? - когда прекращать “крутить гайки” и заниматься медленными запросами? - что такое медленный запрос и когда их надо начинать оптимизировать? - как оптимизировать? - EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание? - как работает оптимизатор запросов PostgreSQL и где могут быть узкие места? - для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется? - какие запросы не будут работать быстро никогда, и как с этим жить? - ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?

Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...

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 проекты начинающему разработчику?

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

Ontico

Сфера финансовых приложений и трейдинга выдвигает особые требования к системам обработки данных: ультракороткие задержки, конкурентные обновления (в т.ч. из разных процессов), репликация высокочастотных обновлений. Существовавшие открытые key-value хранилища не справлялись, поэтому мы сделали свое — Chronicle Map. В докладе я отвечу на вопросы: + Почему бывает эффективнее разбить систему, работающую с общим состоянием, на несколько отдельных процессов? + Зачем вам может захотеться распилить JVM на несколько частей? + Как добиться от key-value хранилища медианной latency меньше 1 микросекунды? + Как сделать репликацию, если она упирается в пропускную способность сети из-за слишком частых обновлений? Развею миф о том, что Java — это медленно :) Также, в докладе будет сравнение Chronicle Map с redis, one-nio и ConcurrentHashMap.

Chronicle Map — key-value хранилище для трейдинга на Java / Левентов Роман (C...

Ontico

Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно. В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении. В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.

Автоматизация тестирования клиентской производительности / Николай Лавлинский...

Ontico

Всем известно о существовании временных таблиц в PostgreSQL, но как они устроены, и чем грозит их некорректное использование - не столь очевидно. На примере одного известного приложения, активно и некорректно использующего временные таблицы, мы расскажем о создаваемой ими проблеме фрагментации памяти. Что такое фрагментация памяти, по каким признакам можно определить ее наличие, чем она грозит, почему она возникает при активном использовании временных таблиц, и как мы пропатчили PostgreSQL, чтобы ее избежать - обо всем этом можно узнать из нашего доклада.

Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти / Г...

Ontico

DNS — это одна из основополагающих служб и протоколов современного интернета, сервис, который должен всегда работать. Каждый раз, когда конечный пользователь обращается к какому-либо ресурсу глобальной паутины, он использует DNS, и чтобы этот самый первый шаг к проектам у наших клиентов не занимал много времени, мы построили свой DNS-хостинг с использованием Anycast-балансировки. Чуть позже мы применили этот метод для балансировки и повышения доступности рекурсивных серверов внутри наших дата-центров. В своём докладе я расскажу о способах обеспечения непрерывного обслуживания DNS-запросов, подводных камнях использования anycast’а, постараюсь раскрыть актуальные проблемы обслуживания DNS-серверов и поведаю о современных тенденциях в мире DNS.

DNS в условиях хостинг-провайдера / Константин Новаковский (Selectel)

Ontico

В эпоху распределённых архитектур и микросервисов как никогда актуальными становятся вопросы — как эффективно сериализовать и передать данные. Большинство решает данный вопрос просто — используют стандартный, универсальный и всем понятный формат JSON. Другие же, ориентируясь на производительность, ищут в интернете бенчмарки и выбирают protobuf или msgpack. Мы протестировали разные реализации статически (thrift, protocol buffers) и динамически (json, msgpack) типизированных протоколов для python; сравнили их производительность в разных сценариях, возможности, внутреннее устройство, удобство разработки. Я расскажу о результатах нашего исследования, особенностях "приготовления" библиотек и выявленных подводных камнях.

Сравнение форматов и библиотек сериализации / Антон Рыжов (Qrator Labs)

Ontico

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

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

Ontico

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

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

Ontico

Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon. Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции. Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.

Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...

Ontico

Доклад о новинках нового релиза PostgreSQL можно сделать экстремально скучным: взять release-notes и зачитать вслух. Но 9.5 обещает быть очень интересным релизом как с точки зрения улучшения производительности, так и функциональности - было бы жалко сделать о нем плохой доклад. Поэтому я выбрал несколько важных и нужных фич и расскажу про каждую - как она устроена, на что влияет и, главное, как ей разумно воспользоваться - максимум практических аспектов, минимум маркетинга. Без этого минимума нельзя, иначе мне никак не поделиться своим взглядом на то, как сейчас развивается PostgreSQL, и как жить пользователям Postgres'а при такой стратегии развития.

Что нового и полезного в PostgreSQL 9.5 / Илья Космодемьянский (PostgreSQL-Co...

Ontico

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

Nikolay Sivko

«Одноклассники» состоят из тысяч серверов, большая часть которых участвует в онлайн-обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия — разнообразного и большого по объему. Таким образом, Одноклассники — это одна из самых больших, сложных и нагруженных распределенных систем в мире. В этом докладе Олег расскажет об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также речь пойдет об авариях в распределенных системах и методах их предупреждения.

Распределенные системы в Одноклассниках / Олег Анастасьев (Одноклассники)

Ontico

Mais procurados (20)