Как стать автором
Обновить
22
0

Ph.D., senior Node.js developer (team lead)

Отправить сообщение
отличное объяснение, спасибо
Получается тогда, что VACUUM очищает не только более «невидимые никому» версии строк, но вычищает и ненужные записи в индексе. Но это я видимо забегаю вперед, насколько помню будет статья о VACUUM. Очень хотелось бы почитать об этой особенности там :)
Если предполагать, что транзакции откатываются намного реже, чем происходит коммит, то откладывать действительно нет смысла, не задумался об этом. Наличие большого количества ROLLBACK — это индикатор проблем в архитектуре.
Спасибо, Егор, за труд. Я сам автор и знаю, насколько сложно написать хорошую статью. Несколько раз заходил на хабр проверить — не появилась ли Ваша очередная (видимо, уже еженедельная) статья и дождался.

Немного вопросов:

№1
XACT — это аббревиатура. Как ее можно расшифровать, пусть даже и условно?

№2
Поэтому выясненный однажды статус транзакции записывается в биты xmin_committed и xmin_aborted версии строки. Если один из этих битов установлен, то состояние транзакции xmin считается известным и следующей транзакции уже не придется обращаться к XACT.


Что будет происходить при race conditions?
Несколько транзакций параллельно (в рамках разных соединений) пытаются посмотреть эти биты, не найдя их — идут в XACT. И далее одновременно пишут биты в заголовок. Одна транзакция установит биты, вторая — установит те же самые значения. И все.
Видимо, никаких проблем тут не будет кроме лишнего похода в XACT, что не является думаю критичным.
Поправьте, пожалуйста, если что-то не так понял.

№3
XACT — не таблица системного каталога; это файлы в каталоге PGDATA/pg_xact.
А работа с этими файлами ведется постранично, как и со всеми другими.

Используется ли буферный кеш для XACТ, как и для таблиц? Или работаем как с обычными файлами, средствами ОС (файловый кеш в RAM на уровне ОС). Если это так, то то интересно, почему так решили? Насколько я успел привыкнуть — в PostgreSQL стараются всю информацию представлять в едином, табличном виде (способе хранения и работы с данными)

№4
Например, для B-дерева строки, относящиеся к листовым страницам, содержат значение ключа индексирования и ссылку (ctid) на соответствующую строку таблицы. В общем случае индекс может быть устроен совсем другим образом.


А далее:

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


Поясните, пожалуйста, для полноты картины. Получается, что одному значению ctid соответствует несколько записей? Хотя в указанных примерах это вроде бы не так. По какому свойству строки индекс находит все возможные версии? Видимо, это приватный ключ — ID.
Или же — при создании новой версии строки происходит какое-то изменение индекса чтобы он знал о новой версии?

№5
И немного не в тему статьи — индекс перестраивается в рамках транзакции но сразу после COMMIT? То есть в рамках снимка индекс, условно говоря, может быть «устаревшим»?

№6
Когда создается новая версия строки при UPDATE — создается полная копия строки в базе данных? Соответственно, если есть строка с большим значением внутри TEXT, то UPDATE создаст его копию даже если изменилось другое поле — например, у поста счетчик number_of_upvotes увеличился на единицу, но сам текст поста никто не изменял.
Поэтому частые UPDATE могут существенно влиять на размер таблицы?

Спасибо
Егор, спасибо за развернутый ответ, теперь все понятно, ну а прочие детали и нюансы очень ждем в Ваших следующих статьях
1. Btree-индексы работать будут — до тех пор, пока значения не слишком длинные. При существующем индексе слишком длинные значения просто не получится вставить (ну или потом не получится создать индекс).


То есть получаем очень интересные грабли — создаем большой NUMERIC и вешаем на него b-tree индекс (как есть, не частичный). На text и JSONB, наверное, такой индекс создавать никогда не будут, но на NUMERIC думаю можно так ошибиться. И все работает до некого момента, когда по бизнес-причинам рейтинги не начнут превышать указанное максимальное значение. И тогда внезапно перестанет работать вставка новых данных (или обновление существующих данных).

Поясните, кстати, тогда, пожалуйста, для каких ситуаций справедливо это утверждение.
Отметим, что TOAST работает только для таблиц, но не для индексов. Это накладывает ограничение на размер индексируемых ключей.


Получается, его надо рассматривать не как «индексируем колонку, для которой существует TOAST», а так:
«Индексируем любую колонку достаточно большого размера. В какой-то момент из-за размера упираемся в ограничение Values larger than 1/3 of a buffer page cannot be indexed. Это ограничение обходится для данных с помощью TOAST технологии, но эта технология неприменима к индексам типа b-tree»
Кажется, прописав условие для себя, я его понял. Поправьте, пожалуйста, если что-то не так.

При этом, насколько я понял, обсуждаемое ограничение распространяется только на индексы типа b-tree? У индексов типа GIN, GIST подобных ограничений нет?

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

Егор, спасибо за статью, который содержит полезные способы оптимизации TOAST, то есть статья не только теоретическая, но и содержит важные практичные советы.
Разрешите уточнить.

Отметим, что TOAST работает только для таблиц, но не для индексов. Это накладывает ограничение на размер индексируемых ключей.


1. Означает ли это, что b-tree индексы на NUMERIC типы полей работать не будут? Например, есть колонка NUMERIC(30, 10) и необходимо, например сортировать по этой колонке или найти все значения, которые больше/меньше некого порогового значения. Будет ли PostgreSQL использовать индекс в этом случае? Или же PostgreSQL даже не позволит такой индекс создать?

