Открытое интервью на Go-разработчика

18 сентября 2024 г. · 74 мин. чтения

Сегодня мы разберём открытое собеседование на позицию Go-разработчика, в ходе которого кандидат Миша продемонстрировал базовое понимание языка, но испытывал трудности с более глубокими техническими концепциями. Интервьюер Аким последовательно проверял знания по типам данных, структурам данных, примитивам синхронизации и базам данных, давая кандидату возможность раскрыть свои сильные стороны и выявить области для роста. В итоге Миша получил честный фидбек и рекомендации по дальнейшему развитию.

Вопрос 1. Расскажите о себе, чем занимались и чем сейчас занимаетесь, какой опыт работы с Go.

Таймкод: 00:02:31

Ответ собеседника: Правильный. Работаю в небольшой веб-студии, делаю инструменты для коллег, автоматизирующие рабочие процессы. Пишу ботов и планирую писать бэкенд на Go. Первый опыт с Go получил на предыдущем месте работы в стартапе, где помогал Go-разработчику, писал микросервисы на Go, понравилось и решил развиваться в этом направлении.

Правильный ответ:

Это вводный вопрос, который задаётся, чтобы кандидат рассказал о своём профессиональном пути и опыте работы с Go. Ожидается структурированный рассказ: где работал, какие задачи решал, какой стек технологий использовал и как пришёл к Go.

Что стоит раскрыть в ответе:

Текущая роль и зона ответственности — чем занимаетесь на текущем месте работы, какие задачи решаете.
Опыт с Go — как давно начали работать, в каких проектах применяли, какие паттерны и инструменты использовали.
Мотивация — почему выбрали Go, что привлекло в языке.
Направление роста — в какую сторону хотите развиваться (микросервисы, высоконагруженные системы, инфраструктура и т.д.).

Ответ собеседника корректный: он кратко описал свой путь, упомянул опыт написания микросервисов на Go и обозначил интерес к дальнейшему развитию в этом направлении. Для усиления ответа можно было бы добавить конкретику: какие именно микросервисы писал, с какими базами данных и брокерами сообщений работал, какие сложные задачи решал.

Вопрос 2. Какие конкретно инструменты вы разрабатываете в веб-студии и как они помогают коллегам.

Таймкод: 00:03:38

Ответ собеседника: Правильный. Разработал шаблонизатор для коммерческих предложений — продажники сами собирают КП без дизайнеров. Также автоматизировали систему планирования для SEO-стратегий — можно автоматически собирать различные планы.

Правильный ответ:

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

Что ожидается в ответе:

Конкретное описание инструментов с деталями реализации — как устроены, какие технологии использовались.
Бизнес-эффект — сколько времени экономится, какие процессы упростились, какие ошибки устраняются.
Архитектурные решения — как инструменты интегрированы в рабочие процессы команды.

Пример развёрнутого ответа:

«В веб-студии я занимаюсь разработкой внутренних инструментов для автоматизации рутинных процессов. Два основных проекта:

Шаблонизатор коммерческих предложений — это веб-приложение, где менеджеры по продажам выбирают шаблон КП, заполняют данные клиента (название, услуги, цены), и система генерирует готовый PDF-документ. Раньше каждый раз обращались к дизайнеру, процесс занимал день-два. Теперь менеджер делает это за 10 минут самостоятельно. Реализовал на Go бэкенде с шаблонизацией через html/template и генерацией PDF.

Система планирования SEO-стратегий — инструмент, который автоматически формирует планы работ на основе входных данных: семантическое ядро, бюджет, сроки. SEO-специалист вводит параметры, а система выдаёт структурированный план с распределением задач по неделям. Это убирает ручное составление таблиц в Excel и снижает вероятность ошибок в планировании.»

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

Вопрос 3. Какие примитивные (встроенные) типы данных есть в Go.

Таймкод: 00:05:02

Ответ собеседника: Неполный. Перечислил int, int8, int16, int32, int64, unsigned int'ы, строки, bool. Забыл про числа с плавающей точкой (float32, float64) и комплексные числа (complex64, complex128).

Правильный ответ:

Go имеет следующую систему примитивных (встроенных) типов данных:

Целочисленные типы со знаком:

int8 — 8 бит, диапазон от -128 до 127
int16 — 16 бит, диапазон от -32768 до 32767
int32 — 32 бита, диапазон от -2147483648 до 2147483647
int64 — 64 бита, диапазон от -9223372036854775808 до 9223372036854775807
int — платформозависимый, 32 или 64 бита в зависимости от архитектуры

Целочисленные типы без знака:

uint8 — 8 бит, диапазон от 0 до 255 (псевдоним byte)
uint16 — 16 бит
uint32 — 32 бита
uint64 — 64 бита
uint — платформозависимый, 32 или 64 бита
uintptr — беззнаковое целое, достаточного размера для хранения указателя

Числа с плавающей точкой:

float32 — 32-битное число с плавающей точкой (около 6-7 значащих десятичных цифр)
float64 — 64-битное число с плавающей точкой (около 15-17 значащих десятичных цифр)

Комплексные числа:

complex64 — комплексное число с вещественной и мнимой частью типа float32
complex128 — комплексное число с вещественной и мнимой частью типа float64

Логический тип:

bool — принимает значения true или false

Строковый тип:

string — неизменяемая последовательность байт, по умолчанию UTF-8

Символьный тип:

rune — псевдоним для int32, представляет собой Unicode code point

Важные нюансы:

В Go нет неявного приведения типов между числовыми типами. Например, int32 и int64 — это разные типы, и для операций между ними нужно явное приведение.
Тип int рекомендуется использовать по умолчанию для целых чисел, если нет веской причины выбрать конкретный размер.
byte — это псевдоним для uint8, а rune — псевдоним для int32. Они присутствуют для читаемости кода.

var a int = 42
var b float64 = 3.14
var c bool = true
var d string = "hello"
var e rune = 'A'
var f byte = 255
var g complex128 = complex(1, 2) // 1 + 2i

Вопрос 4. Чем отличаются различные виды int (int8, int16, int32, int64) в Go и сколько памяти занимает обычный int.

Таймкод: 00:05:56

Ответ собеседника: Неполный. Они занимают разное количество памяти. Ошибся, сказав что int32 занимает 32 байта (на самом деле 4 байта). Для оптимизации можно выбирать подходящий тип. Предположил, что обычный int занимает столько же, что и int64, но на самом деле int зависит от разрядности системы (32 или 64 бита).

Правильный ответ:

Различия между целочисленными типами:

Типы int8, int16, int32, int64 отличаются размером занимаемой памяти и диапазоном допустимых значений:

Тип	Размер	Диапазон значений
`int8`	1 байт (8 бит)	от -128 до 127
`int16`	2 байта (16 бит)	от -32 768 до 32 767
`int32`	4 байта (32 бита)	от -2 147 483 648 до 2 147 483 647
`int64`	8 байт (64 бита)	от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 807

Тип int:

Тип int — это платформозависимый тип. На 32-битных системах он занимает 4 байта (эквивалент int32), на 64-битных — 8 байт (эквивалент int64). В подавляющем большинстве современных серверов и рабочих станций используются 64-битные системы, поэтому на практике int почти всегда равен 8 байтам.

Когда выбирать конкретный размер:

int — используйте по умолчанию для счётчиков, индексов, общих целочисленных вычислений. Компилятор оптимизирует операции с этим типом под целевую архитектуру.
Конкретные размеры (int8, int16, int32, int64) — используйте, когда важна точная размерность: работа с бинарными протоколами, сериализация, структуры, которые маппятся на C-структуры, или при оптимизации памяти в больших массивах.

// Пример маппинга на бинарный протокол
type PacketHeader struct {
    Version  uint8  // 1 байт
    Flags    uint16 // 2 байта
    Length   uint32 // 4 байта
    StreamID uint64 // 8 байт
}

Важный нюанс — выравнивание в структурах:

В Go размер структуры может быть больше суммы размеров её полей из-за выравнивания (padding). Порядок полей в структуре влияет на итоговый размер:

type BadOrder struct {
    a int8  // 1 байт + 7 байт padding
    b int64 // 8 байт
    c int8  // 1 байт + 7 байт padding
} // Итого: 24 байта

type GoodOrder struct {
    b int64 // 8 байт
    a int8  // 1 байт
    c int8  // 1 байт + 6 байт padding
} // Итого: 16 байт

Когда использовать конкретный тип вместо int:

При работе с сетевыми протоколами и бинарными форматами, где размер поля строго определён.
При сериализации/десериализации данных (JSON, Protobuf, MessagePack).
При оптимизации памяти в структурах, которые хранятся в больших количествах (миллионы экземпляров).
При взаимодействии с C-кодом через cgo.
Когда диапазон значений заведомо известен и мал (например, возраст человека — uint8).

Вопрос 5. Сколько памяти занимает обычный int в Go и почему.

Таймкод: 00:07:04

Ответ собеседника: Неполный. Предположил, что int занимает столько же, что и int64 (64 бита). На самом деле int имеет разрядность, зависящую от разрядности системы — 32 или 64 бита.

Правильный ответ:

Тип int в Go — это платформозависимый целочисленный тип. Его размер определяется архитектурой целевой платформы:

На 32-битных системах: int занимает 4 байта (32 бита), эквивалентен int32
На 64-битных системах: int занимает 8 байт (64 бита), эквивалентен int64

Почему так сделано:

Разработчики Go выбрали этот подход осознанно. Нативный размер регистра процессора обеспечивает максимальную производительность арифметических операций. На 64-битной машине процессор работает с 64-битными числами за одну инструкцию, поэтому int равен 64 битам. На 32-битной машине — 32 бита соответственно.

Как проверить размер на текущей платформе:

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var a int
    fmt.Println("Размер int:", unsafe.Sizeof(a), "байт") // 8 на amd64, 4 на 386
    fmt.Println("Битовая архитектура:", strconv.IntSize) // 64 или 32
}

Практический вывод:

В 2024 году практически все серверы, облачные платформы и современные рабочие станции работают на 64-битных архитектурах (amd64, arm64). Поэтому на практике int почти всегда равен 8 байтам. Тем не менее, если вы пишете кроссплатформенный код и хотите быть точным, используйте unsafe.Sizeof() или strconv.IntSize.

Когда это важно:

При сериализации данных — если вы записываете int в бинарный файл или отправляете по сети, размер может отличаться на разных платформах. В таких случаях используйте явные типы (int32, int64).
При работе с большими массивами — разница между 4 и 8 байтами на элемент при миллионах элементов даёт значительную разницу в потреблении памяти.
При взаимодействии с C-кодом через cgo.

Вопрос 6. Что такое unsigned int (uint) в Go, чем он отличается от обычного int и за счёт чего это реализовано.

Таймкод: 00:07:50

Ответ собеседника: Неполный. Объяснил, что uint не имеет отрицательных значений, диапазон сдвинут от нуля и в два раза больше положительных чисел. Не смог точно объяснить реализацию на уровне памяти — не знает, что в signed int один бит занимает знак.

Правильный ответ:

Что такое uint:

uint — это беззнаковый (unsigned) целочисленный тип. Он хранит только неотрицательные значения (ноль и положительные числа). Как и int, его размер зависит от платформы: 4 байта на 32-битных системах и 8 байт на 64-битных.

Сравнение диапазонов:

Тип	Размер	Диапазон
`int8`	1 байт	от -128 до 127
`uint8`	1 байт	от 0 до 255
`int32`	4 байта	от -2 147 483 648 до 2 147 483 647
`uint32`	4 байта	от 0 до 4 294 967 295
`int64`	8 байт	от -9.2×10¹⁸ до 9.2×10¹⁸
`uint64`	8 байт	от 0 до 1.8×10¹⁹

