Кому будет интересен контент канала?

В первую очередь - это системные и бизнес аналитики, т.к. этот канал посвящен именно бизнес и системному анализу в ИТ.

Аналитики здесь могут найти много полезной информации: от теоретических материалов до гайдов, практических заданий и разборов проектов.

Стараюсь делать контент канала максимально разнообразным, поэтому канал будет интересен всем специалистам из ИТ сферы любого грейда.

Присоединяйтесь к каналу, давайте расти вместе!

Навигация по каналу:
📌#ITA_requirements
📌#ITA_process_modeling
📌#ITA_databases
📌#ITA_integration
📌#ITA_architecture
📌#ITA_interview_questions
📌#ITA_projects
📌#ITA_news
📌#ITA_books
📌#ITA_podcast
📌#ITA_life

Как структурировать свои знания с помощью mindmap?

В последнее время изучаю много разной информации из области системного анализа. Для лучшего усвоения нового материала решил составить mindmap для системного аналитика. Читал, что такой подход к изучению позволяет структурировать знания и запоминать больше информации. Чтож, предлагаю проверить...

Сейчас mindmap находится в процессе разработки, и пока я добавил только основные темы. Как думаете, что можно ещё добавить на карту системного аналитика? Буду ждать ваши предложения в комментариях к посту

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

Только сейчас понял, что комментарии к посту выше были выключены. Исправил ситуацию :)
Написать комментарий к предыдущему посту можно тут 👇

О системном мышлении:
Читал недавно две довольно популярных книг про системное мышление (обложки книг прикрепил к посту). Как по мне, мало только поверхностно прочитать эти книги. Чтобы понять, что хочет донести автор и научится видеть зависимости в реальной жизни нужен более глубокий анализ литературы.
Возможно, чуть позже сделаю статью с основными принципами из книг.
IMHO обе книги интересные, хотя местами и пересекаются по темам. Тем, кто ещё не читал - советую.

#моделирование_процессов

Нашёл прикольную шпаргалку с основными элементами BPMN.

А также немного полезного контента про моделирование в нотации BPMN:

Первое - Канал про BPMN

И второе - Статья на habr с описанием основных сущностей нотации

#базы_данных

Интересная статья про индексы в БД. Понравилась подача материала. Как говорится: "простыми словами о сложном".
Статья в посте ниже 👇

Индексы в БД на пальцах

На последних нескольких интервью, к моему удивлению, кандидаты не смогли внятно ответить на вопрос, что такое индекс в бд. Поэтому хочу привести несколько базовых тезисов и в конце - довольно интересную статью с Хабра, где рассказано о разных типах индексов.

🔹 Что такое индекс? Это вспомогательная структура данных, которая создается средствами СУБД и хранит информацию о расположении (или адресе) строки в таблице с некоторым значением поля. Индексы строятся для каждого поля отдельно: можно построить по индексу на каждое поле таблицы, если в этом есть необходимость.

🔹 Зачем нужны индексы? Для ускорения поиска. Без индекса СУБД вынуждена перебирать все строки в таблице в поисках нужной; индекс позволяет быстро узнать местоположение этой строки и перейти сразу к ней. Аналог из жизни - статья в журнале или глава из книги: вместо того, чтобы перелистывать все страницы, вы ищете название в оглавлении и переходите к нужной странице.

🔹 Как работают индексы? Индексы можно упрощенно представить себе как отсортированные копии полей (столбцов таблицы). Поиск значения в отсортированной структуре происходит очень быстро - вы быстрее найдете старницу номер 742 в книге из 1000 страниц, чем бубновую девятку в перетасованной колоде карт, потому что карты нужно перебирать, а номера страниц отсортированы. Найдя значение поля в индексе, СУБД получит информацию об адресе всей строки таблицы (которая там была сохранена при создании индекса), то есть "перейдет по номеру страницы", если сравнивать с книгами.

🔹Минусы и особенности. Помимо очевидноно плюса в виде ускорения поиска, есть ряд особенностей, которые нужно иметь ввиду.
1. Индексы - это дополнительные структуры данных, которые нужно хранить, следовательно, они занимают дисковое пространство, особенно это важно учитывать при работе с большими таблицами (хотя именно там они наиболее эффективны).
2. Если мы меняем значения в таблице (включая добавление и удаление строк), то это будет происходить в двух местах: в самой таблице и в индексе, то есть у нас немного замедляется модификация таблиц. Для задач с большим количеством изменений это может быть ощутимо.
3. Неправильно выбранный тип индекса может замедлить поиск. Например, индексы в виде деревьев неэффективны для столбцов с низкой мощностью множества*

