Многие из нас сталкивались в своей работе с СУБД. На текущий момент базы данных в том или ином виде окружают нас повсюду, начиная с мобильных телефонов и заканчивая социальными сетями, в число которых входит и любимый нами хабр. Реляционные СУБД являются наиболее распространенными представителями семейства СУБД, и большинство из них являются транзакционными.
В институте нас заставляли заучивать определение ACID и стоящие за ним свойства, но почему-то стороной обходились подробности реализации этой парадигмы. В данной статье я постараюсь частично заполнить этот пробел, рассказав о MVCC, которая используется в таких СУБД как Oracle, Postgres, MySQL, etc. и является весьма простой и наглядной.

Нельзя сказать, что в этой статье вас ждут отборные потроха баз данных, но скорее рассказ про базы данных от самого начала, плюс небольшое углубление в некоторые подробности, которые Илье Космодемьянскому (@hydrobiont) кажутся важными. И есть все основания полагать, что так оно и есть.

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

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



О спикере: Илья Космодемьянский CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2. А кроме того, отвечает за продвижение Postgres-технологий, выступает на конференциях и рассказывает людям, как с ними работать.

Ниже материал по докладу Ильи на РИТ++ 2017, который не был связан с какой-то конкретной базой данных, но охватывал многие основные аспекты.

Hello, Habr! With this article I start a set of series (or a series of sets? — In a word, the idea is grandiose) about the internal structure of PostgreSQL.

The material will be based on training courses (in Russian) on administration that Pavel pluzanov and I are creating. Not everyone likes to watch video (I definitely do not), and reading slides, even with comments, is no good at all.

Unfortunately, the only course available in English at the moment is 2-Day Introduction to PostgreSQL 11.

Of course, the articles will not be exactly the same as the content of the courses. I will talk only about how everything is organized, omitting the administration itself, but I will try to do it in more detail and more thoroughly. And I believe that the knowledge like this is as useful to an application developer as it is to an administrator.

I will target those who already have some experience in using PostgreSQL and at least in general understand what is what. The text will be too difficult for beginners. For example, I will not say a word about how to install PostgreSQL and run psql.

The stuff in question does not vary much from version to version, but I will use the current, 11th vanilla PostgreSQL.

The first series deals with issues related to isolation and multiversion concurrency, and the plan of the series is as follows:

1. Isolation as understood by the standard and PostgreSQL (this article).
2. Forks, files, pages — what is happening at the physical level.
3. Row versions, virtual transactions and subtransactions.
4. Data snapshots and the visibility of row versions; the event horizon.
5. In-page vacuum and HOT updates.
6. Normal vacuum.
7. Autovacuum.
8. Transaction id wraparound and freezing.

Off we go!

And before we start, I would like to thank Elena Indrupskaya for translating the articles to English.

Привет, хабр. Меня зовут Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Специально к старту нового набора на курс «Архитектор высоких нагрузок» я написал небольшой материал, которым с радостью делюсь с вами.

Введение

В прошлый раз мы поговорили с вами о том, к чему приводит ослабление изоляции транзакций в базах данных. Сегодня мы обсудим более подробно один из способов обеспечения этой самой изоляции и избегания рассмотренных аномалий. Как вы могли заметить, в прошлой статье часто выделялись два подхода: один был основан на том, что у записей есть некоторые версии, а второй на том, что мы будем запись так или иначе блокировать. Таким образом, выделяются два класса баз данных: версионники и блокировочники. Сегодня мы поговорим о том, что из себя представляют версионники, а рассмотрение блокировочников оставим на следующий раз.

Привет, Хабр. Меня зовут Владислав Родин. В настоящее время я являюсь руководителем курса «Архитектор высоких нагрузок» в OTUS, а также преподаю на курсах, посвященных архитектуре ПО.

Эту статью я подготовил специально к старту нового набора на курс «Архитектор высоких нагрузок».

---

Введение

В позапрошлый раз мы поговорили с вами о том, к чему приводит ослабление изоляции транзакций в базах данных. Сегодня мы обсудим более подробно один из способов обеспечения этой самой изоляции и избегания рассмотренных аномалий. Как вы могли заметить, в позапрошлой статье часто выделялись два подхода: один был основан на том, что у записей есть некоторые версии, а второй на том, что мы будем запись так или иначе блокировать. Таким образом, выделяются два класса баз данных: версионники и блокировочники. О том, что из себя представляют версионники, мы поговорили в прошлый раз, а сейчас я предлагаю обсудить блокировочники.