Вопросы о версионировании API
Мы часто видим номера версий в сторонних API, но не задумываемся о внутренней кухне версионирования: как делать и для чего? Рассмотрим best practice.
❓Когда версионировать API?
API нуждается в версионировании, когда происходят значительные изменения, влияющие на поведение или контракт API:
- Добавляются новые обязательные поля.
- Меняется формат возвращаемых данных.
- Удаляются старые свойства или изменяется логика работы API.
- Изменяется семантика методов (например, ранее GET запрашивал список объектов, теперь возвращается агрегационная статистика).
🔑 Способы версионирования REST API
Существует несколько популярных способов версионирования API:
☝️ Версификация через URL
Один из самых распространённых способов — включение номера версии непосредственно в URL. Например:
Преимущества:
- Простота реализации.
- Легко различимые версии API.
Недостатки:
- Нарушает чистоту концепции REST, поскольку URI должны идентифицировать ресурс, а не его версию.
- Могут возникать сложности при изменении URL структуры (например, смена префикса или удаление старого маршрута).
✌️ Версификация через заголовок HTTP
Альтернативный вариант — размещение версии API в специальном заголовке HTTP, например:
или
Преимущества:
- Более чистое решение с точки зрения REST.
- Сохраняет единство ресурсов и независимость от URL.
Недостатки:
- Требуется дополнительная настройка обработчиков заголовков на стороне сервера.
- Клиенты должны помнить о необходимости отправки правильного заголовка.
🤟 Версификация через Content Type
Можно указывать версию API в MIME-типе, например:
Преимущества:
- Четкое разделение ресурсов и версий.
- Может сочетаться с Content Negotiation.
Недостатки:
- Сложность понимания пользователями, привыкшими видеть номер версии в URL.
- Необходимость поддерживать обработку нескольких Content Types.
💣 Лучшие практики версионирования REST API
1. Обеспечьте обратную совместимость. Всегда старайтесь минимизировать влияние изменений на существующие клиенты. Постепенный переход на новую версию API позволит снизить риски отказа сторонних систем.
2. Четкая документация каждой версии. Каждый релиз новой версии API должен сопровождаться подробной документацией с описанием всех изменений и возможных последствий для клиентов.
3. Ограничьте число активных версий. Со временем устаревшие версии API стоит удалять, уведомив заранее клиентов о сроках прекращения поддержки старых версий.
4. Используйте фазовый вывод старой версии. Постепенно отключайте старую версию API, давая достаточное время для миграции клиентов на новую версию.
5. Тестируйте каждую версию отдельно. Перед выпуском новых версий убедитесь, что старая версия продолжает стабильно функционировать.
6. Создавайте тесты на совместимость. Регулярные проверки API позволят выявить возможные регрессии и убедиться, что новая версия API не ломает старый код.
🪧 Итог 🪧
Выбор способа версионирования зависит от конкретной ситуации и требований проекта. Наиболее распространённый подход — версионирование через URL, однако он имеет ряд недостатков с точки зрения чистоты REST. Альтернатива в виде версионирования через заголовки или Content Type предоставляет больше гибкости и соответствует идеям RESTful дизайна. Независимо от выбранного подхода, ключевое значение имеют продуманность изменений, хорошая документация и обеспечение постепенного вывода старых версий API.
Мы часто видим номера версий в сторонних API, но не задумываемся о внутренней кухне версионирования: как делать и для чего? Рассмотрим best practice.
❓Когда версионировать API?
API нуждается в версионировании, когда происходят значительные изменения, влияющие на поведение или контракт API:
- Добавляются новые обязательные поля.
- Меняется формат возвращаемых данных.
- Удаляются старые свойства или изменяется логика работы API.
- Изменяется семантика методов (например, ранее GET запрашивал список объектов, теперь возвращается агрегационная статистика).
🔑 Способы версионирования REST API
Существует несколько популярных способов версионирования API:
☝️ Версификация через URL
Один из самых распространённых способов — включение номера версии непосредственно в URL. Например:
GET /api/v1/products
GET /api/v2/products
Преимущества:
- Простота реализации.
- Легко различимые версии API.
Недостатки:
- Нарушает чистоту концепции REST, поскольку URI должны идентифицировать ресурс, а не его версию.
- Могут возникать сложности при изменении URL структуры (например, смена префикса или удаление старого маршрута).
✌️ Версификация через заголовок HTTP
Альтернативный вариант — размещение версии API в специальном заголовке HTTP, например:
Accept: application/vnd.mycompany.v1+json
Content-Type: application/json
или
X-Api-Version: v2
Преимущества:
- Более чистое решение с точки зрения REST.
- Сохраняет единство ресурсов и независимость от URL.
Недостатки:
- Требуется дополнительная настройка обработчиков заголовков на стороне сервера.
- Клиенты должны помнить о необходимости отправки правильного заголовка.
🤟 Версификация через Content Type
Можно указывать версию API в MIME-типе, например:
Accept: application/vnd.mycompany.products-v1+json
Преимущества:
- Четкое разделение ресурсов и версий.
- Может сочетаться с Content Negotiation.
Недостатки:
- Сложность понимания пользователями, привыкшими видеть номер версии в URL.
- Необходимость поддерживать обработку нескольких Content Types.
💣 Лучшие практики версионирования REST API
1. Обеспечьте обратную совместимость. Всегда старайтесь минимизировать влияние изменений на существующие клиенты. Постепенный переход на новую версию API позволит снизить риски отказа сторонних систем.
2. Четкая документация каждой версии. Каждый релиз новой версии API должен сопровождаться подробной документацией с описанием всех изменений и возможных последствий для клиентов.
3. Ограничьте число активных версий. Со временем устаревшие версии API стоит удалять, уведомив заранее клиентов о сроках прекращения поддержки старых версий.
4. Используйте фазовый вывод старой версии. Постепенно отключайте старую версию API, давая достаточное время для миграции клиентов на новую версию.
5. Тестируйте каждую версию отдельно. Перед выпуском новых версий убедитесь, что старая версия продолжает стабильно функционировать.
6. Создавайте тесты на совместимость. Регулярные проверки API позволят выявить возможные регрессии и убедиться, что новая версия API не ломает старый код.
🪧 Итог 🪧
Выбор способа версионирования зависит от конкретной ситуации и требований проекта. Наиболее распространённый подход — версионирование через URL, однако он имеет ряд недостатков с точки зрения чистоты REST. Альтернатива в виде версионирования через заголовки или Content Type предоставляет больше гибкости и соответствует идеям RESTful дизайна. Независимо от выбранного подхода, ключевое значение имеют продуманность изменений, хорошая документация и обеспечение постепенного вывода старых версий API.
Как правильно составлять путь к ресурсу?
Большинство знает эти правила на интуитивном уровне, но не лишним будет структурировать эти знания
Ресурс в RESTful API представляет собой сущность, с которой взаимодействуют клиенты. Примеры ресурсов включают пользователей (users), заказы (orders) и товары (products).
Основные правила
〰️ Используйте существительные: Путь к ресурсу должен быть представлен существительным в единственном числе. Это подчеркивает, что ресурс идентифицируется уникальным образом
〰️ Используйте понятные имена каталогов и файлов. Избегайте длинных сложных имен, предпочтительнее короткие и информативные названия.
〰️ Идентификация конкретного экземпляра ресурса: Если вы хотите обратиться к конкретному элементу ресурса, используйте уникальный идентификатор после слэша.
/users/{id}
/orders/{order_id}
〰️ Вложенность ресурсов. Если ресурсы имеют иерархию, отражайте её в пути. Например, заказы принадлежат пользователям, поэтому заказ можно вложить в пользователя:
/users/{user_id}/orders
🧮 Если нужно обратиться к коллекции ресурсов
Когда вам нужно оперировать коллекциями ресурсов, используйте множественное число:
/users
/products
Рекомендации
🧲 Стремитесь сохранять единообразие в именовании и структуре путей. Если один ресурс использует определённый шаблон, старайтесь применять этот шаблон ко всем другим ресурсам.
🧲 Минимизируйте количество уровней вложенности: Чем короче путь, тем проще ориентироваться посетителям и быстрее индексироваться поисковиками.
🧲 Следите за согласованностью стилей: Старайтесь избегать использования транслита или кириллицы там, где возможны проблемы совместимости.
А вот какие правила существуют для именования операций над ресурсами, которые выходят за рамки обычных CRUD-операций, расскажу в следующий раз.
Большинство знает эти правила на интуитивном уровне, но не лишним будет структурировать эти знания
Ресурс в RESTful API представляет собой сущность, с которой взаимодействуют клиенты. Примеры ресурсов включают пользователей (users), заказы (orders) и товары (products).
Основные правила
〰️ Используйте существительные: Путь к ресурсу должен быть представлен существительным в единственном числе. Это подчеркивает, что ресурс идентифицируется уникальным образом
〰️ Используйте понятные имена каталогов и файлов. Избегайте длинных сложных имен, предпочтительнее короткие и информативные названия.
〰️ Идентификация конкретного экземпляра ресурса: Если вы хотите обратиться к конкретному элементу ресурса, используйте уникальный идентификатор после слэша.
/users/{id}
/orders/{order_id}
〰️ Вложенность ресурсов. Если ресурсы имеют иерархию, отражайте её в пути. Например, заказы принадлежат пользователям, поэтому заказ можно вложить в пользователя:
/users/{user_id}/orders
🧮 Если нужно обратиться к коллекции ресурсов
Когда вам нужно оперировать коллекциями ресурсов, используйте множественное число:
/users
/products
Рекомендации
🧲 Стремитесь сохранять единообразие в именовании и структуре путей. Если один ресурс использует определённый шаблон, старайтесь применять этот шаблон ко всем другим ресурсам.
🧲 Минимизируйте количество уровней вложенности: Чем короче путь, тем проще ориентироваться посетителям и быстрее индексироваться поисковиками.
🧲 Следите за согласованностью стилей: Старайтесь избегать использования транслита или кириллицы там, где возможны проблемы совместимости.
А вот какие правила существуют для именования операций над ресурсами, которые выходят за рамки обычных CRUD-операций, расскажу в следующий раз.
Как составить путь, если действие над ресурсом ВНЕ рамок REST?
Уверена, что любой аналитик хотя бы раз задумывался над формированием пути для метода, который делает что-то кроме обычного CRUD. В моей практике CRUD встречается реже, чем действие над ресурсом. Сейчас расскажу, какие фишки я использую.
🏓 Использование дополнительных суффиксов
Если вам действительно нужно указать действие, можно добавить дополнительные суффиксы к пути. Такие подходы считаются менее предпочтительными, поскольку они нарушают чистоту REST подхода, но мы с вами бойцы системного фронта, а не блюстители чистоты REST’a, правда?
🥎 Действия в виде глаголов (да, за это не будут бить, я узнавала)
Пример - Отправка уведомления пользователю
POST /users/{user_id}/send_notification
🥎 Конкретные операции:
Операции, которые нельзя однозначно отнести к стандартным методам HTTP, можно выразить через суффиксы.
Пример - Запуск процесса обработки заказа
POST /orders/{order_id}/process
🏓 Использовать другие методы
Некоторые API предпочитают использовать специальные методы, такие как RPC (Remote Procedure Call), которые позволяют описывать конкретные действия. В таком случае можно использовать префиксы или отдельные маршруты для каждого метода.
Запуск оплаты может выглядеть так:
POST /payments/initiate_payment
Внешне как и REST, но под капотом.....
Было интересно? Узнали что-то новое?
Уверена, что любой аналитик хотя бы раз задумывался над формированием пути для метода, который делает что-то кроме обычного CRUD. В моей практике CRUD встречается реже, чем действие над ресурсом. Сейчас расскажу, какие фишки я использую.
🏓 Использование дополнительных суффиксов
Если вам действительно нужно указать действие, можно добавить дополнительные суффиксы к пути. Такие подходы считаются менее предпочтительными, поскольку они нарушают чистоту REST подхода, но мы с вами бойцы системного фронта, а не блюстители чистоты REST’a, правда?
🥎 Действия в виде глаголов (да, за это не будут бить, я узнавала)
Пример - Отправка уведомления пользователю
POST /users/{user_id}/send_notification
🥎 Конкретные операции:
Операции, которые нельзя однозначно отнести к стандартным методам HTTP, можно выразить через суффиксы.
Пример - Запуск процесса обработки заказа
POST /orders/{order_id}/process
🏓 Использовать другие методы
Некоторые API предпочитают использовать специальные методы, такие как RPC (Remote Procedure Call), которые позволяют описывать конкретные действия. В таком случае можно использовать префиксы или отдельные маршруты для каждого метода.
Запуск оплаты может выглядеть так:
POST /payments/initiate_payment
Внешне как и REST, но под капотом.....
Было интересно? Узнали что-то новое?
🌫 Мифы про REST 🌫
Вы много знаете про REST, но уверены ли вы, что все ваши представления о нем - правда? Рассмотрим самые популярные мифы про REST!
🍋 Любой HTTP-сервис — это REST API
Заблуждение: Многие считают, что если API общается по HTTP-протоколу, значит оно соответствует принципам REST.
Реальность: Просто использование HTTP не означает соблюдение принципов REST. Для того чтобы API было RESTful, оно должно соответствовать следующим критериям:
- Ресурсно-ориентированная структура.
- Использование методов HTTP соответствующим образом (GET, POST, PUT, DELETE и др.).
- Отсутствие состояния на стороне сервера (stateless).
- Кэшируемость результатов запросов.
- Наличие единой точки входа (uniform interface).
Многие API нарушают хотя бы одно из этих правил, несмотря на применение HTTP.
🍊 Только GET-запросы должны возвращать состояние клиента
Заблуждение: Некоторые полагают, что методы HTTP такие как GET предназначены исключительно для чтения данных, а остальные методы (POST, PUT, DELETE) нужны лишь для изменения данных.
Реальность: Любые запросы в RESTful API могут возвращать полезные данные клиенту независимо от метода. Даже запросы POST, PUT или DELETE могут вернуть статус операции, обновленные данные или другой полезный отклик.
🍐 REST API обязательно возвращает JSON
Заблуждение: Часто встречается мнение, что REST API всегда передаёт данные в формате JSON.
Реальность: REST предполагает гибкость форматов данных. API может отвечать XML, YAML, protobuf или даже двоичными файлами, главное — соблюдать принципы REST.
🍓 Каждая сущность должна иметь уникальный URI
Заблуждение: Считается, что каждый объект в системе обязан иметь собственный URL.
Реальность: По сути, REST допускает создание составных сущностей, агрегированных ресурсов и множественных связей. Главное правило — обеспечить прозрачность и единообразие организации маршрутов.
🫐 PUT-запросы заменяют весь ресурс целиком
Заблуждение: Есть заблуждение, что метод PUT предназначен только для полной замены существующего ресурса.
Реальность: PUT может использоваться как для обновления всего ресурса, так и для частичного обновления полей. Важнее сохранять консистентность состояния ресурса и следовать семантике PUT: повторный вызов одного и того же PUT-запроса не должен приводить к изменениям (idempotence).
🍑 Все ресурсы должны находиться на одном уровне
Заблуждение: Иногда считают, что ресурсы должны располагаться на одном уровне иерархии (например,
Реальность: Группировка ресурсов и вложенность вполне допустимы в REST, если они соответствуют бизнес-логике и делают структуру ясной и интуитивной.
🔚
Рассказывайте, у кого совпало?)
Вы много знаете про REST, но уверены ли вы, что все ваши представления о нем - правда? Рассмотрим самые популярные мифы про REST!
🍋 Любой HTTP-сервис — это REST API
Заблуждение: Многие считают, что если API общается по HTTP-протоколу, значит оно соответствует принципам REST.
Реальность: Просто использование HTTP не означает соблюдение принципов REST. Для того чтобы API было RESTful, оно должно соответствовать следующим критериям:
- Ресурсно-ориентированная структура.
- Использование методов HTTP соответствующим образом (GET, POST, PUT, DELETE и др.).
- Отсутствие состояния на стороне сервера (stateless).
- Кэшируемость результатов запросов.
- Наличие единой точки входа (uniform interface).
Многие API нарушают хотя бы одно из этих правил, несмотря на применение HTTP.
🍊 Только GET-запросы должны возвращать состояние клиента
Заблуждение: Некоторые полагают, что методы HTTP такие как GET предназначены исключительно для чтения данных, а остальные методы (POST, PUT, DELETE) нужны лишь для изменения данных.
Реальность: Любые запросы в RESTful API могут возвращать полезные данные клиенту независимо от метода. Даже запросы POST, PUT или DELETE могут вернуть статус операции, обновленные данные или другой полезный отклик.
🍐 REST API обязательно возвращает JSON
Заблуждение: Часто встречается мнение, что REST API всегда передаёт данные в формате JSON.
Реальность: REST предполагает гибкость форматов данных. API может отвечать XML, YAML, protobuf или даже двоичными файлами, главное — соблюдать принципы REST.
🍓 Каждая сущность должна иметь уникальный URI
Заблуждение: Считается, что каждый объект в системе обязан иметь собственный URL.
Реальность: По сути, REST допускает создание составных сущностей, агрегированных ресурсов и множественных связей. Главное правило — обеспечить прозрачность и единообразие организации маршрутов.
🫐 PUT-запросы заменяют весь ресурс целиком
Заблуждение: Есть заблуждение, что метод PUT предназначен только для полной замены существующего ресурса.
Реальность: PUT может использоваться как для обновления всего ресурса, так и для частичного обновления полей. Важнее сохранять консистентность состояния ресурса и следовать семантике PUT: повторный вызов одного и того же PUT-запроса не должен приводить к изменениям (idempotence).
🍑 Все ресурсы должны находиться на одном уровне
Заблуждение: Иногда считают, что ресурсы должны располагаться на одном уровне иерархии (например,
/users, /products), и нельзя создавать вложенность вроде /users/{id}/orders.Реальность: Группировка ресурсов и вложенность вполне допустимы в REST, если они соответствуют бизнес-логике и делают структуру ясной и интуитивной.
🔚
Рассказывайте, у кого совпало?)
👍1
Про gRPC
В одном из недавних постов я упоминала RPC и получила вопросы про него:
Зачем он нужен, если есть REST и SOAP? Что нового он может предложить? а, оказалось, может. Смотрим.
Основные особенности gRPC
🔸 Протокол обмена данными
gRPC построен поверх HTTP/2 — современного протокола, поддерживающего мультиплексирование запросов и потоковую передачу данных. Именно благодаря использованию HTTP/2 gRPC значительно повышает производительность приложений по сравнению с традиционными REST API на HTTP/1.x.
🔸 Формат сообщений
Для описания интерфейсов сервисов и структур данных в gRPC применяется язык определения интерфейсов IDL (Interface Definition Language) на основе формата Protobuf. Protobuf предлагает компактность представления данных и высокую скорость сериализации/десериализации.
🔸 Подход к дизайну API
gRPC позволяет разработчикам определять контракты (интерфейсы) сервиса и типов передаваемых данных декларативно в файлах
🔸 Поддержка двунаправленной связи
gRPC поддерживает четыре основных режима взаимодействия:
- Unary RPC: один запрос → один ответ.
- Server streaming: один запрос → поток ответов.
- Client streaming: поток запросов → один ответ.
- Bidirectional streaming: потоки запросов и ответов одновременно.
Это делает gRPC идеальным решением для реализации реактивных архитектур и построения микросервисов с минимальной задержкой и высокой производительностью.
👁🗨 Зачем использовать gRPC?
1. Производительность. Благодаря компактному формату Protobuf и эффективному протоколу HTTP/2, gRPC показывает лучшую производительность по сравнению с JSON-REST решениями.
2. Строгая схема данных. Определение интерфейсов и схем гарантирует, что клиенты и сервер будут взаимодействовать ожидаемым образом.
3. Типизация данных. Protobuf обеспечивает строгую проверку типов, минимизирует возможность ошибок в процессе разработки.
4. Универсальность клиентов. Генерация клиентских библиотек для разных языков программирования облегчает интеграцию гетерогенных систем.
5. Потоковая передача данных. Возможность передавать данные последовательно (streaming), позволяя обрабатывать большие объёмы данных без блокировки системы ожидания полного завершения обработки.
6. Масштабируемость. gRPC хорошо подходит для микросервисных архитектур, обеспечивая лёгкую интеграцию и масштабирование компонентов приложения.
🔝 Почему не использовать REST?
REST отлично подходит для простых сценариев CRUD (создание/чтение/обновление/удаление) и архитектуры на основе ресурсов. Однако, если приложение требует более производительной передачи данных, поддержки двусторонних потоков, интеграции разнородных технологий и четкого контроля типов данных, gRPC становится лучшим выбором.
Кроме того, некоторые современные облачные сервисы и инструменты уже активно поддерживают gRPC, предоставляя дополнительные возможности для мониторинга, трассировки и безопасности (например, Istio, Envoy Proxy).
🔳 Итоги
gRPC будет выигрывать при работе с большими объемами данных и более требовательными сервисами, где важна поддержка потоковых операций и строгие типы данных.
В одном из недавних постов я упоминала RPC и получила вопросы про него:
Зачем он нужен, если есть REST и SOAP? Что нового он может предложить? а, оказалось, может. Смотрим.
Основные особенности gRPC
🔸 Протокол обмена данными
gRPC построен поверх HTTP/2 — современного протокола, поддерживающего мультиплексирование запросов и потоковую передачу данных. Именно благодаря использованию HTTP/2 gRPC значительно повышает производительность приложений по сравнению с традиционными REST API на HTTP/1.x.
🔸 Формат сообщений
Для описания интерфейсов сервисов и структур данных в gRPC применяется язык определения интерфейсов IDL (Interface Definition Language) на основе формата Protobuf. Protobuf предлагает компактность представления данных и высокую скорость сериализации/десериализации.
🔸 Подход к дизайну API
gRPC позволяет разработчикам определять контракты (интерфейсы) сервиса и типов передаваемых данных декларативно в файлах
.proto. Затем генерируются клиентские библиотеки для различных платформ и языков программирования, обеспечивая строгий контроль над интерфейсами и типы данных.🔸 Поддержка двунаправленной связи
gRPC поддерживает четыре основных режима взаимодействия:
- Unary RPC: один запрос → один ответ.
- Server streaming: один запрос → поток ответов.
- Client streaming: поток запросов → один ответ.
- Bidirectional streaming: потоки запросов и ответов одновременно.
Это делает gRPC идеальным решением для реализации реактивных архитектур и построения микросервисов с минимальной задержкой и высокой производительностью.
👁🗨 Зачем использовать gRPC?
1. Производительность. Благодаря компактному формату Protobuf и эффективному протоколу HTTP/2, gRPC показывает лучшую производительность по сравнению с JSON-REST решениями.
2. Строгая схема данных. Определение интерфейсов и схем гарантирует, что клиенты и сервер будут взаимодействовать ожидаемым образом.
3. Типизация данных. Protobuf обеспечивает строгую проверку типов, минимизирует возможность ошибок в процессе разработки.
4. Универсальность клиентов. Генерация клиентских библиотек для разных языков программирования облегчает интеграцию гетерогенных систем.
5. Потоковая передача данных. Возможность передавать данные последовательно (streaming), позволяя обрабатывать большие объёмы данных без блокировки системы ожидания полного завершения обработки.
6. Масштабируемость. gRPC хорошо подходит для микросервисных архитектур, обеспечивая лёгкую интеграцию и масштабирование компонентов приложения.
🔝 Почему не использовать REST?
REST отлично подходит для простых сценариев CRUD (создание/чтение/обновление/удаление) и архитектуры на основе ресурсов. Однако, если приложение требует более производительной передачи данных, поддержки двусторонних потоков, интеграции разнородных технологий и четкого контроля типов данных, gRPC становится лучшим выбором.
Кроме того, некоторые современные облачные сервисы и инструменты уже активно поддерживают gRPC, предоставляя дополнительные возможности для мониторинга, трассировки и безопасности (например, Istio, Envoy Proxy).
🔳 Итоги
gRPC будет выигрывать при работе с большими объемами данных и более требовательными сервисами, где важна поддержка потоковых операций и строгие типы данных.
👍2
gRPC vs REST
Это все, конечно, хорошо. Но давайте кратко и емко про разницу gRPC и REST и про ситуации их применения.
🎈Когда использовать gRPC?
1. Микросервисная архитектура: Если у вас есть система, состоящая из множества сервисов, взаимодействующих друг с другом, gRPC поможет обеспечить быструю и надёжную коммуникацию между ними.
2. Двунаправленная связь: Например, вам нужно создать приложение, которое должно получать обновления в режиме реального времени (например, мониторинг состояния сервера). gRPC с потоковыми запросами отлично справляется с такими задачами.
3. Передача больших объёмов данных: Благодаря использованию Protobuf, gRPC эффективно обрабатывает большие массивы данных, минимизируя накладные расходы на сериализацию и десериализацию.
4. Мобильные приложения: gRPC хорошо интегрируется с мобильными приложениями благодаря своей эффективности и поддержке различных платформ.
🎈 Отличия от REST
1. Протокол:
- REST использует HTTP/1.1, который ориентирован на передачу текста и часто включает заголовки и метаданные.
- gRPC использует HTTP/2, который поддерживает двоичные потоки данных, мультиплексирование запросов и улучшенную компрессию.
2. Формат данных:
- REST чаще всего передаёт данные в формате JSON или XML.
- gRPC использует Protobuf — компактный бинарный формат, который значительно уменьшает размер передаваемых данных.
3. Тип взаимодействия:
- REST обычно ограничивается запросами и ответами типа «запрос–ответ».
- gRPC поддерживает различные типы взаимодействия: односторонние запросы, двусторонний поток данных, клиентские потоки и серверные потоки.
4. Производительность:
- gRPC обычно быстрее и эффективнее, особенно при передаче большого количества мелких сообщений, благодаря использованию Protobuf и возможностей HTTP/2.
Это все, конечно, хорошо. Но давайте кратко и емко про разницу gRPC и REST и про ситуации их применения.
🎈Когда использовать gRPC?
1. Микросервисная архитектура: Если у вас есть система, состоящая из множества сервисов, взаимодействующих друг с другом, gRPC поможет обеспечить быструю и надёжную коммуникацию между ними.
2. Двунаправленная связь: Например, вам нужно создать приложение, которое должно получать обновления в режиме реального времени (например, мониторинг состояния сервера). gRPC с потоковыми запросами отлично справляется с такими задачами.
3. Передача больших объёмов данных: Благодаря использованию Protobuf, gRPC эффективно обрабатывает большие массивы данных, минимизируя накладные расходы на сериализацию и десериализацию.
4. Мобильные приложения: gRPC хорошо интегрируется с мобильными приложениями благодаря своей эффективности и поддержке различных платформ.
🎈 Отличия от REST
1. Протокол:
- REST использует HTTP/1.1, который ориентирован на передачу текста и часто включает заголовки и метаданные.
- gRPC использует HTTP/2, который поддерживает двоичные потоки данных, мультиплексирование запросов и улучшенную компрессию.
2. Формат данных:
- REST чаще всего передаёт данные в формате JSON или XML.
- gRPC использует Protobuf — компактный бинарный формат, который значительно уменьшает размер передаваемых данных.
3. Тип взаимодействия:
- REST обычно ограничивается запросами и ответами типа «запрос–ответ».
- gRPC поддерживает различные типы взаимодействия: односторонние запросы, двусторонний поток данных, клиентские потоки и серверные потоки.
4. Производительность:
- gRPC обычно быстрее и эффективнее, особенно при передаче большого количества мелких сообщений, благодаря использованию Protobuf и возможностей HTTP/2.
👍1
📑 Что должно быть в документации по интеграциям?
Поскольку моя работа чаще всего связана с интеграционными проектами, то для них у меня выработался определенный шаблон.
Что такое интеграция между системами? Это "диалог" между системами. И работа аналитика сводится к созданию сценария взаимодействия для такого "диалога".
Сам сценарий мы рассмотрим внимательно в следующий раз. Но чтобы документация была полноценной, нужно указать дополнительные атрибуты.
🎾 Протоколы обмена информацией
В моей практике в одной интеграции встретились сразу 3 протокола обмена. И не стоит забывать указывать это в документации.
🎾 Sequence diagrams
Бывает, что потребители документации не хотят знать подробностей о работе систем. Для верхнеуровневого обзора последовательности шагов взаимодействия подойдет sequence диаграмма.
🎾 Входящие и исходящие параметры запросов
У входящих указываем тип и обязательность полей. Если лень описывать, то можно приложить ссылку на свагер. Если у вас еще остались силы, то было бы идеально приложить примеры запроса и ответа. Не забывайте, что ответы могут быть успешными и неуспешными, поэтому примеры стоит приводить на оба кейса.
🎾 Детальные описания всех используемых процедур
Основная работа происходит в сторонних системах, поэтому всегда важно указать, либо описание, либо ссылки на используемые процедуры и параметры запросов к ним.
🎾 Модель физических данных, если она предусмотрена проектом.
или ERD. Редкая интеграция обходится без участия базы, поэтому не забывайте прописывать ее.
Именно такую схему я использую при создании документации для интеграций.
Поскольку моя работа чаще всего связана с интеграционными проектами, то для них у меня выработался определенный шаблон.
Что такое интеграция между системами? Это "диалог" между системами. И работа аналитика сводится к созданию сценария взаимодействия для такого "диалога".
Сам сценарий мы рассмотрим внимательно в следующий раз. Но чтобы документация была полноценной, нужно указать дополнительные атрибуты.
🎾 Протоколы обмена информацией
В моей практике в одной интеграции встретились сразу 3 протокола обмена. И не стоит забывать указывать это в документации.
🎾 Sequence diagrams
Бывает, что потребители документации не хотят знать подробностей о работе систем. Для верхнеуровневого обзора последовательности шагов взаимодействия подойдет sequence диаграмма.
🎾 Входящие и исходящие параметры запросов
У входящих указываем тип и обязательность полей. Если лень описывать, то можно приложить ссылку на свагер. Если у вас еще остались силы, то было бы идеально приложить примеры запроса и ответа. Не забывайте, что ответы могут быть успешными и неуспешными, поэтому примеры стоит приводить на оба кейса.
🎾 Детальные описания всех используемых процедур
Основная работа происходит в сторонних системах, поэтому всегда важно указать, либо описание, либо ссылки на используемые процедуры и параметры запросов к ним.
🎾 Модель физических данных, если она предусмотрена проектом.
или ERD. Редкая интеграция обходится без участия базы, поэтому не забывайте прописывать ее.
Именно такую схему я использую при создании документации для интеграций.
Табличек много не бывает
Если аналитик сценарист, то давайте покажу, как выглядит сценарий
Часто, читая чужую документацию, написанную сплошным текстом с обычной нумерацией или обилием буллетов, мне не хотелось погружаться в эти дебри и напрягать зрение сливающимися строками, ведь в современном мире уже существуют разнообразные инструменты и макросы, способные сделать восприятие информации проще и удобнее. Поэтому всякий раз, когда мне приходится иметь дело с документацией, я предпочитаю преобразовывать её в таблицы.
Обычно аналитикам нужно сделать универсальную документацию, понятную и бизнесу, и разработчику. Как это сделать при документировании интеграций?
Если аналитик сценарист, то давайте покажу, как выглядит сценарий
Часто, читая чужую документацию, написанную сплошным текстом с обычной нумерацией или обилием буллетов, мне не хотелось погружаться в эти дебри и напрягать зрение сливающимися строками, ведь в современном мире уже существуют разнообразные инструменты и макросы, способные сделать восприятие информации проще и удобнее. Поэтому всякий раз, когда мне приходится иметь дело с документацией, я предпочитаю преобразовывать её в таблицы.
Обычно аналитикам нужно сделать универсальную документацию, понятную и бизнесу, и разработчику. Как это сделать при документировании интеграций?
Согласитесь, что каждое действие системы представляет собой последовательность шагов, следовательно, любую задачу можно оформить в виде сценария. А сценарии записать в виде таблицы. На картинке видно, как выглядит типичный сценарий для интеграций. Расскажу, как это устроено.
✴️ Краткое описание шага. Этот столбец предназначен для бизнес-заказчиков, которым важно получить общее представление о логике функционирования системы или конкретной функции/метода.
✴️ Направление. Такой столбец полезен в многоуровневых интеграциях, где можно запутаться между системами. Обычно его тоже смотрит бизнес.
✴️ Описание. Здесь содержится подробная информация для разработчиков: технические детали реализации, имена используемых методов, ключи для поиска в кешах и прочие важные аспекты.
✴️ Шлюзы. В любом алгоритме неизбежно присутствуют условия и ветвления, и табличный формат прекрасно справляется с отображением даже сложных многоуровневых структур. Условные обозначения и нумерация показывают, к какой ветке относится ветвление, а цветовое выделение позволяет визуально отделить блоки друг от друга. Таким образом навигация становится интуитивно понятной, а чтение превращается в приятное занятие.
· Такой подход помогает не только упростить восприятие информации, но и сделать процесс разработки более структурированным и организованным.
Как считаете, такой формат был бы вам удобен?
Какие шаблоны у вас выработались? Расскажите в комментариях
✴️ Краткое описание шага. Этот столбец предназначен для бизнес-заказчиков, которым важно получить общее представление о логике функционирования системы или конкретной функции/метода.
✴️ Направление. Такой столбец полезен в многоуровневых интеграциях, где можно запутаться между системами. Обычно его тоже смотрит бизнес.
✴️ Описание. Здесь содержится подробная информация для разработчиков: технические детали реализации, имена используемых методов, ключи для поиска в кешах и прочие важные аспекты.
✴️ Шлюзы. В любом алгоритме неизбежно присутствуют условия и ветвления, и табличный формат прекрасно справляется с отображением даже сложных многоуровневых структур. Условные обозначения и нумерация показывают, к какой ветке относится ветвление, а цветовое выделение позволяет визуально отделить блоки друг от друга. Таким образом навигация становится интуитивно понятной, а чтение превращается в приятное занятие.
· Такой подход помогает не только упростить восприятие информации, но и сделать процесс разработки более структурированным и организованным.
Как считаете, такой формат был бы вам удобен?
Какие шаблоны у вас выработались? Расскажите в комментариях
Diagramm-as-code – удобно?
Раз уж начали говорить про документацию, давайте обсудим самое насущное. Что чаще всего делает аналитик? Правильно, рисует диаграммы. Но это полбеды. Диаграммы нужно править. И не один раз. Обычные рисовалки как draw.io требуют много времени на правки, и я полюбила подход, когда нужно писать код для создания диаграмм.
Что рисуем
flowcharts, sequence diagrams, class diagrams, entity relationship diagrams
Какие плюсы я увидела
➕ Простота внесения изменений
➕ Возможность совместной работы
Что мне не понравилось
Код обычно храним в репо, иногда мы так и делаем, но чаще всего диаграммы вставляются в документацию. Не все базы знаний имеют макросы, в которые в режиме редактирования пишешь код, а в режиме чтения видишь диаграмму. А это значит, исходник нужно тоже где-то хранить. Иногда я вставляю его прямо на страницу в виде скрываемого текста, а иногда храню отдельно. А это, как понимаете, не очень удобно и эстетично.
Какие инструменты рекомендую
🟤 Mermaid
простой и легкий инструмент, основанный на Markdown-подобном синтаксисе для создания различных типов диаграмм.
🔹 Поддерживает множество форматов вывода, таких как SVG, PNG и PDF.
🔹 Простота использования благодаря легкому синтаксису.
🔹 Может использоваться в паре с платформами вроде GitHub Pages, ReadTheDocs и MkDocs для автоматического отображения диаграмм.
Для visual studio Code требует отдельного плагина.
🟤 PlantUML
Мощный генератор UML-диаграмм, использующий собственный текстовый язык для построения классов, последовательности действий, компонентов и другой сложной архитектуры программного обеспечения.
🔹 Полностью поддерживаются стандарты UML, включая использование стереотипов и нотаций. Можно настраивать внешний вид элементов диаграммы вплоть до шрифтов и цветов.
🔹 Подходит для документирования крупных проектов и приложений с большим количеством взаимосвязей.
PlantUML я использовала онлайн. Редакторов много, вот один из них https://editor.plantuml.com/
Итог
Если диаграммы храните в репо или ваша база знаний имеет плагин для таких редакторов, то этот способ однозначно для вас. В иных случаях выбор неочевиден, но я все чаще выбираю код, потому что мне больше не нужно думать над расположением элементов, умещается ли текст на стрелочки и прочее. Я думаю только над контентом.
Раз уж начали говорить про документацию, давайте обсудим самое насущное. Что чаще всего делает аналитик? Правильно, рисует диаграммы. Но это полбеды. Диаграммы нужно править. И не один раз. Обычные рисовалки как draw.io требуют много времени на правки, и я полюбила подход, когда нужно писать код для создания диаграмм.
Что рисуем
flowcharts, sequence diagrams, class diagrams, entity relationship diagrams
Какие плюсы я увидела
➕ Простота внесения изменений
➕ Возможность совместной работы
Что мне не понравилось
Код обычно храним в репо, иногда мы так и делаем, но чаще всего диаграммы вставляются в документацию. Не все базы знаний имеют макросы, в которые в режиме редактирования пишешь код, а в режиме чтения видишь диаграмму. А это значит, исходник нужно тоже где-то хранить. Иногда я вставляю его прямо на страницу в виде скрываемого текста, а иногда храню отдельно. А это, как понимаете, не очень удобно и эстетично.
Какие инструменты рекомендую
🟤 Mermaid
простой и легкий инструмент, основанный на Markdown-подобном синтаксисе для создания различных типов диаграмм.
🔹 Поддерживает множество форматов вывода, таких как SVG, PNG и PDF.
🔹 Простота использования благодаря легкому синтаксису.
🔹 Может использоваться в паре с платформами вроде GitHub Pages, ReadTheDocs и MkDocs для автоматического отображения диаграмм.
Для visual studio Code требует отдельного плагина.
🟤 PlantUML
Мощный генератор UML-диаграмм, использующий собственный текстовый язык для построения классов, последовательности действий, компонентов и другой сложной архитектуры программного обеспечения.
🔹 Полностью поддерживаются стандарты UML, включая использование стереотипов и нотаций. Можно настраивать внешний вид элементов диаграммы вплоть до шрифтов и цветов.
🔹 Подходит для документирования крупных проектов и приложений с большим количеством взаимосвязей.
PlantUML я использовала онлайн. Редакторов много, вот один из них https://editor.plantuml.com/
Итог
Если диаграммы храните в репо или ваша база знаний имеет плагин для таких редакторов, то этот способ однозначно для вас. В иных случаях выбор неочевиден, но я все чаще выбираю код, потому что мне больше не нужно думать над расположением элементов, умещается ли текст на стрелочки и прочее. Я думаю только над контентом.
❤1
Базу данных можно считать центральным компонентом любой современной информационной системы. Она служит ключевым элементом инфраструктуры, ответственным за хранение, управление и предоставление данных другим подсистемам и приложениям.
Производительность базы данных оказывает огромное влияние на всю информационную систему. Как правило, именно база данных является слабым звеном («бутылочным горлышком») многих решений, поскольку обработка и получение данных требуют значительных вычислительных ресурсов.
Поэтому открываю цикл статей про Базу данных, как увеличить ее эффективность, кто такие шардинги, индексы, репликации, кеширование,какой тип базы выбрать и многое другое.
Производительность базы данных оказывает огромное влияние на всю информационную систему. Как правило, именно база данных является слабым звеном («бутылочным горлышком») многих решений, поскольку обработка и получение данных требуют значительных вычислительных ресурсов.
Поэтому открываю цикл статей про Базу данных, как увеличить ее эффективность, кто такие шардинги, индексы, репликации, кеширование,какой тип базы выбрать и многое другое.
❤2
Типы БД
Для начала разберемся, какие бывают базы и почему они разные, для каких задач подойдут.
🔘 Реляционные
Этот тип основан на концепции отношений (таблиц), где информация представлена в виде строк и столбцов. Данные организованы в четкую структуру, которая обеспечивается системой ограничений и ключей.
Примеры
▪️MySQL: Бесплатная открытая СУБД, активно используется в веб-приложениях и малых/средних предприятиях.
▪️PostgreSQL: Открытая СУБД с мощным функционалом, популярной в финансовых и научных расчетах.
▪️Microsoft SQL Server: Коммерческий продукт от Microsoft, популярный в крупных компаниях и организациях.
▪️Oracle Database: Ведущая коммерческая СУБД, известная своей мощностью и возможностями. По известным причинам почти не используется у нас.
🔘 Документоориентированные (NoSQL)
Эти системы хранят данные в виде "документов", представленных в форматах JSON, XML или YAML. Каждый документ самодостаточен и может содержать вложенные поля, что удобно для нерегламентированной структуры данных.
Примеры
▪️MongoDB: Одна из самых известных документоориентированных СУБД, популярна в веб-приложениях и стартапах.
▪️Couchbase: Используется для мобильных и web-приложений, где требуются высокие темпы обработки данных.
▪️ArangoDB: Гибридная СУБД, поддерживающая различные модели данных (документы, графы).
🔘Key-value
Эти СУБД хранят пары "ключ-значение", где ключ однозначно идентифицирует соответствующее значение. Часто применяются для временного хранения и кэширования данных.
Примеры
▪️Redis: Очень быстрая in-memory база данных, популярная для кэша, очередей сообщений и сессий.
▪️Memcached: Еще одно простое и быстрое решение для кэширования данных.
▪️RocksDB: Внутренняя база данных Facebook, используемая для высокоэффективных приложений.
🔘 Колоночные
Эта категория основана на хранении данных по колонкам, а не по строкам, в отличие от реляционных структур. Такой подход ускоряет аналитические запросы, позволяя извлекать лишь нужные колонки без полного считывания всей строки. Используется при обработке логов, формировании отчетов и статистики
Примеры
▪️ClickHouse: Российская СУБД, популярная в аналитике и обработке больших объемов данных.
▪️Vertica: Система от Micro Focus, нацеленная на аналитические задачи.
▪️Apache Kudu: Проект Cloudera для обработки больших данных.
🔘 Графовые
Эти СУБД специализируются на представлении данных в виде графов (вершин и ребер), показывая взаимоотношения между сущностями. Хорошо подходят для социальной аналитики, обнаружения мошенничества и картографии путей.
Примеры
▪️Neo4j: Известная графовая СУБД, используемая крупными компаниями.
▪️JanusGraph: Масштабируемая графовая база данных с поддержкой больших объемов данных.
▪️AllegroGraph: СУБД от Franz Inc., популярная в областях семантического анализа.
🔘 Time-series
Эти СУБД предназначены специально для хранения временных рядов, таких как показания датчиков, рыночные котировки акций и статистики производительности.
Примеры
▪️InfluxDB: Самая популярная time-series СУБД, ориентирована на IoT и DevOps.
Prometheus: Система сбора метрик и мониторинга.
▪️OpenTSDB: Open-source решение для больших временных серий.
Для начала разберемся, какие бывают базы и почему они разные, для каких задач подойдут.
🔘 Реляционные
Этот тип основан на концепции отношений (таблиц), где информация представлена в виде строк и столбцов. Данные организованы в четкую структуру, которая обеспечивается системой ограничений и ключей.
Примеры
▪️MySQL: Бесплатная открытая СУБД, активно используется в веб-приложениях и малых/средних предприятиях.
▪️PostgreSQL: Открытая СУБД с мощным функционалом, популярной в финансовых и научных расчетах.
▪️Microsoft SQL Server: Коммерческий продукт от Microsoft, популярный в крупных компаниях и организациях.
▪️Oracle Database: Ведущая коммерческая СУБД, известная своей мощностью и возможностями. По известным причинам почти не используется у нас.
🔘 Документоориентированные (NoSQL)
Эти системы хранят данные в виде "документов", представленных в форматах JSON, XML или YAML. Каждый документ самодостаточен и может содержать вложенные поля, что удобно для нерегламентированной структуры данных.
Примеры
▪️MongoDB: Одна из самых известных документоориентированных СУБД, популярна в веб-приложениях и стартапах.
▪️Couchbase: Используется для мобильных и web-приложений, где требуются высокие темпы обработки данных.
▪️ArangoDB: Гибридная СУБД, поддерживающая различные модели данных (документы, графы).
🔘Key-value
Эти СУБД хранят пары "ключ-значение", где ключ однозначно идентифицирует соответствующее значение. Часто применяются для временного хранения и кэширования данных.
Примеры
▪️Redis: Очень быстрая in-memory база данных, популярная для кэша, очередей сообщений и сессий.
▪️Memcached: Еще одно простое и быстрое решение для кэширования данных.
▪️RocksDB: Внутренняя база данных Facebook, используемая для высокоэффективных приложений.
🔘 Колоночные
Эта категория основана на хранении данных по колонкам, а не по строкам, в отличие от реляционных структур. Такой подход ускоряет аналитические запросы, позволяя извлекать лишь нужные колонки без полного считывания всей строки. Используется при обработке логов, формировании отчетов и статистики
Примеры
▪️ClickHouse: Российская СУБД, популярная в аналитике и обработке больших объемов данных.
▪️Vertica: Система от Micro Focus, нацеленная на аналитические задачи.
▪️Apache Kudu: Проект Cloudera для обработки больших данных.
🔘 Графовые
Эти СУБД специализируются на представлении данных в виде графов (вершин и ребер), показывая взаимоотношения между сущностями. Хорошо подходят для социальной аналитики, обнаружения мошенничества и картографии путей.
Примеры
▪️Neo4j: Известная графовая СУБД, используемая крупными компаниями.
▪️JanusGraph: Масштабируемая графовая база данных с поддержкой больших объемов данных.
▪️AllegroGraph: СУБД от Franz Inc., популярная в областях семантического анализа.
🔘 Time-series
Эти СУБД предназначены специально для хранения временных рядов, таких как показания датчиков, рыночные котировки акций и статистики производительности.
Примеры
▪️InfluxDB: Самая популярная time-series СУБД, ориентирована на IoT и DevOps.
Prometheus: Система сбора метрик и мониторинга.
▪️OpenTSDB: Open-source решение для больших временных серий.
❤2🔥1
Реляционные или нет?
В начале пути создания системы встает вопрос, какой тип БД выбрать? Обычно выбор стоит между реляционной и NoSQL базой. Оба типа обладают своими сильными сторонами и предназначены для различных случаев использования. Разберем, как выбрать между ними.
🟠 Реляционные
🔸Особенности
Данные представлены в виде таблиц с жестко заданной схемой (структурой).
Связи между таблицами реализованы через первичные и внешние ключи.
Обеспечивается высокий уровень целостности данных и согласованности
Предлагают мощные средства для анализа и обработки данных через SQL-запросы.
🔸 Преимущества
Строгая структура данных гарантирует ясность и предсказуемость.
Высокий уровень безопасности и устойчивости данных.
🔸Недостатки
Трудности с масштабированием для больших объемов данных.
Могут быть неэффективны для постоянно меняющейся структуры данных.
Сложность адаптации к изменениям структуры данных (необходимость миграции данных).
🔸Примеры ситуаций, когда предпочтительна реляционная база данных
Банковские системы: необходимость высокого уровня безопасности и согласованности данных.
Финансовая отчётность: требование точного соблюдения стандартов отчетности и соответствия стандартам регулирования.
CRM-системы: точные данные о клиентах и история взаимодействии необходимы для анализа и маркетинга.
🟠 NoSQL базы данных
🔸Особенности
Более гибкий подход к хранению данных, отсутствует жесткая схема.
Ориентированы на горизонтальную масштабируемость и отказоустойчивость.
Обычно жертвуют согласованностью данных в пользу доступности и производительности (CAP-теорема).
🔸Преимущества
Гарантированная масштабируемость для больших объемов данных.
Легко адаптируются к изменению структуры данных.
Повышенная производительность для операций чтения и записи.
Лучшее соответствие современным задачам обработки больших данных и распределённых систем.
🔸Недостатки
Сложность выполнения сложных запросов и соединений.
Потенциальные риски нарушения целостности данных.
🔸Примеры ситуаций, когда предпочтительны NoSQL базы данных
Интернет-магазины: обработка большого количества заказов и продуктов, простота добавления новых атрибутов товара.
IoT (Интернет вещей): постоянное поступление данных с датчиков, требующих быстрого сохранения и обработки.
Каталоги товаров: огромная коллекция разноплановых данных, которые сложно представить в жесткой схеме.
❓Рассмотрим кейсы, в которых нужно выбрать тип бд.
🅰️ Онлайн-магазин книг
Для такой системы потребуется точное представление ассортимента, цен, поставщиков и покупателей. Каждый заказ включает точный список покупок, доставку и оплату. Важно соблюдать точность данных и избегать ошибок. Тут очевидным выбором станет реляционная база данных. Мы можем организовать чёткую структуру данных, реализовать сильные связи между пользователями, товарами и заказами, а также воспользоваться механизмами транзакций для предотвращения возможных ошибок.
🅱️ Социальная сеть
Пользователи ежедневно загружают миллионы фотографий, публикуют посты и комментарии, создают группы и страницы. Каждое событие сопровождается множеством атрибутов, которые могут меняться в зависимости от ситуации. Важнее всего быстрая реакция на новые публикации и лёгкость внесения изменений в структуру данных. В таком случае оптимальным решением будет NoSQL база данных, такая как MongoDB, которая позволит свободно добавлять новые свойства и обрабатывать гигантские потоки данных.
Итог
Перед выбором типа базы данных обязательно оценивайте характеристики проекта, особенности данных и будущие перспективы развития. В некоторых случаях рационально комбинировать оба подхода, используя NoSQL для хранения быстро изменяемых данных и RDBMS для задач, требующих точности и согласованности.
В начале пути создания системы встает вопрос, какой тип БД выбрать? Обычно выбор стоит между реляционной и NoSQL базой. Оба типа обладают своими сильными сторонами и предназначены для различных случаев использования. Разберем, как выбрать между ними.
🟠 Реляционные
🔸Особенности
Данные представлены в виде таблиц с жестко заданной схемой (структурой).
Связи между таблицами реализованы через первичные и внешние ключи.
Обеспечивается высокий уровень целостности данных и согласованности
Предлагают мощные средства для анализа и обработки данных через SQL-запросы.
🔸 Преимущества
Строгая структура данных гарантирует ясность и предсказуемость.
Высокий уровень безопасности и устойчивости данных.
🔸Недостатки
Трудности с масштабированием для больших объемов данных.
Могут быть неэффективны для постоянно меняющейся структуры данных.
Сложность адаптации к изменениям структуры данных (необходимость миграции данных).
🔸Примеры ситуаций, когда предпочтительна реляционная база данных
Банковские системы: необходимость высокого уровня безопасности и согласованности данных.
Финансовая отчётность: требование точного соблюдения стандартов отчетности и соответствия стандартам регулирования.
CRM-системы: точные данные о клиентах и история взаимодействии необходимы для анализа и маркетинга.
🟠 NoSQL базы данных
🔸Особенности
Более гибкий подход к хранению данных, отсутствует жесткая схема.
Ориентированы на горизонтальную масштабируемость и отказоустойчивость.
Обычно жертвуют согласованностью данных в пользу доступности и производительности (CAP-теорема).
🔸Преимущества
Гарантированная масштабируемость для больших объемов данных.
Легко адаптируются к изменению структуры данных.
Повышенная производительность для операций чтения и записи.
Лучшее соответствие современным задачам обработки больших данных и распределённых систем.
🔸Недостатки
Сложность выполнения сложных запросов и соединений.
Потенциальные риски нарушения целостности данных.
🔸Примеры ситуаций, когда предпочтительны NoSQL базы данных
Интернет-магазины: обработка большого количества заказов и продуктов, простота добавления новых атрибутов товара.
IoT (Интернет вещей): постоянное поступление данных с датчиков, требующих быстрого сохранения и обработки.
Каталоги товаров: огромная коллекция разноплановых данных, которые сложно представить в жесткой схеме.
❓Рассмотрим кейсы, в которых нужно выбрать тип бд.
🅰️ Онлайн-магазин книг
Для такой системы потребуется точное представление ассортимента, цен, поставщиков и покупателей. Каждый заказ включает точный список покупок, доставку и оплату. Важно соблюдать точность данных и избегать ошибок. Тут очевидным выбором станет реляционная база данных. Мы можем организовать чёткую структуру данных, реализовать сильные связи между пользователями, товарами и заказами, а также воспользоваться механизмами транзакций для предотвращения возможных ошибок.
🅱️ Социальная сеть
Пользователи ежедневно загружают миллионы фотографий, публикуют посты и комментарии, создают группы и страницы. Каждое событие сопровождается множеством атрибутов, которые могут меняться в зависимости от ситуации. Важнее всего быстрая реакция на новые публикации и лёгкость внесения изменений в структуру данных. В таком случае оптимальным решением будет NoSQL база данных, такая как MongoDB, которая позволит свободно добавлять новые свойства и обрабатывать гигантские потоки данных.
Итог
Перед выбором типа базы данных обязательно оценивайте характеристики проекта, особенности данных и будущие перспективы развития. В некоторых случаях рационально комбинировать оба подхода, используя NoSQL для хранения быстро изменяемых данных и RDBMS для задач, требующих точности и согласованности.
Понедельник - день тяжелый. Хотите интересную задачку, чтобы размять мозг в начале недели?
👍2❤1
Знаю, что хотите задачку :) Держите!
🏥
Предположим, вы работаете в крупной медицинской компании, занимающейся обработкой результатов медицинских исследований пациентов. Ваша задача — разработать новую платформу для ведения электронных медицинских карт пациентов. Пользовательская база огромна — десятки миллионов человек. Основная цель системы заключается в следующем:
- Собирать подробную историю болезни пациента, включающую разнообразные медицинские данные: анализы крови, рентгеновские снимки, УЗИ, МРТ, ЭКГ и многие другие.
- Предоставлять врачам быстрый доступ ко всей истории болезней пациента
- Проводить регулярный анализ данных пациентов для выявления закономерностей заболеваний и рисков осложнений.
- Вести учёт лечения и назначаемых препаратов пациентам.
- Планировать профилактические мероприятия и диспансеризацию.
❓Какой тип базы данных вы бы выбрали для этого проекта: реляционный или NoSQL? расскажите в комментариях, почему?
📝Ответ расскажу вечером
🏥
Предположим, вы работаете в крупной медицинской компании, занимающейся обработкой результатов медицинских исследований пациентов. Ваша задача — разработать новую платформу для ведения электронных медицинских карт пациентов. Пользовательская база огромна — десятки миллионов человек. Основная цель системы заключается в следующем:
- Собирать подробную историю болезни пациента, включающую разнообразные медицинские данные: анализы крови, рентгеновские снимки, УЗИ, МРТ, ЭКГ и многие другие.
- Предоставлять врачам быстрый доступ ко всей истории болезней пациента
- Проводить регулярный анализ данных пациентов для выявления закономерностей заболеваний и рисков осложнений.
- Вести учёт лечения и назначаемых препаратов пациентам.
- Планировать профилактические мероприятия и диспансеризацию.
❓Какой тип базы данных вы бы выбрали для этого проекта: реляционный или NoSQL? расскажите в комментариях, почему?
📝Ответ расскажу вечером
❤1
Идеальным вариантом будет комбинация двух типов баз данных:
🏥 Реляционная база данных
используется для хранения точной и последовательной информации о пациенте, врачах, лечении, лекарствах, результатах обследований и истории болезней. Сюда относятся стандартные диагностические данные, такие как имя пациента, фамилия врача, назначения лекарств и регулярные проверки.
🏥 NoSQL база данных
используется для хранения разнородных данных — изображений (рентгеновских снимков, МРТ, КТ), биоэлектрических сигналов (ЭКГ), лабораторных данных и нестандартных показателей. Эта база будет отвечать за расширение набора данных и экспериментальные нововведения.
Такой подход позволяет сочетать преимущества обеих технологий и обеспечить оптимальное функционирование системы медицинского учёта.
🏥 Реляционная база данных
используется для хранения точной и последовательной информации о пациенте, врачах, лечении, лекарствах, результатах обследований и истории болезней. Сюда относятся стандартные диагностические данные, такие как имя пациента, фамилия врача, назначения лекарств и регулярные проверки.
🏥 NoSQL база данных
используется для хранения разнородных данных — изображений (рентгеновских снимков, МРТ, КТ), биоэлектрических сигналов (ЭКГ), лабораторных данных и нестандартных показателей. Эта база будет отвечать за расширение набора данных и экспериментальные нововведения.
Такой подход позволяет сочетать преимущества обеих технологий и обеспечить оптимальное функционирование системы медицинского учёта.
Forwarded from ИТ ПСБ
ЛАФ — одна из старейших ежегодных конференций в России и СНГ по направлению системного анализа, бизнес-анализа, работы с требованиями и управлению продуктами.
Присоединяйтесь, чтобы узнать, как сделать ваши системы быстрее и эффективнее, и поддержать коллег!
Когда, где:
7–8 июня, Кострома
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1