Реализация на уровне памяти — дополнительный код (two's complement):

Знаковые целые числа в современных компьютерах хранятся в дополнительном коде (two's complement). Это не просто «один бит на знак», а целая система кодирования:

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

Для int8 (8 бит):

 5  = 00000101
-5  = 11111011  (инвертируем 00000101 → 11111010, затем +1 → 11111011)
 0  = 00000000
-128 = 10000000

Преимущества дополнительного кода:

Ноль имеет единственное представление (нет проблемы -0 и +0).
Арифметические операции сложения и вычитания работают одинаково для знаковых и беззнаковых чисел — процессору не нужно отдельной схемы.
Диапазон несимметричен: int8 может хранить от -128 до 127 (на одно отрицательное число больше).

Когда использовать uint:

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

Осторожность с uint:

// Классическая ловушка — переполнение в ноль
var a uint32 = 0
b := a - 1 // b = 4294967295 (максимальное значение uint32), а не -1

// Проблема при сравнении с отрицательными числами
var length uint32 = 10
var offset int32 = -1
if offset < int32(length) { // Явное приведение нужно!
    // ...
}

Go не позволяет напрямую смешивать int и uint в выражениях — требуется явное приведение типов, что помогает избежать подобных ошибок.

Вопрос 7. Что такое строка в Go, из чего она состоит, что такое символ и есть ли тип char в Go.

Таймкод: 00:09:08

Ответ собеседника: Неполный. Строка — это массив символов. Symbol — это char. В Go нет типа char. Не знает, что строка в Go — это массив байт ([]byte), а для работы с символами используется rune (алиас int32).

Правильный ответ:

Устройство строки в Go:

Строка в Go — это неизменяемая (immutable) последовательность байт. Внутри строка представлена структурой, содержащей указатель на массив байт и длину:

// Упрощённое представление внутренней структуры строки
type stringStruct struct {
    str *byte  // указатель на начало данных
    len int    // длина в байтах
}

Строки в Go по умолчанию хранятся в кодировке UTF-8. Это означает, что один символ (кодовая точка Unicode) может занимать от 1 до 4 байт.

Отличие от массива символей:

Строка — это не массив символов. Это массив байт. Это принципиальное отличие от языков вроде C (массив char) или Java (массив char с UTF-16).

s := "Hello"
fmt.Println(len(s)) // 5 байт

s := "Привет"
fmt.Println(len(s)) // 12 байт, а не 6 символов! Каждая кириллическая буква = 2 байта в UTF-8

Тип rune вместо char:

В Go нет типа char. Для работы с отдельными символами (кодовыми точками Unicode) используется тип rune, который является псевдонимом для int32:

var r rune = 'A'     // 65
var r2 rune = 'Я'    // 1071
var r3 rune = '😀'   // 128512

rune может хранить любую кодовую точку Unicode (от U+0000 до U+10FFFF), что требует 32 бита.

Итерация по строке:

s := "Hello, Мир"

// Итерация по байтам (неправильно для Unicode)
for i := 0; i < len(s); i++ {
    fmt.Printf("%x ", s[i]) // выводит байты
}

// Итерация по символам (rune) — правильный способ
for i, r := range s {
    fmt.Printf("позиция %d: символ %c (код %d)\n", i, r, r)
}

При использовании range по строке Go автоматически декодирует UTF-8 и возвращает rune. Индекс i указывает на байтовую позицию начала символа, а не на порядковый номер символа.

Преобразования между string, []byte и []rune:

s := "Привет"

// string → []byte
b := []byte(s) // [208 159 209 128 208 184 208 178 208 181 209 130]

// string → []rune
r := []rune(s) // [1055 1088 1080 1074 1077 1090]

// []byte → string
s2 := string(b)

// []rune → string
s3 := string(r)

Каждое преобразование string ↔ []byte и string ↔ []rune создаёт новую копию данных, поскольку строки неизменяемы.

Важные свойства строк:

Неизменяемость — нельзя изменить отдельный байт строки. Любая «модификация» создаёт новую строку.
UTF-8 по умолчанию — исходный код Go в UTF-8, и строки тоже.
Нулевой байт — строки в Go не обнулены в конце (в отличие от C). Длина хранится явно.
Сравнение — операторы ==, <, > работают побайтово, что корректно для UTF-8.

Вопрос 8. Почему в Go нельзя просто обращаться к строке по индексу и как это связано с байтами.

Таймкод: 00:10:33

Ответ собеседника: Правильный. Объяснил, что один символ может занимать больше одного байта (например, два байта), поэтому обращение по индексу к байтам может дать некорректный результат для Unicode-символов.

Правильный ответ:

Формулировка вопроса немного неточна — в Go можно обращаться к строке по индексу, но результат может быть не тем, что ожидается. Вот почему:

Что происходит при обращении по индексу:

Когда вы пишете s[i], вы получаете байт (тип byte, он же uint8), а не символ. Поскольку строка — это последовательность байт в кодировке UTF-8, обращение по индексу возвращает байт по указанной позиции.

s := "Привет"

fmt.Println(s[0])  // 208 — первый байт символа 'П', а не сам символ 'П'
fmt.Println(s[1])  // 159 — второй байт символа 'П'
fmt.Println(s[2])  // 209 — первый байт символа 'р'

// Тип s[i] — это byte, а не rune
var b byte = s[0] // OK

Проблема с многобайтовыми символами:

В UTF-8 символы кодируются разным количеством байт:

Диапазон Unicode	Количество байт	Примеры
U+0000 — U+007F	1 байт	ASCII: A, 0, !
U+0080 — U+07FF	2 байта	Кириллица: А, Я
U+0800 — U+FFFF	3 байта	Иероглифы: 你, 好
U+10000 — U+10FFFF	4 байта	Эмодзи: 😀, 🚀

s := "AП😀"
// Байты: [65, 208, 159, 240, 159, 152, 128]
//        ^A  ^^^П^^^^  ^^^^^^^😀^^^^^^^

fmt.Println(len(s)) // 7 байт, а не 3 символа

fmt.Println(s[0]) // 65 — корректно, 'A' = 1 байт
fmt.Println(s[1]) // 208 — только первый байт 'П', не сам символ
fmt.Println(s[3]) // 240 — только первый байт '😀', не сам символ

Как правильно получить символ:

s := "Привет"

// Способ 1: преобразовать в []rune
runes := []rune(s)
fmt.Println(runes[0])  // 1055 — код символа 'П'
fmt.Println(runes[1])  // 1088 — код символа 'р'
fmt.Printf("%c", runes[0]) // П

// Способ 2: использовать range
for i, r := range s {
    fmt.Printf("индекс %d: символ %c\n", i, r)
}

Когда обращение по индексу допустимо:

Работа с ASCII-строками, где каждый символ = 1 байт.
Обработка бинарных данных, хранящихся в строке.
Парсинг протоколов с фиксированными байтовыми смещениями.

// Корректно для ASCII
header := "HTTP/1.1 200 OK"
if header[0] == 'H' {
    fmt.Println("Это HTTP")
}

Практический вывод:

Обращение s[i] возвращает байт, а не символ. Для корректной работы с Unicode-текстом нужно либо конвертировать строку в []rune, либо использовать range. Это осознанное решение в Go — обращение по индексу к байтам работает за O(1), тогда как доступ по номеру символа в UTF-8 требует O(n) без предварительной конвертации.

Вопрос 9. Что такое rune в Go и какой тип он представляет.

Таймкод: 00:11:02

Ответ собеседника: Неправильный. Не знает, что rune — это алиас int32, представляющий Unicode-код символа.

Правильный ответ:

Определение:

rune — это встроенный псевдоним (alias) для типа int32. Он представляет собой Unicode code point — числовой код символа в стандарте Unicode.

type rune = int32 // определение в спецификации Go

Зачем нужен rune:

Тип int32 может хранить значения от -2 147 483 648 до 2 147 483 647, но для code point используются только положительные значения от 0 до 1 114 111 (0x10FFFF) — именно столько кодовых точек определено в стандарте Unicode. Размер в 32 бита достаточен для хранения любого Unicode-символа.

Использование rune:

// Объявление и инициализация
var r rune = 'A'     // 65
var r2 rune = 'Я'    // 1071
var r3 rune = '😀'   // 128512
var r4 rune = '中'   // 20013

// rune эквивалентен int32
var a int32 = 'B'
var b rune = 66
fmt.Println(a == b) // true — это один и тот же тип

rune и строки:

При итерации по строке через range Go автоматически декодирует байты UTF-8 и возвращает rune:

s := "Hello, Мир!"

for index, char := range s {
    fmt.Printf("байтовая позиция %d: символ '%c' (code point %d)\n", index, char, char)
}
// байтовая позиция 0: символ 'H' (code point 72)
// байтовая позиция 1: символ 'e' (code point 101)
// ...
// байтовая позиция 7: символ 'М' (code point 1052)
// байтовая позиция 9: символ 'и' (code point 1080)
// байтовая позиция 11: символ 'р' (code point 1088)

Обратите внимание: index — это байтовая позиция, а не порядковый номер символа. Символ 'М' начинается с байтовой позиции 7, потому что предшествующие ему кириллические символы занимают по 2 байта.

Конвертация string ↔ []rune:

s := "Привет"

// string → []rune (декодирование UTF-8)
runes := []rune(s)
fmt.Println(runes)     // [1055 1088 1080 1074 1077 1090]
fmt.Println(len(runes)) // 6 символов

// []rune → string (кодирование в UTF-8)
s2 := string(runes)
fmt.Println(s2) // Привет

Практический пример — подсчёт символов:

s := "Привет, мир!"

// Неправильно — считает байты
fmt.Println(len(s)) // 18 байт

// Правильно — считает символы
fmt.Println(len([]rune(s))) // 12 символов

// Или с помощью utf8
import "unicode/utf8"
fmt.Println(utf8.RuneCountInString(s)) // 12 символов (без аллокации)

Функция utf8.RuneCountInString предпочтительнее len([]rune(s)), потому что она не создаёт промежуточный срез и работает без дополнительных аллокаций памяти.

Вопрос 10. Что такое слайс в Go, как он устроен и как работает динамическое расширение.

Таймкод: 00:12:00

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

Правильный ответ:

Внутреннее устройство слайса:

Слайс в Go — это структура из трёх полей:

type slice struct {
    array unsafe.Pointer // указатель на массив (базовый массив в памяти)
    len   int            // длина — количество элементов, доступных для чтения/записи
    cap   int            // ёмкость — общее количество элементов в базовом массиве
}

Слайс — не самостоятельный контейнер, а представление (view) над существующим массивом.

Создание слайса:

// Через литерал
s := []int{1, 2, 3} // len=3, cap=3

// Через make
s := make([]int, 5)    // len=5, cap=5
s := make([]int, 3, 8) // len=3, cap=8

// Нарезка существующего слайса или массива
arr := [5]int{1, 2, 3, 4, 5}
s := arr[1:4] // len=3, cap=4 (от индекса 1 до конца базового массива)

Динамическое расширение через append:

Когда append добавляет элементы и текущей ёмкости не хватает, Go выделяет новый базовый массив большего размера и копирует туда данные.

s := make([]int, 0, 2) // len=0, cap=2

s = append(s, 1) // len=1, cap=2 — место есть, перевыделения нет
s = append(s, 2) // len=2, cap=2 — место есть
s = append(s, 3) // len=3, cap=4 — ёмкость превышена, выделен новый массив

Стратегия роста ёмкости:

Go использует следующую эвристику для определения новой ёмкости:

Если текущая ёмкость меньше 256, ёмкость удваивается.
Если текущая ёмкость 256 и более, ёмкость увеличивается примерно на 25% (коэффициент ~1.25).

Точная формула учитывает выравнивание под размер элементов и аллокированные классы памяти (size classes) рантайма Go.

// Пример наблюдения за ростом ёмкости
s := make([]int, 0)
for i := 0; i < 10; i++ {
    s = append(s, i)
    fmt.Printf("len=%d, cap=%d\n", len(s), cap(s))
}
// len=1, cap=1
// len=2, cap=2
// len=3, cap=4
// len=4, cap=4
// len=5, cap=8
// len=6, cap=8
// len=7, cap=8
// len=8, cap=8
// len=9, cap=16
// len=10, cap=16

Важные свойства слайсов:

Слайсы разделяют базовый массив:

original := []int{1, 2, 3, 4, 5}
slice1 := original[1:3] // [2, 3]
slice2 := original[1:4] // [2, 3, 4]

slice1[0] = 99
fmt.Println(original) // [1, 99, 3, 4, 5] — оригинал изменился!
fmt.Println(slice2)   // [99, 3, 4] — slice2 тоже изменился!

Полная копия для независимости:

original := []int{1, 2, 3}
copySlice := make([]int, len(original))
copy(copySlice, original) // полная копия данных

copySlice[0] = 99
fmt.Println(original)  // [1, 2, 3] — оригинал не изменился
fmt.Println(copySlice) // [99, 2, 3]

Предвыделение памяти для оптимизации:

Если известно примерное количество элементов, лучше заранее выделить нужную ёмкость:

// Плохо — множественные перевыделения
var s []int
for i := 0; i < 10000; i++ {
    s = append(s, i)
}

// Хорошо — одно выделение
s := make([]int, 0, 10000)
for i := 0; i < 10000; i++ {
    s = append(s, i)
}

Пустой слайс vs nil слайс:

var s1 []int        // nil слайс: len=0, cap=0, array=nil
s2 := []int{}       // пустой слайс: len=0, cap=0, array=указатель на пустой массив
s3 := make([]int, 0) // пустой слайс: len=0, cap=0

fmt.Println(s1 == nil) // true
fmt.Println(s2 == nil) // false
fmt.Println(s3 == nil) // false

Разница важна при сериализации JSON: nil слайс сериализуется как null, а пустой — как [].

Вопрос 11. Что произойдёт при взятии среза из середины слайса и добавлении элемента в этот срез.

Таймкод: 00:13:17

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

Правильный ответ:

Это один из классических подводных камней Go, связанный с тем, что слайсы разделяют общий базовый массив.

Разбор ситуации:

original := []int{1, 2, 3, 4, 5, 6, 7, 8}
// original: len=8, cap=8

// Берём срез из середины
middle := original[2:5] // [3, 4, 5], len=3, cap=6
// middle указывает на тот же массив, начиная с индекса 2
// cap=6, потому что от индекса 2 до конца базового массива 6 элементов

Добавление элемента в middle без перевыделения:

Если ёмкости middle хватает, append запишет новый элемент прямо в базовый массив:

middle = append(middle, 99)
// middle: [3, 4, 5, 99], len=4, cap=6

fmt.Println(original) // [1, 2, 3, 4, 5, 99, 7, 8]
// Элемент 6 (индекс 5 в original) перезаписан на 99!

Что произошло:

middle имел cap=6, после append — len=4, перевыделения не было.
Новый элемент 99 записался в базовый массив по индексу 5.
Это позиция, которая в original содержала значение 6.
Оба слайса original и middle продолжают ссылаться на один и тот же базовый массив.

Добавление элемента с перевыделением:

Если ёмкости не хватает, append создаст новый базовый массив, и связь с original разорвётся:

original := []int{1, 2, 3, 4, 5, 6, 7, 8}
middle := original[2:5] // [3, 4, 5], len=3, cap=6

// Добавляем столько элементов, чтобы превысить cap=6
middle = append(middle, 10, 20, 30) // len=6, cap=12 (новый массив!)

middle[0] = 999
fmt.Println(original) // [1, 2, 3, 4, 5, 6, 7, 8] — не изменился!
fmt.Println(middle)   // [999, 4, 5, 10, 20, 30]

Визуализация:

До append (cap хватает):
original: [1, 2, 3, 4, 5, 6, 7, 8]
                 ↑-----------↑
middle:          [3, 4, 5]  + свободное место для 3 элементов

После append(middle, 99):
original: [1, 2, 3, 4, 5, 99, 7, 8]  ← затронут!
middle:   [3, 4, 5, 99]

После append с перевыделением:
original: [1, 2, 3, 4, 5, 6, 7, 8]  ← не затронут
middle:   [999, 4, 5, 10, 20, 30]   ← новый массив

Как избежать проблем:

Использовать copy для создания независимой копии слайса.
Ограничивать ёмкость среза через трёхиндексную нарезку s[low:high:max], чтобы гарантировать перевыделение при первом append.

// Трёхиндексная нарезка ограничивает ёмкость
middle := original[2:5:5] // len=3, cap=3
middle = append(middle, 99) // cap=3 недостаточно → новый массив

fmt.Println(original) // [1, 2, 3, 4, 5, 6, 7, 8] — не изменился

Вопрос 12. Что такое map в Go, как работает и всегда ли доступ к элементу по ключу выполняется за константное время O(1).

Таймкод: 00:14:06

Ответ собеседния: Неполный. Map позволяет получать данные по ключу за O(1). Можно складывать любые comparable типы. В большинстве случаев доступ константный, в наихудшем случае — O(N). Не смог точно объяснить, почему скорость доступа не всегда константная.

Правильный ответ:

Что такое map:

map в Go — это встроенная хэш-таблица, реализующая ассоциативный массив (словарь). Хранит пары ключ-значение, где ключ должен быть comparable (поддерживать операторы == и !=).

// Создание map
m := make(map[string]int)
m := map[string]int{"a": 1, "b": 2}

// Операции
m["key"] = 42        // запись
val := m["key"]      // чтение
delete(m, "key")     // удаление
val, ok := m["key"]  // проверка наличия ключа

Какие типы могут быть ключами:

Ключом может быть любой comparable тип:

Все примитивные типы: int, string, bool, float64, rune, указатели
Массивы из comparable элементов (например, [3]int)
Структуры, содержащие только comparable поля
Интерфейсы (сравниваются динамический тип + значение)

Не могут быть ключами: слайсы, map'ы, функции (они не comparable).

Внутреннее устройство хэш-таблицы:

Map в Go реализован как хэш-таблица с методом цепочек (chaining). Внутри она содержит:

Хэш-функция — преобразует ключ в числовое значение (хэш).
Массив бакетов (buckets) — массив фиксированного размера, каждый элемент — указатель на бакет.
Бакет — структура, хранящая до 8 пар ключ-значение. При переполнении бакет связан с overflow-бакетом.

hmap (заголовок карты)
├── buckets → [bucket0][bucket1][bucket2]...[bucketN]
                              │
                              ▼
                    ┌─────────────────────┐
                    │ bucket (8 слотов)   │
                    │ keys:  [k1][k2]...  │
                    │ vals:  [v1][v2]...  │
                    │ overflow → ─────────┼──→ [overflow bucket]
                    └─────────────────────┘

Почему доступ не всегда O(1):

В теории хэш-таблиц доступ по ключу — O(1) в среднем. Но на практике есть нюансы:

Коллизии хэшей — когда два разных ключа дают одинаковый хэш (или попадают в один бакет). Go разрешает коллизии через цепочки бакетов. Если много ключей попали в один бакет, поиск идёт линейно по цепочке.

// В крайнем случае (все ключи в один бакет):
// Поиск: O(n), где n — количество элементов в map

Рехеширование (grow) — при загрузке map свыше определённого порога (load factor ~6.5), Go увеличивает количество бакетов и перераспределяет все элементы. Во время роста операции чтения/записи могут быть медленнее.

Качество хэш-функции — Go использует рандомизированную хэш-функцию (seed генерируется при создании map), что защищает от атак на коллизии. Но для определённых паттернов данных коллизии всё равно возможны.

Сложность в среднем и худшем случае:

Операция	Средний случай	Худший случай
Чтение	O(1)	O(n)
Запись	O(1)	O(n)
Удаление	O(1)	O(n)
Итерация	O(n)	O(n)

Практический вывод:

Для реальных приложений с нормальным распределением ключей map в Go работает за O(1). Худший случай O(n) наступает только при массовых коллизиях, что практически исключено благодаря рандомизированной хэш-функции. Тем не менее, map не гарантирует строгого O(1) в каждом конкретном вызове — это свойство всех хэш-таблиц.

Важные особенности map в Go:

// Map — это ссылочный тип (указатель на hmap)
m1 := make(map[string]int)
m2 := m1
m2["key"] = 42
fmt.Println(m1["key"]) // 42 — оба указывают на одну map

// Map не потокобезопасен
// Для конкурентного доступа нужна синхронизация:
var mu sync.RWMutex
// или sync.Map для специфических сценариев

// Порядок итерации не определён (рандомизирован)
for k, v := range m {
    fmt.Println(k, v) // порядок каждый раз разный
}

Вопрос 13. Как устроена хэш-таблица внутри в Go: что такое бакеты, эвакуация данных и зачем нужна ёмкость бакетов.

Таймкод: 00:15:17

Ответ собеседника: Неполный. Хранение в map реализовано через бакеты по 8 элементов. Упомянул порог 6.5 для эвакуации, но перепутал — эвакуация начинается при 8 элементах в бакете. Коллизию объяснил неверно — как ситуацию, когда по одному ключу можно получить разные значения, а не когда разные ключи дают одинаковый хэш.

Правильный ответ:

Внутренняя структура hmap:

Map в Go представлен структурой hmap, которая содержит указатель на массив бакетов и метаданные:

// Упрощённое представление (из runtime/map.go)
type hmap struct {
    count     int    // количество элементов в map
    B         uint8  // log2 количества бакетов (2^B бакетов)
    buckets   unsafe.Pointer // указатель на массив бакетов
    oldbuckets unsafe.Pointer // указатель на старые бакеты (при эвакуации)
    nevacuate uintptr // прогресс эвакуации
    // ...
}

Структура бакета (bmap):

Каждый бакет — это структура, хранящая до 8 пар ключ-значение:

type bmap struct {
    tophash [8]uint8  // старшие 8 бит хэша для каждого ключа
    // Затем идут 8 ключей и 8 значений (расположены последовательно)
    // overflow *bmap — указатель на следующий бакет при переполнении
}

Что такое коллизия:

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

Как работает поиск:

Вычисляется хэш ключа.
Младшие B бит хэша определяют номер бакета: bucket = hash & (2^B - 1).
В бакете проверяется поле tophash — старшие 8 бит хэша. Это быстрый предфильтр.
Если tophash совпал, проверяется полное равенство ключа (==).
Если ключ не найден в текущем бакете, поиск продолжается в overflow-бакете.

Load factor и порог 6.5:

Порог 6.5 — это среднее количество элементов на бакет по всей map, а не количество элементов в одном бакете.

load factor = количество элементов / количество бакетов

Поскольку каждый бакет вмещает 8 элементов:

При load factor = 6.5: в среднем 6.5 элементов на бакет.
Это означает, что бакеты заполнены на ~81% (6.5/8).
Когда средняя загрузка превышает 6.5, Go запускает рост map (увеличивает количество бакетов вдвое).

Эвакуация данных (evacuation):

Когда map растёт, количество бакетов удваивается. Но Go не копирует все данные сразу — вместо этого используется инкрементальная эвакуация:

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

// Визуализация эвакуации
// До роста: 4 бакета
oldbuckets: [B0][B1][B2][B3]

// После начала роста: 8 бакетов, эвакуатация в процессе
newbuckets:  [B0'][B1'][B2'][B3'][B4'][B5'][B6'][B7']
oldbuckets:  [B0][B1][B2][B3] ← ещё не все эвакуированы
              ↑
              nevacuate указывает сюда

Почему это важно:

Без инкрементальной эвакуации вставка в map могла бы вызвать паузу в O(n) при каждом росте.
С инкрементальной эвакуацией каждая вставка делает немного работы по миграции, а общая стоимость роста распределяется.

Overflow-бакеты:

Когда бакет заполнен (8 элементов), Go создаёт overflow-бакет и связывает его с текущим. Множественные overflow-бакеты образуют связный список. Именно длинные цепочки overflow-бакетов ухудшают производительность до O(n).

Предвыделение ёмкости:

// Без предвыделения — множественные росты
m := make(map[string]int)
for i := 0; i < 10000; i++ {
    m[strconv.Itoa(i)] = i
}

// С предвыделением — один рост
m := make(map[string]int, 10000) // hint для runtime

При создании map с подсказкой ёмкости Go сразу выделяет достаточное количество бакетов, что уменьшает количество ростов и эвакуаций.

Вопрос 14. Что такое хэш-функция, что такое коллизия в контексте хэширования и какие есть способы разрешения коллизий.

Таймкод: 00:19:00

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

Правильный ответ:

Хэш-функция:

Хэш-функция — это функция, которая преобразует входные данные произвольного размера в значение фиксированного размера (хэш). Формально: h: K → {0, 1, ..., m-1}, где K — множество ключей, m — размер хэш-таблицы.

Свойства хорошей хэш-функции:

Детерминированность — один и тот же ключ всегда даёт один и тот же хэш.
Равномерность — хэши равномерно распределены по диапазону, минимизируя коллизии.
Быстрота — вычисление хэша должно быть за O(1) или O(len(key)).
Лавинный эффект — изменение одного бита входных данных должно значительно менять хэш.

Коллизия:

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

// Пример: hash("abc") == hash("xyz") — коллизия
// Разные ключи, одинаковый хэш

Способы разрешения коллизий:

1. Метод цепочек (Separate Chaining) — закрытая адресация:

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

hash table:
[0] → nil
[1] → (k1,v1) → (k5,v5) → nil
[2] → (k2,v2) → nil
[3] → nil
[4] → (k4,v4) → (k7,v7) → (k9,v9) → nil

Поиск: вычисляем хэш → находим слот → линейный поиск по списку.
Простота реализации.
Эффективен при коротких цепочках.
Используется в Go — бакеты с overflow-цепочками.

2. Открытая адресация (Open Addressing):

Все элементы хранятся непосредственно в массиве хэш-таблицы. При коллизии ищется следующий свободный слот по определённой стратегии.

Линейное пробирование (Linear Probing):

// При коллизии в слоте i проверяем i+1, i+2, i+3, ...
index = (hash(key) + j) % m  // j = 0, 1, 2, ...

Простая реализация.
Хорошая локальность кэша (последовательные ячейки рядом).
Проблема кластеризации — длинные заполненные последовательности замедляют поиск.

Квадратичное пробирование (Quadratic Probing):

index = (hash(key) + c1*j + c2*j*j) % m  // j = 0, 1, 2, ...

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

Двойное хэширование (Double Hashing):

index = (h1(key) + j * h2(key)) % m  // j = 0, 1, 2, ...

Лучшее распределение среди методов открытой адресации.
Требует двух хэш-функций.

3. Кукау (Cuckoo Hashing):

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

Гарантированный O(1) поиск (проверяются ровно 2 позиции).
Вставка может быть дорогой (каскадное вытеснение).

Сравнение методов:

Метод	Поиск (средний)	Поиск (худший)	Память	Локальность кэша
Цепочки	O(1)	O(n)	Больше (указатели)	Хуже
Линейное пробирование	O(1)	O(n)	Меньше	Лучше
Кукау	O(1)	O(1)	2 таблицы	Средне

Что использует Go:

Go использует метод цепочек с бакетами по 8 элементов и overflow-бакетами. Это даёт хороший баланс между производительностью и простотой реализации, а также позволяет эффективно использовать инкрементальную эвакуацию при росте map.

Вопрос 15. Какие есть способы разрешения коллизий в хэш-таблицах и что такое открытая адресация.

Таймкод: 00:21:03

Ответ собеседника: Неполный. Слышал про закрытую и открытую адресацию, но про открытую адресацию рассказать не смог. Собеседующий объяснил, что открытая адресация — это когда хэш вычисляется как остаток от деления на размер массива, а при коллизии ищется следующий свободный слот. Бакеты в Go — это алгоритм разрешения коллизий с использованием младших бит хэша для выбора бакета и старших бит для выбора позиции внутри бакета.

Правильный ответ:

Этот вопрос уже был подробно разобран в предыдущем (вопрос 14). Вот краткое резюме ключевых моментов:

Два основных подхода к разрешению коллизий:

Закрытая адресация (Separate Chaining):

Каждый слот таблицы содержит связный список элементов, попавших в этот слот. При коллизии новый элемент добавляется в список. Именно этот подход используется в Go — бакеты с overflow-цепочками.

Открытая адресация (Open Addressing):

Все элементы хранятся непосредственно в массиве хэш-таблицы. При коллизии ищется следующий свободный слот по определённой стратегии пробирования:

// Линейное пробирование — ищем следующий слот
index = (hash(key) + i) % tableSize  // i = 0, 1, 2, ...

// Квадратичное пробирование
index = (hash(key) + c1*i + c2*i*i) % tableSize

// Двойное хэширование
index = (h1(key) + i * h2(key)) % tableSize

Как это работает в Go — бакеты:

Go использует закрытую адресацию с бакетами по 8 элементов:

Младшие B бит хэша определяют номер бакета: bucketIndex = hash & (2^B - 1).
Старшие 8 бит хэша (tophash) хранятся в бакете и используются для быстрого предфильтра — если tophash не совпал, ключ точно не в этом слоте.
При переполнении бакета (более 8 элементов) создаётся overflow-бакет, связанный с текущим.

// Пример: как Go выбирает бакет и слот
hash := runtime.hasher(key)
bucketIndex := hash & ((1 << B) - 1)  // младшие B бит
tophash := uint8(hash >> 57)           // старшие 8 бит (для 64-битного хэша)

// Поиск внутри бакета:
// 1. Сравниваем tophash — быстрая проверка
// 2. Если tophash совпал — сравниваем ключ через ==
// 3. Если не нашли — идём в overflow-бакет

Ключевое отличие от открытой адресации:

При открытой адресации элементы хранятся прямо в основном массиве, и при коллизии мы «прыгаем» по этому массиву. В Go элементы хранятся в бакетах (связных списках), и при коллизии мы либо добавляем в текущий бакет, либо переходим в overflow-бакет — это классическая закрытая адресация.

Вопрос 16. Что такое интерфейс в Go, чем он отличается от интерфейсов в других языках и как он устроен под капотом.

Таймкод: 00:24:06

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

Правильный ответ:

Что такое интерфейс:

Интерфейс в Go — это набор методов (method set), которые тип должен реализовать, чтобы удовлетворить интерфейсу. Реализация происходит неявно — не нужно явно указывать, что тип реализует интерфейс.

type Writer interface {
    Write(p []byte) (n int, err error)
}

type File struct{ /* ... */ }

func (f *File) Write(p []byte) (int, error) {
    // реализация
}

// File автоматически реализует Writer — никаких ключевых слов implements
var w Writer = &File{} // OK

Утиная типизация (Duck Typing):

Если тип имеет все методы интерфейса — он реализует этот интерфейс. Проверка происходит на этапе компиляции (в отличие от утиной типизации в Python, где это runtime).

Отличия от интерфейсов в других языках:

Характеристика	Go	Java	Rust
Реализация	Неявная	Явная (`implements`)	Явная (`impl Trait for Type`)
Проверка	Компиляция	Компиляция	Компиляция
Наследование интерфейсов	Встраивание	`extends`	Supertraits
Значение nil-интерфейсы	Разрешено	N/A	N/A
Пустой интерфейс	`interface{}` — любой тип	`Object`	`dyn Trait`

Внутреннее устройство интерфейса:

Интерфейсное значение в Go — это структура из двух указателей (16 байт на 64-битной системе):

type iface struct {
    tab  *itab          // указатель на таблицу методов (тип + методы)
    data unsafe.Pointer // указатель на данные конкретного значения
}

itab содержит:

type itab struct {
    inter *interfacetype // метаданные интерфейса
    _type *_type         // метаданные конкретного типа
    hash  uint32         // хэш типа (для оптимизации type switch)
    _     [4]byte        // padding
    fun   [1]uintptr     // массив указателей на методы (переменная длина)
}

Как это работает:

type Speaker interface {
    Speak() string
}

type Dog struct{ Name string }

func (d Dog) Speak() string {
    return d.Name + " says woof!"
}

// Присваивание интерфейсу
var s Speaker = Dog{Name: "Rex"}

В памяти:

s (iface):
┌──────────────┬──────────────────┐
│ tab → itab   │ data → Dog{"Rex"} │
└──────────────┴──────────────────┘

itab:
┌─────────────┬──────────┬──────────┬────────────────┐
│ inter       │ _type    │ hash     │ fun[0]         │
│ (Speaker)   │ (Dog)    │ (hash)   │ → Dog.Speak    │
└─────────────┴──────────┴──────────┴────────────────┘

Вызов метода через интерфейс:

s.Speak()
// Компилятор генерирует:
// 1. Загрузить itab из s.tab
// 2. Загрузить указатель на функцию из itab.fun[0]
// 3. Вызвать функцию с s.data как приёмником

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

Nil интерфейсы и интерфейсы с nil-значением:

// Nil интерfейс — оба поля nil
var s Speaker // tab=nil, data=nil
fmt.Println(s == nil) // true

// Интерфейс с nil-значением — tab не nil, data nil
var d *Dog = nil
var s Speaker = d // tab указывает на itab для *Dog, data=nil
fmt.Println(s == nil) // false! Это частая ловушка

Пустой интерфейс interface{} (или any в Go 1.18+):

Пустой интерфейс не имеет методов, поэтому любой тип его

Вопрос 17. Какие примитивы синхронизации данных существуют в Go и зачем они нужны.

Таймкод: 00:25:19

Ответ собеседника: Неполный. Назвал каналы, пакет atomic, мьютекс из пакета sync и WaitGroup. Знает, что мьютексы нужны для предотвращения data race. Не назвал RWMutex, Cond, Pool, sync.Map и другие примитивы.

Правильный ответ:

Зачем нужны примитивы синхронизации:

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

Основные примитивы синхронизации в Go:

1. Mutex (sync.Mutex) — взаимное исключение:

var mu sync.Mutex
var counter int

func increment() {
    mu.Lock()
    counter++
    mu.Unlock()
}

Гарантирует, что только одна горутина может выполнять код между Lock() и Unlock() в любой момент времени.

2. RWMutex (sync.RWMutex) — читатель-писатель мьютекс:

var mu sync.RWMutex
var data map[string]string

func read(key string) string {
    mu.RLock()         // множество читателей одновременно
    defer mu.RUnlock()
    return data[key]
}

func write(key, value string) {
    mu.Lock()          // эксклюзивный доступ для писателя
    defer mu.Unlock()
    data[key] = value
}

Позволяет множеству горутин читать одновременно, но запись — эксклюзивно. Оптимален для сценариев «много чтений, мало записей».

3. WaitGroup (sync.WaitGroup) — ожидание завершения горутин:

var wg sync.WaitGroup

for i := 0; i < 10; i++ {
    wg.Add(1)
    go func(id int) {
        defer wg.Done()
        // работа
    }(i)
}

wg.Wait() // ждём завершения всех горутин

4. Once (sync.Once) — однократное выполнение:

var once sync.Once
var instance *Database

func GetInstance() *Database {
    once.Do(func() {
        instance = &Database{/* инициализация */}
    })
    return instance
}

Гарантирует, что функция будет выполнена ровно один раз, даже если вызывается из множества горутин.

5. Cond (sync.Cond) — условная переменная:

var mu sync.Mutex
cond := sync.NewCond(&mu)
var ready bool

// Горутина-ожидатель
mu.Lock()
for !ready {
    cond.Wait() // освобождает мьютекс и ждёт сигнала
}
mu.Unlock()

// Горутина-сигнализатор
mu.Lock()
ready = true
cond.Signal() // или cond.Broadcast() для всех
mu.Unlock()

Позволяет горутинам ждать наступления определённого условия.

6. Channels — каналы:

ch := make(chan int, 10)

// Отправка
ch <- 42

// Получение
val := <-ch

// Закрытие
close(ch)

Каналы — основной механизм коммуникации между горутинами в Go. Реализуют принцип CSP (Communicating Sequential Processes).

7. Atomic (sync/atomic) — атомарные операции:

var counter int64

atomic.AddInt64(&counter, 1)
val := atomic.LoadInt64(&counter)
atomic.CompareAndSwapInt64(&counter, old, new)

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

8. sync.Map — конкурентная map:

var m sync.Map

m.Store("key", "value")
val, ok := m.Load("key")
m.Delete("key")
m.Range(func(key, value interface{}) bool {
    fmt.Println(key, value)
    return true
})

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

9. sync.Pool — пул объектов:

var pool = sync.Pool{
    New: func() interface{} {
        return make([]byte, 1024)
    },
}

buf := pool.Get().([]byte)
// используем buf
pool.Put(buf) // возвращаем в пул

Позволяет переиспользовать объекты, снижая нагрузку на сборщик мусора. Объекты в пуле могут быть удалены GC в любой момент.

10. Context — контекст выполнения:

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

result, err := doWork(ctx)

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

Когда что использовать:

Примитив	Сценарий
Mutex	Защита общего состояния
RWMutex	Много чтений, мало записей
Channel	Передача данных между горутинами, координация
WaitGroup	Ожидание завершения группы горутин
Once	Ленивая инициализация, singleton
Cond	Ожидание условия
Atomic	Простые счётчики, флаги
sync.Map	Кэш с редкой записью
sync.Pool	Переиспользование временных объектов
Context	Отмена, таймауты, дедлайны

Золотое правило Go:

> «Don't communicate by sharing memory; share memory by communicating.»

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

Вопрос 18. Что такое мьютекс в Go, как с его помощью сделать map потокобезопасной и что происходит при блокировке и разблокировке.

Таймкод: 00:28:01

Ответ собеседника: Правильный. Мьютекс используется для обеспечения потокобезопасности. Map можно сделать потокобезопасной, обернув в структуру вместе с мьютексом. При работе с map мьютекс блокируется (Lock), после завершения — разблокируется (Unlock). Другие горутины ожидают разблокировки.

Правильный ответ:

Что такое мьютекс:

sync.Mutex — это примитив взаимного исключения (mutual exclusion). Он обеспечивает, что в любой момент времени только одна горутина может владеть мьютексом и выполнять защищённый код.

Потокобезопасная map:

type SafeMap struct {
    mu sync.RWMutex
    data map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{
        data: make(map[string]int),
    }
}

func (m *SafeMap) Get(key string) (int, bool) {
    m.mu.RLock()
    defer m.mu.RUnlock()
    val, ok := m.data[key]
    return val, ok
}

func (m *SafeMap) Set(key string, value int) {
    m.mu.Lock()
    defer m.mu.Unlock()
    m.data[key] = value
}

func (m *SafeMap) Delete(key string) {
    m.mu.Lock()
    def

#### **Вопрос 19**. Могут ли две горутины одновременно залочить мьютекс и существует ли примитив, позволяющий нескольким потокам лочить его одновременно.

**Таймкод:** <YouTubeSeekTo id="262GElUipOM" time="00:29:07"/>

**Ответ собеседника:** **Неполный**. Две горутины не могут одновременно залочить мьютекс. Вспомнил семафор. Не назвал RWMutex, который позволяет нескольким читателям одновременно иметь доступ, но только одному писателю.

**Правильный ответ:**

**Могут ли две горутины одновременно залочить мьютекс:**

Нет, это принципиально невозможно — иначе мьютекс не выполнял бы свою функцию. `sync.Mutex` гарантирует, что в любой момент времени только **одна** горутина может владеть блокировкой. Если горутина A вызвала `Lock()` и не вызвала `Unlock()`, то горутина B, вызвавшая `Lock()`, будет заблокирована до тех пор, пока A не освободит мьютекс.

**Примитивы, допускающие одновременный доступ нескольких горутин:**

**1. RWMutex (sync.RWMutex) — читатель-писатель мьютекс:**

Это основной примитив в Go для сценариев «много чтений, мало записей»:

```go
var mu sync.RWMutex

// Множество читателей одновременно
mu.RLock()    // блокирует писателей, но не других читателей
// чтение данных
mu.RUnlock()

// Только один писатель (без читателей и других писателей)
mu.Lock()     // эксклюзивный доступ
// запись данных
mu.Unlock()

Правила:

Множество горутин могут одновременно удерживать RLock().
Lock() ждёт, пока все RLock() будут освобождены.
Пока удерживается Lock(), ни один RLock() не может быть получен.

2. Semaphore (семафор) через каналы:

В Go нет встроенного семафора в стандартной библиотеке, но его можно реализовать через буферизованный канал:

// Семафор, разрешающий N одновременных доступов
sem := make(chan struct{}, 3) // максимум 3 горутины одновременно

func worker() {
    sem <- struct{}{}        // захват (P-операция)
    defer func() { <-sem }() // освобождение (V-операция)
    // работа с ограниченным ресурсом
}

3. Семафор через golang.org/x/sync/semaphore:

import "golang.org/x/sync/semaphore"

sem := semaphore.NewWeighted(3) // максимум 3 одновременных доступа

func worker(ctx context.Context) error {
    if err := sem.Acquire(ctx, 1); err != nil {
        return err
    }
    defer sem.Release(1)
    // работа
    return nil
}

Сравнение примитивов:

Примитив	Одновременный доступ	Сценарий
`sync.Mutex`	1 горутина	Эксклюзивный доступ
`sync.RWMutex`	Много читателей или 1 писатель	Много чтений, мало записей
Semaphore (канал)	N горутин	Ограничение параллелизма
`sync.WaitGroup`	Не ограничивает доступ	Ожидание завершения

Когда использовать RWMutex vs Mutex:

// RWMutex выгоден, когда чтений значительно больше записей
type Cache struct {
    mu   sync.RWMutex
    data map[string]*Item
}

func (c *Cache) Get(key string) *Item {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.data[key] // множество горутин читают одновременно
}

func (c *Cache) Set(key string, item *Item) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[key] = item // эксклюзивная запись
}

Важный нюанс:

RWMutex не всегда быстрее Mutex. Если записи происходят часто или критическая секция очень маленькая, накладные расходы RWMutex могут превысить выгоду от параллельного чтения. Профилирование — единственный надёжный способ определить, что лучше в конкретном случае.

Вопрос 20. Чем отличается мьютекс (Mutex) от RWMutex в Go.

Таймкод: 00:30:13

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

Правильный ответ:

Формально кандидат в последней фразе описал поведение RWMutex правильно, но не смог дать полноценного объяснения разницы. Вот развёрнутый ответ:

sync.Mutex — взаимное исключение:

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

var mu sync.Mutex
var data map[string]int

func read(key string) int {
    mu.Lock()         // блокирует ВСЕ другие горутины
    defer mu.Unlock()
    return data[key]
}

func write(key string, value int) {
    mu.Lock()         // ждёт, пока другие освободят
    defer mu.Unlock()
    data[key] = value
}

Проблема: даже при одновременном чтении горутины выстраиваются в очередь. Два параллельных чтения не могут происходить одновременно, хотя это безопасно.

sync.RWMutex — читатель-писатель мьютекс:

RWMutex разделяет блокировки на два типа:

RLock() (Read Lock) — множество горутин могут удерживать одновременно.
Lock() (Write Lock) — только одна горутина, и только когда нет активных RLock'ов.

var mu sync.RWMutex
var data map[string]int

func read(key string) int {
    mu.RLock()        // другие читатели тоже могут читать параллельно
    defer mu.RUnlock()
    return data[key]
}

func write(key string, value int) {
    mu.Lock()         // эксклюзивный доступ: ждёт ВСЕХ читателей и писателей
    defer mu.Unlock()
    data[key] = value
}

Правила RWMutex:

┌─────────────────────────────────────────────────────────┐
│  RLock() может быть получен, если:                      │
│  - Нет активного Lock() (писателя)                      │
│  - Другие RLock() приветствуются                        │
├─────────────────────────────────────────────────────────┤
│  Lock() может быть получен, если:                       │
│  - Нет активного Lock() (другого писателя)              │
│  - Нет активных RLock() (читателей)                     │
│  - Ждёт освобождения ВСЕХ текущих блокировок            │
└─────────────────────────────────────────────────────────┘

Визуализация параллелизма:

Mutex:
Time →  G1: [====read====]
              G2:        [====read====]
                     G3:              [====write====]

RWMutex:
Time →  G1: [====read====]
         G2: [====read====]        ← параллельно!
              G3:        [====read====]  ← параллельно!
                     G4:              [====write====]  ← ждёт всех

Когда использовать что:

Сценарий	Рекомендация
Много чтений (>90%), редкие записи	`RWMutex`
Примерно равное количество чтений и записей	`Mutex`
Частые записи	`Mutex` (RWMutex может быть медленнее)
Очень короткая критическая секция	`Mutex` или `atomic`
Неопределённый паттерн	Профилировать оба варианта

Важные нюансы RWMutex:

RWMutex не рекурсивный — повторный RLock() из той же горутины вызовет deadlock.
RWMutex в Go не отдаёт приоритет писателям — если читатели непрерывно приходят, писатель может быть заблокирован надолго (writer starvation). Начиная с Go 1.18, это поведение было улучшено — после определённого числа читателей писатель получает приоритет.
Накладные расходы RWMutex выше, чем у Mutex — он должен отслеживать количество читателей.

// Пример: профилирование для выбора
// go test -bench=. -benchmem
func BenchmarkMutexRead(b *testing.B) {
    var mu sync.Mutex
    m := map[string]int{"key": 1}
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            mu.Lock()
            _ = m["key"]
            mu.Unlock()
        }
    })
}

func BenchmarkRWMutexRead(b *testing.B) {
    var mu sync.RWMutex
    m := map[string]int{"key": 1}
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            mu.RLock()
            _ = m["key"]
            mu.RUnlock()
        }
    })
}

Вопрос 21. Как работает планировщик Go: какая горутина первая получит мьютекс и как передаётся владение мьютексом после разблокировки.

Таймкод: 00:31:15

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

Правильный ответ:

Модель планировщика Go — M:P:G:

Планировщик Go использует модель M:P:G (три уровня):

M (Machine) — ОС-поток (thread). Реальный поток операционной системы, на котором выполняется код.
P (Processor) — логический процессор. Контекст выполнения, содержащий локальную очередь горутин. Количество P по умолчанию равно GOMAXPROCS (числу ядер CPU).
G (Goroutine) — горутина. Легковесный поток выполнения, управляемый рантаймом Go.

┌─────────────────────────────────────────────┐
│ ОС-потоки (M)                               │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │   M1    │  │   M2    │  │   M3    │     │
│  └────┬────┘  └────┬────┘  └────┬────┘     │
│       │            │            │           │
│  ┌────▼────┐  ┌────▼────┐  ┌────▼────┐     │
│  │   P1    │  │   P2    │  │   P3    │     │
│  │ [G1-G8] │  │ [G9-G16]│  │[G17-G24]│     │
│  │ локальная│  │ локальная│  │ локальная│    │
│  │ очередь │  │ очередь │  │ очередь │     │
│  └─────────┘  └─────────┘  └─────────┘     │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │     Глобальная очередь (runq)       │    │
│  │     [G25, G26, G27, ...]            │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Как работает планирование:

Каждый P имеет локальную очередь из до 256 горутин.
Когда G вытесняется (системный вызов, канал, time.Sleep и т.д.), P берёт следующую G из своей локальной очереди.
Если локальная очередь пуста, P берёт горутины из глобальной очереди или ворует у других P (work stealing).
Планировщик Go кооперативный с вытеснением — горутина отдаёт управление в определённых точках (syscall, channel operations, функции calls) или при превышении кванта времени (с Go 1.14 — вытеснение по сигналу, ~10ms).

Как передаётся владение мьютексом:

Когда горутина вызывает Unlock(), мьютекс переходит в свободное состояние. Но порядок пробуждения ожидающих горутин не гарантирован:

// Горутины G1, G2, G3 ждут мьютекс
// G1 вызывает Unlock()
// Кто получит мьютекс следующим? — НЕОПРЕДЕЛЕНО

Внутри sync.Mutex используется futex-подобный механизм (на Linux — системный вызов futex):

Горутина, вызывающая Lock() на занятом мьютексе, помещается в очередь ожидания мьютекса.
При Unlock() одна из ожидающих горутин пробуждается и пытается захватить мьютекс.
Порядок пробуждения зависит от планировщика ОС и рантайма Go — нет гарантии FIFO.

Реализация мьютекса в Go:

// Упрощённое представление (из sync/mutex.go)
type Mutex struct {
    state int32  // бит 0: locked, бит 1: woken, бит 2: starving
    sema  uint32 // семафор для блокировки горутин
}

Механизм работы в два этапа:

Быстрый путь (fast path) — мьютекс свободен:

// Атомарно меняем state с 0 на 1
if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
    return // захватили мьютекс мгновенно
}

Медленный путь (slow path) — мьютекс занят:

// Горутина добавляется в очередь ожидания
// Переходит в состояние сна через runtime_SemacquireMutex
// При Unlock() — пробуждается одна из ожидающих горутин

Starvation-режим:

Начиная с Go 1.9, мьютекс имеет starvation-режим. Если горутина ждёт мьютекс дольше 1 мс, мьютекс переключается в starvation-режим, где владение передаётся последней ожидающей горутине (FIFO), а не случайной. Это предотвращает голодание горутин.

// В starvation-режиме:
// Unlock() передаёт мьютекс конкретной горутине из очереди
// Другие горутины не могут «влезть без очереди»

Практический вывод:

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

Вопрос 22. Что такое WaitGroup в Go, какие у неё методы и как работает счётчик внутри.

Таймкод: 00:32:28

Ответ собеседника: Неполный. WaitGroup — примитив синхронизации для ожидания выполнения группы горутин. Метод Add добавляет горутины, Done уменьшает счётчик, Wait блокирует выполнение, пока счётчик не станет нулём. Не знает, как устроен счётчик под капотом.

Правильный ответ:

Что такое WaitGroup:

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

Методы WaitGroup:

type WaitGroup struct {
    // Публичных методов три:
}

func (wg *WaitGroup) Add(delta int)  // увеличить счётчик на delta
func (wg *WaitGroup) Done()          // уменьшить счётчик на 1 (аналог Add(-1))
func (wg *WaitGroup) Wait()          // заблокироваться, пока счётчик != 0

Типичное использование:

func main() {
    var wg sync.WaitGroup

    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Printf("Goroutine %d done\n", id)
        }(i)
    }

    wg.Wait() // блокируется, пока все 5 горутин не вызовут Done()
    fmt.Println("All goroutines finished")
}

Важные правила использования:

// 1. Add() должен быть вызван ДО запуска горутины (в той же горутине, что и Wait)
wg.Add(1)
go func() {
    defer wg.Done()
    // работа
}()

// 2. Done() эквивалентен Add(-1)
wg.Done()
wg.Add(-1) // то же самое

// 3. Счётчик не может стать отрицательным — будет panic
var wg sync.WaitGroup
wg.Done() // panic: negative WaitGroup counter

// 4. Wait() можно вызывать из нескольких горутин — все разблокируются

Внутреннее устройство WaitGroup:

// Из sync/waitgroup.go (упрощённо)
type WaitGroup struct {
    noCopy noCopy          // защита от копирования через vet
    state1 [3]uint32       // state + semaphore
}

Поле state1 хранит два значения в одном 64-битном слове (на 32-битных системах — два 32-битных слова):

┌────────────────────┬────────────────────┐
│   waiter count     │   counter (n)      │
│   (32 бита)        │   (32 бита)        │
│   сколько горутин  │   сколько задач    │
│   ждут в Wait()    │   ещё не завершено │
└────────────────────┴────────────────────┘

На 64-битных системах используется одно 64-битное слово:

type WaitGroup struct {
    noCopy noCopy
    state1 uint64  // старшие 32 бита — waiter count, младшие 32 бита — counter
}

Как работают методы внутри:

Add(delta):

func (wg *WaitGroup) Add(delta int) {
    // Атомарно увеличиваем младшие 32 бита (counter)
    state := atomic.AddUint64(&wg.state1, uint64(delta)<<32)
    counter := int32(state >> 32) // извлекаем счётчик

    if counter < 0 {
        panic("negative WaitGroup counter")
    }

    if counter > 0 && waiters > 0 {
        // Нелогичная ситуация — panic
    }
}

Done():

func (wg *WaitGroup) Done() {
    wg.Add(-1) // просто вызывает Add с -1
}

Wait():

func (wg *WaitGroup) Wait() {
    for {
        state := atomic.LoadUint64(&wg.state1)
        counter := int32(state >> 32)

        if counter == 0 {
            return // все задачи завершены
        }

        // Увеличиваем waiter count и засыпаем на семафоре
        if atomic.CompareAndSwapUint64(&wg.state1, state, state+1) {
            runtime_Semacquire(&wg.sema)
            return
        }
    }
}

Когда последняя горутина вызывает Done() (counter становится 0), она пробуждает все горутины, заблокированные в Wait(), через runtime_Semrelease.

Распространённые ошибки:

// ОШИБКА: Add внутри горутины — гонка с Wait
go func() {
    wg.Add(1) // Wait() может выполниться раньше!
    defer wg.Done()
    // работа
}()
wg.Wait() // может завершиться до того, как Add вызван

// ПРАВИЛЬНО: Add до запуска горутины
wg.Add(1)
go func() {
    defer wg.Done()
    // работа
}()
wg.Wait()

// ОШИБКА: повторное использование WaitGroup до завершения Wait()
var wg sync.WaitGroup
wg.Add(1)
go func() { wg.Done() }()
wg.Wait()

// Попытка использовать снова — может работать некорректно,
// если предыдущий Wait ещё не завершился полностью
wg.Add(1) // Технически допустимо после Wait(), но опасно

WaitGroup vs каналы:

// WaitGroup — для ожидания завершения
var wg sync.WaitGroup
wg.Add(1)
go func() {
    defer wg.Done()
    // работа
}()
wg.Wait()

// Канал — для сигнализации о завершении
done := make(chan struct{})
go func() {
    // работа
    close(done)
}()
<-done

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

Вопрос 23. Что такое пакет atomic в Go и как он работает на уровне процессора.

Таймкод: 00:34:37

Ответ собеседника: Неполный. Пакет atomic работает на уровне процессора. Отправляется команда (например, записи), которая попадает в очередь работы с памятью процессора. Атомарные операции работают быстрее мьютексов. Объяснение было не совсем точным в деталях.

Правильный ответ:

Что такое sync/atomic:

Пакет sync/atomic предоставляет низкоуровневые атомарные операции над целыми числами и указателями. Эти операции выполняются без блокировки (lock-free), используя специальные инструкции процессора.

import "sync/atomic"

var counter int64

atomic.AddInt64(&counter, 1)          // атомарное сложение
atomic.LoadInt64(&counter)            // атомарное чтение
atomic.StoreInt64(&counter, 42)       // атомарная запись
atomic.CompareAndSwapInt64(&counter, old, new) // CAS
atomic.SwapInt64(&counter, new)       // атомарная замена

Какие операции доступны:

Типы	Операции
`int32`, `int64`	Add, Load, Store, Swap, CompareAndSwap
`uint32`, `uint64`, `uintptr`	Add, Load, Store, Swap, CompareAndSwap
`unsafe.Pointer`	Load, Store, Swap, CompareAndSwap
`uint32`, `uint64`	Add (остальные через вышеуказанные)

Как это работает на уровне процессора:

Обычная операция counter++ на уровне процессора состоит из трёх шагов:

Read — загрузить значение из памяти в регистр.
Modify — увеличить значение в регистре.
Write — записать значение обратно в память.

Между шагами 1 и 3 другая горутина может прочитать или записать то же самое значение — это data race.

Атомарные операции используют специальные инструкции процессора, которые выполняют все три шага неделимо:

На x86/x64:

// Обычная операция (не атомарна):
mov eax, [counter]    ; чтение
inc eax               ; увеличение
mov [counter], eax    ; запись

// Атомарная операция:
lock add [counter], 1 ; атомарное сложение

Префикс lock в x86 инструкциях блокирует шину памяти (или использует cache locking) на время выполнения операции, гарантируя, что ни другой ядро, ни другой поток не сможет обратиться к этой ячейке памяти одновременно.

Compare-and-Swap (CAS) — ключевая операция:

CAS — это фундаментальная атомарная операция, на которой строятся многие lock-free алгоритмы:

// Атомарно: если counter == old, установить counter = new
// Вернуть true, если замена произошла
success := atomic.CompareAndSwapInt64(&counter, old, new)

На уровне x86:

// CAS эквивалент:
lock cmpxchg [counter], new
// Сравнивает [counter] с eax (old), если равны — записывает new

Почему atomic быстрее мьютексов:

Mutex:
  1. Проверить состояние мьютекса
  2. Если занят — перейти в очередь ожидания (syscall)
  3. Уснуть (переключение контекста)
  4. При разблокировке — пробудить горутину (syscall)
  5. Переключение контекста обратно
  Итого: ~100-200 нс (с конкуренцией), ~20-30 нс (без)

Atomic:
  1. Одна инструкция процессора с lock-префиксом
  Итого: ~5-15 нс

Практический пример — lock-free счётчик:

type AtomicCounter struct {
    value int64
}

func (c *AtomicCounter) Increment() {
    atomic.AddInt64(&c.value, 1)
}

func (c *AtomicCounter) Get() int64 {
    return atomic.LoadInt64(&c.value)
}

Практический пример — lock-free retry через CAS:

func incrementWithCAS(counter *int64) {
    for {
        old := atomic.LoadInt64(counter)
        new := old + 1
        if atomic.CompareAndSwapInt64(counter, old, new) {
            return // успех
        }
        // CAS не удался — другой поток изменил значение
        // Повторяем с новым old
    }
}

Memory ordering (порядок доступа к памяти):

Атомарные операции в Go гарантируют sequential consistency — самый строгий порядок. Это означает, что все горутины видят атомарные операции в одном и том же порядке.

На уровне процессора это реализуется через memory bарьеры (fences):

Load — гарантирует, что последующие чтения не будут переупорядочены до этого чтения.
Store — гарантирует, что предшествующие записи не будут переупорядочены после этой записи.
CAS — полный барьер: и чтение, и запись.

Ограничения atomic:

Работает только с простыми типами (целые числа, указатели).
Не подходит для сложных структур данных.
Lock-free алгоритмы на CAS сложны в реализации и отладке.
Проблема ABA: значение изменилось с A на B и обратно на A — CAS не заметит изменения.

// Проблема ABA:
// Горутина 1: читает counter = A
// Горутина 2: меняет A → B → A
// Горутина 1: CAS(A, new) — успешен, хотя значение менялось!

Когда использовать atomic vs mutex:

Сценарий	Выбор
Простой счётчик/флаг	`atomic`
Сложная структура данных	`sync.Mutex`
Высокая конкуренция на простой операции	`atomic`
Нужно защитить несколько связанных переменных	`sync.Mutex`

Вопрос 24. Что такое каналы в Go, какие бывают типы каналов и как работают буферизированные и небуферизированные каналы.

Таймкод: 00:36:28

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

Правильный ответ:

Что такое канал:

Канал (channel) — это типизированный канал связи между горутинами, реализующий принцип CSP (Communicating Sequential Processes). Каналы обеспечивают безопасную передачу данных и синхронизацию без явных блокировок.

ch := make(chan int)    // небуферизированный канал
ch := make(chan int, 5) // буферизированный канал (ёмкость 5)

ch <- 42    // отправка в канал
val := <-ch // получение из канала
close(ch)   // закрытие канала

Типы каналов по направлению:

// Двунаправленный (по умолчанию) — можно и читать, и писать
ch := make(chan int)
ch <- 42        // OK
val := <-ch     // OK

// Только для отправки (send-only)
var sendCh chan<- int = ch
sendCh <- 42    // OK
// <-sendCh     // ошибка компиляции

// Только для получения (receive-only)
var recvCh <-chan int = ch
val := <-recvCh // OK
// recvCh <- 42 // ошибка компиляции

Однонаправленные каналы используются в сигнатурах функций для ограничения доступа:

// Функция может только отправлять в канал
func producer(ch chan<- int) {
    for i := 0; i < 10; i++ {
        ch <- i
    }
    close(ch)
}

// Функция может только получать из канала
func consumer(ch <-chan int) {
    for val := range ch {
        fmt.Println(val)
    }
}

Небуферизированные каналы (unbuffered):

Небуферизированный канал имеет ёмкость 0. Операция отправки блокируется, пока другая горутина не выполнит получение, и наоборот. Это создаёт синхронизационную точку (rendezvous).

ch := make(chan int)

// Горутина-отправитель
go func() {
    ch <- 42 // блокируется, пока consumer не прочитает
}()

// Горутина-получатель
val := <-ch // блокируется, пока producer не отправит

Время →
Producer: [send 42]──────[блокировка]──────[разблокировка]
Consumer:                [receive]──────[разблокировка]
                         ↑
                    rendezvous-точка

Буферизированные каналы (buffered):

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

ch := make(chan int, 3) // буфер на 3 элемента

ch <- 1 // не блокируется (буфер: [1])
ch <- 2 // не блокируется (буфер: [1, 2])
ch <- 3 // не блокируется (буфер: [1, 2, 3])
ch <- 4 // БЛОКИРУЕТСЯ — буфер полон

val := <-ch // получили 1, буфер: [2, 3]

Буфер (capacity=3):
┌───┬───┬───┐
│ 1 │ 2 │ 3 │  ← буфер полон, отправка блокируется
└───┴───┴───┘
  ↑
  ← чтение из этой позиции (FIFO)

Внутреннее устройство канала (hchan):

type hchan struct {
    qcount   uint           // количество элементов в буфере
    dataqsiz uint           // размер буровера
    buf      unsafe.Pointer // кольцевой буфер
    sendx    uint           // индекс для следующей отправки
    recvx    uint           // индекс для следующего получения
    recvq    waitq          // очередь ожидающих получателей
    sendq    waitq          // очередь ожидающих отправителей
    mutex    mutex          // мьютекс для защиты структуры
}

Закрытие канала:

ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch) // закрываем канал

// Чтение из закрытого канала — возвращает zero value
val := <-ch // 1
val = <-ch  // 2
val = <-ch  // 0 (zero value для int), канал пуст и закрыт

// Проверка закрытия
val, ok := <-ch // val=0, ok=false

// Итерация по каналу — автоматически завершается при закрытии
for val := range ch {
    fmt.Println(val)
}

Важные правила:

Только отправитель должен закрывать канал — закрытие получателем приведёт к panic.
Запись в закрытый канал — panic.
Закрытие уже закрытого канала — panic.
Чтение из закрытого канала — безопасно, возвращает zero value, затем (0, false).

Select — мультиплексирование каналов:

select {
case v1 := <-ch1:
    fmt.Println("Получено из ch1:", v1)
case v2 := <-ch2:
    fmt.Println("Получено из ch2:", v2)
case ch3 <- 42:
    fmt.Println("Отправлено в ch3")
case <-time.After(5 * time.Second):
    fmt.Println("Таймаут!")
default:
    fmt.Println("Ничего не готово") // неблокирующий вариант
}

select блокируется, пока один из case не станет готов. Если готово несколько — выбирается случайный. default делает select неблокирующим.

Когда что использовать:

Тип канала	Сценарий
Небуферизированный	Синхронизация, гарантия доставки, сигнализация
Буферизированный	Очередь задач, ограничение пропускной способности, batch-обработка
`chan struct{}`	Сигнализация без передачи данных (легковесно)
`close(ch)`	Сигнал завершения для множества горутин (broadcast)

Вопрос 25. Какие бывают типы баз данных, чем реляционные отличаются от нереляционных.

Таймкод: 00:39:01

Ответ собеседника: Неполный. Базы данных бывают реляционные (SQL) и нереляционные (NoSQL). Нереляционные включают документо-ориентированные, колоночные и базы ключ-значение. Не смог привести конкретные примеры СУБД. Ошибочно отнёс Prometheus к базам данных.

Правильный ответ:

Реляционные базы данных (RDBMS):

Реляционные базы данных хранят данные в таблицах с заранее определённой схемой (schema). Таблицы связаны между собой через внешние ключи (foreign keys). Для работы с данными используется язык SQL (Structured Query Language).

Примеры реляционных СУБД:

СУБД	Особенности
PostgreSQL	Открытая, расширяемая, поддерживает JSON, полнотекстовый поиск
MySQL	Открытая, широко распространена, простая в настройке
SQLite	Встраиваемая, файловая, без сервера
Oracle	Корпоративная, высокая производительность
Microsoft SQL Server	Корпоративная, интеграция с экосистемой Microsoft

Ключевые свойства реляционных БД:

ACID-транзакции — Atomicity, Consistency, Isolation, Durability.
Строгая схема — структура данных определена заранее.
Нормализация — минимизация дублирования данных через связи между таблицами.
Мощные запросы — JOIN, подзапросы, агрегации, оконные функции.

-- Пример реляционной модели
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total DECIMAL(10,2),
    created_at TIMESTAMP DEFAULT NOW()
);

-- JOIN для получения данных из связанных таблиц
SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.name;

Нереляционные базы данных (NoSQL):

NoSQL — это широкий класс баз данных, которые не используют реляционную модель. Подразделяются на несколько типов:

1. Документо-ориентированные (Document Stores):

Хранят данные в виде документов (обычно JSON/BSON). Каждый документ может иметь свою структуру (schema-flexible).

СУБД	Особенности
MongoDB	Самая популярная, богатый язык запросов, агрегационные pipeline
CouchDB	Репликация, HTTP API, MVCC
Firestore	Облачная от Google, real-time обновления

// Пример документа в MongoDB
{
    "_id": ObjectId("..."),
    "name": "Иван",
    "email": "ivan@example.com",
    "orders": [
        { "product": "Книга", "price": 500 },
        { "product": "Ручка", "price": 50 }
    ]
}

2. Ключ-значение (Key-Value Stores):

Простейшая модель: каждому ключу соответствует значение. Оптимизированы для быстрого чтения/записи по ключу.

СУБД	Особенности
Redis	In-memory, поддержка структур данных, pub/sub
Memcached	In-memory кэш, простая модель
etcd	Распределённое хранилище, консенсус через Raft
DynamoDB	Облачная от AWS, автоматическое шардирование

# Redis примеры
SET user:1:name "Иван"
GET user:1:name
LPUSH user:1:orders '{"product":"Книга","price":500}'

3. Колоночные (Column-Family Stores):

Данные хранятся по столбцам, а не по строкам. Оптимизированы для аналитических запросов над большими объёмами данных.

СУБД	Особенности
Apache Cassandra	Распределённая, высокая доступность, линейная масштабируемость
HBase	На базе Hadoop, строгая согласованность
ClickHouse	Колоночная СУБД для аналитики в реальном времени
ScyllaDB	Совместима с Cassandra, написана на C++

4. Графовые (Graph Databases):

Хранят данные в виде узлов и рёбер (связей). Оптимизированы для запросов, связанных с обходом графа.

СУБД	Особенности
Neo4j	Самая популярная графовая БД, язык запросов Cypher
Amazon Neptune	Облачная от AWS
ArangoDB	Мультимодельная (документы + графы + ключ-значение)

// Neo4j — найти друзей друзей
MATCH (user:User {name: "Иван"})-[:FRIEND]->(friend)-[:FRIEND]->(fof)
RETURN fof.name

5. Временные ряды (Time-Series Databases):

Оптимизированы для хранения и запросов данных, привязанных ко времени.

СУБД	Особенности
InfluxDB	Высокая производительность записи, язык Flux
TimescaleDB	Расширение PostgreSQL для временных рядов
Prometheus	Мониторинг, метрики, PromQL

Примечание: Prometheus — это система мониторинга, а не база данных в классическом смысле. Он хранит метрики, но не предназначен для произвольных запросов.

Сравнение реляционных и нереляционных БД:

Характеристика	Реляционные	Нереляционные
Схема	Строгая (schema-on-write)	Гибкая (schema-on-read)
Масштабирование	Вертикальное (мощнее сервер)	Горизонтальное (больше серверов)
Транзакции	Полный ACID	Зависит от СУБД (часто eventual consistency)
Запросы	SQL, JOIN, сложная аналитика	Простые запросы по ключу, ограниченные JOIN
Связи между данными	Внешние ключи, JOIN	Денормализация, вложенные документы
Примеры использования	Финансы, ERP, CRM	Кэш, IoT, аналитика в реальном времени

Когда что выбирать:

Реляционные — когда важна целостность данных, сложные запросы с JOIN, транзакции (банковские системы, учётные системы).
Документо-ориентированные — когда структура данных меняется, нужна гибкость (каталоги товаров, контент-менеджмент).
Ключ-значение — когда нужна максимальная скорость доступа по ключу (кэш, сессии).
Колоночные — аналитика больших данных, логи, метрики.
Графовые — социальные сети, рекомендательные системы, обнаружение мошенничества.

Вопрос 26. Какие типы нереляционных баз данных существуют и какие конкретные СУБД можно привести в качестве примеров.

Таймкод: 00:39:28

Ответ собеседника: Неполный. Назвал документо-ориентированные, колоночные и базы ключ-значение. Не смог привести конкретные примеры СУБД для каждого типа (например, MongoDB, Redis, Cassandra и т.д.). Ошибочно отнёс Prometheus к базам данных.

Правильный ответ:

Этот вопрос уже был подробно разобран в предыдущем (вопрос 25). Вот краткая сводка с конкретными примерами СУБД:

Типы NoSQL баз данных и примеры СУБД:

1. Документо-ориентированные:

MongoDB — наиболее популярная, хранит документы в формате BSON, богатый язык запросов, агрегационные pipeline, поддержка индексов и репликации.
CouchDB — HTTP API, MVCC, встроенная репликация между узлами.
Firestore — облачная от Google, real-time подписка на изменения.

2. Ключ-значение:

Redis — in-memory хранилище, поддерживает строки, списки, множества, сортированные множества, хэши. Pub/sub, Lua-скрипты, персистентность.
Memcached — простой in-memory кэш, распределённая архитектура.
etcd — распределённое хранилище конфигурации, консенсус через Raft, используется в Kubernetes.
Amazon DynamoDB — управляемая облачная БД, автоматическое шардирование.

3. Колоночные (Column-Family):

Apache Cassandra — распределённая, высокая доступность, eventual consistency, линейная масштабируемость.
Apache HBase — на базе Hadoop/HDFS, строгая согласованность.
ClickHouse — колоночная аналитическая СУБД, экстремально быстрая агрегация больших объёмов.
ScyllaDB — совместима с Cassandra API, написана на C++, значительно быстрее.

4. Графовые:

Neo4j — лидер среди графовых БД, язык запросов Cypher, транзакции ACID.
Amazon Neptune — управляемая графовая БД от AWS.
ArangoDB — мультимодельная (документы + графы + ключ-значение).

5. Временные ряды (Time-Series):

InfluxDB — оптимизирована для метрик и событий, язык запросов Flux/InfluxQL.
TimescaleDB — расширение PostgreSQL, SQL-интерфейс.
Prometheus — система мониторинга с хранением метрик (PromQL). Это не классическая БД, а именно система мониторинга.

Почему Prometheus — не база данных:

Prometheus — это система мониторинга и алертинга. Он хранит метрики (временные ряды), но:

Не поддерживает произвольные запросы как полноценная БД.
Не предназначен для хранения бизнес-данных.
Имеет ограниченные возможности долгосрочного хранения.
Оптимизирован для pull-модели сбора метрик.

Полная сводная таблица:

Тип	СУБД	Формат данных	Сценарий
Документ	MongoDB	JSON/BSON	Каталоги, CMS, профили
Ключ-значение	Redis	Любой	Кэш, сессии, очереди
Ключ-значение	etcd	Key-Value	Конфигурация, service discovery
Колоночная	Cassandra	Column-Family	Логи, IoT, события
Колоночная	ClickHouse	Column	Аналитика, метрики
Графовая	Neo4j	Nodes + Edges	Соцсети, рекомендации
Time-Series	InfluxDB	Time-series	Мониторинг, метрики

Вопрос 27. Какие SQL базы данных вы знаете и с какими работали.

Таймкод: 00:40:21

Ответ собеседника: Правильный. Работал с MySQL, PostgreSQL и немного с Oracle. Основной опыт — с MySQL и PostgreSQL.

Правильный ответ:

Это вопрос об опыте кандидата, поэтому правильный ответ зависит от реального опыта. Однако стоит знать основные реляционные СУБД и их особенности для полноценного обсуждения.

Основные реляционные СУБД:

PostgreSQL:

Открытая, с самым богатым набором функций среди open-source реляционных БД.
Поддержка JSON/JSONB, полнотекстовый поиск, репликация, партиционирование.
Расширяемость: пользовательские типы, операторы, языки процедур (PL/pgSQL, PL/Python и др.).
Строгое соответствие стандарту SQL.
Хорош для сложных запросов, аналитики, геоданных (PostGIS).

MySQL:

Открытая, самая популярная для веб-приложений.
Простота настройки и использования.
Несколько движков хранения: InnoDB (транзакционный), MyISAM (только чтение).
Широкая экосистема: репликация, шардирование (Vitess), кластеризация (Group Replication).
Используется в WordPress, Facebook, GitHub и многих других проектах.

SQLite:

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

Oracle Database:

Корпоративная, коммерческая.
Высокая производительность, масштабируемость, безопасность.
PL/SQL, RAC (Real Application Clusters), партиционирование.
Дорогая лицензия, используется в крупном бизнесе и госструктурах.

Microsoft SQL Server:

Корпоративная от Microsoft.
T-SQL, интеграция с .NET и Azure.
SSIS, SSRS, SSAS — инструменты ETL, отчётности, аналитики.

MariaDB:

Форк MySQL, созданный основателем MySQL после приобретения Oracle.
Полная совместимость с MySQL, дополнительные движки (ColumnStore, Spider).
Открытая, активно развивается.

Ключевые различия между популярными СУБД:

Характеристика	PostgreSQL	MySQL	SQLite
Лицензия	PostgreSQL License	GPL	Public Domain
Сервер	Да	Да	Нет (встраиваемая)
JSON поддержка	JSONB (индексируемый)	JSON (ограниченный)	Нет
Полнотекстовый поиск	Да	Да (ограниченный)	FTS5 (расширение)
Репликация	Встроенная	Встроенная	Нет
Типичное использование	Сложные приложения, аналитика	Веб-приложения	Мобильные, десктоп, тесты

Что стоит добавить в ответ:

При ответе на этот вопрос полезно упомянуть не только названия СУБД, но и конкретику опыта:

Какие задачи решали (миграции, оптимизация запросов, проектирование схемы).
Какие ORM или драйверы использовали (database/sql, pgx, GORM, sqlx).
Опыт с репликацией, партиционированием, индексами.
Опыт оптимизации медленных запросов (EXPLAIN, профилирование).

Ответ собеседника корректный — он назвал три наиболее распространённые СУБД и обозначил основной опыт.

Вопрос 28. Как можно ускорить чтение из базы данных и какие инструменты помогут найти медленные запросы.

Таймкод: 00:40:45

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

Правильный ответ:

Инструменты для поиска медленных запросов:

1. EXPLAIN и EXPLAIN ANALYZE:

Это основные инструменты для анализа плана выполнения запроса.

-- EXPLAIN — показывает план выполнения без реального выполнения
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';

-- EXPLAIN ANALYZE — выполняет запрос и показывает реальную статистику
EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@example.com';

Вывод EXPLAIN (PostgreSQL):

Seq Scan on users  (cost=0.00..35.50 rows=1 width=72)
  Filter: (email = 'test@example.com'::text)
  Rows Removed by Filter: 9999

Здесь видно, что используется Seq Scan (последовательное сканирование всей таблицы) — это медленно для больших таблиц.

После создания индекса:

Index Scan using idx_users_email on users  (cost=0.29..8.30 rows=1 width=72)
  Index Cond: (email = 'test@example.com'::text)

Теперь используется Index Scan — быстрый поиск по индексу.

Ключевые поля в выводе EXPLAIN ANALYZE:

Поле	Значение
`cost=0.00..35.50`	Оценка стоимости (startup..total)
`rows=1`	Ожидаемое количество строк
`width=72`	Средний размер строки в байтах
`actual time=0.012..0.015`	Реальное время выполнения (после ANALYZE)
`loops=1`	Количество итераций
`Buffers: shared hit=4`	Количество прочитанных блоков из кэша

2. Slow Query Log (журнал медленных запросов):

PostgreSQL:

-- В postgresql.conf
log_min_duration_statement = 100  -- логировать запросы дольше 100 мс

MySQL:

-- В my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.1  -- логировать запросы дольше 100 мс

3. pg_stat_statements (PostgreSQL):

-- Включить расширение
CREATE EXTENSION pg_stat_statements;

-- Топ самых медленных запросов
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

4. SHOW PROCESSLIST (MySQL):

-- Текущие выполняющиеся запросы
SHOW FULL PROCESSLIST;

-- Или через performance_schema
SELECT * FROM performance_schema.events_statements_current
WHERE TIMER_WAIT > 1000000000; -- больше 1 секунды

Способы ускорения чтения:

1. Индексы:

-- B-tree индекс (по умолчанию) — для точного поиска и диапазонов
CREATE INDEX idx_users_email ON users(email);

-- Составной индекс — для запросов с несколькими условиями
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- Частичный индекс — для часто фильтруемых подмножеств
CREATE INDEX idx_active_users ON users(email) WHERE active = true;

-- Покрывающий индекс (covering index) — все нужные поля в индексе
CREATE INDEX idx_users_email_name ON users(email) INCLUDE (name);

Правила использования индексов:

Индекс ускоряет SELECT, но замедляет INSERT, UPDATE, DELETE (нужно обновлять индекс).
Не создавайте индексы на все столбцы — это контрпродуктивно.
Порядок столбцов в составном индексе важен: сначала столбцы с равенством (=), потом с диапазоном (>, <, BETWEEN).
Используйте EXPLAIN для проверки, что индекс действительно используется.

2. Оптимизация запросов:

-- Плохо: SELECT * — читает все столбцы
SELECT * FROM users WHERE email = 'test@example.com';

-- Хорошо: выбираем только нужные столбцы
SELECT id, name FROM users WHERE email = 'test@example.com';

-- Плохо: функция на индексированном столбце — индекс не используется
SELECT * FROM users WHERE LOWER(email) = 'test@example.com';

-- Хорошо: функциональный индекс
CREATE INDEX idx_users_email_lower ON users(LOWER(email));
-- Или хранить нормализованное значение
SELECT * FROM users WHERE email_lower = 'test@example.com';

3. Кэширование:

// Пример: кэширование частых запросов в Redis
func GetUser(db *sql.DB, redis *redis.Client, userID int) (*User, error) {
    // Проверяем кэш
    cached, err := redis.Get(ctx, fmt.Sprintf("user:%d", userID)).Result()
    if err == nil {
        var user User
        json.Unmarshal([]byte(cached), &user)
        return &user, nil
    }

    // Кэш пуст — идём в БД
    user, err := queryUser(db, userID)
    if err != nil {
        return nil, err
    }

    // Сохраняем в кэш
    data, _ := json.Marshal(user)
    redis.Set(ctx, fmt.Sprintf("user:%d", userID), data, 5*time.Minute)
    return user, nil
}

4. Партиционирование (Partitioning):

-- PostgreSQL: партиционирование по дате
CREATE TABLE orders (
    id SERIAL,
    user_id INTEGER,
    created_at TIMESTAMP,
    total DECIMAL(10,2)
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2024_q1 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

CREATE TABLE orders_2024_q2 PARTITION OF orders
    FOR VALUES FROM ('2024-04-01') TO ('2024-07-01');

5. Репликация (Read Replicas):

                    ┌─────────────┐
                    │   Master    │
                    │  (writes)   │
                    └──────┬──────┘
                           │ replication
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Replica 1│ │ Replica 2│ │ Replica 3│
        │ (reads)  │ │ (reads)  │ │ (reads)  │
        └──────────┘ └──────────┘ └──────────┘

6. Денормализация:

-- Вместо JOIN на лету — хранить вычисленное значение
ALTER TABLE orders ADD COLUMN user_name VARCHAR(100);

-- Обновлять через триггер или приложение
-- Запрос без JOIN:
SELECT id, user_name, total FROM orders WHERE user_id = 42;

7. Пул соединений:

// Go: настройка пула соединений
db, _ := sql.Open("postgres", dsn)
db.SetMaxOpenConns(25)        // максимум открытых соединений
db.SetMaxIdleConns(10)        // максимум idle соединений
db.SetConnMaxLifetime(5 * time.Minute) // время жизни соединения

Чек-лист оптимизации:

Найти медленные запросы: slow query log, pg_stat_statements.
Проанализировать план: EXPLAIN ANALYZE.
Добавить/оптимизировать индексы.
Переписать запрос: убрать SELECT *, избавиться от N+1, использовать JOIN вместо подзапросов.
Добавить кэширование (Redis, in-memory).
Рассмотреть партиционирование для больших таблиц.
Настроить реплики для чтения.
Профилировать повторно — убедиться, что изменения помогли.

Вопрос 29. Что такое индекс в базе данных, какие типы индексов существуют в PostgreSQL и какова их скорость поиска.

Таймкод: 00:42:24

Ответ собеседника: Неполный. Индекс — структура данных для быстрого доступа к строкам, скорость поиска O(log N). Назвал B-tree (сбалансированное дерево) и хеш-индексы. Перепутал, сказав что B-tree — бинарное дерево, а не сбалансированное. Не назвал другие типы индексов (GiST, GIN, BRIN).

Правильный ответ:

Что такое индекс:

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

Без индекса СУБД выполняет Seq Scan (последовательное сканирование всей таблицы) — O(N). С индексом — Index Scan — O(log N) или O(1) в зависимости от типа.

Важно: индекс ускоряет SELECT, но замедляет INSERT, UPDATE, DELETE, потому что СУБД должна обновлять и индекс.

Типы индексов в PostgreSQL:

1. B-tree (Balanced Tree) — по умолчанию:

B-tree — это не бинарное дерево, а сбалансированное многопутевое дерево (balanced multi-way tree). Каждый узел может иметь множество потомков (зависит от размера страницы).

          [50]
        /      \
    [20|30]    [70|80]
   / | \      / | \
 [10] [25] [35] [60] [75] [90]

Сложность поиска: O(log N)
Используется для: =, >, <, >=, <=, BETWEEN, IN, LIKE 'prefix%', IS NULL
Порядок сортировки: поддерживает ASC/DESC, NULLS FIRST/NULLS LAST

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_orders_date_desc ON orders(created_at DESC NULLS LAST);

2. Hash-индекс:

Хэш-таблица, которая преобразует значение в числовой хэш и по нему находит строку.

Сложность поиска: O(1) в среднем
Используется только для: =
Не поддерживает: диапазонные запросы (>, <, BETWEEN)
До PostgreSQL 10 не был WAL-логирован (небезопасен), сейчас — безопасен.

CREATE INDEX idx_users_email_hash ON users USING HASH (email);

3. GiST (Generalized Search Tree):

Обобщённое дерево поиска — фреймворк для создания пользовательских индексов на сложных типах данных.

Сложность поиска: O(log N) в среднем
Используется для: геометрических типов (PostGIS), полнотекстовый поиск, range-типы, массивы
Примеры: поиск «ближайших соседей», «пересечение геометрических объектов»

-- Геопространственные данные (PostGIS)
CREATE INDEX idx_locations_geom ON locations USING GIST (geom);

-- Range-типы
CREATE INDEX idx_events_period ON events USING GIST (period);

-- Полнотекстовый поиск (устаревший способ, лучше GIN)
CREATE INDEX idx_articles_tsvector ON articles USING GIST (to_tsvector('english', content));

4. GIN (Generalized Inverted Index):

Инвертированный индекс — хранит для каждого элемента список строк, содержащих этот элемент.

Сложность поиска: O(log N) для поиска ключа + O(K) для извлечения K строк
Используется для: JSONB, массивы, полнотекстовый поиск, составные значения
Медленнее на запись, чем B-tree (нужно обновлять множество записей в индексе)

-- JSONB — самый частый сценарий использования GIN
CREATE INDEX idx_users_data ON users USING GIN (data);

-- Запросы по JSONB используют GIN-индекс:
SELECT * FROM users WHERE data @> '{"role": "admin"}';
SELECT * FROM users WHERE data ? 'phone';

-- Массивы
CREATE INDEX idx_tags ON articles USING GIN (tags);
SELECT * FROM articles WHERE tags @> ARRAY['golang'];

-- Полнотекстовый поиск
CREATE INDEX idx_articles_fts ON articles USING GIN (to_tsvector('english', content));

5. BRIN (Block Range Index):

Индекс диапазонов блоков — хранит минимальное и максимальное значение для диапазона физических блоков таблицы.

Сложность поиска: O(log N) для поиска диапазона + последовательное сканирование подходящих блоков
Размер: очень маленький (в сотни раз меньше B-tree)
Используется для: больших таблиц с физически упорядоченными данными (например, временные ряды, где новые записи добавляются в конец)

-- Таблица логов с 100 млн записей, отсортированная по времени
CREATE INDEX idx_logs_created_at ON logs USING BRIN (created_at)
    WITH (pages_per_range = 32);

-- BRIN-индекс для такой таблицы может быть ~1 МБ вместо ~2 ГБ для B-tree

6. SP-GiST (Space-Partitioned GiST):

Пространственно-разбиваемое дерево — для данных с естественной кластеризацией (IP-адреса, телефонные номера, префиксные деревья).

CREATE INDEX idx_ips ON network_logs USING SP-GiST (ip_address);

Сравнение типов индексов:

Тип	Размер	Скорость поиска	Скорость записи	Основные сценарии
B-tree	Средний	O(log N)	Средняя	Универсальный, по умолчанию
Hash	Средний	O(1)	Средняя	Только точный поиск (=)
GiST	Большой	O(log N)	Медленная	Геоданные, range, полнотекст
GIN	Большой	O(log N + K)	Медленная	JSONB, массивы, полнотекст
BRIN	Очень маленький	O(log N + M)	Быстрая	Большие упорядоченные таблицы
SP-GiST	Средний	O(log N)	Средняя	IP-адреса, префиксные деревья

Когда какой тип выбирать:

-- Обычный поиск по столбцу — B-tree
CREATE INDEX idx_users_email ON users(email);

-- JSONB запросы — GIN
CREATE INDEX idx_doc_data ON documents USING GIN (data);

-- Геопространственные запросы — GiST
CREATE INDEX idx_places_location ON places USING GIN (location);

-- Большая таблица логов по времени — BRIN
CREATE INDEX idx_logs_ts ON logs USING BRIN (created_at);

-- Только точное совпадение — Hash
CREATE INDEX idx_sessions_token ON sessions USING HASH (token);

Составные и частичные индексы:

-- Составной индекс — порядок столбцов важен!
-- Эффективен для WHERE user_id = ? AND created_at > ?
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- НЕ эффективен для WHERE created_at > ? (без user_id)

-- Частичный индекс — только для подмножества строк
CREATE INDEX idx_active_users ON users(email) WHERE active = true;
-- Размер индекса меньше, скорость выше для запросов по активным пользователям

B-tree vs бинарное дерево:

B-tree — это не бинарное дерево. Бинарное дерево имеет максимум 2 потомка на узел. B-tree имеет множество потомков (десятки или сотни) на узел, что уменьшает высоту дерева и количество обращений к диску. Для таблицы в 1 млн строк B-tree высотой 3-4 уровня достаточно, тогда как бинарное дерево потребовало бы ~20 уровней.

Вопрос 30. Почему PostgreSQL по умолчанию использует B-tree, а не хеш-индекс, и зачем нужны разные типы индексов.

Таймкод: 00:44:59

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

Правильный ответ:

Почему B-tree — индекс по умолчанию:

B-tree выбран как тип индекса по умолчанию, потому что он универсален — покрывает подавляющее большинство типичных запросов:

B-tree поддерживает:

-- Точный поиск
SELECT * FROM users WHERE email = 'test@example.com';

-- Диапазонные запросы
SELECT * FROM orders WHERE total BETWEEN 100 AND 500;
SELECT * FROM logs WHERE created_at > '2024-01-01';

-- Сортировка (ORDER BY) — индекс уже отсортирован
SELECT * FROM users ORDER BY created_at DESC LIMIT 10;

-- Префиксный поиск для строк
SELECT * FROM users WHERE name LIKE 'Ivan%';

-- Проверка на NULL
SELECT * FROM users WHERE deleted_at IS NULL;

-- Минимум/максимум — крайние значения в дереве
SELECT MAX(created_at) FROM orders;

Хеш-индекс поддерживает только:

-- Только точное совпадение
SELECT * FROM users WHERE email = 'test@example.com';

-- Диапазонные запросы НЕ поддерживаются:
-- SELECT * FROM orders WHERE total > 100 — хеш не поможет
-- SELECT * FROM users ORDER BY email — хеш не поможет

Сравнение возможностей:

Операция	B-tree	Hash
`=`	✅	✅
`>`, `<`, `>=`, `<=`	✅	❌
`BETWEEN`	✅	❌
`ORDER BY`	✅	❌
`LIKE 'prefix%'`	✅	❌
`MIN()` / `MAX()`	✅	❌
`IS NULL`	✅	❌

Таким образом, B-tree покрывает все сценарии, которые покрывает хеш, плюс множество дополнительных. Хеш-индекс быстрее только для точного поиска (=), но разница на практике невелика.

Историческая причина:

До PostgreSQL 10 (2017) хеш-индексы не были WAL-логированы, то есть после сбоя их нужно было перестраивать вручную (REINDEX). Это делало их небезопасными для production. С PostgreSQL 10 это исправлено, но B-tree по-прежнему остаётся универсальным выбором.

Зачем нужны разные типы индексов:

Разные типы данных и паттерны запросов требуют разных структур данных для эффективного поиска:

B-tree — для скалярных типов с естественным порядком (числа, строки, даты).

Hash — когда нужен только точный поиск и критична каждая наносекунда (редко на практике).

GIN — для составных значений: JSONB, массивы, полнотекстовый поиск. Когда нужно найти строки, содержащие определённый элемент.

-- GIN: найти документы, где JSONB-поле содержит ключ "role" = "admin"
SELECT * FROM users WHERE data @> '{"role": "admin"}';

-- GIN: найти статьи с тегом "golang"
SELECT * FROM articles WHERE tags @> ARRAY['golang'];

-- GIN: полнотекстовый поиск
SELECT * FROM articles WHERE to_tsvector('english', content) @@ to_tsquery('english', 'postgresql & index');

GiST — для пространственных данных, геометрии, range-типов. Когда нужны операции «пересекается с», «содержит», «ближайший сосед».

-- GiST: найти все точки в радиусе 5 км
SELECT * FROM places
WHERE ST_DWithin(geom, ST_MakePoint(37.6173, 55.7558)::geography, 5000);

-- GiST: найти пересекающиеся временные периоды
SELECT * FROM events
WHERE period && '[2024-06-01, 2024-06-30]'::tsrange;

BRIN — для огромных таблиц с физическим порядком данных (логи, метрики). Когда важен маленький размер индекса.

-- BRIN для таблицы из 100 млн записей логов
-- Размер индекса: ~2 МБ вместо ~20 ГБ для B-tree
CREATE INDEX idx_logs_ts ON logs USING BRIN (created_at) WITH (pages_per_range = 32);

SP-GiST — для данных с иерархической структурой (префиксные деревья, IP-адреса, квадродеревья).

Аналогия:

Тип индекса	Аналогия
B-tree	Алфавитный указатель в книге
Hash	Хэш-таблица в программировании
GIN	Инвертированный индекс (как в поисковике)
GiST	Карта с координатами
BRIN	Оглавление глав в книге

Практический вывод:

Для 90% случаев достаточно B-tree.
GIN — если работаете с JSONB или массивами.
GiST — если работаете с геоданными или range-типами.
BRIN — если таблица огромная и данные физически упорядочены.
Hash — редко нужен, B-tree обычно не хуже.

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

Вопрос 31. Какой индекс подойдёт для запроса с условием по диапазону (например, возраст > 30).

Таймкод: 00:46:59

Ответ собеседника: Правильный. Хеш-индекс не поможет для диапазонного запроса, так как потребуется перебор элементов. Для диапазонных запросов лучше подойдёт B-tree (сбалансированное дерево), так как оно поддерживает сортировку.

Правильный ответ:

B-tree — единственный из стандартных индексов PostgreSQL, который эффективно поддерживает диапазонные запросы.

Почему B-tree подходит для диапазонов:

B-tree хранит данные отсортированными. При запросе age > 30 СУБД:

Находит в дереве узел со значением 30 — за O(log N).
Последовательно читает все значения справа — это уже отсортированный диапазон.
По каждому значению находит соответствующую строку в таблице (tid).

-- Создание B-tree индекса
CREATE INDEX idx_users_age ON users(age);

-- Запросы, которые используют этот индекс:
SELECT * FROM users WHERE age > 30;
SELECT * FROM users WHERE age BETWEEN 25 AND 35;
SELECT * FROM users WHERE age >= 30 AND age < 40;
SELECT * FROM users ORDER BY age LIMIT 10; -- индекс уже отсортирован

Почему другие типы не подходят:

Hash — хранит данные без порядка. Запрос age > 30 потребует полного сканирования всех записей хеш-таблицы, что эквивалентно Seq Scan. Хеш работает только для =.
GIN — инвертированный индекс. Для простых скалярных значений не даёт преимущества, а для диапазонов не оптимизирован.
GiST — теоретически поддерживает range-операции, но для простых скалярных типов B-tree обычно быстрее.
BRIN — может помочь для диапазонов, но только если данные физически упорядочены по индексируемому столбцу.

Пример плана выполнения:

EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30;

-- Без индекса:
Seq Scan on users  (cost=0.00..10000.00 rows=50000 width=72)
  Filter: (age > 30)
  Rows Removed by Filter: 50000
  Planning Time: 0.050 ms
  Execution Time: 150.000 ms

-- С B-tree индексом:
Index Scan using idx_users_age on users  (cost=0.29..3500.00 rows=50000 width=72)
  Index Cond: (age > 30)
  Planning Time: 0.080 ms
  Execution Time: 50.000 ms

Важный нюанс:

Индекс используется не всегда. Если планировщик запросов решит, что последовательное сканирование быстрее (например, когда условие выбирает >80% строк), он проигнорирует индекс:

-- Если 90% пользователей старше 30, индекс не используется:
EXPLAIN SELECT * FROM users WHERE age > 5;
-- Seq Scan — планировщик решил, что читать всю таблицу быстрее

Это связано с тем, что Index Scan требует случайных чтений с диска (по каждому tid), а Seq Scan — последовательных, что часто быстрее для больших выборок.

Вопрос 32. Что такое составной индекс, важен ли порядок полей при его создании и как он работает при запросах.

Таймкод: 00:48:28

Ответ собеседника: Неполный. Составной индекс — индекс на несколько полей. Порядок полей имеет значение: составной индекс на (email, age) будет работать при запросе только по email, но не будет работать при запросе только по age. Индекс работает слева направо — сначала сортирует по email, затем внутри одинаковых email сортирует по age.

Правильный ответ:

Что такой составной индекс:

Составной (composite, multi-column) индекс — это индекс, созданный на двух или более столбцах одновременно. Он хранит комбинации значений этих столбцов в отсортированном виде.

CREATE INDEX idx_users_email_age ON users(email, age);

Принцип работы — «слева направо» (leftmost prefix rule):

Составной индекс работает как телефонный справочник: сначала сортируется по фамилии, затем по имени. Вы можете быстро найти всех «Ивановых», но не можете быстро найти всех «Петровых» без знания фамилии.

Индекс (email, age) в виде отсортированного списка:
(a@mail.ru, 25)
(a@mail.ru, 30)
(a@mail.ru, 35)
(b@mail.ru, 20)
(b@mail.ru, 28)
(c@mail.ru, 22)

Какие запросы используют индекс:

-- ✅ Использует индекс полностью (email + age)
SELECT * FROM users WHERE email = 'a@mail.ru' AND age > 30;

-- ✅ Использует индекс частично (только email — leftmost prefix)
SELECT * FROM users WHERE email = 'a@mail.ru';

-- ❌ НЕ использует индекс (age без email — нарушен leftmost prefix)
SELECT * FROM users WHERE age > 30;

-- ✅ Использует индекс для email, затем фильтрует по age
SELECT * FROM users WHERE email = 'a@mail.ru' AND age > 30 AND city = 'Moscow';

Правило leftmost prefix:

Индекс (A, B, C) может быть использован для:

Условие WHERE	Использование индекса
`A = ?`	✅ Полностью (A)
`A = ? AND B = ?`	✅ Полностью (A, B)
`A = ? AND B = ? AND C = ?`	✅ Полностью (A, B, C)
`B = ?`	❌ Не используется
`C = ?`	❌ Не используется
`B = ? AND C = ?`	❌ Не используется
`A = ? AND C = ?`	⚠️ Частично (A), C фильтруется отдельно

Порядок полей — как выбирать:

Правило: сначала столбцы с равенством (=), затем с диапазоном (>, <, BETWEEN).

-- Запрос:
SELECT * FROM orders WHERE user_id = 42 AND created_at > '2024-01-01';

-- Оптимальный индекс: user_id первым (равенство), created_at вторым (диапазон)
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- Плохой порядок: created_at первым
CREATE INDEX idx_orders_date_user ON orders(created_at, user_id);
-- Индекс не поможет эффективно — сначала фильтр по created_at, потом по user_id

Пример с покрывающим индексом (covering index):

-- Индекс включает все нужные столбцы — таблица вообще не читается
CREATE INDEX idx_orders_user_date_total ON orders(user_id, created_at) INCLUDE (total);

-- Index Only Scan — данные берутся только из индекса
SELECT total FROM orders WHERE user_id = 42 AND created_at > '2024-01-01';

Практические рекомендации:

Анализируйте реальные запросы перед созданием составного индекса.
Не создавайте индекс (A, B), если уже есть индекс (A) — он избыточен.
Используйте EXPLAIN ANALYZE для проверки, что индекс действительно используется.
Помните: каждый дополнительный индекс замедляет INSERT, UPDATE, DELETE.

Вопрос 1. Расскажите о себе, чем занимались и чем сейчас занимаетесь, какой опыт работы с Go.​

Вопрос 2. Какие конкретно инструменты вы разрабатываете в веб-студии и как они помогают коллегам.​

Вопрос 3. Какие примитивные (встроенные) типы данных есть в Go.​

Вопрос 4. Чем отличаются различные виды int (int8, int16, int32, int64) в Go и сколько памяти занимает обычный int.​

Вопрос 5. Сколько памяти занимает обычный int в Go и почему.​

Вопрос 6. Что такое unsigned int (uint) в Go, чем он отличается от обычного int и за счёт чего это реализовано.​

Вопрос 7. Что такое строка в Go, из чего она состоит, что такое символ и есть ли тип char в Go.​

Вопрос 8. Почему в Go нельзя просто обращаться к строке по индексу и как это связано с байтами.​

Вопрос 9. Что такое rune в Go и какой тип он представляет.​

Вопрос 10. Что такое слайс в Go, как он устроен и как работает динамическое расширение.​

Вопрос 11. Что произойдёт при взятии среза из середины слайса и добавлении элемента в этот срез.​

Вопрос 12. Что такое map в Go, как работает и всегда ли доступ к элементу по ключу выполняется за константное время O(1).​

Вопрос 13. Как устроена хэш-таблица внутри в Go: что такое бакеты, эвакуация данных и зачем нужна ёмкость бакетов.​

Вопрос 14. Что такое хэш-функция, что такое коллизия в контексте хэширования и какие есть способы разрешения коллизий.​

Вопрос 15. Какие есть способы разрешения коллизий в хэш-таблицах и что такое открытая адресация.​

Вопрос 16. Что такое интерфейс в Go, чем он отличается от интерфейсов в других языках и как он устроен под капотом.​

Вопрос 17. Какие примитивы синхронизации данных существуют в Go и зачем они нужны.​

Вопрос 18. Что такое мьютекс в Go, как с его помощью сделать map потокобезопасной и что происходит при блокировке и разблокировке.​

Вопрос 20. Чем отличается мьютекс (Mutex) от RWMutex в Go.​

Вопрос 21. Как работает планировщик Go: какая горутина первая получит мьютекс и как передаётся владение мьютексом после разблокировки.​

Вопрос 22. Что такое WaitGroup в Go, какие у неё методы и как работает счётчик внутри.​

Вопрос 23. Что такое пакет atomic в Go и как он работает на уровне процессора.​

Вопрос 24. Что такое каналы в Go, какие бывают типы каналов и как работают буферизированные и небуферизированные каналы.​

Вопрос 25. Какие бывают типы баз данных, чем реляционные отличаются от нереляционных.​

Вопрос 26. Какие типы нереляционных баз данных существуют и какие конкретные СУБД можно привести в качестве примеров.​

Вопрос 27. Какие SQL базы данных вы знаете и с какими работали.​

Вопрос 28. Как можно ускорить чтение из базы данных и какие инструменты помогут найти медленные запросы.​

Вопрос 29. Что такое индекс в базе данных, какие типы индексов существуют в PostgreSQL и какова их скорость поиска.​

Вопрос 30. Почему PostgreSQL по умолчанию использует B-tree, а не хеш-индекс, и зачем нужны разные типы индексов.​

Вопрос 31. Какой индекс подойдёт для запроса с условием по диапазону (например, возраст > 30).​

Вопрос 32. Что такое составной индекс, важен ли порядок полей при его создании и как он работает при запросах.​

Вопрос 1. Расскажите о себе, чем занимались и чем сейчас занимаетесь, какой опыт работы с Go.

Вопрос 2. Какие конкретно инструменты вы разрабатываете в веб-студии и как они помогают коллегам.

Вопрос 3. Какие примитивные (встроенные) типы данных есть в Go.

Вопрос 4. Чем отличаются различные виды int (int8, int16, int32, int64) в Go и сколько памяти занимает обычный int.

Вопрос 5. Сколько памяти занимает обычный int в Go и почему.

Вопрос 6. Что такое unsigned int (uint) в Go, чем он отличается от обычного int и за счёт чего это реализовано.

Вопрос 7. Что такое строка в Go, из чего она состоит, что такое символ и есть ли тип char в Go.

Вопрос 8. Почему в Go нельзя просто обращаться к строке по индексу и как это связано с байтами.

Вопрос 9. Что такое rune в Go и какой тип он представляет.

Вопрос 10. Что такое слайс в Go, как он устроен и как работает динамическое расширение.

Вопрос 11. Что произойдёт при взятии среза из середины слайса и добавлении элемента в этот срез.

Вопрос 12. Что такое map в Go, как работает и всегда ли доступ к элементу по ключу выполняется за константное время O(1).

Вопрос 13. Как устроена хэш-таблица внутри в Go: что такое бакеты, эвакуация данных и зачем нужна ёмкость бакетов.

Вопрос 14. Что такое хэш-функция, что такое коллизия в контексте хэширования и какие есть способы разрешения коллизий.

Вопрос 15. Какие есть способы разрешения коллизий в хэш-таблицах и что такое открытая адресация.

Вопрос 16. Что такое интерфейс в Go, чем он отличается от интерфейсов в других языках и как он устроен под капотом.

Вопрос 17. Какие примитивы синхронизации данных существуют в Go и зачем они нужны.

Вопрос 18. Что такое мьютекс в Go, как с его помощью сделать map потокобезопасной и что происходит при блокировке и разблокировке.

Вопрос 20. Чем отличается мьютекс (Mutex) от RWMutex в Go.

Вопрос 21. Как работает планировщик Go: какая горутина первая получит мьютекс и как передаётся владение мьютексом после разблокировки.

Вопрос 22. Что такое WaitGroup в Go, какие у неё методы и как работает счётчик внутри.

Вопрос 23. Что такое пакет atomic в Go и как он работает на уровне процессора.

Вопрос 24. Что такое каналы в Go, какие бывают типы каналов и как работают буферизированные и небуферизированные каналы.

Вопрос 25. Какие бывают типы баз данных, чем реляционные отличаются от нереляционных.

Вопрос 26. Какие типы нереляционных баз данных существуют и какие конкретные СУБД можно привести в качестве примеров.

Вопрос 27. Какие SQL базы данных вы знаете и с какими работали.

Вопрос 28. Как можно ускорить чтение из базы данных и какие инструменты помогут найти медленные запросы.

Вопрос 29. Что такое индекс в базе данных, какие типы индексов существуют в PostgreSQL и какова их скорость поиска.

Вопрос 30. Почему PostgreSQL по умолчанию использует B-tree, а не хеш-индекс, и зачем нужны разные типы индексов.

Вопрос 31. Какой индекс подойдёт для запроса с условием по диапазону (например, возраст > 30).

Вопрос 32. Что такое составной индекс, важен ли порядок полей при его создании и как он работает при запросах.