ℹ️ Какой тип индекса выбрать в PostgreSQL

Индекс — это мощный инструмент для ускорения запросов, но не все они одинаково полезны. В PostgreSQL есть несколько типов индексов, и вот как не промахнуться с выбором:

🔹 B-tree (по умолчанию)

→ Лучший выбор для: =, <, >, BETWEEN, ORDER BY.
→ Поддерживает сортировку.
→ Используется в 90% случаев.

CREATE INDEX idx_users_name ON users(name);

🔹 Hash

→ Только для точного сравнения =.
→ Не поддерживает диапазоны, сортировку, LIKE.
→ Редко используется, но может быть быстрее B-tree на =.

CREATE INDEX idx_users_email_hash ON users USING hash(email);

🔹 GIN (Generalized Inverted Index)

→ Для массивов, jsonb, full-text search.
→ Отличен при поиске по вложенным структурам или множеству значений.

CREATE INDEX idx_data_tags ON posts USING gin(tags);

🔹 GiST (Generalized Search Tree)

→ Для геоданных (PostGIS), поиска по диапазонам, tsvector.
→ Более универсален, но медленнее в некоторых кейсах, чем GIN.

CREATE INDEX idx_events_location ON events USING gist(location);

🔹 BRIN (Block Range Index)

→ Для огромных таблиц, где данные физически упорядочены.
→ Занимает очень мало места.
→ Не всегда эффективен — зависит от корреляции данных.

CREATE INDEX idx_logs_timestamp ON logs USING brin(timestamp);

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

🔍 Магия openssl

Сертификат на проде истёк, а вы узнали от пользователей? openssl s_client покажет всю цепочку сертификатов, даты истечения и проблемы за одну команду.

🔹 Зачем это нужно

— Проверка SSL без браузера: работает на любом сервере через SSH.
— Показывает всю цепочку: leaf, intermediate, root.
— Видны даты: Not Before и Not After и можно настроить алертинг до истечения.

🔹 Как использовать
— Проверить сертификат сайта: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
— Вся цепочка: openssl s_client -connect example.com:443 -showcerts </dev/null
— Subject и issuer: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer
— Проверить локальный файл: openssl x509 -in cert.pem -noout -text
— Дней до истечения: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

ℹ️ Liveness vs Readiness vs Startup: где чаще всего путаются

Три пробы в Kubernetes решают разные задачи, но иногда бывает путаница между ними. Давайте разберемся.

🔹 Liveness — «приложение живое или его пора убить». Зафейлился → под перезапускается. Подходит для дедлоков, зависших потоков, состояний, из которых само не выйдет.

🔹 Readiness — «готово ли принимать трафик прямо сейчас». Зафейлился → под не убивается, просто выпиливается из Service. Вернулся в норму и трафик снова идёт. Это про временную недоступность: упала БД, прогревается кэш, лёг downstream.

🔹 Startup — «приложение ещё стартует». Пока активен startup probe, liveness и readiness отключены. Без него Kubernetes может прибить Spring Boot приложение, которое просто долго поднимается (привет, миграции и прогрев контекста).

Ключевая ошибка: перепутать liveness с readiness. Зафейленный readiness говорит «я живой, но занят не шли мне трафик». Зафейленный liveness — «я сломан, убей и подними заново». Перепутаешь — будешь рестартовать здоровые поды или слать трафик в мёртвые.

В Spring Boot это маппится через health groups:

management:
  endpoint:
    health:
      probes:
        enabled: true
      group:
        liveness:
          include: livenessState
        readiness:
          include: readinessState, db, redis

Если readiness включает проверку БД, под автоматически выпадет из балансировки при обрыве соединения, без единой строчки кастомного кода.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

😮 Топ-вакансий для джавистов за неделю

Java разработчик — удалёнка — CPS.ai

Middle Backend Developer (Kotlin/Java) — удалёнка — ДжазТим

Ведущий разработчик Java — офис (Москва) — МТС Банк

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

⚠️ Self-invocation: почему аннотации иногда просто не срабатывают

@Transactional, @Async, @Cacheable, @Retryable работают через прокси (JDK dynamic proxy на интерфейсах, CGLIB на классах). Аннотация срабатывает, только когда вызов проходит через прокси, то есть приходит снаружи бина.

Вызов соседнего метода через this идёт мимо прокси и аннотация молча игнорируется:

@Service
public class OrderService {

    public void handle() {
        save();             // this.save() — мимо прокси
    }

    @Transactional
    public void save() {    // транзакции здесь НЕ будет
        ...
    }
}

Сюда же: @Transactional на private, final и static методах не работает — CGLIB не может их переопределить.

🔹 Лечится так:

→ вынести метод в отдельный бин (самый чистый вариант);
→ self-injection (инъекция самого себя и вызов через него);
→ ((OrderService) AopContext.currentProxy()).save() (требует exposeProxy = true);
→ TransactionTemplate для программного управления.

Симптом всегда один «аннотация висит, а эффекта нет». Первым делом проверяй, не self-invocation ли это.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

📊 UUID vs автоинкремент в качестве первичного ключа

Спор древний, но решается не вкусовщиной, а тем, кто и когда генерирует ключ.

🔹 Автоинкремент хорош, когда:

— Ключ нужен только внутри одной БД
— Важна плотная индексация и предсказуемый порядок вставки (B-tree счастлив)
— Не страшно, что /users/42 выдаёт размер таблицы наружу

🔹 UUID (а лучше UUIDv7) уместен, когда:

— ID нужно сгенерировать на клиенте/в другом сервисе до записи в БД
— Идёт шардирование или слияние данных из нескольких источников
— Последовательный ID — это утечка бизнес-метрики

⚠️ Частая ловушка

Случайный UUIDv4 как кластерный ключ в InnoDB. Вставки идут вразнобой по индексу → фрагментация страниц, распухание, просадка на записи. Именно поэтому появился UUIDv7, он временно-упорядоченный, ложится в индекс почти как автоинкремент, но остаётся глобально уникальным.

Практичный компромисс: автоинкремент как внутренний PK + UUIDv7 как публичный идентификатор в URL и API. Внутри — быстро, наружу — безопасно.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

✔️ Java-тест: индексация списка в Map

Напишите метод для production-кода 👇

📦 Задание

Реализуйте метод, который строит индекс «email → пользователь»:

public Map<String, User> indexByEmail(List<User> users) {
    // Ваша реализация
}

📋 Требования

— На вход может прийти null или пустой список → вернуть пустую Map.
— В списке встречаются пользователи с одинаковым email → при дубле оставить последнего (и обоснуйте политику).
— email может быть null → такие записи пропускать.
— Порядок итерации сохранять.

Ставьте → 🔥, если нравится формат. Если нет → 🤔

💬 Решения под спойлер. Сравним, какое будет лучше.

🐸 Библиотека собеса по Java

#practise

🔥 Хот-тейк на вечер

Твой Service-слой — это карго-культ, а «доменная модель» — мешок сеттеров- Контроллер → Сервис → Репозиторий, @Entity с голыми полями, вся логика в *ServiceImpl. Знакомо? Поздравляю: ты пишешь процедурный код и уже лет 15 называешь это ООП.

Мартин Фаулер записал anemic domain model в антипаттерны ещё в 2003-м. Поведение должно жить внутри сущности (Rich Model), а не в стопке сервисов, которые дёргают её сеттеры снаружи.

Но стоит затащить бизнес-логику в JPA-сущность и ты женишь домен на Hibernate, ловишь LazyInitializationException где не ждал и молишься на detached-состояния.

Так за кем правда?

Анемичная модель = здоровый прагматизм и чистое разделение слоёв. Или мы просто разучились в ООП и прикрываемся «так исторически сложилось».

Пишите, за кого топите 👇

🐸Библиотека джависта

#DevLife

🔧 Магия kubectl

Под рестартится каждые 5 минут, а kubectl logs показывает только текущий инстанс? Добавьте --previous, и вы увидите логи предыдущего упавшего контейнера — именно там обычно лежит причина крэша.

🔹 Зачем это нужно

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

🔹 Как использовать

— Логи предыдущего контейнера: kubectl logs pod-name --previous
— Конкретный контейнер в мультиконтейнерном поде: kubectl logs pod-name -c sidecar --previous
— Последние 50 строк: kubectl logs pod-name --previous --tail=50
— Следить за логами в реальном времени: kubectl logs -f pod-name
— Логи всех подов деплоймента сразу: kubectl logs deploy/my-app --all-containers

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

⚙️ В чем разница между балансировщиками нагрузки, обратными прокси и API-шлюзами?

1️⃣ Балансировщик нагрузки

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

Он получает запрос, перенаправляет его на сервер, принимает ответ и отправляет его обратно клиенту.

Это увеличивает пропускную способность, снижает задержки и оптимизирует использование ресурсов.

2️⃣ Обратные прокси

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

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

Дополнительно, они могут кэшировать контент для уменьшения нагрузки на сервер, сжимать данные для ускорения передачи и управлять SSL/TLS-шифрованием, разгружая веб-серверы.

3️⃣ API-шлюзы

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

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

Идеально подходят для работы с микросервисной архитектурой.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

🔐 Spring Security: хватит бояться, пора настраивать

Все мы рано или поздно упираемся в Spring Security и обычно это выглядит как «добавил стартер, всё сломалось, ничего не понятно».

В новой статье на Хабре практика с самого нуля:

▪️ поднимаем проект на Spring Boot + PostgreSQL в Docker Compose
▪️ смотрим, что Security делает «из коробки»: дефолтный логин, редиректы, сгенерированный пароль
▪️ пишем свою сущность User с ролями и разбираем каждый метод UserDetails. Зачем нужны isAccountNonLocked, isEnabled и прочие «непонятные» методы
▪️ реализуем UserDetailsService — ту самую точку входа, без которой фреймворк вообще не знает о ваших пользователях

Уровень — простой, время — ~9 минут. Идеально, если только начинаете разбираться в безопасности Spring-приложений или хотите наконец понять, что происходит под капотом.

🔗 Подробнее

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise