Postgresql + Тест

С этим тегом используют

2 поста сначала свежее

kznalp

5 месяцев назад

Лига Новых Технологий

Серия СУБД PostgreSQL

Оценка производительности PostgreSQL - одного сценария НЕДОСТАТОЧНО⁠⁠

Взято с основного технического канала Postgres DBA

До финиша дойдут не все...

Проблема

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

Причина

По умолчанию pgbench тестирует сценарий, примерно соответствующий TPC-B, который состоит из пяти команд SELECT, UPDATE и INSERT в одной транзакции.

Postgres Pro Enterprise : Документация: 16: pgbench : Компания Postgres Professional

Для тестирования использовался именно этот сценарий .

Конфигурация виртуальных машин

ВМ-1

Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Soft 11.4.0-1), 64-bit

CPU = 8

RAM = 15

OC = RED 7.3

ВМ-2

Postgres Pro (enterprise certified) 14.11.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit

CPU = 24

RAM = 189

ОС = Astra Linux (Smolensk) 1.6

Итоги теста по сценарию TPC-B

Производительность ВМ-1 существенно выше ВМ-2

Т.е. по итогам данного теста получается - СУБД развёрнутая по шаблону ВМ-1 будет существенно производительнее ?

Что будет , если архитектор примет решение о выборе версии СУБД и запланирует ресурсы инфраструктуры на основании только данного теста ?

Решение проблемы

Одного теста для анализа производительности СУБД и ВМ - недостаточно.

Как было указано в документации:

Однако вы можете легко протестировать и другие сценарии, написав собственные скрипты транзакций.

Что и было сделано.

Для продолжения тестов, был подготовлен сценарий требующий серьезных вычислительных ресурсов - SELECT ... JOIN

Результат тестирования тяжелого запроса

ВМ-2 СУЩЕСТВЕННО производительнее чем ВМ-1

Все встало на свои места.

ВМ-1 даже не хватило ресурсов при количестве одновременных запросов свыше 160. При этом производительности ВМ-2 существенно выше производительности ВМ-1.

Итог

Нельзя принимать архитектурных решений на основании результатов одного только сценария нагрузочного тестирования

2. Для оценки производительности архитектурного решения по конкретной СУБД необходим комплекс разных сценариев нагрузочного тестирования.

Как минимум:

-Select only: оценка скорости чтения данных из СУБД

-Standard: оценка производительности СУБД в условиях конкуренции за блокировки.

-Heavyweight: оценка производительности СУБД при выполнении тяжелых вычислительных и ресурсоемких операций.

Показать полностью 2

[моё] Postgresql Субд Мониторинг Производительность Тестирование Тест Длиннопост

TyuleshPelmesh

2 года назад

Лига программистов

Производительность БД с одной и многими таблицами. Мини-тест⁠⁠

В прошлом посте обмолвился, что собираюсь в своей базе данных завести каждому пользователю по табличке. Ну потому что у меня запросы всегда только для одного пользователя, а значит можно сэкономить ресурсы сервера на индексации, так я думал. Мне накидали полную панамку что так делать нельзя, но почему – никто особо не объяснил. И я решил бахнуть небольшой тест на нескольких БД – проверить что там будет на самом деле.

Для ЛЛ: В большинстве случаев выдавать каждому пользователю по таблице действительно нет смысла. Но для SQLite запросы обрабатываются ощутимо быстрее, если у каждого пользователя своя табличка.

Итак, тестовая задача, более- менее приближенная к моему сценарию:

периодически пользователи закидываеют в БД записи в которой есть ID пользоватея, время записи, текстовая метка (комментарий) и какой-то параметр (число)

INSERT INTO mega_table (id, dt, txt, dat_stat) VALUES ( %s, %s, %s, %s )

после наполнения базы пользователями иногда запрашивается статистика по тому самому числовому параметру за какой-то период времени и с определенным комментарием

SELECT SUM( dat_stat ) FROM mega_table WHERE id=%s AND dt < %s AND dt > %s AND txt = %s

Проверял 3 БД: MySQL сдвижками InnoDB и MyISAM, SQLite и Postgres. Написал скрипт, который эмулирует заполнение БД и запросы к ней, и измеряет сколько времени занимает добавление записи и выполнение запроса. Скачать скриптец можно тут (он сугубо тестовый, т.е. стрёмный и без никакой обработки ошибок, уж сорян). Менял количество пользователей и количество записей у каждого пользователя и смотрел что будет если всё писать в одну таблицу, либо каждому пользователю создавать отдельную. Заодно после выполнения скрипта посмотрел сколько полученные базы данных занимают места на диске.
И вот получились такие таблички.

Производительность БД с одной и многими таблицами. Мини-тест Программирование, Python, IT, Mysql, Postgresql, База данных, Тест, Чайник, Длиннопост

Какие выводы я для себя сделал.

Во первых видно, что если делать по таблице для каждого пользователя, то и добавление записи, и обработка запроса и размер БД получаются вобщем не лучше, чем если завести одну таблицу на всех. Единственное исключение – выполнение запросов в SQLite (и в некоторых случаях для Postgre) может быть в разы быстрее на многих таблицах, чем на одной. Почему так получается? Думаю потому что БД люто заоптимизированы очень крутыми чуваками под определенные сценарии использования. И если ты не столь-же крут (я лично нет), то нужно выбрать наиболее подходящую БД и подгонять свою задачу под типичные сценарии использования этой БД.

Во вторых если мне важнее скорость добавления/чтения (т.е. экономить вычислительные ресурсы) то из протестированных лучше пользовать Postgres, если важнее экономить место на диске – то MySQL с движком MyISAM. MySQL с движком InnoDB где-то посередине.

В третьих SQLite неожиданно всех обошел в скорости выполнения запросов (для моего случая по крайней мере). Прикольно.

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

В любом случае это было интересно сделать, надеюсь кому-то было интересно и почитать.

Показать полностью 3

[моё] Программирование Python IT Mysql Postgresql База данных Тест Чайник Длиннопост

Посты не найдены