🔹Когда использовать индексы? Строить индексы нужно только по тем полям, по которым осуществляется поиск. Идеальный случай - данные в таблице меняются редко, а запрашиваются часто. Контрпример - таблица, которая представляет собой журнал аудита, куда данные пишутся постоянно всей системой, а читаются только в случае инцидентов и нет высоких требований к скорости поиска. В этом случае использование индекса только навредит: будет тратиться лишнее дисковое пространство и запись будет чуть медленнее.

* Мощность множества или Cardinality - это характеристка, показывающая уникальность данных, входящих в множество. Если у нас есть миллион строк для поля Gender, которые содержат только значения Male и Female, то говорят, что у такого множества низкая мощность. А поле Email с уникальными данными будет иметь высокую мощность.

Подробнее о типах индексов можно почитать в этой статье на хабре

#СУБД #собеседование

Друзья, привет! 👋

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

Что такое шаблоны взаимодействия ? 🤔

Шаблоны взаимодействия - это способы, с помощью которых организуется среда «общения» АС. И эти способы задают формат взаимодействия. В качестве аналогии из жизни можно использовать формат встречи - совещание, вечеринка и т.д. 🥳
Другими словами шаблоны отвечают на вопрос, «какую среду организовать для «общения» АС?»

Типы шаблонов взаимодействия:

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

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

3. Сервисная шина предприятия (англ. enterprise service bus, ESB) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры. Другими словами, это промежуточное ПО, которое позволяет объединить большее число систем или приложений, а также организовать взаимодействия между ними на основе сервисов
Преимущества: производительность, готовая реализация интеграции, унифицированное решение, возможность переиспользования
Недостатки: сложность управления, сложность изменения, сложность поиска всех взаимодействий при большом их количестве, дополнительная точка отказа, команда сопровождения

4. Service mesh — шаблон для динамического связывания сервисов, в особенности микросервисов, из которых формируется одно приложение. Это выделенный слой инфраструктуры для обеспечения безопасного, быстрого и надёжного взаимодействия между сервисами.
Преимущества: производительность, гибкость, масштабируемость
Недостатки: дополнительная точка отказа, команда сопровождения с достаточными знаниями для создания и использования этого шаблона

5. Перегрузка данных — это специфический шаблон для передачи большого объема данных. Процесс перегрузки заключается в переносе данных из системы источника в систему потребителя или хранилище данных с помощью специализированных средств (например, ETL (от англ. Extract, Transform, Load) или промежуточное ПО)

А с какими шаблонами взаимодействия приходилось сталкивать вам на практике ?
Делитесь своим опытом в комментариях 👇

PS Относительно давно не было постов на канале, но буду исправлять эту ситуацию и стараться выкладывать полезный контент чаще 😊
PSS Ваши реакции мотивируют меня на новые посты 🔥

Хорошая наглядная иллюстрация к предыдущему сообщения 🔥

#базы_данных

Про оптимизацию sql запросов

Зачастую на практике мне (думаю, что вам тоже) приходится сталкиваться с написанием сложных sql запросов, а потом долгое время ожидать выполнения запроса и пить кофе ☕️

Чтобы уменьшить время наслаждения вкусным ароматом кофе и сократить время работы запросов предлагаю ознакомиться со следующей статьей. В ней рассказывают про разные подходы к оптимизации sql запросов.

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

Можем сыграть в игру "самый долгий sql запрос". Пишите в комментарии самое долгое время выполнения запроса 😄
Победителю - подарок 🎁

Друзья, доброе утро!
Количество участников канала стало трехзначным числом. Спасибо всем, кто следит за каналом и интересуется его новостями.
Всем хорошего дня 😊

Начинаем новую неделю с серии постов про подходы к проектированию баз данных 🔥

Что такое ACID и BASE в теории баз данных ?

BASE (Basically Available, Soft state, Eventually consistent) и ACID (Atomicity, Consistency, Isolation, Durability) - это два разных подхода к проектированию и обеспечению целостности данных в распределенных системах.

ACID - это классический подход к управлению транзакциями в реляционных базах данных, который обеспечивает высокий уровень согласованности и надежности данных. ACID-транзакции являются “жесткими”, так как они гарантируют, что транзакция либо полностью выполнится, либо откатится к исходному состоянию в случае сбоя, что обеспечивает согласованность данных.

BASE, с другой стороны, является более гибким подходом, который учитывает ограничения и неизбежность ошибок в распределенных системах. BASE поддерживает высокую доступность и отказоустойчивость путем снижения требований к согласованности данных. Это достигается за счет того, что база данных может находиться в промежуточном состоянии - состоянии, когда некоторые копии данных могут быть обновлены, а другие нет. Однако, с течением времени все копии данных сходятся к одному состоянию (Eventually consistent), что обеспечивает согласованность.

В чем различаются эти подходы ?

Основная разница между BASE и ACID заключается в том, что ACID обеспечивает жесткую согласованность данных, в то время как BASE обеспечивает гибкую согласованность, позволяющую достичь высокой доступности и отказоустойчивости данных в условиях распределенности и масштабируемости.

В следующих постах мы подробно рассмотрим основные принципы, лежащие в модели ACID и BASE, а также поговорим про CAP теорему.

Ставьте реакции к посту, если было полезно🔥

#базы_данных

Продолжаем тему предыдущего поста и остановимся на подходе ACID.

Давайте подробно разберём каждое свойство из аббревиатуры.

1⃣ Atomicity (Атомарность) – транзакция является неделимой и должна быть выполнена полностью или не выполнена вообще. Если транзакция не может быть выполнена до конца, то СУБД должна откатить ее и вернуть данные к предыдущему состоянию. Это гарантирует, что если транзакция не может быть выполнена успешно, то все изменения, внесенные в базу данных до этого момента, будут отменены.

2⃣ Consistency (Согласованность) – транзакции должны поддерживать целостность данных. Это означает, что если данные в базе данных находятся в конкретном состоянии, то любая транзакция должна привести базу данных к другому согласованному состоянию. Транзакции не могут изменять данные в противоречии с правилами базы данных.

3⃣ Isolation (Изолированность) – каждая транзакция должна выполняться в изоляции от других транзакций, т.е. не должно быть видимости изменений, внесенных в базу данных другими транзакциями, пока текущая транзакция не завершена. Это гарантирует, что транзакции не будут конфликтовать между собой.

4⃣ Durability (Долговечность) – изменения, внесенные в базу данных транзакцией, должны быть сохранены и доступны после завершения транзакции, даже если происходит отказ системы или другой сбой. Это гарантирует, что данные в базе данных сохранятся даже в случае сбоя системы.

Зачем соблюдать вышеперечисленные свойства ❓

ACID-свойства очень важны для проектирования ПО, особенно при работе с транзакционными базами данных. При соблюдении этих свойств, разработчики могут создавать приложения, которые гарантируют, что данные будут сохранены в надежном состоянии и не будут повреждены в случае сбоя или других непредвиденных обстоятельств. Но использование ACID-свойств может иметь некоторые ограничения на производительность системы, особенно при работе с большими объемами данных. Поэтому, для некоторых приложений может быть более подходящим использование более гибких моделей данных, таких как BASE, которые предоставляют более высокую производительность за счет некоторой потери надежности.

О модели BASE мы поговорим в следующем посте  🔜

#базы_данных

One hour later one month later...
Итак, мы завершаем серию постов про подходы к проектированию ПО👨‍💻

И сегодня разберём подход под названием BASE.

BASE - сокращение от Basically Available, Soft state, Eventually consistent. Подход BASE ставит упор на доступность данных и их масштабируемость, позволяя достигнуть этих целей за счет компромисса в отношении согласованности данных. В этом подходе допускается, что данные могут находиться в “мягком” состоянии, то есть состоянии, которое может быть не совсем точным или актуальным в любой момент времени.

Подход BASE подходит для систем, которые нуждаются в высокой доступности и масштабируемости, но могут терпеть небольшие задержки и несогласованности данных. Он может использоваться в системах, таких как распределенные системы, сетевые приложения, системы Big Data и другие.

Что означают буквы в аббревеатуре BASE❓

1⃣ Basically Available - это свойство обозначает, что система должна быть доступна для обработки запросов и предоставления данных в любое время, даже в случае сбоев в работе или разделения на несколько частей

2⃣ Soft state - это свойство обозначает, что состояние системы может быть временно несогласованным, то есть данные могут находиться в процессе изменения и обновления.

3⃣ Eventually consistent - это свойство обозначает, что в системе может быть временная несогласованность данных, но в конечном итоге все данные будут согласованы

Есть хорошая статья, где подробно описаны различия между двумя подходами в пооектировании: https://phoenixnap.com/kb/acid-vs-base