🧼 SOAP. Краткий обзор

SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.

Протокол SOAP обычно использует HTTP в качестве транспорта (SOAP over HTTP). Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP. Сообщения передаются POST-запросами.

Структура XML-сообщения

> Envelope — корневой элемент, который определяет сообщение и пространство имен, использованное в документе.

> Header — содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.

> Body — содержит сообщение, которым обмениваются приложения.

> Fault — необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.

Все данные в SOAP-сообщении размечаются <тегами>. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают <открывающие> (перед данными) и </закрывающие>.

Как понять, какие теги использовать? А это как раз описывается отдельно – в файле WSDL.

WSDL (Web Services Denoscription Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML. В SOAP для описания своего сервиса нужно использовать строгие правила в виде файла WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как составить запрос, на какой эндпоинт его отправлять, как прочитать ответ.

Для каждого веб-сервиса SOAP есть только одна конечная точка (endpoint). Эта конечная точка может иметь несколько функций. Какие у сервиса есть функции и по каким правилам их использовать также описывается в WSDL-файле.

✅ Преимущества SOAP
1. Наличие официального стандарта
2. Наличие встроенного механизма обработки ошибок

❌ Недостатки SOAP
1. Сложность использования ввиду необходимости придерживаться строгого стандарта и правил
2. Низкая скорость обработки из-за избыточного объёма передаваемых сообщений

Применение SOAP

В настоящее время SOAP применяется в системах, где требуется жёсткая стандартизация и соблюдение строгих правил безопасности. Например, госструктуры, банкинг, финансы, здравоохранение.

В остальном SOAP теряет популярность и применяется в legacy-системах.

📎Материалы по теме
1. Применение SOAP при интеграции систем: статья и вебинар
2. Официальный учебник по SOAP на русском от w3.org
3. Пример API: Взаимодействие с API Яндекс Директа по протоколу SOAP
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API
5. SOAP API — обзорная мини-статья
6. Вебинар: Что такое SOAP, WSDL, XSD / Урок 28 / Тестировщик с нуля

#интеграции #api

🆚 REST vs SOAP. Главное

Определение
🔹 SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт.
🔸 REST – это архитектурный стиль, а не протокол. REST лишь определяет набор принципов и ограничений.

Протокол
🔹 SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. Но в большинстве случаев SOAP использует HTTP в качестве транспорта (SOAP over HTTP).
🔸 REST, как правило, хотя и не обязательно, использует HTTP. С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST Рэй Филдинг также является соавтором HTTP.

Формат сообщений
🔹 SOAP работает только с XML
🔸 В REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие

Подход к API
🔹 SOAP основан на подходе удалённого вызова процедур (RPC). Это вызов функции в коде, только по сети. Например, чтобы получить информацию о заказе, нужно вызвать SOAP-метод getOrder, чтобы оформить заказ – makeOrder и т.д.
🔸 REST фокусируется на ресурсах, доступ к которым осуществляется через URL. Это значит, например, что наш интернет-заказ имеет URI — /api/v1/order. Если мы хотим получить информацию о заказе, нужно вызвать HTTP метод GET /api/v1/order, чтобы оформить заказ, вызовем POST /api/v1/order. В обоих случаях ресурс один и тот же, а методы работы с ним разные.

Производительность
🔹 SOAP работает медленнее из-за избыточного объёма передаваемых сообщений
🔸 REST быстрее благодаря кэшированию (принцип №3) и меньшему размеру сообщений

Гибкость
🔹 SOAP сложнее масштабировать и вносить изменения. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие, что усложняет масштабирование
🔸 REST проще масштабировать, так как сервер не сохраняет состояние клиента, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.

Простота
🔹 SOAP сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Реализация SOAP API требует описания WSDL для каждого сервиса, обрабатывать и анализировать XML сложнее.
🔸 REST проще в реализации и более “человекопонятен”. Он не привязан к XML и чаще всего использует JSON.

Обработка ошибок
🔹 В протокол SOAP встроена логика обработки ошибок. SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
🔸 REST использует протокол HTTP, который может возвращать коды состояний

Раскрытие API
🔹 SOAP-сервис всегда должен иметь WSDL. Плюс этого в том, что WSDL даёт чёткие правила, как отправлять и по какой структуре отправлять запросы и принимать ответы
🔸 REST не имеет языка описания веб-сервисов. Однако на помощь приходит Swagger (OpenAPI)

Безопасность
🔹 SOAP имеет встроенное расширение безопасности – WS Security, которое регулирует процедуры конфиденциальности и аутентификации для обмена сообщениями
🔸 REST не предусматривает никаких специальных мер безопасности. Безопасность REST может быть обеспечена только за счет HTTPS

Использование
🔹 SOAP применяется в системах, где нужна жёсткая стандартизация, а также в legacy
🔸 REST используется повсеместно


📌 Выводы
SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Каждая задача сама диктует наиболее разумный подход к интеграции.

📎 Полезные материалы
1. О REST на нашем канале
2. Про SOAP
3. Статья про разницу SOAP и REST от Amazon (на русском)
4. SOAP и REST API: Ключевые различия, объясненные для новичков
5. REST vs SOAP на Medium (через VPN)
6. Что происходит, когда мы отправляем SOAP или REST запрос — 3,5 минуты видео

#api #интеграции #сравнение

Сравнение REST vs SOAP картинкой для Вашего удобства #сравнение

🏭 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 (скачать презентацию)

#инструменты #подборка

24 сентября — День Системного Аналитика, наш профессиональный праздник.

Нас поздравляет само ChatGPT

Основы 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

Подборка бесплатных материалов по 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

🐇 Основы 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
📢 Делитесь с коллегами

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

Юрий Химонин. Сбор и анализ требований к программному продукту

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

На своем канале Pro анализ в ИТ Иннокентий Бодров, аналитик и менеджер продукта с 15-летним стажем, делится полезными материалами по созданию ИТ продуктов и систем, развитию и росту аналитиков, работе аналитиков в РФ и других странах.
👨‍💻 Ревью статьи Евгения Скорикова про проработку нефункциональных требований

🎥 Эфир про работу аналитика в Нидерландах

📶 Обсуждение KPI аналитика

Также подготовили сравнение RabbitMQ vs Kafka в табличном виде
#сравнение

🫙 Основные понятия баз данных. Главное

Понимание принципов работы и основ проектирования БД – это основа всех 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, БД будет целостна только тогда, когда она будет содержать все результаты успешных запросов, выполненных в транзакции. БД гарантирует, что в случае ошибки в транзакции, данные не будут изменены.

Про типы связей и нормализацию данных расскажем в следующих постах. Если вы хотите увидеть эти материалы поскорее, ставьте ⚡️

Ссылки на полезные материалы по основам БД в следующем посте👇

#бд

🖇 Подборка полезных материалов по основам баз данных
📣 Делитесь с коллегами

🎓 Бесплатные курсы
Наша подборка: список бесплатных онлайн-курсов по базам данных и 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

Типы связей в БД. Нормализация

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

Сущности (таблицы) в БД не существуют изолированно друг от друга: между ними устанавливаются связи. Для организации связи используются внешние ключи. Например, таблица Заказы может быть связана с таблицей Книги через поле 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. Нормальные формы базы данных. Три нормальных формы, нормализация и денормализация БД

#бд

DAMA-DMBOK: Свод знаний по управлению данными. Второе издание [2020] на русском

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

Задачи "DAMA-DMBOK2":
● Выработка общепринятого согласованного представления об областях знаний по управлению данными (выделено 11 таких областей);
● Определение руководящих принципов управления данными;
● Предоставление стандартных определений для наиболее часто используемых понятий (общих и по областям знаний);
● Обзор общепринятых лучших практик, широко распространенных методов и методик, а также наиболее известных альтернативных подходов;
● Краткий обзор общих организационных и культурных вопросов;
● Уточнение границ сферы управления данными.

#бд #свод_знаний

🆚 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 #интеграции #сравнение