Graphana vs Kibana — в чём разница?
Кратко: Kibana — анализ логов и запросов, Graphana — визуализация и мониторинг нагрузки.
Подробнее. Оба инструмента с открытым исходным кодом, используются для анализа больших объёмов данных от разных систем. Хотя системы имеют созвучное название, они, как правило, используются в разных кейсах.
Graphana — система для визуализации и мониторинга временных рядов данных. Graphana позволяет создавать красивые и интерактивные дашборды, которые отображают данные из разных источников, таких как базы данных, API, файлы и т.д.
Какие задачи решает Graphana:
1️⃣ Расчёт нефункциональных требований (RPS, response time) для микросервисов
2️⃣ Мониторинг состояния и ресурсов серверов и приложений. Graphana позволяет отображать и анализировать различные метрики, связанные с работой серверов и приложений, такие как загрузка CPU, использование памяти, дисковое пространство
3️⃣ Визуализация данных из разных источников. Graphana поддерживает множество баз данных и API, которые могут быть использованы для получения и отображения данных в разных форматах
Kibana — система для поиска, анализа и визуализации данных, хранящихся в Elasticsearch. Собственно, это буква K в знаменитой ELK. Kibana позволяет использовать огромное число фильтров и поддерживает сложный поисковые (KQL) запросы для анализа логов и событий.
Какие задачи решает Kibana
1️⃣ Анализ логов запросов по определённому методу API. Kibana позволяет извлекать и анализировать данные из логов, хранящихся в Elasticsearch. Например, можно построить график распределения запросов по методам API, фильтровать по статусу ответа, времени выполнения, IP-адресу и другим параметрам
2️⃣ Визуализация данных из разных источников различными способами, используя диаграммы, таблицы, географические карты и другие типы визуализаций.
📎 Материалы
1. Руководство пользователя Kibana (ENG, RUS)
2. Видео по Кибане
3. Официальная документация Graphana
4.Обзорная статья о Graphana
#инструменты
Кратко: Kibana — анализ логов и запросов, Graphana — визуализация и мониторинг нагрузки.
Подробнее. Оба инструмента с открытым исходным кодом, используются для анализа больших объёмов данных от разных систем. Хотя системы имеют созвучное название, они, как правило, используются в разных кейсах.
Graphana — система для визуализации и мониторинга временных рядов данных. Graphana позволяет создавать красивые и интерактивные дашборды, которые отображают данные из разных источников, таких как базы данных, API, файлы и т.д.
Какие задачи решает Graphana:
1️⃣ Расчёт нефункциональных требований (RPS, response time) для микросервисов
2️⃣ Мониторинг состояния и ресурсов серверов и приложений. Graphana позволяет отображать и анализировать различные метрики, связанные с работой серверов и приложений, такие как загрузка CPU, использование памяти, дисковое пространство
3️⃣ Визуализация данных из разных источников. Graphana поддерживает множество баз данных и API, которые могут быть использованы для получения и отображения данных в разных форматах
Kibana — система для поиска, анализа и визуализации данных, хранящихся в Elasticsearch. Собственно, это буква K в знаменитой ELK. Kibana позволяет использовать огромное число фильтров и поддерживает сложный поисковые (KQL) запросы для анализа логов и событий.
Какие задачи решает Kibana
1️⃣ Анализ логов запросов по определённому методу API. Kibana позволяет извлекать и анализировать данные из логов, хранящихся в Elasticsearch. Например, можно построить график распределения запросов по методам API, фильтровать по статусу ответа, времени выполнения, IP-адресу и другим параметрам
2️⃣ Визуализация данных из разных источников различными способами, используя диаграммы, таблицы, географические карты и другие типы визуализаций.
📎 Материалы
1. Руководство пользователя Kibana (ENG, RUS)
2. Видео по Кибане
3. Официальная документация Graphana
4.Обзорная статья о Graphana
#инструменты
👍8🤔1
🚫Типовые ошибки младшего системного аналитика
Всем привет! Сегодня мы рассмотрим, какие ошибки совершает джун-аналитик Вася в процессе своей работы.
1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka”
2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами
3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.
4️⃣ Боится показаться глупым. Когда Вася получает задачу от старшего коллеги, он стесняется задавать глупые вопросы. В итоге Вася неправильно понимает постановку задачи и в лучшем случае теряет время впустую, пока его старший коллега не заметит косяк. Короче, Вася любит создавать себе сложности
5️⃣ Считает, что документация в конфлюэнсе всегда актуальная. Вася не успел окончательно разочароваться в людях, поэтому смело опирается на документацию. И вот, через неделю он показывает своё ТЗ коллеге: увы, придётся переделавать, так как эта система уже месяц как не используется, просто не обновили страничку…
6️⃣ Не фиксирует договорённости. Обсудив с заказчиком изменения требований в зуме, Вася никак не фиксирует, что такое-то требование было изменено и молча вносит правки в ТЗ. Через два месяца на Васю падает баг – изменения в требованиях оказались несовместимы с legacy бизнес-правилами в системе, о которых уже все забыли. Виноватым оказался конечно Вася, так как заказчик не помнит, что сам изменял требования.
7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…
А какие ошибки допускали вы? Делитесь в комментариях под постом 👇
P.S. Вася, прости
#развитие
Всем привет! Сегодня мы рассмотрим, какие ошибки совершает джун-аналитик Вася в процессе своей работы.
1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka”
2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами
3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.
4️⃣ Боится показаться глупым. Когда Вася получает задачу от старшего коллеги, он стесняется задавать глупые вопросы. В итоге Вася неправильно понимает постановку задачи и в лучшем случае теряет время впустую, пока его старший коллега не заметит косяк. Короче, Вася любит создавать себе сложности
5️⃣ Считает, что документация в конфлюэнсе всегда актуальная. Вася не успел окончательно разочароваться в людях, поэтому смело опирается на документацию. И вот, через неделю он показывает своё ТЗ коллеге: увы, придётся переделавать, так как эта система уже месяц как не используется, просто не обновили страничку…
6️⃣ Не фиксирует договорённости. Обсудив с заказчиком изменения требований в зуме, Вася никак не фиксирует, что такое-то требование было изменено и молча вносит правки в ТЗ. Через два месяца на Васю падает баг – изменения в требованиях оказались несовместимы с legacy бизнес-правилами в системе, о которых уже все забыли. Виноватым оказался конечно Вася, так как заказчик не помнит, что сам изменял требования.
7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…
А какие ошибки допускали вы? Делитесь в комментариях под постом 👇
P.S. Вася, прости
#развитие
🔥8❤3👎2😁2👍1👏1🤔1
SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
Кратко. SOA использует ESB – единую интеграционную шину, все системы общаются только с ней, а та, как посредник, передаёт сообщения от одной системы к другой. В MSA сервисы общаются напрямую, отсутствует единая точка отказа, как ESB в SOA.
В SOA сервисы – это кирпичики, из которых собираются более крупные – максимальное переиспользование логики. В MSA микросервисы не зависят друг от друга и имеют ограниченный контекст
Подробнее
1️⃣ Внесение изменений
В SOA для внесения одного изменения требуется изменения сразу в нескольких сервисах. Так как отдельными сервисами владеют разные команды, то внесение элементарных изменений превращается в сущий ад из бесконечных совещаний, согласований и документов.
В MSA зависимости от других сервисов отсутствуют либо минимальны, то необходимость взаимодействия с другими сервисами и командами пропадает. Внесение изменений осуществляется командой, которая владеет сервисом/
2️⃣ Переиспользование
В SOA стремится переиспользованию. Разработчики часто тратят много времени, пытаясь интегрировать повторно используемые сервисы, которые потом мало используются повторно
В MSA избегают повторного использования: дублирование логики лучше зависимости от других сервисов. Повторное использование предполагает связанность, а архитектура микросервисов старается ее избегать. Это достигается за счет разбиения системы на сервисы по ограниченным контекстам (бизнес областям)
3️⃣ Команды
В SOA команды разделены так же, как архитектура. Требуются колоссальные усилия координации для простых изменений.
В MSA команда кроссфункциональна, то есть включает в себя всех специалистов, необходимых для развития сервиса. Так как сервис реализует процесс от и до, то команда владеет процессом от начала до конца. Как следствие они отвечают за процесс целиком
4️⃣ Взаимодействие
В SOA взаимодействие осуществляется через корпоративную шину. Если в ней со временем появляется много логики, то она легко становится бутылочным горлышком.
В MSA Каждый сервис обладает всеми частями своего ограниченного контекста и осуществляет связь с другими ограниченными контекстами с помощью обмена данными, используя брокер сообщений. Просто обмен, никакой сложной логики.
5️⃣ Автоматизация и развертывание
SOA состоит из множества развертываемых модулей, что затрудняет процесс автоматизации и координации
В MSA каждый cервис может быть развернут независимо от других сервисов (и другой инфраструктуры), что отражает ограниченный контекст
6️⃣ Тестирование
В SOA ни одна из частей архитектуры не является завершенной — все они являются частью более крупного рабочего потока и обычно не предназначены для изолированного тестирования
В MSA каждый сервис имеет хорошо определенную границу и минимум зависимостей, это позволяет легко тестировать сервис в изоляции от других частей системы
📎 Материалы
1. SOA vs MSA
2. Microservices Architecture – SOA and MSA
3. Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам
4. ▶️ Различия SOA и микросервисной архитектуры за 9 минут
#архитектура #сравнение
Кратко. SOA использует ESB – единую интеграционную шину, все системы общаются только с ней, а та, как посредник, передаёт сообщения от одной системы к другой. В MSA сервисы общаются напрямую, отсутствует единая точка отказа, как ESB в SOA.
В SOA сервисы – это кирпичики, из которых собираются более крупные – максимальное переиспользование логики. В MSA микросервисы не зависят друг от друга и имеют ограниченный контекст
Подробнее
1️⃣ Внесение изменений
В SOA для внесения одного изменения требуется изменения сразу в нескольких сервисах. Так как отдельными сервисами владеют разные команды, то внесение элементарных изменений превращается в сущий ад из бесконечных совещаний, согласований и документов.
В MSA зависимости от других сервисов отсутствуют либо минимальны, то необходимость взаимодействия с другими сервисами и командами пропадает. Внесение изменений осуществляется командой, которая владеет сервисом/
2️⃣ Переиспользование
В SOA стремится переиспользованию. Разработчики часто тратят много времени, пытаясь интегрировать повторно используемые сервисы, которые потом мало используются повторно
В MSA избегают повторного использования: дублирование логики лучше зависимости от других сервисов. Повторное использование предполагает связанность, а архитектура микросервисов старается ее избегать. Это достигается за счет разбиения системы на сервисы по ограниченным контекстам (бизнес областям)
3️⃣ Команды
В SOA команды разделены так же, как архитектура. Требуются колоссальные усилия координации для простых изменений.
В MSA команда кроссфункциональна, то есть включает в себя всех специалистов, необходимых для развития сервиса. Так как сервис реализует процесс от и до, то команда владеет процессом от начала до конца. Как следствие они отвечают за процесс целиком
4️⃣ Взаимодействие
В SOA взаимодействие осуществляется через корпоративную шину. Если в ней со временем появляется много логики, то она легко становится бутылочным горлышком.
В MSA Каждый сервис обладает всеми частями своего ограниченного контекста и осуществляет связь с другими ограниченными контекстами с помощью обмена данными, используя брокер сообщений. Просто обмен, никакой сложной логики.
5️⃣ Автоматизация и развертывание
SOA состоит из множества развертываемых модулей, что затрудняет процесс автоматизации и координации
В MSA каждый cервис может быть развернут независимо от других сервисов (и другой инфраструктуры), что отражает ограниченный контекст
6️⃣ Тестирование
В SOA ни одна из частей архитектуры не является завершенной — все они являются частью более крупного рабочего потока и обычно не предназначены для изолированного тестирования
В MSA каждый сервис имеет хорошо определенную границу и минимум зависимостей, это позволяет легко тестировать сервис в изоляции от других частей системы
📎 Материалы
1. SOA vs MSA
2. Microservices Architecture – SOA and MSA
3. Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам
4. ▶️ Различия SOA и микросервисной архитектуры за 9 минут
#архитектура #сравнение
❤10👍5👏3
Паттерны декомпозиции User Story / задач
1. Разделение на «Проще-сложнее»
2. Разделение по бизнес-правилам
3. Разделение по способу ввода/вывода данных
4. Разделение по вариантивности данных
5. Разделение по операциям
6. По шагам workflow
7. Выделение основного усилия
8. Разделение по наращиванию функционала
9. Исследование-разработка (спайки)
📎 Ещё статьи по теме в этом посте
#требования
1. Разделение на «Проще-сложнее»
2. Разделение по бизнес-правилам
3. Разделение по способу ввода/вывода данных
4. Разделение по вариантивности данных
5. Разделение по операциям
6. По шагам workflow
7. Выделение основного усилия
8. Разделение по наращиванию функционала
9. Исследование-разработка (спайки)
📎 Ещё статьи по теме в этом посте
#требования
Telegraph
Паттерны декомпозиции User Story / задач
Иногда продуктовые команды пренебрегают декомпозицией задач, которые попадают в их бэклог. Слишком большую пользовательскую историю часто вообще не удается оценить по сложности, потому что она не является достаточно понятным и прозрачным элементом бэклога.…
🔥3😢1
Кэширование — разбор по полочкам
🔹Кэширование – способ способов оптимизации приложений, при котором результаты выполнения операций сохраняются на некоторое время
🔹Кэширование позволяет ускорить время отклика системы и повысить устойчивость к увеличению нагрузки (росту RPS)
🔹Главный принцип работы с кэшем: если вы можете обойтись без кэширования, то именно так и сделайте
Как работает кэширование?
Логически кэш представляет из себя базу типа ключ-значение. Каждая запись в кэше имеет “время жизни”, по истечении которого она удаляется. Это время называют термином Time To Live или TTL. Размер кэша гораздо меньше, чем у основного хранилища, но этот недостаток компенсируется высокой скоростью доступа к данным. Это достигается за счет размещения кэша в быстродействующей памяти ОЗУ (RAM). Поэтому обычно кэш содержит самые “горячие” данные.
Процесс 1. Когда данные в кэше отсутствуют
1️⃣ Пользователь запрашивает некие данные
2️⃣ Кэш приложения ПУСТ, поэтому приложение обращается к базе данных (БД)
3️⃣ БД возвращает запрошенные данные приложению
4️⃣ Приложение сохраняет полученные данные в кэше
5️⃣ Пользователь получает данные
Процесс 2. В кэше есть данные
1️⃣ Пользователь запрашивает данные
2️⃣Приложение уже имеет эти данные в кэше (ведь они были записаны туда при первом обращении) и поэтому НЕ ОБРАЩАЕТСЯ за ними к БД
3️⃣Пользователь получает данные
Стратегии инвалидации кэша
➖ Инвалидация по TTL.
TTL (Time To Live) – время жизни данных в кэше. При сохранении данных в кэш для них устанавливается TTL и данные будут обновляться с периодичностью не менее TTL.
➖ Инвалидация по событию
При таком подходе данные инвалидируют при наступлении некоего события – обычно это обновление данных в источнике
Стратегии вытеснения
🔸LRU (Least Recently Used) – стратегия вытеснения, которая опирается на время последнего использования записи. Она удаляет записи, у которых время последнего использования старше остальных. Таким образом, в кэше остаются записи, которые использовались недавно. Эта стратегия опирается уже не на случай, а на паттерн использования данных, поэтому она гораздо эффективнее предыдущих.
🔸LFU (Least Frequently Used) – стратегия вытеснения, опирающаяся на частоту использования записи. Она удаляет записи, которые использовались реже всего. Так в кэше остаются данные, которые использовались чаще других. Эта стратегия тоже опирается не на случай, а на паттерн использования данных, поэтому она тоже эффективнее остальных и является альтернативой LRU.
Полную версию читайте на Хабре.
📎 Полезные ссылки
1. О стратегиях вытеснения на примере инструментов redis
2. Трудности и стратегии кэширования на сайте Amazon
3. Основы кэширования от Amazon
4. Базовый “ликбез” и ссылки на первоисточники от Wikipedia
#архитектура
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
🔹Кэширование – способ способов оптимизации приложений, при котором результаты выполнения операций сохраняются на некоторое время
🔹Кэширование позволяет ускорить время отклика системы и повысить устойчивость к увеличению нагрузки (росту RPS)
🔹Главный принцип работы с кэшем: если вы можете обойтись без кэширования, то именно так и сделайте
Как работает кэширование?
Логически кэш представляет из себя базу типа ключ-значение. Каждая запись в кэше имеет “время жизни”, по истечении которого она удаляется. Это время называют термином Time To Live или TTL. Размер кэша гораздо меньше, чем у основного хранилища, но этот недостаток компенсируется высокой скоростью доступа к данным. Это достигается за счет размещения кэша в быстродействующей памяти ОЗУ (RAM). Поэтому обычно кэш содержит самые “горячие” данные.
Процесс 1. Когда данные в кэше отсутствуют
1️⃣ Пользователь запрашивает некие данные
2️⃣ Кэш приложения ПУСТ, поэтому приложение обращается к базе данных (БД)
3️⃣ БД возвращает запрошенные данные приложению
4️⃣ Приложение сохраняет полученные данные в кэше
5️⃣ Пользователь получает данные
Процесс 2. В кэше есть данные
1️⃣ Пользователь запрашивает данные
2️⃣Приложение уже имеет эти данные в кэше (ведь они были записаны туда при первом обращении) и поэтому НЕ ОБРАЩАЕТСЯ за ними к БД
3️⃣Пользователь получает данные
Стратегии инвалидации кэша
➖ Инвалидация по TTL.
TTL (Time To Live) – время жизни данных в кэше. При сохранении данных в кэш для них устанавливается TTL и данные будут обновляться с периодичностью не менее TTL.
➖ Инвалидация по событию
При таком подходе данные инвалидируют при наступлении некоего события – обычно это обновление данных в источнике
Стратегии вытеснения
🔸LRU (Least Recently Used) – стратегия вытеснения, которая опирается на время последнего использования записи. Она удаляет записи, у которых время последнего использования старше остальных. Таким образом, в кэше остаются записи, которые использовались недавно. Эта стратегия опирается уже не на случай, а на паттерн использования данных, поэтому она гораздо эффективнее предыдущих.
🔸LFU (Least Frequently Used) – стратегия вытеснения, опирающаяся на частоту использования записи. Она удаляет записи, которые использовались реже всего. Так в кэше остаются данные, которые использовались чаще других. Эта стратегия тоже опирается не на случай, а на паттерн использования данных, поэтому она тоже эффективнее остальных и является альтернативой LRU.
Полную версию читайте на Хабре.
📎 Полезные ссылки
1. О стратегиях вытеснения на примере инструментов redis
2. Трудности и стратегии кэширования на сайте Amazon
3. Основы кэширования от Amazon
4. Базовый “ликбез” и ссылки на первоисточники от Wikipedia
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤7🔥3
Цикл статьей по изучению Postman (через VPN)
Часть 1 - Postman — как инструмент тестирования API
Часть 2 - Postman — менеджмент, структурирование, импорт и экспорт коллекций
Часть 3 - Postman. Смена окружений, предварительная настройка авторизации, установка переменных
Часть 4 - Postman — Collection runner, тесты и сниппеты (Snippets), запуск тестов в CI через Newman
#api #инструменты
Часть 1 - Postman — как инструмент тестирования API
Часть 2 - Postman — менеджмент, структурирование, импорт и экспорт коллекций
Часть 3 - Postman. Смена окружений, предварительная настройка авторизации, установка переменных
Часть 4 - Postman — Collection runner, тесты и сниппеты (Snippets), запуск тестов в CI через Newman
#api #инструменты
👍7👏2❤1
Бесплатная книга по проектированию API
Книга Сергея Константинова «API» состоит из шести разделов, посвящённых:
1. проектированию API,
2. паттернам дизайна API,
3. поддержанию обратной совместимости,
4. HTTP API и архитектурным принципам REST,
5. SDK и UI-библиотекам,
6. продуктовому управлению API.
📖 Читать онлайн
⬇️ Скачать PDF | EPUB
#api
Книга Сергея Константинова «API» состоит из шести разделов, посвящённых:
1. проектированию API,
2. паттернам дизайна API,
3. поддержанию обратной совместимости,
4. HTTP API и архитектурным принципам REST,
5. SDK и UI-библиотекам,
6. продуктовому управлению API.
📖 Читать онлайн
⬇️ Скачать PDF | EPUB
#api
❤13👍4⚡1
SQL vs NoSQL: отличие реляционных и нереляционных БД
Реляционная база данных (SQL) — база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом. В таблице есть строки и столбцы, каждая строка представляет отдельную запись, а столбец — поле с назначенным ей типом данных. В каждой ячейке информация записана по шаблону
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. Не поддерживают запросы SQL.
Особенности реляционных БД
1️⃣ Структурированность. Реляционные БД идеальны для работы со структурированными данными, структура которых не подвержена частым изменениям.
2️⃣ Есть статичная схема данных. Между таблицами определены связи, первичные и внешние ключи, которые обеспечивают целостность данных
3️⃣ Обеспечивают высокую целостность, надежность и безопасность данных. транзакционности по ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность)
4️⃣ Использование SQL для запросов и манипуляций с данными
Примеры реляционных СУБД: MySQL, PostgreSQL, Oracle, Microsoft SQL Server
Особенности нереляционных БД
1️⃣ Схема данных является динамической и может меняться в любой момент времени
2️⃣ Данные не структурированы
3️⃣ Оптимизированы для работы с большими объемами данных, высокой производительности и низкой задержкой
Примеры нереляционных СУБД: MongoDB, Redis, Cassandra, Neo4
Что лучше?
Зависит от целей и характеристик проекта.
🔹Реляционные БД, если нужна строгая структура данных, высокая целостность и безопасность данных, сложные отношения между данными, поддержка транзакций и стандартизированный язык запросов
🔸Нереляционные БД, если нужна гибкая модель данных, высокая масштабируемость и производительность, быстрая обработка больших объемов данных, простота разработки и развертывания
#бд #сравнение
Реляционная база данных (SQL) — база, где данные хранятся в формате таблиц, они строго структурированы и связаны друг с другом. В таблице есть строки и столбцы, каждая строка представляет отдельную запись, а столбец — поле с назначенным ей типом данных. В каждой ячейке информация записана по шаблону
Нереляционная база данных (NoSQL) — хранит данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. Не поддерживают запросы SQL.
Особенности реляционных БД
1️⃣ Структурированность. Реляционные БД идеальны для работы со структурированными данными, структура которых не подвержена частым изменениям.
2️⃣ Есть статичная схема данных. Между таблицами определены связи, первичные и внешние ключи, которые обеспечивают целостность данных
3️⃣ Обеспечивают высокую целостность, надежность и безопасность данных. транзакционности по ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность)
4️⃣ Использование SQL для запросов и манипуляций с данными
Примеры реляционных СУБД: MySQL, PostgreSQL, Oracle, Microsoft SQL Server
Особенности нереляционных БД
1️⃣ Схема данных является динамической и может меняться в любой момент времени
2️⃣ Данные не структурированы
3️⃣ Оптимизированы для работы с большими объемами данных, высокой производительности и низкой задержкой
Примеры нереляционных СУБД: MongoDB, Redis, Cassandra, Neo4
Что лучше?
Зависит от целей и характеристик проекта.
🔹Реляционные БД, если нужна строгая структура данных, высокая целостность и безопасность данных, сложные отношения между данными, поддержка транзакций и стандартизированный язык запросов
🔸Нереляционные БД, если нужна гибкая модель данных, высокая масштабируемость и производительность, быстрая обработка больших объемов данных, простота разработки и развертывания
#бд #сравнение
🔥9👍5❤3
Sync vs Async: синхронное и асинхронное взаимодействие
1️⃣ В синхронном взаимодействии клиентский микросервис ожидает ответа от вызываемого микросервиса перед продолжением своей работы.
Плюсы синхрона:
1. Простота. Проще в реализации и отладке.
2. Прозрачность. Позволяет легко отслеживать и управлять последовательностью выполнения операций.
Минусы синхрона:
1. Зависимость от доступности. Если вызываемый микросервис недоступен или работает медленно, это может привести к задержкам и блокировкам в клиентском микросервисе.
2. Узкое место. Если синхронные вызовы выполняются последовательно, это может стать узким местом производительности.
2️⃣ В асинхронном взаимодействии клиентский микросервис отправляет запрос вызываемому микросервису и продолжает свою работу без ожидания ответа. Ответ может быть получен позже, например, через сообщения или коллбэки.
Плюсы асинхрона:
1. Отказоустойчивость. Позволяет избежать блокировки клиентского микросервиса при недоступности вызываемого микросервиса.
2. Масштабируемость. Может быть параллельным, что способствует лучшей масштабируемости системы.
Минусы асинхрона:
1. Сложность. Требует более сложной реализации, так как необходимо обрабатывать асинхронные ответы и управлять состоянием запросов.
2. Усложнение отладки. Отслеживание и отладка может быть сложнее из-за распределения запросов и ответов во времени.
Что выбрать?
Правильный выбор подхода зависит от следующих факторов:
1. Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным.
2. Надежность. Если надежность и отказоустойчивость важны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
3. Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.
Развернутая статья здесь
#api #интеграции #архитектура
1️⃣ В синхронном взаимодействии клиентский микросервис ожидает ответа от вызываемого микросервиса перед продолжением своей работы.
Плюсы синхрона:
1. Простота. Проще в реализации и отладке.
2. Прозрачность. Позволяет легко отслеживать и управлять последовательностью выполнения операций.
Минусы синхрона:
1. Зависимость от доступности. Если вызываемый микросервис недоступен или работает медленно, это может привести к задержкам и блокировкам в клиентском микросервисе.
2. Узкое место. Если синхронные вызовы выполняются последовательно, это может стать узким местом производительности.
2️⃣ В асинхронном взаимодействии клиентский микросервис отправляет запрос вызываемому микросервису и продолжает свою работу без ожидания ответа. Ответ может быть получен позже, например, через сообщения или коллбэки.
Плюсы асинхрона:
1. Отказоустойчивость. Позволяет избежать блокировки клиентского микросервиса при недоступности вызываемого микросервиса.
2. Масштабируемость. Может быть параллельным, что способствует лучшей масштабируемости системы.
Минусы асинхрона:
1. Сложность. Требует более сложной реализации, так как необходимо обрабатывать асинхронные ответы и управлять состоянием запросов.
2. Усложнение отладки. Отслеживание и отладка может быть сложнее из-за распределения запросов и ответов во времени.
Что выбрать?
Правильный выбор подхода зависит от следующих факторов:
1. Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным.
2. Надежность. Если надежность и отказоустойчивость важны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
3. Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.
Развернутая статья здесь
#api #интеграции #архитектура
❤11👍4🔥4
🗣Webhook. Что это такое и когда используется
Вебхук — это способ оповещения клиента о произошедшем в системе событии с помощью пользовательских обратных вызовов по HTTP.
Вебхук запускается, когда в системе происходит какое-то событие. Например, человек написал комментарий на сайте. Когда происходит такое событие, сервер создает HTTP-вызов и отправляет его на адрес, который клиент указал для получения вебхуков.
Кроме самого события, сервер может передавать дополнительные данные: время события, логин пользователя, количество регистраций и другие параметры. Что именно передаёт сервер и в каком порядке — зависит от настроек сервера.
❕Чем Webhook отличается от API?
Большинство API работает по принципу «Спроси меня и я отвечу». То есть для получения свежих данных, программному клиенту нужно постоянно отправлять запросы на сервер.
Вебхуки работают иначе. Они как бы говорят: «Дружище, больше не нужно названивать. Если произойдет что-то для тебя важное, я сам сообщу».
Если простыми словами, вебхук — как бы подписка на обновления для определенных событий. Сервер будет оповещать клиента только о тех изменениях, которые ему по-настоящему важны. Он сам сообщит об этих событиях при настройке вебхука.
❓Когда использовать API, когда вебхуки?
Вебхуки подходят для ситуаций, когда нужно реагировать на события в режиме реального времени, а не опрашивать серверы периодически. Однако вебхуки не могут полностью заменить API, так как они не позволяют просматривать, изменять или удалять данные на сервере. Для этого нужно использовать API-запросы. Вебхуки же служат только для уведомления об изменении данных.
⛔️ Когда НЕ следует использовать вебхуки?
Когда нужна гарантированная доставка. У вебхуков такого нет Это значит, что если по каким-то причинам мы не успели обработать запрос, то данные будут потеряны. Поэтому привязывать к вебхукам критичные события не стоит — лучше поискать другой механизм мониторинга.
Ещё бывает так, что проблемы могут быть на самом сервере. Например, если зависнет сервис, который рассылает вебхуки, то мы об этом не узнаем и не получим новых данных.
📎 Материалы по теме
1. Вебхук
2. Вебхук — простой способ получить уведомление с сайта
3. Что такое вебхук, как и зачем его использовать
4. Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами
5. Попробовать поэксперементировать онлайн — webhook.site
#интеграции
Вебхук — это способ оповещения клиента о произошедшем в системе событии с помощью пользовательских обратных вызовов по HTTP.
Вебхук запускается, когда в системе происходит какое-то событие. Например, человек написал комментарий на сайте. Когда происходит такое событие, сервер создает HTTP-вызов и отправляет его на адрес, который клиент указал для получения вебхуков.
Кроме самого события, сервер может передавать дополнительные данные: время события, логин пользователя, количество регистраций и другие параметры. Что именно передаёт сервер и в каком порядке — зависит от настроек сервера.
❕Чем Webhook отличается от API?
Большинство API работает по принципу «Спроси меня и я отвечу». То есть для получения свежих данных, программному клиенту нужно постоянно отправлять запросы на сервер.
Вебхуки работают иначе. Они как бы говорят: «Дружище, больше не нужно названивать. Если произойдет что-то для тебя важное, я сам сообщу».
Если простыми словами, вебхук — как бы подписка на обновления для определенных событий. Сервер будет оповещать клиента только о тех изменениях, которые ему по-настоящему важны. Он сам сообщит об этих событиях при настройке вебхука.
❓Когда использовать API, когда вебхуки?
Вебхуки подходят для ситуаций, когда нужно реагировать на события в режиме реального времени, а не опрашивать серверы периодически. Однако вебхуки не могут полностью заменить API, так как они не позволяют просматривать, изменять или удалять данные на сервере. Для этого нужно использовать API-запросы. Вебхуки же служат только для уведомления об изменении данных.
⛔️ Когда НЕ следует использовать вебхуки?
Когда нужна гарантированная доставка. У вебхуков такого нет Это значит, что если по каким-то причинам мы не успели обработать запрос, то данные будут потеряны. Поэтому привязывать к вебхукам критичные события не стоит — лучше поискать другой механизм мониторинга.
Ещё бывает так, что проблемы могут быть на самом сервере. Например, если зависнет сервис, который рассылает вебхуки, то мы об этом не узнаем и не получим новых данных.
📎 Материалы по теме
1. Вебхук
2. Вебхук — простой способ получить уведомление с сайта
3. Что такое вебхук, как и зачем его использовать
4. Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами
5. Попробовать поэксперементировать онлайн — webhook.site
#интеграции
👍9❤5🔥3
📌 Список бесплатных онлайн-курсов по базам данных и SQL
▪️ Курс от Stepik: Интерактивный тренажер по SQL - практические задания на создание SQL-запросов.
▪️ Курс от Stepik: Введение в базы данных - Знакомство с методами структурированного хранения данных, основами SQL, принципами использования баз данных в приложениях
▪️ LearnDB- интерактивные онлайн-курсы по SQL СУБД PostgreSQL.
▪️ Базовый курс SQL для аналитиков и менеджеров — 24 видеоурока по SQL для начинающих, автор Максим Кухарь
▪️ Основы SQL - базовый курс на платформе Интуит, теоретические материалы + тесты для самопроверки.
▪️ Видеокурс по SQL от IT Proger - изучение SQL и работа с базами данных на примере MySQL.
▪️ SQL для начинающих - курс по основам SQL от Академии IT
Онлайн-тренажёры по SQL
🔹 SQL Academy - онлайн тренажер с упражнениями по SQL;
🔹SQL-EX упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt - пошаговый интерактивный учебник (уроки + упражнения);
🔹 Solve SQL | HackerRank - платформа для практики и изучения языков программирования;
🔹 SQL Fiddle - эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server);
🔹 SQL Tutorial - справочник с множеством примеров и упражнений.
Источник: @notes_analyst
#sql #бд
▪️ Курс от Stepik: Интерактивный тренажер по SQL - практические задания на создание SQL-запросов.
▪️ Курс от Stepik: Введение в базы данных - Знакомство с методами структурированного хранения данных, основами SQL, принципами использования баз данных в приложениях
▪️ LearnDB- интерактивные онлайн-курсы по SQL СУБД PostgreSQL.
▪️ Базовый курс SQL для аналитиков и менеджеров — 24 видеоурока по SQL для начинающих, автор Максим Кухарь
▪️ Основы SQL - базовый курс на платформе Интуит, теоретические материалы + тесты для самопроверки.
▪️ Видеокурс по SQL от IT Proger - изучение SQL и работа с базами данных на примере MySQL.
▪️ SQL для начинающих - курс по основам SQL от Академии IT
Онлайн-тренажёры по SQL
🔹 SQL Academy - онлайн тренажер с упражнениями по SQL;
🔹SQL-EX упражнения и Интерактивный учебник по SQL;
🔹 SQLBolt - пошаговый интерактивный учебник (уроки + упражнения);
🔹 Solve SQL | HackerRank - платформа для практики и изучения языков программирования;
🔹 SQL Fiddle - эмулятор написания SQL-запросов, позволяет практиковаться на разных типах СУБД (MySQL, PostgreSQL, SQLite, MS SQL Server);
🔹 SQL Tutorial - справочник с множеством примеров и упражнений.
Источник: @notes_analyst
#sql #бд
🔥11❤5👍2👏1
🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже развиваются, хотя бы чуть-чуть 😉
Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
Архитектура
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Александр Швец. Погружение в Паттерны Проектирования
Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
Своды знаний
📔 BABOK v3
📔 INCOSE Guide for Writing Requirements
Навыки
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
Библиотека будет пополняться в канале Библиотека Системного Аналитика
#подборка
Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком.
👉 Скачать весь архив
Пересылайте коллегам, пусть тоже развиваются, хотя бы чуть-чуть 😉
Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
Архитектура
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Александр Швец. Погружение в Паттерны Проектирования
Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
Своды знаний
📔 BABOK v3
📔 INCOSE Guide for Writing Requirements
Навыки
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
Библиотека будет пополняться в канале Библиотека Системного Аналитика
#подборка
Яндекс Диск
Книги для SA
Посмотреть и скачать с Яндекс Диска
❤53🔥24👍10
Системный Аналитик pinned «🔥 Книги для системного аналитика бесплатно без регистрации и СМС 📚 Собрали для Вас 20 лучших книг для развития аналитика. Ссылки кликабельны, можно скачивать любую книгу отдельно или весь архив целиком. 👉 Скачать весь архив Пересылайте коллегам, пусть тоже…»
📟 Разбираемся с моделью OSI на пальцах
Модель OSI (Open System Interconnection) описывает, как устройства в локальных и глобальных сетях обмениваются данными и что происходит с этими данными. Её предложили в 1984 году инженеры из Международной организации по стандартизации (ISO), которая работала над единым стандартом передачи данных по интернету.
1️⃣ уровень: Физический. Здесь биты передаются между устройствами оптическими, электрическими или радиосигналами. Устройства не понимают данные, а только сигналы. Примеры оборудования: концентраторы, медиаконвертеры, репитеры.
2️⃣ уровень: Канальный.
Здесь определяется адресация устройств с помощью MAC-адресов. Биты превращаются в кадры, проверяются на ошибки и управляются. Пример оборудования: коммутаторы.
3️⃣ уровень 3: Сетевой
Здесь происходит маршрутизация трафика с помощью роутеров. Здесь работает протокол ARP, который связывает IP-адреса и MAC-адреса. Информация передается в виде пакетов.
4️⃣ уровень 4: Транспортный
Здесь пакеты передаются по сети с установлением или без соединения. Здесь работают протоколы TCP и UDP, которые разбивают данные на сегменты или датаграммы.
5️⃣ уровень: Сеансовый
Здесь поддерживается сессия между приложениями. Здесь работают протоколы, которые координируют коммуникацию, синхронизацию и обмен информацией. Пример: созвон в Zoom или прямой эфир на YouTube.
6️⃣ уровень: Уровень представления
Подготавливает и преобразует (сжимает, кодирует, шифрует) информацию в понятный язык для пользователя или машины. Например, если вы отправляете картинку, то она сначала приходит в виде битов, а потом трансформируются в JPEG, GIF или другой формат.
7️⃣ уровень: Прикладной
Самый верхний уровень модели OSI. С помощью своих протоколов он отображает данные в понятном конечному пользователю формате. Сюда входят такие технологии, как HTTP, DNS, FTP, SSH и многое другое. Почти каждый человек ежедневно взаимодействует с протоколами прикладного уровня.
📎 Ссылки
1. Это база. Сетевая модель OSI. Истоки
2. Уровни модели OSI
3. Что такое модель OSI и зачем она нужна
#сети
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
Модель OSI (Open System Interconnection) описывает, как устройства в локальных и глобальных сетях обмениваются данными и что происходит с этими данными. Её предложили в 1984 году инженеры из Международной организации по стандартизации (ISO), которая работала над единым стандартом передачи данных по интернету.
1️⃣ уровень: Физический. Здесь биты передаются между устройствами оптическими, электрическими или радиосигналами. Устройства не понимают данные, а только сигналы. Примеры оборудования: концентраторы, медиаконвертеры, репитеры.
2️⃣ уровень: Канальный.
Здесь определяется адресация устройств с помощью MAC-адресов. Биты превращаются в кадры, проверяются на ошибки и управляются. Пример оборудования: коммутаторы.
3️⃣ уровень 3: Сетевой
Здесь происходит маршрутизация трафика с помощью роутеров. Здесь работает протокол ARP, который связывает IP-адреса и MAC-адреса. Информация передается в виде пакетов.
4️⃣ уровень 4: Транспортный
Здесь пакеты передаются по сети с установлением или без соединения. Здесь работают протоколы TCP и UDP, которые разбивают данные на сегменты или датаграммы.
5️⃣ уровень: Сеансовый
Здесь поддерживается сессия между приложениями. Здесь работают протоколы, которые координируют коммуникацию, синхронизацию и обмен информацией. Пример: созвон в Zoom или прямой эфир на YouTube.
6️⃣ уровень: Уровень представления
Подготавливает и преобразует (сжимает, кодирует, шифрует) информацию в понятный язык для пользователя или машины. Например, если вы отправляете картинку, то она сначала приходит в виде битов, а потом трансформируются в JPEG, GIF или другой формат.
7️⃣ уровень: Прикладной
Самый верхний уровень модели OSI. С помощью своих протоколов он отображает данные в понятном конечному пользователю формате. Сюда входят такие технологии, как HTTP, DNS, FTP, SSH и многое другое. Почти каждый человек ежедневно взаимодействует с протоколами прикладного уровня.
📎 Ссылки
1. Это база. Сетевая модель OSI. Истоки
2. Уровни модели OSI
3. Что такое модель OSI и зачем она нужна
#сети
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16❤3