🏭 PlantUML: полезные материалы
Небольшая подборка для тех, кто давно хотел начать применять PlantUML, но никак не доходили руки. К счастью, это не займёт много времени.
PlantUML — это крайне полезный инструмент для аналитика, который превращает псевдокод в UML-диаграммы. Это значительно быстрее и удобнее, чем вечно тыкаться со стрелочками и ручным выравниванием в draw.io или в Visio. Жирный плюс — есть плагин для Confluence.
Синтаксис очень простой, пугаться кода не нужно. По примерам становится всё понятно.
Для начала выберете место, где вам будет удобнее писать диаграмму: это может быть:
1. planttext.com — онлайн редактор
2. расширение для Notepad++
3. расширение для IDE (лучший вариант, ссылки кликабельны): IDEA, PyCharm, Visual Studio
После того как определитесь, где будете работать, можете начать изучение по статьям или видео.
Документация
1. Официальная документация (почти всё на русском)
2. Гайд на русском в pdf
Статьи
1. Диаграммы без боли и страданий: PlantUML — хороший гайд с примерами
2. Пишу диаграммы последовательностей текстом (кодом). Вы тоже можете — тут только про sequence
Видео
1. PlantUML с нуля до гуру: учимся «кодить» sequence-диаграммы — доклад Никиты Харичкина с Flow 2022 (скачать презентацию)
2. PlantUML на всю катушку: Автоматизация и лайфхаки для диаграмм последовательности — доклад всё того же Никиты, но с Analyst Days #14 (скачать презентацию)
#инструменты #подборка
Небольшая подборка для тех, кто давно хотел начать применять PlantUML, но никак не доходили руки. К счастью, это не займёт много времени.
PlantUML — это крайне полезный инструмент для аналитика, который превращает псевдокод в UML-диаграммы. Это значительно быстрее и удобнее, чем вечно тыкаться со стрелочками и ручным выравниванием в draw.io или в Visio. Жирный плюс — есть плагин для Confluence.
Синтаксис очень простой, пугаться кода не нужно. По примерам становится всё понятно.
Для начала выберете место, где вам будет удобнее писать диаграмму: это может быть:
1. planttext.com — онлайн редактор
2. расширение для Notepad++
3. расширение для IDE (лучший вариант, ссылки кликабельны): IDEA, PyCharm, Visual Studio
После того как определитесь, где будете работать, можете начать изучение по статьям или видео.
Документация
1. Официальная документация (почти всё на русском)
2. Гайд на русском в pdf
Статьи
1. Диаграммы без боли и страданий: PlantUML — хороший гайд с примерами
2. Пишу диаграммы последовательностей текстом (кодом). Вы тоже можете — тут только про sequence
Видео
1. PlantUML с нуля до гуру: учимся «кодить» sequence-диаграммы — доклад Никиты Харичкина с Flow 2022 (скачать презентацию)
2. PlantUML на всю катушку: Автоматизация и лайфхаки для диаграмм последовательности — доклад всё того же Никиты, но с Analyst Days #14 (скачать презентацию)
#инструменты #подборка
🔥34👍9❤3👏1
Основы Kafka – что нужно знать аналитику
Неделей ранее мы рассматривали основные понятия очередей сообщений. Пришло время копнуть чуть глубже и познакомиться с Кафкой.
Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.
Подход к обмену сообщениями
Те, кто отправляют сообщения в Kafka, называются продюсерами, а те, кто читает, косьюмерами. В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Архитектура Kafka
Kafka является распределенной системой. Все серверы объединяются в кластеры. Хранение и пересылка сообщений идёт параллельно на разных серверах, это даёт большую надежность и отказоустойчивость. Такая архитектура упрощает горизонтальное масштабирование: достаточно добавить дополнительные серверы.
Хранение сообщений в Kafka
Каждое сообщение (event или message) в Kafka состоит из ключа, значения, таймстампа и опционального набора метаданных (headers). Сообщения хранятся в топиках, которые делятся на партиции (partitions). Партиции распределены между брокерами в кластере и могут быть реплицированы для надёжности. Сообщения с одинаковыми ключами попадают в одну партицию, что обеспечивает порядок записи и чтения.
Чтение сообщений в Kafka
Как не читать одно сообщение дважды? Консьюмеры в Kafka отмечают обработанные сообщения с помощью оффсетов. Оффсет – это номер сообщения в партиции. Консьюмер отправляет брокеру запрос offset-commit с офсетом, который нужно сохранить. Брокер хранит эти офсеты в специальном топике. Консьюмеры могут получить последний закоммиченный оффсет у брокера и продолжить чтение сообщений с него.
Процесс обмена сообщениями в Kafka
0️⃣ Создается именованный топик, который является точкой интеграции между продюсером и консьюмером. Топик делится на несколько партиций, которые распределяются между брокерами в кластере
1️⃣ Продюсер отправляет сообщение в топик брокера. Сообщение содержит ключ, значение, таймстамп и опциональные хедеры. Ключ определяет, в какую партицию попадет сообщение.
2️⃣ Консьюмер пытается забрать сообщение и его уникальный идентификатор (оффсет), присвоенный брокером (как правило, порядковый номер).
3️⃣ Брокер хранит сообщение до запланированной очистки журнала. Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
4️⃣ Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет запрос обратно на сервер, используя его уникальный офсет и сообщает брокеру либо об успешной обработке (offset-commit), либо об ошибке (offset-reset).
5️⃣ В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное. Сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.
Где используется Kafka
Kafka используется для обработки больших объёмов данных, сотен тысяч сообщений в секунду, которые читаются тысячами подписчиков. Kafka — это легко масштабируемая система, обладающая повышенной отказоустойчивостью, что очень важно в крупных проектах, например, банкинг, телеком социальные сети, IoT.
Материалы по Kafka выйдут в следующем посте завтра, а на следующей неделе рассмотрим RabbitMQ и сравним его с Kafka.
#интеграции #очереди #async
Неделей ранее мы рассматривали основные понятия очередей сообщений. Пришло время копнуть чуть глубже и познакомиться с Кафкой.
Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.
Подход к обмену сообщениями
Те, кто отправляют сообщения в Kafka, называются продюсерами, а те, кто читает, косьюмерами. В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Архитектура Kafka
Kafka является распределенной системой. Все серверы объединяются в кластеры. Хранение и пересылка сообщений идёт параллельно на разных серверах, это даёт большую надежность и отказоустойчивость. Такая архитектура упрощает горизонтальное масштабирование: достаточно добавить дополнительные серверы.
Хранение сообщений в Kafka
Каждое сообщение (event или message) в Kafka состоит из ключа, значения, таймстампа и опционального набора метаданных (headers). Сообщения хранятся в топиках, которые делятся на партиции (partitions). Партиции распределены между брокерами в кластере и могут быть реплицированы для надёжности. Сообщения с одинаковыми ключами попадают в одну партицию, что обеспечивает порядок записи и чтения.
Чтение сообщений в Kafka
Как не читать одно сообщение дважды? Консьюмеры в Kafka отмечают обработанные сообщения с помощью оффсетов. Оффсет – это номер сообщения в партиции. Консьюмер отправляет брокеру запрос offset-commit с офсетом, который нужно сохранить. Брокер хранит эти офсеты в специальном топике. Консьюмеры могут получить последний закоммиченный оффсет у брокера и продолжить чтение сообщений с него.
Процесс обмена сообщениями в Kafka
0️⃣ Создается именованный топик, который является точкой интеграции между продюсером и консьюмером. Топик делится на несколько партиций, которые распределяются между брокерами в кластере
1️⃣ Продюсер отправляет сообщение в топик брокера. Сообщение содержит ключ, значение, таймстамп и опциональные хедеры. Ключ определяет, в какую партицию попадет сообщение.
2️⃣ Консьюмер пытается забрать сообщение и его уникальный идентификатор (оффсет), присвоенный брокером (как правило, порядковый номер).
3️⃣ Брокер хранит сообщение до запланированной очистки журнала. Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
4️⃣ Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет запрос обратно на сервер, используя его уникальный офсет и сообщает брокеру либо об успешной обработке (offset-commit), либо об ошибке (offset-reset).
5️⃣ В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное. Сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.
Где используется Kafka
Kafka используется для обработки больших объёмов данных, сотен тысяч сообщений в секунду, которые читаются тысячами подписчиков. Kafka — это легко масштабируемая система, обладающая повышенной отказоустойчивостью, что очень важно в крупных проектах, например, банкинг, телеком социальные сети, IoT.
Материалы по Kafka выйдут в следующем посте завтра, а на следующей неделе рассмотрим RabbitMQ и сравним его с Kafka.
#интеграции #очереди #async
🔥22👍8❤6
Подборка бесплатных материалов по Kafka
Делитесь с коллегами 📢
📑 Статьи (теория)
1. Apache Kafka: основы технологии от Слёрм
2. Короткая статья на Яндекс.Практикум
3. Apache Kafka для аналитика: ТОП-7 требований к интеграционной шине
4. Kafka за 20 минут от СберМаркета
5. Перевод на русский главы "Kafka" из книги «Understanding Message Brokers»
6. Микросервисы, Apache Kafka и Domain-Driven Design
📝 Статьи (практика)
1. Как построить систему, способную выдерживать нагрузку в 5 млн rps
2. Разбираемся в технологии и собираем простое приложение на базе managed-решения
3. Как мы автоматизировали работу с Kafka
⏯ Вебинары
1. Apache Kafka, открытый базовый курс — 3 видеоурока от Слёрм
2. Про Kafka (основы) — Владимир Богдановский
3. Основы работы с Kafka с Павлом Вейником — видеолекция с примерами от разработчика
📚 Книги
1. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
2. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — книга про Kafka на русском
3. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть ещё чем поделиться, пишите в комментариях 👇
#подборка #интеграции #очереди #async
Делитесь с коллегами 📢
📑 Статьи (теория)
1. Apache Kafka: основы технологии от Слёрм
2. Короткая статья на Яндекс.Практикум
3. Apache Kafka для аналитика: ТОП-7 требований к интеграционной шине
4. Kafka за 20 минут от СберМаркета
5. Перевод на русский главы "Kafka" из книги «Understanding Message Brokers»
6. Микросервисы, Apache Kafka и Domain-Driven Design
📝 Статьи (практика)
1. Как построить систему, способную выдерживать нагрузку в 5 млн rps
2. Разбираемся в технологии и собираем простое приложение на базе managed-решения
3. Как мы автоматизировали работу с Kafka
⏯ Вебинары
1. Apache Kafka, открытый базовый курс — 3 видеоурока от Слёрм
2. Про Kafka (основы) — Владимир Богдановский
3. Основы работы с Kafka с Павлом Вейником — видеолекция с примерами от разработчика
📚 Книги
1. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
2. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — книга про Kafka на русском
3. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть ещё чем поделиться, пишите в комментариях 👇
#подборка #интеграции #очереди #async
🔥20❤8👍5
🐇 Основы RabbitMQ – что нужно знать аналитику
В предыдущих постах мы немного рассмотрели Кафку, пришла очередь Кролика.
RabbitMQ – это брокер сообщений с открытым исходным кодом, который реализует протокол AMQP (Advanced Message Queuing Protocol). Применяется в системах для асинхронной интеграции, где требуется гибкая и надежная маршрутизация сообщений.
Основная фишка RabbitMQ — это гибкая маршрутизация сообщений между различными поставщиками (продьюсерами) и потребителями (косьюмерами) событий. RabbitMQ – это не просто очередь данных между двумя сторонами, это менеджер очередей, который маршрутизирует данные в разные очереди сообщений. Продьюсер отправляет сообщения не в саму очередь, а на обменник, который сам распределяет сообщения между очередями.
Например, одно и то же сообщение должны получить три подписчика. Оно попадает на узел (обменник), который отправит три одинаковых сообщения в три очереди для всех подписчиков, которым оно должно быть доставлено. При этом в очереди может храниться любое количество сообщений от неограниченного количества поставщиков, а получать их может неограниченное число подписчиков.
Подход к обмену сообщениями
В RabbitMQ используется подход push, когда брокер сам активно отправляет сообщения консьюмерам, которые подписаны на очереди. Такой подход позволяет уменьшить задержку обработки данных и более равномерно распределить нагрузку между потребителями.
В RabbitMQ после получения консьюмерами сообщение удаляется из очереди. Благодаря этому одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого.
К минусам подхода push относится меньшая гибкость для потребителей. В отличие от модели pull, когда потребитель сам ходит за новыми сообщениями, когда ему надо, push не оставляет выбора потребителю – тот должен обработать поступившее сообщение. Кроме того, RabbitMQ не гарантирует порядок доставки сообщений.
Процесс обмена сообщениями в RabbitMQ
0️⃣ Создается именованный обменник, который является точкой интеграции между продюсером и консьюмером. Обменник задает правила маршрутизации сообщений.
1️⃣ Создаются одна или несколько очередей, которые привязываются к обменнику с помощью ключей маршрутизации.
2️⃣ Продюсер отправляет сообщение в обменник
3️⃣ Обменник, получив сообщение, маршрутизирует его в одну или несколько очередей в соответствии с правилами привязки между ним и очередью
4️⃣ Очередь отправляет сообщение потребителям (одному или нескольким), которые подписались на “push-уведомления” (поставили 🔔 на канале 😄)
5️⃣ Потребитель обрабатывает сообщение, исходя из своей бизнес-логики и отправляет брокеру подтверждение об успешной обработке (ack) или отказе (nack)
6️⃣ В случае успешной обработки брокер удаляет сообщение из очереди. В случае неудачной обработки со стороны потребителя (nack) сообщение остается в очереди, пока не будет успешно обработано
В случае некорректного завершения работы сервера, данные в очереди не теряются. И при последующем запуске обработка продолжается с того места, где был обрыв.
Архитектура RabbitMQ
RabbitMQ является распределенной системой. Все серверы объединяются в кластеры. Пересылка сообщений идёт через специальные узлы, называемые обменниками (exchanges), которые могут иметь разные типы и правила маршрутизации. Обменники отправляют сообщения в очереди (queues). Обменники и очереди связаны через binding – правила, которое сообщает имеющемуся обмену в какой из очередей эти сообщения должны сохраняться. Очереди могут быть распределены между брокерами в кластере и реплицированы для надёжности.
Где используется RabbitMQ
RabbitMQ — это универсальный брокер сообщений. Он отлично подходит для интеграции микросервисов, потоковой передачи данных в режиме реального времени или при передаче работы удалённым работникам. Его используют крупные компании, в числе которых Bloomberg, Reddit, NASA и др.
Подборка полезные материалов о RabbitMQ будет в следующем посте. В понедельник выйдет верхнеуровневое сравнение RabbitMQ vs Kafka по пунктам.
#интеграции #очереди #async
В предыдущих постах мы немного рассмотрели Кафку, пришла очередь Кролика.
RabbitMQ – это брокер сообщений с открытым исходным кодом, который реализует протокол AMQP (Advanced Message Queuing Protocol). Применяется в системах для асинхронной интеграции, где требуется гибкая и надежная маршрутизация сообщений.
Основная фишка RabbitMQ — это гибкая маршрутизация сообщений между различными поставщиками (продьюсерами) и потребителями (косьюмерами) событий. RabbitMQ – это не просто очередь данных между двумя сторонами, это менеджер очередей, который маршрутизирует данные в разные очереди сообщений. Продьюсер отправляет сообщения не в саму очередь, а на обменник, который сам распределяет сообщения между очередями.
Например, одно и то же сообщение должны получить три подписчика. Оно попадает на узел (обменник), который отправит три одинаковых сообщения в три очереди для всех подписчиков, которым оно должно быть доставлено. При этом в очереди может храниться любое количество сообщений от неограниченного количества поставщиков, а получать их может неограниченное число подписчиков.
Подход к обмену сообщениями
В RabbitMQ используется подход push, когда брокер сам активно отправляет сообщения консьюмерам, которые подписаны на очереди. Такой подход позволяет уменьшить задержку обработки данных и более равномерно распределить нагрузку между потребителями.
В RabbitMQ после получения консьюмерами сообщение удаляется из очереди. Благодаря этому одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого.
К минусам подхода push относится меньшая гибкость для потребителей. В отличие от модели pull, когда потребитель сам ходит за новыми сообщениями, когда ему надо, push не оставляет выбора потребителю – тот должен обработать поступившее сообщение. Кроме того, RabbitMQ не гарантирует порядок доставки сообщений.
Процесс обмена сообщениями в RabbitMQ
0️⃣ Создается именованный обменник, который является точкой интеграции между продюсером и консьюмером. Обменник задает правила маршрутизации сообщений.
1️⃣ Создаются одна или несколько очередей, которые привязываются к обменнику с помощью ключей маршрутизации.
2️⃣ Продюсер отправляет сообщение в обменник
3️⃣ Обменник, получив сообщение, маршрутизирует его в одну или несколько очередей в соответствии с правилами привязки между ним и очередью
4️⃣ Очередь отправляет сообщение потребителям (одному или нескольким), которые подписались на “push-уведомления” (поставили 🔔 на канале 😄)
5️⃣ Потребитель обрабатывает сообщение, исходя из своей бизнес-логики и отправляет брокеру подтверждение об успешной обработке (ack) или отказе (nack)
6️⃣ В случае успешной обработки брокер удаляет сообщение из очереди. В случае неудачной обработки со стороны потребителя (nack) сообщение остается в очереди, пока не будет успешно обработано
В случае некорректного завершения работы сервера, данные в очереди не теряются. И при последующем запуске обработка продолжается с того места, где был обрыв.
Архитектура RabbitMQ
RabbitMQ является распределенной системой. Все серверы объединяются в кластеры. Пересылка сообщений идёт через специальные узлы, называемые обменниками (exchanges), которые могут иметь разные типы и правила маршрутизации. Обменники отправляют сообщения в очереди (queues). Обменники и очереди связаны через binding – правила, которое сообщает имеющемуся обмену в какой из очередей эти сообщения должны сохраняться. Очереди могут быть распределены между брокерами в кластере и реплицированы для надёжности.
Где используется RabbitMQ
RabbitMQ — это универсальный брокер сообщений. Он отлично подходит для интеграции микросервисов, потоковой передачи данных в режиме реального времени или при передаче работы удалённым работникам. Его используют крупные компании, в числе которых Bloomberg, Reddit, NASA и др.
Подборка полезные материалов о RabbitMQ будет в следующем посте. В понедельник выйдет верхнеуровневое сравнение RabbitMQ vs Kafka по пунктам.
#интеграции #очереди #async
🔥13👍12❤2
🐇 Подборка бесплатных материалов по RabbitMQ
📢 Делитесь с коллегами
0. Официальная документация
📑 Статьи (теория)
1. Цикл конспектов от Слёрм:
✹ RabbitMQ: терминология и базовые сущности
✹ Когда и зачем нужен RabbitMQ
✹ Как запускать RabbitMQ в Docker
✹ Типовое использование RabbitMQ
✹ Разбираемся с RabbitMQ: High Availability и High Load
✹ RabbitMQ: дополнительные возможности
2. RabbitMQ для аналитика: практический ликбез — подробно о RabbitMQ + практический пример
3. AMQP на примере RabbitMQ: как же «готовить кролика»? — о принципе работы RabbitMQ на пальцах
📝 Статьи (практика)
1. 101 способ приготовления RabbitMQ и немного о pipeline архитектуре (то же, только видео с HighLoad++)
2. Построение распределенной системы очередей сообщений с RabbitMQ и Python
3. Highly Available кластер RabbitMQ
▶️ Видео и вебинары
1. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
2. Разработка требований к Rabbit MQ — Зоя Степчева, Systems Education
3. Системы обмена сообщениями: RabbitMQ и Kafka // Архитектура и шаблоны проектирования
4. Очень (даже слишком) подробная лекция о RabbitMQ и Kafka: часть 1 и часть 2
5. Использование RabbitMQ Streams — лекция от разработчика
6. Брокеры сообщений RabbitMQ, Kafka и Redis в работе системного аналитика: как и когда использовать
🧑💻 Для любителей всё попробовать руками есть бесплатный видеокурс на Ютубе.
📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Остальные книги на английском можно скачать здесь
#подборка #интеграции #очереди #async
📢 Делитесь с коллегами
0. Официальная документация
📑 Статьи (теория)
1. Цикл конспектов от Слёрм:
✹ RabbitMQ: терминология и базовые сущности
✹ Когда и зачем нужен RabbitMQ
✹ Как запускать RabbitMQ в Docker
✹ Типовое использование RabbitMQ
✹ Разбираемся с RabbitMQ: High Availability и High Load
✹ RabbitMQ: дополнительные возможности
2. RabbitMQ для аналитика: практический ликбез — подробно о RabbitMQ + практический пример
3. AMQP на примере RabbitMQ: как же «готовить кролика»? — о принципе работы RabbitMQ на пальцах
📝 Статьи (практика)
1. 101 способ приготовления RabbitMQ и немного о pipeline архитектуре (то же, только видео с HighLoad++)
2. Построение распределенной системы очередей сообщений с RabbitMQ и Python
3. Highly Available кластер RabbitMQ
▶️ Видео и вебинары
1. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
2. Разработка требований к Rabbit MQ — Зоя Степчева, Systems Education
3. Системы обмена сообщениями: RabbitMQ и Kafka // Архитектура и шаблоны проектирования
4. Очень (даже слишком) подробная лекция о RabbitMQ и Kafka: часть 1 и часть 2
5. Использование RabbitMQ Streams — лекция от разработчика
6. Брокеры сообщений RabbitMQ, Kafka и Redis в работе системного аналитика: как и когда использовать
🧑💻 Для любителей всё попробовать руками есть бесплатный видеокурс на Ютубе.
📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Остальные книги на английском можно скачать здесь
#подборка #интеграции #очереди #async
❤6👍5🔥4👏1🎉1
Forwarded from Библиотека Системного Аналитика
Юрий_Химонин_Сбор_и_анализ_требований_к_программному_продукту.pdf
2 MB
Юрий Химонин. Сбор и анализ требований к программному продукту
Альтернатива Вигерсу. Книга небольшая и охватывает все по существу. Автор предлагает готовый подход по сбору и анализу требовании с последующим проектированием системы на их основе. Методики изначально рассматриваются в рамках итерационного или циклического циклов разработки, в отличие от методик ведущих издателей, которые в исходном виде могут быть использованы только в водопадной или каскадной моделях.
Альтернатива Вигерсу. Книга небольшая и охватывает все по существу. Автор предлагает готовый подход по сбору и анализу требовании с последующим проектированием системы на их основе. Методики изначально рассматриваются в рамках итерационного или циклического циклов разработки, в отличие от методик ведущих издателей, которые в исходном виде могут быть использованы только в водопадной или каскадной моделях.
👍22❤3🔥1
На своем канале Pro анализ в ИТ Иннокентий Бодров, аналитик и менеджер продукта с 15-летним стажем, делится полезными материалами по созданию ИТ продуктов и систем, развитию и росту аналитиков, работе аналитиков в РФ и других странах.
👨💻 Ревью статьи Евгения Скорикова про проработку нефункциональных требований
🎥 Эфир про работу аналитика в Нидерландах
📶 Обсуждение KPI аналитика
👨💻 Ревью статьи Евгения Скорикова про проработку нефункциональных требований
🎥 Эфир про работу аналитика в Нидерландах
📶 Обсуждение KPI аналитика
Telegram
PRO анализ в ИТ
Канал о продуктовом мышлении, полезной работае с AI, системном и бизнес-анализе, архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT.
Все вопросы - @innokentyB
Все вопросы - @innokentyB
👍1
🆚 Kafka vs RabbitMQ: сравнение по пунктам
В предыдущих постах мы рассмотрели основы по RabbitMQ и Kafka и собрали полезные материалы для изучения. Перейдём к сравнению, что лучше?
Подход к обмену сообщениями
🔸 В RabbitMQ используется подход push, когда брокер сам активно отправляет сообщения консьюмерам, которые подписаны на очереди. Плюсы: меньше задержка и равномернее нагрузка. Минусы: меньшая гибкость для потребителя и невозможность потребления сообщений пакетами.
▪️ В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
Удаление сообщений из очереди
🔸 В RabbitMQ после получения консьюмерами сообщение удаляется из очереди Благодаря этому одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого.
▪️ В Kafka сообщения после прочтения косньюмерами не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Скорость доставки сообщений
🔸 Очереди RabbitMQ работают быстрее всего на относительно небольших объёмах.
▪️ Kafka хранит большие объемы данных с минимальными издержками, поэтому подходит для передачи большого количества сообщений, + поддерживает пакетное потребление сообщений
Масштабируемость
🔸 RabbitMQ может масштабироваться горизонтально, но это требует большего количества настроек и управления
▪️ Kafka легко масштабируется горизонтально, что позволяет добавлять новые брокеры для обработки большего объема данных
Маршрутизация сообщений
🔸 В RabbitMQ все сообщения маршрутизируются через обменник (exchange) перед попаданием в очереди. RabbitMQ предлагает несколько видов маршрутизации с помощью ключей по протоколу AMQP.
▪️ У Kafka упрощённый подход к маршрутизации
Протокол
🔸 RabbitMQ поддерживает несколько стандартизированных протоколов: AMQP, MQTT, STOMP и др. Это позволяет заменить его на любой брокер на основе AMQP.
▪️ Kafka использует собственный двоичный протокол поверх TCP. Вы не сможете так просто удалить или заменить эту платформу, потому что она единственная реализует данный протокол.
Приоритезация сообщений
🔸 RabbitMQ позволяет назначать приоритет сообщениям
▪️ В Kafka приоритет для всех сообщений одинаков и его нельзя изменить. Обходной путь: создать нескольких топиков под сообщения с разным приоритетом, например, events_low, events_medium, events_high, а затем реализовать логику приоритетного чтения на стороне консьюмера.
Выводы
Kafka – это про большие данные и потоковую обработку:
➖ когда в реальном времени требуется обрабатывать огромные куски данных с частотой от тысяч до миллионов сообщений в секунду
➖ когда нужно собирать кучу данных с большого числа источников (например, системы логирования и мониторинга)
➖ когда несколько потребителей должны получить все сообщения (например, в системах подписок).
RabbitMQ подходит для более стандартной очереди или брокера сообщений:
➖ когда нужна сложная маршрутизация сообщений (например, выборочная подписка или публикация)
➖ когда нужно просто передавать краткосрочные сообщения от одного микросервиса к другому
➖ когда нужна поддержка разных протоколов обмена и более зрелый подход к стандартной очереди задач
📎 Ссылки
1. Сравнительный анализ Apache Kafka и RabbitMQ — Хабр, БФТ-Холдинг
2. Чем различаются Kafka и RabbitMQ: простыми словами — Хабр, Иннотех
3. RabbitMQ против Kafka: два разных подхода — Хабр, ITSumma
4. RabbitMQ и Apache Kafka: что выбрать — Слёрм
5. В чем разница между Kafka и RabbitMQ? — AWS
⏯️ Видео: RabbitMQ и чем он отличается от Apache Kafka за 10 минут
#интеграции #очереди #async #сравнение
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
В предыдущих постах мы рассмотрели основы по RabbitMQ и Kafka и собрали полезные материалы для изучения. Перейдём к сравнению, что лучше?
Подход к обмену сообщениями
🔸 В RabbitMQ используется подход push, когда брокер сам активно отправляет сообщения консьюмерам, которые подписаны на очереди. Плюсы: меньше задержка и равномернее нагрузка. Минусы: меньшая гибкость для потребителя и невозможность потребления сообщений пакетами.
▪️ В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
Удаление сообщений из очереди
🔸 В RabbitMQ после получения консьюмерами сообщение удаляется из очереди Благодаря этому одно и то же сообщение может быть обработано только одним консьюмером и не хранится дольше необходимого.
▪️ В Kafka сообщения после прочтения косньюмерами не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Скорость доставки сообщений
🔸 Очереди RabbitMQ работают быстрее всего на относительно небольших объёмах.
▪️ Kafka хранит большие объемы данных с минимальными издержками, поэтому подходит для передачи большого количества сообщений, + поддерживает пакетное потребление сообщений
Масштабируемость
🔸 RabbitMQ может масштабироваться горизонтально, но это требует большего количества настроек и управления
▪️ Kafka легко масштабируется горизонтально, что позволяет добавлять новые брокеры для обработки большего объема данных
Маршрутизация сообщений
🔸 В RabbitMQ все сообщения маршрутизируются через обменник (exchange) перед попаданием в очереди. RabbitMQ предлагает несколько видов маршрутизации с помощью ключей по протоколу AMQP.
▪️ У Kafka упрощённый подход к маршрутизации
Протокол
🔸 RabbitMQ поддерживает несколько стандартизированных протоколов: AMQP, MQTT, STOMP и др. Это позволяет заменить его на любой брокер на основе AMQP.
▪️ Kafka использует собственный двоичный протокол поверх TCP. Вы не сможете так просто удалить или заменить эту платформу, потому что она единственная реализует данный протокол.
Приоритезация сообщений
🔸 RabbitMQ позволяет назначать приоритет сообщениям
▪️ В Kafka приоритет для всех сообщений одинаков и его нельзя изменить. Обходной путь: создать нескольких топиков под сообщения с разным приоритетом, например, events_low, events_medium, events_high, а затем реализовать логику приоритетного чтения на стороне консьюмера.
Выводы
Kafka – это про большие данные и потоковую обработку:
➖ когда в реальном времени требуется обрабатывать огромные куски данных с частотой от тысяч до миллионов сообщений в секунду
➖ когда нужно собирать кучу данных с большого числа источников (например, системы логирования и мониторинга)
➖ когда несколько потребителей должны получить все сообщения (например, в системах подписок).
RabbitMQ подходит для более стандартной очереди или брокера сообщений:
➖ когда нужна сложная маршрутизация сообщений (например, выборочная подписка или публикация)
➖ когда нужно просто передавать краткосрочные сообщения от одного микросервиса к другому
➖ когда нужна поддержка разных протоколов обмена и более зрелый подход к стандартной очереди задач
📎 Ссылки
1. Сравнительный анализ Apache Kafka и RabbitMQ — Хабр, БФТ-Холдинг
2. Чем различаются Kafka и RabbitMQ: простыми словами — Хабр, Иннотех
3. RabbitMQ против Kafka: два разных подхода — Хабр, ITSumma
4. RabbitMQ и Apache Kafka: что выбрать — Слёрм
5. В чем разница между Kafka и RabbitMQ? — AWS
⏯️ Видео: RabbitMQ и чем он отличается от Apache Kafka за 10 минут
#интеграции #очереди #async #сравнение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍3❤2
🫙 Основные понятия баз данных. Главное
Понимание принципов работы и основ проектирования БД – это основа всех hard skills для системного аналитика, а также и для бизнес-аналитика: BABOK упоминает технику моделирования данных как одно из наиболее востребованных умений бизнес-аналитика.
Следует различать БД и СУБД:
➖ База данных (БД) – структурированный набор данных, который хранится на сервере.
➖ Система управления базами данных (СУБД) – это ПО, которая позволяет управлять данными в БД: читать и изменять.
БД могут быть реляционными и нереляционными (подробнее см. пост).
🔹 Реляционные БД хранят информацию в виде таблиц. Между таблицами определяются связи (relations) – создаётся схема данных. Для манипулирования данными применяется специальный язык запросов – SQL. Реляционные БД применяются повсеместно, лучше всего подходят для поддержки транзакций или когда нужно поддерживать строгую структуру данных и соблюдать требования ACID (о них ниже). Примеры реляционных СУБД: MySQL, PostgreSQL, Oracle.
🔸 Нереляционные БД (NoSQL) – это все остальные виды БД, например, ключ-значение, графовые, временных рядов и другие. Все виды нереляционных БД объединяет одно – данные хранятся любым другим способом, кроме таблиц. Из альтернативного названия (NoSQL) Часто применяется там, где нужна высокая скорость (например, для кэширования), требуется работать с большими объёмами данных и обеспечивать лёгкость масштабирования. Примеры нереляционных СУБД: MongoDB, Redis, Cassandra.
Основные понятия реляционных БД
📌 Сущность (entity) – это объект, который имеет смысл в предметной области и может быть представлен в БД. Например, студент, книга, заказ и т.д. Сущности обычно соответствуют таблицам в реляционных БД.
📌 Атрибут (attribute) – это характеристика сущности, которая может быть измерена или описана. Например, сущность Книга имеет название, автора, год издания и т.д. Атрибуты обычно соответствуют столбцам в реляционных БД.
📌 Первичный ключ (primary key) – это атрибут или набор атрибутов, который однозначно идентифицирует каждую сущность в БД. Например, username в телеграме, id страницы ВК и т.д. Первичный ключ не может быть пустым или повторяться в рамках одной таблицы.
📌 Внешний ключ (foreign key) – это атрибут или набор атрибутов, который ссылается на первичный ключ другой сущности. Например,
Транзакционность – важнейшее свойство реляционных БД
Транзакция — это комплекс последовательных операций с применением операторов SQL, имеющих определенную цель. Например, перевод денег между счетами. Ошибка в транзакции может привести к неконсистентности данных: деньги спишутся, но не поступят.
Все транзакции должны отвечать требованиям ACID:
1️⃣ Атомарность (atomicity) — транзакция является неделимым блоком и выполняется или полностью, или никак.
2️⃣ Согласованность (consistency) — завершенная транзакция сохраняет согласованность базы данных.
3️⃣ Изолированность (isolation) — параллельные транзакции не могут влиять друг на друга.
4️⃣ Устойчивость (durability) — никакой сбой в системе не может влиять на результат завершенной транзакции.
Следуя принципу ACID, БД будет целостна только тогда, когда она будет содержать все результаты успешных запросов, выполненных в транзакции. БД гарантирует, что в случае ошибки в транзакции, данные не будут изменены.
Про типы связей и нормализацию данных расскажем в следующих постах. Если вы хотите увидеть эти материалы поскорее, ставьте ⚡️
Ссылки на полезные материалы по основам БД в следующем посте👇
#бд
Понимание принципов работы и основ проектирования БД – это основа всех hard skills для системного аналитика, а также и для бизнес-аналитика: BABOK упоминает технику моделирования данных как одно из наиболее востребованных умений бизнес-аналитика.
Следует различать БД и СУБД:
➖ База данных (БД) – структурированный набор данных, который хранится на сервере.
➖ Система управления базами данных (СУБД) – это ПО, которая позволяет управлять данными в БД: читать и изменять.
БД могут быть реляционными и нереляционными (подробнее см. пост).
🔹 Реляционные БД хранят информацию в виде таблиц. Между таблицами определяются связи (relations) – создаётся схема данных. Для манипулирования данными применяется специальный язык запросов – SQL. Реляционные БД применяются повсеместно, лучше всего подходят для поддержки транзакций или когда нужно поддерживать строгую структуру данных и соблюдать требования ACID (о них ниже). Примеры реляционных СУБД: MySQL, PostgreSQL, Oracle.
🔸 Нереляционные БД (NoSQL) – это все остальные виды БД, например, ключ-значение, графовые, временных рядов и другие. Все виды нереляционных БД объединяет одно – данные хранятся любым другим способом, кроме таблиц. Из альтернативного названия (NoSQL) Часто применяется там, где нужна высокая скорость (например, для кэширования), требуется работать с большими объёмами данных и обеспечивать лёгкость масштабирования. Примеры нереляционных СУБД: MongoDB, Redis, Cassandra.
Основные понятия реляционных БД
📌 Сущность (entity) – это объект, который имеет смысл в предметной области и может быть представлен в БД. Например, студент, книга, заказ и т.д. Сущности обычно соответствуют таблицам в реляционных БД.
📌 Атрибут (attribute) – это характеристика сущности, которая может быть измерена или описана. Например, сущность Книга имеет название, автора, год издания и т.д. Атрибуты обычно соответствуют столбцам в реляционных БД.
📌 Первичный ключ (primary key) – это атрибут или набор атрибутов, который однозначно идентифицирует каждую сущность в БД. Например, username в телеграме, id страницы ВК и т.д. Первичный ключ не может быть пустым или повторяться в рамках одной таблицы.
📌 Внешний ключ (foreign key) – это атрибут или набор атрибутов, который ссылается на первичный ключ другой сущности. Например,
book_id в таблице Заказы ссылается на номер книги id в таблице Книги. Внешний ключ позволяет установить связь между сущностями и гарантировать соблюдение целостности данных. В данном примере с таблицей Заказы мы не можем поместить в столбец такой номер книги book_id, которого нет в таблице Книги – СУБД нам не позволит.Транзакционность – важнейшее свойство реляционных БД
Транзакция — это комплекс последовательных операций с применением операторов SQL, имеющих определенную цель. Например, перевод денег между счетами. Ошибка в транзакции может привести к неконсистентности данных: деньги спишутся, но не поступят.
Все транзакции должны отвечать требованиям ACID:
1️⃣ Атомарность (atomicity) — транзакция является неделимым блоком и выполняется или полностью, или никак.
2️⃣ Согласованность (consistency) — завершенная транзакция сохраняет согласованность базы данных.
3️⃣ Изолированность (isolation) — параллельные транзакции не могут влиять друг на друга.
4️⃣ Устойчивость (durability) — никакой сбой в системе не может влиять на результат завершенной транзакции.
Следуя принципу ACID, БД будет целостна только тогда, когда она будет содержать все результаты успешных запросов, выполненных в транзакции. БД гарантирует, что в случае ошибки в транзакции, данные не будут изменены.
Про типы связей и нормализацию данных расскажем в следующих постах. Если вы хотите увидеть эти материалы поскорее, ставьте ⚡️
Ссылки на полезные материалы по основам БД в следующем посте👇
#бд
⚡25👍22🔥10❤3👏2😁1
🖇 Подборка полезных материалов по основам баз данных
📣 Делитесь с коллегами
🎓 Бесплатные курсы
Наша подборка: список бесплатных онлайн-курсов по базам данных и SQL
+ курс по реляционным БД от Хекслет (теория бесплатно — кликайте на ссылку теория напротив каждой темы либо зарегистрируйтесь)
+ курс Введение в базы данных от ВШЭ и Политеха
+ видеокурс на YouTube Реляционные базы данных. SQL
+ ещё курс лекций на YouTube от Института программных систем
📑 Статьи (теория)
1. Основы баз данных для бизнес-аналитика: краткий ликбез — Babok School
2. Реляционные базы данных — база знаний Yandex Cloud
3. Что такое ACID в базах данных? — подробная статья
3.1 Требования ACID на простом языке
4. О транзакционности
Виды баз данных. Большой обзор типов СУБД — про виды нереляционных БД
5. Руководство по проектированию реляционных баз данных
📝 Статьи (практика)
1. Как выбрать СУБД для работы с большими данными?
2. Как получить информацию о структуре БД для документации
3. Инструкция: как посмотреть ER-модель готовой БД
⏯ Видео и вебинары
1. Основы реляционных баз данных и языка SQL
2. Что такое SQL и реляционные базы данных
📚 Книги
1. Большая подборка книг по БД на любой вкус
2. Основы проектирования БД от ИТМО (73 стр.)
3. Роб Корон. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — огромный талмуд, но основательно
🕹 Онлайн-тренажёры по SQL
🔹 Karpov.courses — тренажёр с исчерпывающими заданиями
🔹 SQL Academy — онлайн тренажер с упражнениями по SQL
🔹 Learn DB — аналог первого
🔹SQL-EX — упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt — пошаговый интерактивный учебник (уроки + упражнения)
🔹 Solve SQL | HackerRank — платформа для практики и изучения языков программирования
🔹 SQL Fiddle — эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server)
🔹 SQL Tutorial — справочник с множеством примеров и упражнений
А ещё коллеги из Systems.Education и NextWay собрали большой каталог ссылок на тему баз данных и анализа данных.
#подборка #бд #sql
📣 Делитесь с коллегами
🎓 Бесплатные курсы
Наша подборка: список бесплатных онлайн-курсов по базам данных и SQL
+ курс по реляционным БД от Хекслет (теория бесплатно — кликайте на ссылку теория напротив каждой темы либо зарегистрируйтесь)
+ курс Введение в базы данных от ВШЭ и Политеха
+ видеокурс на YouTube Реляционные базы данных. SQL
+ ещё курс лекций на YouTube от Института программных систем
📑 Статьи (теория)
1. Основы баз данных для бизнес-аналитика: краткий ликбез — Babok School
2. Реляционные базы данных — база знаний Yandex Cloud
3. Что такое ACID в базах данных? — подробная статья
3.1 Требования ACID на простом языке
4. О транзакционности
Виды баз данных. Большой обзор типов СУБД — про виды нереляционных БД
5. Руководство по проектированию реляционных баз данных
📝 Статьи (практика)
1. Как выбрать СУБД для работы с большими данными?
2. Как получить информацию о структуре БД для документации
3. Инструкция: как посмотреть ER-модель готовой БД
⏯ Видео и вебинары
1. Основы реляционных баз данных и языка SQL
2. Что такое SQL и реляционные базы данных
📚 Книги
1. Большая подборка книг по БД на любой вкус
2. Основы проектирования БД от ИТМО (73 стр.)
3. Роб Корон. Базы данных. Проектирование, реализация и сопровождение. Теория и практика — огромный талмуд, но основательно
🕹 Онлайн-тренажёры по SQL
🔹 Karpov.courses — тренажёр с исчерпывающими заданиями
🔹 SQL Academy — онлайн тренажер с упражнениями по SQL
🔹 Learn DB — аналог первого
🔹SQL-EX — упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt — пошаговый интерактивный учебник (уроки + упражнения)
🔹 Solve SQL | HackerRank — платформа для практики и изучения языков программирования
🔹 SQL Fiddle — эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server)
🔹 SQL Tutorial — справочник с множеством примеров и упражнений
А ещё коллеги из Systems.Education и NextWay собрали большой каталог ссылок на тему баз данных и анализа данных.
#подборка #бд #sql
🔥28👍14❤7⚡2👏2
Типы связей в БД. Нормализация
В предыдущих постах мы коснулись основных понятий БД и собрали ссылки на полезные материалы. Пора написать про типы связей и нормализацию.
Сущности (таблицы) в БД не существуют изолированно друг от друга: между ними устанавливаются связи. Для организации связи используются внешние ключи. Например, таблица Заказы может быть связана с таблицей Книги через поле
Связи между таблицами бывают следующих типов:
1️⃣ Один-к-одному (one-to-one) – одной записи в родительской таблице соответствует одна запись в дочерней. Например, человек может иметь только один паспорт и паспорт может принадлежать только одному человеку. Этот вид связи используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации, однако для чтения связанной информации в нескольких таблицах приходится производить ряд операций чтения вместо одной, когда данные хранятся в одной таблице.
2️⃣ Один-ко-многим (one-to-many) – одной записи родительской таблицы может соответствовать несколько записей дочерней. Например, преподаватель может вести несколько курсов, но каждый курс может вести только один преподаватель. Это самая классическая связь для реляционных БД.
3️⃣ Многие-ко-многим (many-to-many) – каждый экземпляр одной сущности может быть связан с несколькими экземплярами другой сущности и наоборот. Всякую связь "многие–ко–многим" в реляционной базе данных необходимо заменить на связь "один–ко–многим" (одну или более) с помощью введения дополнительных таблиц. Например, студент может записаться на несколько курсов и каждый курс может иметь несколько студентов. Следует добавить новую таблицу Расписание, которое будет связывать таблицы Студенты и Курсы.
Нормализация данных
📌 Нормализация – это организация данных в таблицах таким образом, чтобы устранить дублирование и избыточность данных и тем самым избежать нарушения целостности данных при их изменении (аномалий).
Когда одни и те же данные хранятся в базе в нескольких местах, это приводит к аномалиям, то есть, к расхождениям и противоречиям. Например, если не выполнить операцию в каком-нибудь одном месте, то возникает ситуация, когда одни данные не соответствуют вроде как точно таким же данным в другом месте. Поэтому и нужна нормализация.
Нормализация базы данных выполняется с помощью набора правил. Они называются нормальными формами. Выделяют около 8-ми нормальных форм, но на практике используются первые три. Каждая следующая НФ дополняет предыдущую.
Три нормальные формы:
1️⃣ Информация в каждом поле таблицы является неделимой и не может быть разбита на подгруппы: нет повторяющихся строк и все атрибуты атомарны (простые типы данных)
2️⃣ У таблицы есть первичный ключ, а все остальные поля зависят от всего первичного ключа, но не от его части (если первичный ключ составной)
3️⃣ Все неключевые атрибуты зависят только от первичного ключа и не зависят друг от друга
📎 Материалы
📑 Статьи
1. Разбираем базы данных и язык SQL. (Часть 5 — связи и джоины) — статья на JavaRush про связи в БД с примерами
2. Связи между таблицами SQL — обзор Максима Гритчина про виды джойнов и связей в БД
3. Простыми словами про нормализацию + аудио- видео- ряд
4. Что такое нормализация базы данных — от merion academy
5. Как привести данные в форму — блог Практикума
⏯ Видео
1. Моделирование данных за 9 минут — про типы связей
2. Базы данных. 1,2,3 нормальные формы (10 минут)
3. Нормальные формы базы данных. Три нормальных формы, нормализация и денормализация БД
#бд
В предыдущих постах мы коснулись основных понятий БД и собрали ссылки на полезные материалы. Пора написать про типы связей и нормализацию.
Сущности (таблицы) в БД не существуют изолированно друг от друга: между ними устанавливаются связи. Для организации связи используются внешние ключи. Например, таблица Заказы может быть связана с таблицей Книги через поле
book_id в таблице Заказы, значения которого берутся из поля id таблицы Книги.Связи между таблицами бывают следующих типов:
1️⃣ Один-к-одному (one-to-one) – одной записи в родительской таблице соответствует одна запись в дочерней. Например, человек может иметь только один паспорт и паспорт может принадлежать только одному человеку. Этот вид связи используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации, однако для чтения связанной информации в нескольких таблицах приходится производить ряд операций чтения вместо одной, когда данные хранятся в одной таблице.
2️⃣ Один-ко-многим (one-to-many) – одной записи родительской таблицы может соответствовать несколько записей дочерней. Например, преподаватель может вести несколько курсов, но каждый курс может вести только один преподаватель. Это самая классическая связь для реляционных БД.
3️⃣ Многие-ко-многим (many-to-many) – каждый экземпляр одной сущности может быть связан с несколькими экземплярами другой сущности и наоборот. Всякую связь "многие–ко–многим" в реляционной базе данных необходимо заменить на связь "один–ко–многим" (одну или более) с помощью введения дополнительных таблиц. Например, студент может записаться на несколько курсов и каждый курс может иметь несколько студентов. Следует добавить новую таблицу Расписание, которое будет связывать таблицы Студенты и Курсы.
Нормализация данных
📌 Нормализация – это организация данных в таблицах таким образом, чтобы устранить дублирование и избыточность данных и тем самым избежать нарушения целостности данных при их изменении (аномалий).
Когда одни и те же данные хранятся в базе в нескольких местах, это приводит к аномалиям, то есть, к расхождениям и противоречиям. Например, если не выполнить операцию в каком-нибудь одном месте, то возникает ситуация, когда одни данные не соответствуют вроде как точно таким же данным в другом месте. Поэтому и нужна нормализация.
Нормализация базы данных выполняется с помощью набора правил. Они называются нормальными формами. Выделяют около 8-ми нормальных форм, но на практике используются первые три. Каждая следующая НФ дополняет предыдущую.
Три нормальные формы:
1️⃣ Информация в каждом поле таблицы является неделимой и не может быть разбита на подгруппы: нет повторяющихся строк и все атрибуты атомарны (простые типы данных)
2️⃣ У таблицы есть первичный ключ, а все остальные поля зависят от всего первичного ключа, но не от его части (если первичный ключ составной)
3️⃣ Все неключевые атрибуты зависят только от первичного ключа и не зависят друг от друга
📎 Материалы
📑 Статьи
1. Разбираем базы данных и язык SQL. (Часть 5 — связи и джоины) — статья на JavaRush про связи в БД с примерами
2. Связи между таблицами SQL — обзор Максима Гритчина про виды джойнов и связей в БД
3. Простыми словами про нормализацию + аудио- видео- ряд
4. Что такое нормализация базы данных — от merion academy
5. Как привести данные в форму — блог Практикума
⏯ Видео
1. Моделирование данных за 9 минут — про типы связей
2. Базы данных. 1,2,3 нормальные формы (10 минут)
3. Нормальные формы базы данных. Три нормальных формы, нормализация и денормализация БД
#бд
👍19🔥14❤2👏1
Forwarded from Библиотека Системного Аналитика
DAMA_DMBOK_Svod_znaniy_po_upravleniyu_dannymi_Vtoroe_izdanie_2020.pdf
13.3 MB
DAMA-DMBOK: Свод знаний по управлению данными. Второе издание [2020] на русском
Главная задача книги — определить набор руководящих принципов и описать их применение в функциональных областях управления данными. Издание всесторонне описывает проблемы, возникающие в процессе управления данными, и предлагает способы их решения. В нем подробно описаны широко принятые практики, методы и приемы, функции, роли, результаты и метрики.
Задачи "DAMA-DMBOK2":
● Выработка общепринятого согласованного представления об областях знаний по управлению данными (выделено 11 таких областей);
● Определение руководящих принципов управления данными;
● Предоставление стандартных определений для наиболее часто используемых понятий (общих и по областям знаний);
● Обзор общепринятых лучших практик, широко распространенных методов и методик, а также наиболее известных альтернативных подходов;
● Краткий обзор общих организационных и культурных вопросов;
● Уточнение границ сферы управления данными.
#бд #свод_знаний
Главная задача книги — определить набор руководящих принципов и описать их применение в функциональных областях управления данными. Издание всесторонне описывает проблемы, возникающие в процессе управления данными, и предлагает способы их решения. В нем подробно описаны широко принятые практики, методы и приемы, функции, роли, результаты и метрики.
Задачи "DAMA-DMBOK2":
● Выработка общепринятого согласованного представления об областях знаний по управлению данными (выделено 11 таких областей);
● Определение руководящих принципов управления данными;
● Предоставление стандартных определений для наиболее часто используемых понятий (общих и по областям знаний);
● Обзор общепринятых лучших практик, широко распространенных методов и методик, а также наиболее известных альтернативных подходов;
● Краткий обзор общих организационных и культурных вопросов;
● Уточнение границ сферы управления данными.
#бд #свод_знаний
👍17❤4
🚀 gRPC – краткий обзор
gRPC (Google Remote Procedure Call) – open-source фреймворк для работы с удаленными вызовами процедур. Разработан в 2015 году корпорацией Google на основе парадигмы RPC. Применяется для межсистемной интеграции наряду с REST, SOAP и GraphQL.
Особенности gRPC
Основная фишка gRPC – высокая пропускная способность и снижение нагрузки на сеть. Достигается это благодаря тому, что gRPC использует Protoboof и HTTP/2.
💠 Protobuf (Protocol Buffers) – формат сериализации данных в бинарном формате. Он не является человеко-читаемым, но зато дает высокую производительность и низкую нагрузку на сеть. Поддерживается большинством языков программирования.
💠 HTTP/2 – версия протокола HTTP, который поддерживает двунаправленную потоковую передачу (прямо как веб-сокеты), а также позволяет группировать запросы во фреймы. Это удобно, так как в одном канале может быть замультиплексировано несколько запросов, идущих фреймами Сообщения внутри фреймов можно приоритизировать. Благодаря HTTP/2, не нужно заново устанавливать соединение под каждый запрос, весь обмен данными происходит в одном TCP-соединении
⚙️ Принцип работы gRPC
Коммуникация между клиентом и сервером, для которой используется не HTTP-вызов, а вызов процедуры. Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении, после чего шлет сообщение на сервер. Приняв данные, сервер производит их десериализацию, выполняет запрошенную операцию и шлет результат обратно клиенту. Сериализация и десериализация параметров осуществляется специальными объектами: stub сервера и stub клиента
Разработка начинается строго с контракта: необходимо сначала описать proto-файлы и затем преобразовать контракт в заглушки для реализации клиента. Для этого существует множество плагинов кодогенерации, написанных Google.
🧩 GRPC предусматривает четыре возможных режима взаимодействия сервера и клиента:
1️⃣ Однонаправленное (Unary GRPC), когда после каждого запроса клиент ждет ответа от сервера.
2️⃣ Потоковая передача сервера, когда в ответ на запрос клиента сервер предоставляет поток сообщений.
3️⃣ Потоковая передача клиента, когда сервер принимает поток сообщений от клиента и отвечает одним подтверждающим сообщением.
4️⃣ Двунаправленный обмен (дуплексный) с разделением каналов передачи сервера и клиента. В этом случае потоки сообщений одновременно передаются в обоих направлениях.
🚧 Ограничения
1. Высокий порог входа. Требуется больше времени и усилий для настройки и развертывания
2. Vendor lock. Google является основным драйвером и определяет направление развития протокола.
3. Сложности балансировки нагрузки. Так как в gRPC устанавливается постоянное соединение с одним сервисом, то неважно, сколько экземпляров сервиса запущено: запросы не будут перераспределяться между экземплярами сервиса.
4. В gRPC не поддерживается трассировка запросов
5. Сообщения в protoboof нечеловекочитаемы
🛠 Применение
gRPC следует использовать, когда критически важна высокая пропускная способность и производительность при низких требованиях к сети, аппаратным ресурсам, например, платформы интернета вещей. Так же gRPC очень хорош для общения микросервисов в MSA.
В следующем посте сравним REST и gRPC по пунктам.
📑 Материалы
1. Что нужно знать о gRPC системному аналитику
2. Что такое gRPC и как он работает — обзорная статья Highload Today
3. Объяснение буферов протокола, потоковой передачи и архитектуры
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API — Babok School
5. gRPC на практике: особенности, преимущества и недостатки — Хабр
#api #интеграции
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
gRPC (Google Remote Procedure Call) – open-source фреймворк для работы с удаленными вызовами процедур. Разработан в 2015 году корпорацией Google на основе парадигмы RPC. Применяется для межсистемной интеграции наряду с REST, SOAP и GraphQL.
Особенности gRPC
Основная фишка gRPC – высокая пропускная способность и снижение нагрузки на сеть. Достигается это благодаря тому, что gRPC использует Protoboof и HTTP/2.
💠 Protobuf (Protocol Buffers) – формат сериализации данных в бинарном формате. Он не является человеко-читаемым, но зато дает высокую производительность и низкую нагрузку на сеть. Поддерживается большинством языков программирования.
💠 HTTP/2 – версия протокола HTTP, который поддерживает двунаправленную потоковую передачу (прямо как веб-сокеты), а также позволяет группировать запросы во фреймы. Это удобно, так как в одном канале может быть замультиплексировано несколько запросов, идущих фреймами Сообщения внутри фреймов можно приоритизировать. Благодаря HTTP/2, не нужно заново устанавливать соединение под каждый запрос, весь обмен данными происходит в одном TCP-соединении
⚙️ Принцип работы gRPC
Коммуникация между клиентом и сервером, для которой используется не HTTP-вызов, а вызов процедуры. Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении, после чего шлет сообщение на сервер. Приняв данные, сервер производит их десериализацию, выполняет запрошенную операцию и шлет результат обратно клиенту. Сериализация и десериализация параметров осуществляется специальными объектами: stub сервера и stub клиента
Разработка начинается строго с контракта: необходимо сначала описать proto-файлы и затем преобразовать контракт в заглушки для реализации клиента. Для этого существует множество плагинов кодогенерации, написанных Google.
🧩 GRPC предусматривает четыре возможных режима взаимодействия сервера и клиента:
1️⃣ Однонаправленное (Unary GRPC), когда после каждого запроса клиент ждет ответа от сервера.
2️⃣ Потоковая передача сервера, когда в ответ на запрос клиента сервер предоставляет поток сообщений.
3️⃣ Потоковая передача клиента, когда сервер принимает поток сообщений от клиента и отвечает одним подтверждающим сообщением.
4️⃣ Двунаправленный обмен (дуплексный) с разделением каналов передачи сервера и клиента. В этом случае потоки сообщений одновременно передаются в обоих направлениях.
🚧 Ограничения
1. Высокий порог входа. Требуется больше времени и усилий для настройки и развертывания
2. Vendor lock. Google является основным драйвером и определяет направление развития протокола.
3. Сложности балансировки нагрузки. Так как в gRPC устанавливается постоянное соединение с одним сервисом, то неважно, сколько экземпляров сервиса запущено: запросы не будут перераспределяться между экземплярами сервиса.
4. В gRPC не поддерживается трассировка запросов
5. Сообщения в protoboof нечеловекочитаемы
🛠 Применение
gRPC следует использовать, когда критически важна высокая пропускная способность и производительность при низких требованиях к сети, аппаратным ресурсам, например, платформы интернета вещей. Так же gRPC очень хорош для общения микросервисов в MSA.
В следующем посте сравним REST и gRPC по пунктам.
📑 Материалы
1. Что нужно знать о gRPC системному аналитику
2. Что такое gRPC и как он работает — обзорная статья Highload Today
3. Объяснение буферов протокола, потоковой передачи и архитектуры
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API — Babok School
5. gRPC на практике: особенности, преимущества и недостатки — Хабр
#api #интеграции
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤5🔥5😢1
🆚 gRPC vs REST: сравнение по пунктам
Ранее мы уже делали посты про REST и SOAP, а также сравнивали их по пунктам. А
в предыдущем посте мы рассмотрели основные аспекты gRPC. Теперь сравним его с REST, чтобы понять, когда что использовать для проектирования API.
Protobuf вместо JSON / XML
🔹 Обычно в REST используются форматы сообщений JSON / XML / YAML. Такой формат удобен и понятен для человека, но обратная сторона этого – скорость передачи сообщений
🔸 В gRPC использует двоичный формат обмена сообщениями Protobuf . За счёт сжатия и бинарной сериализации это позволяет увеличить скорость передачи сообщений в разы. Обратная сторона – формат Protobuf нечеловекочитаем
HTTP/2 вместо HTTP 1/1
🔹 Обычно в REST API используются HTTP 1/1, который предполагает взаимодействие по типу запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы.
🔸 gRPC использует HTTP/2 и позволяет группировать запросы в пакеты и, самое главное, устанавливать двунаправленное соединение. Теперь, когда микросервис получает несколько запросов от более чем одного клиента, он может обслуживать их одновременно и отдавать ответы в режиме реального времени. Клиенту не нужно отправлять несколько запросов последовательно, открывая для каждого запроса новое TCP-соединение (см. модель OSI)
gRPC строго определяет контракт
🔹 В REST не даёт чёткого определения того, как должны быть описаны контракты. Да, можно использовать OpenAPI и Swagger для генерации кода, но на практике такое встречается нечасто, в том числе в силу объективных причин. Обычно наоборот: из кода генерируют сваггер и вставляют в Confluence. У кого есть опыт на этот счёт, пишите в комменты!
🔸 В gRPC есть строгое определение того, как должны выглядеть запросы и ответы. Контракт определяется в файле .proto, который описывает типы сообщений и сервисы, которые предоставляются. Затем proto-файлы клиент может преобразовать в заглушки с помощью готовых плагинов кодогенерации от Google для разных языков программирования
gRPC API дольше реализовывать
🔹 REST – это мейнстрим и огромное коммьюнити, лёгкость и простота. Существует множество фреймворков и библиотек, которые упрощают разработку и тестирование REST API.
🔸 gRPC требует гораздо более серьёзного погружения и менее распространён. Для создания gRPC API необходимо использовать специальный формат данных Protobuf и определять контракты в файлах .proto. Также нужно учитывать особенности HTTP/2 и потоковой передачи данных.
Итак, что выбрать
Таким образом, gRPC не является полной заменой REST во всех кейсах. API на gRPC может оказаться лучше REST в следующих случаях:
1️⃣ Общение микросервисов между собой: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
2️⃣ Системы где используется несколько языков программирования благодаря поддержке генерации собственного кода для широкого спектра языков разработки
3️⃣ Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
4️⃣ Сети с низким энергопотреблением и низкой пропускной способностью, например, IoT: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость по сравнению с JSON.
Статьи
1. gRPC vs REST, что выбрать для нового сервера? — Хабр. Есть также видео
2. Сравнение от Amazon
Видео
1. gRPC vs REST, что выбрать для нового сервера? — видео о статье 1
2. gRPC vs REST. Плюсы и минусы на примере реального проекта
#api #интеграции #сравнение
Ранее мы уже делали посты про REST и SOAP, а также сравнивали их по пунктам. А
в предыдущем посте мы рассмотрели основные аспекты gRPC. Теперь сравним его с REST, чтобы понять, когда что использовать для проектирования API.
Protobuf вместо JSON / XML
🔹 Обычно в REST используются форматы сообщений JSON / XML / YAML. Такой формат удобен и понятен для человека, но обратная сторона этого – скорость передачи сообщений
🔸 В gRPC использует двоичный формат обмена сообщениями Protobuf . За счёт сжатия и бинарной сериализации это позволяет увеличить скорость передачи сообщений в разы. Обратная сторона – формат Protobuf нечеловекочитаем
HTTP/2 вместо HTTP 1/1
🔹 Обычно в REST API используются HTTP 1/1, который предполагает взаимодействие по типу запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы.
🔸 gRPC использует HTTP/2 и позволяет группировать запросы в пакеты и, самое главное, устанавливать двунаправленное соединение. Теперь, когда микросервис получает несколько запросов от более чем одного клиента, он может обслуживать их одновременно и отдавать ответы в режиме реального времени. Клиенту не нужно отправлять несколько запросов последовательно, открывая для каждого запроса новое TCP-соединение (см. модель OSI)
gRPC строго определяет контракт
🔹 В REST не даёт чёткого определения того, как должны быть описаны контракты. Да, можно использовать OpenAPI и Swagger для генерации кода, но на практике такое встречается нечасто, в том числе в силу объективных причин. Обычно наоборот: из кода генерируют сваггер и вставляют в Confluence. У кого есть опыт на этот счёт, пишите в комменты!
🔸 В gRPC есть строгое определение того, как должны выглядеть запросы и ответы. Контракт определяется в файле .proto, который описывает типы сообщений и сервисы, которые предоставляются. Затем proto-файлы клиент может преобразовать в заглушки с помощью готовых плагинов кодогенерации от Google для разных языков программирования
gRPC API дольше реализовывать
🔹 REST – это мейнстрим и огромное коммьюнити, лёгкость и простота. Существует множество фреймворков и библиотек, которые упрощают разработку и тестирование REST API.
🔸 gRPC требует гораздо более серьёзного погружения и менее распространён. Для создания gRPC API необходимо использовать специальный формат данных Protobuf и определять контракты в файлах .proto. Также нужно учитывать особенности HTTP/2 и потоковой передачи данных.
Итак, что выбрать
Таким образом, gRPC не является полной заменой REST во всех кейсах. API на gRPC может оказаться лучше REST в следующих случаях:
1️⃣ Общение микросервисов между собой: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
2️⃣ Системы где используется несколько языков программирования благодаря поддержке генерации собственного кода для широкого спектра языков разработки
3️⃣ Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
4️⃣ Сети с низким энергопотреблением и низкой пропускной способностью, например, IoT: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость по сравнению с JSON.
Статьи
1. gRPC vs REST, что выбрать для нового сервера? — Хабр. Есть также видео
2. Сравнение от Amazon
Видео
1. gRPC vs REST, что выбрать для нового сервера? — видео о статье 1
2. gRPC vs REST. Плюсы и минусы на примере реального проекта
#api #интеграции #сравнение
🔥11❤3👍2
🏆 Лучшие практики проектирования API
В названиях путей к эндпоинтам используем имена, а не глаголы
В метода HTTP-запроса уже содержится глагол. Ставить глаголы в названиях путей к конечной точке API не добавит никакой ценной информации
✅
Соблюдаем единообразие интерфейсов (принцип REST №4)
✅
Если есть сущности, которые состоят из других сущностей, то нужно показать это в адресе ресурса. Это поможет понять структуру и связи между сущностями.
✅
Существует много кодов HTTP. Важно, чтобы HTTP-код был верным
✅ возвращать код 200, когда всё ОК и запрос отработал без ошибок
✅ “пятисотить” только в случае аварийной ситуации/багов/исключений на нашей стороне
✅ по коду HTTP понятно состояние запроса, например, 404 – не найдено
❌ возвращать код 200 с информацией об ошибке в body
❌ возвращать код 5xx, когда получена стандартная ошибка
❌ всегда возвращать коды 400 или 500 без использования разнообразия
Используем уместные HTTP-методы
GET – получение данных о ресурсах
POST – создание новых ресурсов
PUT – полное обновление существующих ресурсов
PATCH – обновление только определённых полей уже существующих ресурсов
DELETE – удаление ресурса
Используем пагинацию/оффсеты для массивных данных
Если у нас есть метод, который, например, возвращает список всех заказов, то не стоит вытягивать все данные за один раз. Вместо этого лучше добавить пагинацию или оффсет, чтобы извлекать часть данных и не создавать лишнюю нагрузку
Кэшируем данные для улучшения производительности
В некоторых случаях может быть полезно сохранять в быстрой памяти (например, в Redis) данные вместо того, чтобы каждый раз выполнять ряд сложных запросов к БД или внешним системам (см. наш пост про кэширование).
Применяем версионирование API
У нас должны быть различные версии API на тот случай, если мы вносим в них такие изменения, которые могут нарушить работу клиента. Так мы можем соблюсти требование обратной совместимости.
Например, есть метод публикации статьи, который уже на проде и используется несколькими потребителями. Необходимо добавить новый обязательный параметр в теле входящего запроса:
✅ Создать новую версию API метода
❌ Выкатить изменения сразу на
Ещё несколько рекомендаций
❌ Передавать токены аутентификации в URL или в body
✅ Передавать токены аутентификации в заголовках
✅ Использовать kebab-case для URL и camelCase для параметров
✅ Использовать даты в формате ISO 8601. Отображение дат в конкретном часовом поясе – задача клиента.
✅ Возвращать созданные ресурсы после POST. Это поможет клиенту, например, узнать сгенерированный ID и не делать лишних запросов
✅ Используйте PUT, если нужно заменить ресурс целиком. Используйте PATCH, если нужно изменить в ресурсе лишь часть данных.
📎 Статьи
1. Наилучшие практики создания REST API — Habr
2. RESTful web API design — Microsoft
3. Как проектировать веб-API: 7 самых важных вопросов — Babok School
4. Best Practices, которые стоит использовать при проектировании REST API — советы от ведущего системного аналитика
5. Как построить REST-like API в крупном проекте — опыт от ЮMoney
6. Рекомендации по REST API — примеры Habr
⏯ Видео
1. Проектирование API в терминах RESTful — доклад Алексея Романова на конференции Analyst Days EA #1
2. Паттерны проектирования API — доклад Андрея Буракова из VK Pay на конференции Analyst Days-12 (скачать .pptx)
3. Как аналитику спроектировать свой REST API — демо-занятие курса от OTUS
📚 Книги
1. Джей Гивакс. Паттерны проектирования API
2. Арно Лоре. Проектирование веб-API
3. Сергей Константинов. API
#api #интеграции #проектирование
В названиях путей к эндпоинтам используем имена, а не глаголы
В метода HTTP-запроса уже содержится глагол. Ставить глаголы в названиях путей к конечной точке API не добавит никакой ценной информации
✅
GET /v1/articles/{id}
❌ POST /v1/get-article/{id}
Коллекции называем существительными во множественном числеСоблюдаем единообразие интерфейсов (принцип REST №4)
✅
GET /v1/articles/{id}
❌ GET /v1/article/{id}
Иерархия сущностей должны отражаться в URLЕсли есть сущности, которые состоят из других сущностей, то нужно показать это в адресе ресурса. Это поможет понять структуру и связи между сущностями.
✅
GET /v1/articles/{id}/comments
❌ GET /v1/article-comments?article_id={id}
Используем подходящие коды ошибокСуществует много кодов HTTP. Важно, чтобы HTTP-код был верным
✅ возвращать код 200, когда всё ОК и запрос отработал без ошибок
✅ “пятисотить” только в случае аварийной ситуации/багов/исключений на нашей стороне
✅ по коду HTTP понятно состояние запроса, например, 404 – не найдено
❌ возвращать код 200 с информацией об ошибке в body
❌ возвращать код 5xx, когда получена стандартная ошибка
❌ всегда возвращать коды 400 или 500 без использования разнообразия
Используем уместные HTTP-методы
GET – получение данных о ресурсах
POST – создание новых ресурсов
PUT – полное обновление существующих ресурсов
PATCH – обновление только определённых полей уже существующих ресурсов
DELETE – удаление ресурса
Используем пагинацию/оффсеты для массивных данных
Если у нас есть метод, который, например, возвращает список всех заказов, то не стоит вытягивать все данные за один раз. Вместо этого лучше добавить пагинацию или оффсет, чтобы извлекать часть данных и не создавать лишнюю нагрузку
Кэшируем данные для улучшения производительности
В некоторых случаях может быть полезно сохранять в быстрой памяти (например, в Redis) данные вместо того, чтобы каждый раз выполнять ряд сложных запросов к БД или внешним системам (см. наш пост про кэширование).
Применяем версионирование API
У нас должны быть различные версии API на тот случай, если мы вносим в них такие изменения, которые могут нарушить работу клиента. Так мы можем соблюсти требование обратной совместимости.
Например, есть метод публикации статьи, который уже на проде и используется несколькими потребителями. Необходимо добавить новый обязательный параметр в теле входящего запроса:
✅ Создать новую версию API метода
POST /v2/articles и добавить новый параметр туда, а POST /v1/articles оставить без изменений❌ Выкатить изменения сразу на
POST /articles без всякого версионирования, чтобы потребителям жилось веселееЕщё несколько рекомендаций
❌ Передавать токены аутентификации в URL или в body
✅ Передавать токены аутентификации в заголовках
✅ Использовать kebab-case для URL и camelCase для параметров
✅ Использовать даты в формате ISO 8601. Отображение дат в конкретном часовом поясе – задача клиента.
✅ Возвращать созданные ресурсы после POST. Это поможет клиенту, например, узнать сгенерированный ID и не делать лишних запросов
✅ Используйте PUT, если нужно заменить ресурс целиком. Используйте PATCH, если нужно изменить в ресурсе лишь часть данных.
📎 Статьи
1. Наилучшие практики создания REST API — Habr
2. RESTful web API design — Microsoft
3. Как проектировать веб-API: 7 самых важных вопросов — Babok School
4. Best Practices, которые стоит использовать при проектировании REST API — советы от ведущего системного аналитика
5. Как построить REST-like API в крупном проекте — опыт от ЮMoney
6. Рекомендации по REST API — примеры Habr
⏯ Видео
1. Проектирование API в терминах RESTful — доклад Алексея Романова на конференции Analyst Days EA #1
2. Паттерны проектирования API — доклад Андрея Буракова из VK Pay на конференции Analyst Days-12 (скачать .pptx)
3. Как аналитику спроектировать свой REST API — демо-занятие курса от OTUS
📚 Книги
1. Джей Гивакс. Паттерны проектирования API
2. Арно Лоре. Проектирование веб-API
3. Сергей Константинов. API
#api #интеграции #проектирование
🔥19👍13❤3🤣2