Предположу, что здесь все сильно зависит от заданного размера NUMERIC (количество знаков)

2. Следующий вопрос, вытекающий из первого — пусть поле NUMERIC очень большое или присутствует text поле. Для text видимо нужно использовать индекс типа GIN, а для NUMERIC?

3. Насколько сильно TOAST-таблицы влияют на производительность PostgreSQL? Кейс из реального проекта — есть колонка NUMERIC (рейтинг поста) и text — текст поста. Можно ли провести аналогию и сказать, что наличие TOAST добавляет +1 JOIN к запросу на поиск постов?

4. UPD: Как быть с JSONB типом данных? Создается ли для него TOAST или присутствуют ограничения, чтобы данные помещались на одну страницу?

Буду рад, если мои вопросы помогут дополнить саму статью, потому что очень интересен вопрос производительности при наличии TOAST. Спасибо
Егор, спасибо! Ваши статьи (в частности цикл статей про индексы) читаю и перечитываю много раз, очень рад новой серии статей, очень жду продолжения

В PostgreSQL достаточно средств, чтобы одним SQL-оператором решать сложные задачи. Отметим общие табличные выражения (CTE), в которых в том числе можно использовать операторы INSERT/UPDATE/DELETE, а также оператор INSERT ON CONFLICT, который реализует логику «вставить, а если строка уже есть, то обновить» в одном операторе.


Существует еще конструкция CASE WHEN THEN END, но почему то я очень давно не встречал ее упоминания в статьях (а статей разных читаю много). Я использую периодически эту конструкцию. Почему ее не упоминают? Быть может у нее есть какой-то существенный недостаток?
Спасибо за кейс!

По поводу нового класса задач идея такая. Время у всех катастрофически ограничено. И ежедневно (а то и чаще) возникает вопрос "что учить, куда развиваться?" И выбор — либо углубиться наконец-то в алгоритмы, либо изучить что-то новое в прикладном плане.

Новый класс задач открывается и при изучении алгоритмов, и при изучении новых прикладных методов (например, новых языков программирования или баз данных).

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

Наверное, так.
А в какой области Вы работаете и какие задачи обычно решаете/решали?
Уважаемые читатели!

Было бы обалденно, если бы кто-нибудь рассказал о своих кейсах из рабочей практики. Речь не о том, что они "развивают мышление". Это бесспорно. Расскажите случаи, когда вам действительно очень помогло знание алгоритмов — насколько удалось поднять производительность/сэкономить ресурсов и т.п.

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

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

Однако, они нужны в отраслях бизнеса, связанных с математикой и вычислениями. Например, разработка микропроцессоров или google cars (кейс моего приятеля JAVA-программиста). В случае, когда необходимо разрабатывать именно новые математические алгоритмы на основе существующих.

А так, согласен с Вами. С точки зрения практики — зачем досконально знать алгоритмы в прикладных задачах? Это вдоль и поперек изученная теория, прекрасно (хотелось бы верить) реализованная в готовых библиотеках. Например, у JAVA таких библиотек огромное количество.
Джуниором пошел в фирму, где был full stack. Не жалею. Попробовал одно, другое, третье. Нащупал, чем нравится заниматься больше всего. И пошел в итоге узким специалистом.

Имхо, джуниору лучше пойти именно на full stack (хотя бы бекенд + фронтенд по обязанностями, 50 на 50). Как поймешь, чем хочешь заниматься, не попробовав в бою все эти технологии?
Если возможно, опишите, пожалуйста, фишки Yii в процессе решения задач, более сложных, чем установка.
Авторам большое спасибо! Рекомендация — давать не только подборки, но и рейтинги. Рекомендовать те или иные инструменты.
Каким именно тайм-трекером пользуетесь?
Если вы в теме, то напишите свои комментарии. Если они хорошо и наглядно обоснованы, то будут чрезвычайно полезны всем.
По-моему, заголовок для того, чтобы привлечь внимание к статье. Имхо никакой «один волшебный навык» вас успешным не сделает.
А вот большой набор таких «небольших» навыков сделает успешным кого угодно. В этом и сложность — нужно систематически развивать и культивировать связанные положительные привычки.

Все навыки есть здесь. На мой взгляд, исчерпывающая книга по навыкам успеха в любой области.
www.ozon.ru/context/detail/id/2505686

Неужели нет программы, получше Анки по юзабилити? Я не нашел, поделитесь, если знаете вдруг. Quizlet например не содержит систему контроля припоминаний.

З.Ы. Когда-то хотел написать такую программу сам, на OpenSource
Конспектировать с помощью тулзов не получается — слишком много действий надо совершить.

Вот мне так многие тоже говорят. Это дело привычки и скорости печати. Но приучить себя весьма сложно — согласен.

3. К сожалению, не хватает собеседников, с кем можно было бы продуктивно делиться. Фрилансер, работаю из дома.

Есть скайп, сам обычно ищу по друзьям и знакомым «коллег по цеху» — так и знакомимся.

Вот только на практике, если эти эмоции не возникают спонтанно, искусственно их вызвать не получается.

Если Вам не помогают высказывания, то попробуйте визуализировать что-то приятное или «почувствовать умом» тепло, солнце и проч. Вообще, все достигается практикой :)

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


Меня заработанная таким образом ассоциация преследует уже несколько лет. Удовольствие от изучения материала возрасло многократно и сохраняется.

10. Признайтесь, этот пункт добавлен для ровного счета?

Да, книги спорные, не всем подходят, не всегда к месту. Но многим они нравятся, прививают интерес к предмету.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность