Константин Осипов ( kostja ), Алексей Рыбак ( fisher )

Константин Осипов: Доклад родился из следующего разговора. Я, как всегда, пытался убедить Алексея больше использовать Tarantool, а он сказал, что там до сих пор нет шардинга и, вообще, неинтересно. Тогда мы стали рассуждать о том, почему нет. Я стал рассказывать, что тут нет одного универсального решения, автоматика полная за вас работает, а вы только кофе на работе пьете и все…

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

Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL.

Материал будет основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov. Смотреть видео не все любят (я точно не люблю), а читать слайды, пусть даже с комментариями, — совсем «не то».

Конечно, статьи не будут повторять содержание курсов один в один. Я буду говорить только о том, как все устроено, опуская собственно администрирование, зато постараюсь делать это более подробно и обстоятельно. И я верю в то, что такие знания полезны прикладному разработчику не меньше, чем администратору.

Ориентироваться я буду на тех, кто уже имеет определенный опыт использования PostgreSQL и хотя бы в общих чертах представляет себе, что к чему. Для совсем новичков текст будет тяжеловат. Например, я ни слова не скажу о том, как установить PostgreSQL и запустить psql.

Вещи, о которых пойдет речь, не сильно меняются от версии к версии, но использовать я буду текущий, 11-й «ванильный» PostgreSQL.

Первый цикл посвящен вопросам, связанным с изоляцией и многоверсионностью, и план его таков:

1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Ну, поехали.

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

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

Взаимоблокировки

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

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

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

Блокировки строк

Устройство

Напомню несколько важных выводов из прошлой статьи.

• Блокировка должна существовать где-то в разделяемой памяти сервера.
• Чем выше гранулярность блокировок, тем меньше конкуренция (contention) среди одновременно работающих процессов.
• С другой стороны, чем выше гранулярность, тем больше места в памяти занимают блокировки.

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

Есть разные пути решения этой проблемы. В некоторых СУБД происходит повышение уровня блокировки: если блокировок уровня строк становится слишком много, они заменяются одной более общей блокировкой (например, уровня страницы или всей таблицы).

Как мы увидим позже, в PostgreSQL такой механизм тоже применяется, но только для предикатных блокировок. С блокировками строк дело обстоит иначе.

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

В этом цикле мы поговорим о блокировках (locks). Я буду придерживаться этого термина, но в литературе может встретиться и другой: замóк.

Цикл будет состоять из четырех частей:

1. Блокировки отношений (эта статья);
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

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

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Журналирование:

1. Буферный кеш;
2. Журнал предзаписи — как устроен и как используется при восстановлении;
3. Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
4. Настройка журнала — уровни и решаемые задачи, надежность и производительность.

В PostgreSQL существует очень удобный механизм рекомендательных блокировок, они же — advisory locks. Мы в «Тензоре» используем их во многих местах системы, но мало кто детально понимает, как конкретно они работают, и какие проблемы можно получить при неправильном обращении.

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

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

---

Введение

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

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

Итак, что такое system design и как пройти интервью такого типа?

Привет, Хабр! Меня зовут Паша Доронин и бóльшую часть жизни я работаю в индустрии переводов и локализации. Я долгое время проработал в компании Smartcat, где прошел путь от аналитика до менеджера по продукту. Несколько месяцев назад я переехал в Дублин и решил заняться дальнейшим развитием своей карьеры.

На этот раз я решил сменить схему поиска вакансий – раньше я просто смотрел на то, «что есть», и выбирал интересные варианты. Теперь же хотелось исходить из того, что хочу получить на новом месте я, и уже соответственно фильтровать объявления. За период активного поиска я связался с 17 компаниями из Европы и США, и устроился в AI-стартап Intento (недавно поднял новый раунд инвестиций). Вот что я понял по итогам этого процесса.

Привет-привет! Мы вновь подготовили Вам подборку интересных вопросов и задачек с собеседований в ведущие IT-компании!


Выпуски будут появляться каждую неделю — следите за обновлениями! Рубрика выходит при поддержке рекрутингового агентства Spice IT.

На этой неделе мы собрали задачи с собеседований в американскую компанию PayPal. Кстати, ответы на задачки из прошлого выпуска уже опубликованы.

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

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

Последние несколько дней в СМИ появилось много статей с данными о смертности и летальности из-за 2019-nCoV. Люди часто путают эти понятия.

Чего только стоит это интервью в Московском комсомольце:

Ссылка на оригинал
Журналист спрашивает про смертность, собеседник отвечает про летальность! Это простая некомпетентность или в очередной раз "ученый изнасиловал журналиста"?
А в чём разница?

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

Недавно я поделился опытом о том, какие параметры мы в команде чаще всего используем для Kafka Producer и Consumer, чтобы приблизиться к гарантированной доставке. В этой статье хочу рассказать, как мы организовали повторную обработку события, полученного из Kafka, в результате временной недоступности внешней системы.

Современные приложения работают в очень сложной среде. Бизнес-логика, обернутая в современный технологический стек, работающая в Docker-образе, который управляется оркестратором вроде Kubernetes или OpenShift, и коммуницирующая с другими приложениями или enterprise-решениями через цепочку физических и виртуальных маршрутизаторов. В таком окружении всегда что-то может сломаться, поэтому повторная обработка событий в случае недоступности одной из внешних систем — важная часть наших бизнес-процессов.

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

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

Когда кластеры достигают размеров в сотни, а иногда и тысячи машин, возникает вопрос о согласованности состояний серверов относительно друг друга. Алгоритм распределённого консенсуса Raft даёт самые строгие гарантии консистентности из возможных. В этой статье мы рассмотрим Raft с точки зрения инженера и постараемся ответить на вопросы «Как?» и «Почему?» он работает.

Итак, представим. В комнате заперты 5 котов, и чтобы пойти разбудить хозяина им необходимо всем вместе договориться между собой об этом, ведь дверь они могут открыть только впятером навалившись на неё. Если один из котов – кот Шрёдингера, а остальные коты не знают о его решении, возникает вопрос: «Как они могут это сделать?»

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