SQL *

Повышение производительности PostgreSQL после настройки параметров

Привет, Хабр!

Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.

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

Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"

В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.

Предисловие

Предисловие

Введение в osquery

• запущенных процессах;
• загруженных модулях ядра;
• открытых стевых соединениях.

Create Table WithOutSequence1
(
	 EmpId int identity not null primary key
	,EmpName varchar(50) not null
)

Insert into WithOutSequence1
	Select 'Violet' Union All
	Select 'Tape'

Select * from WithOutSequence1

Create Table WithOutSequence2
(
	 EmpId int identity not null primary key
	,EmpName varchar(50) not null
)

Insert into WithOutSequence2
	Select 'Violet' Union All
	Select 'Tape'

Select * from WithOutSequence2

CREATE SEQUENCE [schema_name . ] sequence_name
[ AS { built_in_integer_type | user-defined_integer_type } ]
| START WITH <constant>
| INCREMENT BY <constant>
| { MINVALUE <constant> | NO MINVALUE }
| { MAXVALUE <constant> | NO MAXVALUE }
| { CYCLE | NO CYCLE }
| { CACHE [<constant> ] | NO CACHE }

На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.

Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.

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

Давайте честно: совместный доступ к документам — одна из главных «болей» для всех, кто хоть как-то связан с базами данных. Вроде бы оба пользователя могут работать с файлом, но есть один нюанс: например, количество предоставленных доступов может быть больше, чем их есть на самом деле. Или у документа и вовсе появляется несколько владельцев. Для всего этого требуется решение – и мы его нашли!

Меня зовут Владимир Ревякин, я старший инженер-программист компании «МойОфис», и вместе с QA-инженером Анной Рукавицыной мы подготовили этот материал, чтобы поделиться опытом реализации функции шаринга данных через графовую базу ArangoDB в рамках разработки платформы «Документы Онлайн». Если коротко — это продукт для совместной работы и хранения документов в рамках единой мультипродуктовой экосистемы.

В российских источниках не так много полезной информации по ArangoDB, и наша задача — исправить это недоразумение. Разберем главные нюансы работы с этой системой БД в разработке и тестировании, вспомним ее плюсы, минусы и потенциальные баги. Текст будет полезен как инженерам любых грейдов, которые связаны с работой над базами данных (сил вам...), так и классическим разработчикам продуктов.

Задачи на собеседованиях. Денежные переводы в SQL. Обновление счетов и уровни изоляций

Задача перевода денег в первом приближении сводится к обновлению пары строк и кажется простой — но обеспечение корректности при параллельном доступе может быть неожиданно сложным для только знакомящихся с уровнями изоляций БД.

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

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

Давайте сделаем это попроще.

Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.

Внешние ключи (foreign keys) - мощный и удобный механизм контроля логической целостности данных в базе. Но он бывает не только лишь полезен, и может неплохо пригрузить вашу БД.

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