🖥 Топ-10 советов по настройке PostgreSQL

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

Вот несколько советов, которые помогут повысить производительность вашей базы данных:

👉 Переходите по ссылке

🔒 Pessimistic vs Optimistic Locking

🔵 Pessimistic Locking

- Запись недоступна для других потоков до тех пор, пока текущий поток не закончит работу с ней.
- Даже чтение данных другими потоками невозможно, пока лок не снят.
- Пример: EntityManager.lock(entity, LockModeType.PESSIMISTIC_WRITE) в JPA.
- Минусы: снижает производительность при высоком уровне конкурентного доступа.
- Когда применять: при критической необходимости точности данных.

🔵 Optimistic Locking

- Не блокирует данные при чтении, но проверяет версию записи при сохранении.
- Пример: аннотация @Version в JPA (колонка для хранения версии).
- Если версия изменена другим потоком, выбрасывается OptimisticLockException.
- Минусы: требует обработки конфликтов.
- Когда применять: при большом количестве чтений и низкой вероятности конфликтов.

💬 Какой подход вы чаще используете в своих проектах?

🏢📊 Как сократить расходы на инфраструктуру в 20 раз: опыт внедрения мультитенантной архитектуры

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

Хотите узнать, как правильно её внедрить, избежать типичных ошибок и достичь впечатляющих результатов? Ознакомьтесь с реальным опытом, который вдохновит на изменения. 🍹

🔗 Читать статью
🔗 Зеркало

❓ Что такое GraphQL?

GraphQL — это язык запросов и среда выполнения для API. Его основная цель — предоставить клиентам возможность запрашивать только те данные, которые действительно нужны, и делать это гибко, без избыточности. Это мощная альтернатива REST API, которая делает взаимодействие между клиентом и сервером более эффективным и удобным.

❗️ Ключевые особенности GraphQL

🔵 Запросы по потребности

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

Пример:

query {
  user(id: "1") {
    name
    email
  }
}

Ответ:

{
  "data": {
    "user": {
      "name": "John Doe",
      "email": "[email protected]"
    }
  }
}

🔵 Единая точка входа (Single Endpoint)

В отличие от REST, где для разных операций используются разные URL (например, /users, /posts), в GraphQL всё взаимодействие происходит через единый эндпоинт, например, /graphql.

🔵 Гибкость и вложенные запросы

Можно запрашивать сложные связанные данные в одном запросе.

Пример:

query {
  user(id: "1") {
    name
    posts {
      title
      comments {
        text
      }
    }
  }
}

Ответ:

{
  "data": {
    "user": {
      "name": "John Doe",
      "posts": [
        {
          "title": "My First Post",
          "comments": [
            { "text": "Great post!" },
            { "text": "Very helpful, thanks!" }
          ]
        }
      ]
    }
  }
}

🔵 Строгая типизация

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

Пример схемы:

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post]
}

type Post {
  id: ID!
  title: String!
  comments: [Comment]
}

type Comment {
  id: ID!
  text: String!
}

🔵 Поддержка мутаций

GraphQL поддерживает не только чтение данных, но и их изменение через мутации.

Пример мутации:

mutation {
  createUser(input: { name: "Jane", email: "[email protected]" }) {
    id
    name
    email
  }
}

Ответ:

{
  "data": {
    "createUser": {
      "id": "2",
      "name": "Jane",
      "email": "[email protected]"
    }
  }
}

🔵 Реактивность через подписки (Subscriptions)

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

Пример:

subscription {
  messageAdded {
    id
    text
  }
}

🔼 Преимущества GraphQL

- Экономия трафика: Возвращает только запрошенные данные.
- Меньше запросов: Вложенные данные можно получить за один запрос.
- Документация встроена в схему: Инструменты вроде GraphiQL позволяют изучать API прямо в процессе разработки.
- Гибкость для клиентов: Клиент управляет структурой ответа.

🔽 Недостатки GraphQL

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

👀 Задачи с собеседований: Проверка, является ли бинарное дерево деревом поиска (middle)

— Как определить, является ли заданное бинарное дерево деревом поиска (BST)?

💡 Ключевые моменты:

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

Реализация с числами в узлах на картинке 👆🏻

🕯 Паттерн Фасад (Facade)

Фасад — это структурный паттерн, который предоставляет унифицированный интерфейс для работы с набором сложных подсистем. Он скрывает сложность системы и упрощает взаимодействие с ней, предоставляя более простой и понятный API для клиента.

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

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

Преимущества:

1️⃣ Упрощает взаимодействие с комплексной системой, предоставляя удобный интерфейс.
2️⃣ Снижает зависимость клиента от конкретных классов подсистем, облегчая поддержку и тестирование.
3️⃣ Уменьшает количество точек взаимодействия с системой, что помогает избежать ошибок и повысить удобство работы.

Недостатки:

1️⃣ Может скрывать избыточную функциональность, ограничивая возможности системы.
2️⃣ Увеличивает количество кода за счёт добавления нового фасадного класса.
3️⃣ Если фасад слишком абстрактен, может стать сложным для понимания и поддержки.

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

🖥 Освежите свои знания о CompletableFuture

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

🔗 Читать статью

ℹ️ Ключевое слово volatile

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

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

Когда использовать volatile?
- Когда переменная должна быть доступна для записи и чтения несколькими потоками, но нет необходимости в сложной синхронизации (например, для флагов, флагов завершения, индикаторов состояний).
- В случаях, когда нужно просто гарантировать видимость изменений, но не требуется атомарность или операции с несколькими шагами (для этих случаев лучше использовать synchronized или java.util.concurrent).

Пример:

public class VolatileExample {
    private static volatile boolean flag = false; 

    public static void main(String[] args) throws InterruptedException {
        Thread writer = new Thread(() -> {
            try {
                Thread.sleep(1000); // эмулируем задержку
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            flag = true; 
            System.out.println("Flag set to true");
        });

        Thread reader = new Thread(() -> {
            while (!flag) { 
            }
            System.out.println("Flag is now true");
        });

        writer.start();
        reader.start();

        writer.join();
        reader.join();
    }
}

ℹ️ Что такое "Проблема бриллианта" (Diamond Problem)?

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

В Java множественное наследование классов не поддерживается, но проблема все равно может возникнуть при использовании интерфейсов.

interface A {
    void method();
}

interface B extends A {
    @Override
    default void method() {
        System.out.println("Method from B");
    }
}

interface C extends A {
    @Override
    default void method() {
        System.out.println("Method from C");
    }
}

class D implements B, C { }

public class Main {
    public static void main(String[] args) {
        D d = new D();
        d.method();  // Какая версия метода будет вызвана?
    }
}

📌 В чем суть проблемы?

Когда класс D реализует оба интерфейса B и C, которые оба предоставляют дефолтные реализации метода method(), возникает неопределенность — какую версию метода должен использовать класс D? При компиляции будет выброшен error: class D inherits unrelated defaults for method() from types B and C.

Это решается с помощью явного переопределения метода в классе D, что позволяет избежать конфликтов.

class D implements B, C {
    @Override
    public void method() {
        B.super.method();
        // или можно использовать C.super.method(), если хотите вызвать метод из C
    }
}