Шпаргалка для тех, кто ещё не понял, что выбрать

Виды нереляционных БД. Какие бывают NoSQL базы данных

Ранее мы писали о реляционных БД, сравнивали их с нереляционными. Познакомимся с NoSQL подробнее. Все ссылки кликабельны, нажмите на название СУБД и откроется статья из Хабра.

Нереляционные базы данных хранят данные без четких связей друг с другом и четкой структуры. Вместо структурированных таблиц внутри базы находится множество разнородных документов, в том числе изображения, видео и даже публикации в социальных сетях. Такие базы данных ещё называют NoSQL, так как они не поддерживают запросы SQL.

1️⃣ Ключ-значение (Key-value)
Предназначены для быстрых, почти мгновенных запросов для таких задач как кэш, отображение баланса и т.д.. Высокая скорость осуществляется за счет хранения данных по принципу ключ-значение, и в большинстве случаев благодаря работе в оперативной памяти. Записи хранятся и извлекаются с использованием ключа, который однозначно идентифицирует запись и используется для быстрого поиска данных.
👉 Примеры СУБД: Redis, Memcached, Tarantool.

2️⃣ Документо-ориентированные БД
Могут быть полезны, если нужно хранить много файлов/документов и вы не хотите задумываться о структуре хранения, иерархии, связях. Такие БД имеют структуру дерева: начинаются с корневого узла и может содержать несколько внутренних и листовых узлов.

Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, это дает возможность даже при достаточно сложной структуре находить путь к искомых данных. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память.
👉 Примеры СУБД: MongoDB.

3️⃣ БД временных рядов (TSDB)
Подходят, если есть упорядоченные по времени данные с временными метками, такие как метрики от инфраструктуры или данные датчиков. Часто используются для осуществления мониторинга различных метрик (будь то загрузка CPU, или показатели работы какого-либо датчика).
👉 Примеры СУБД: Prometheus, InfluxDB, Graphite.

4️⃣ Графовые БД
Применяются, когда нужно анализировать отношения данных, их связи или просто упростить запросы с километровыми Join, имеет смысл использовать графовые базы данных. Данные и их связи представляются как вершины и ребра графа соответственно. Таким способом можно легко представить денежные переводы (для определения различных мошеннических схем), связи в социальной сети и граф общения между операторами сотовой сети.
👉 Примеры СУБД: Neo4J.

5️⃣ Поисковые БД (Search Engines)
Подходит, если вам необходимо осуществлять поиск по большим объемам данных, особенно неструктурированным, как пример поиск по нескольким терабайтами логов.

Поиск по текстам работает на основе индексирования. Каждому слову/лемме/n-грамме присваивается индекс. Затем формируется структура вроде таблицы, где строки являются документом, а столбцы индексами. Поиск по индексу существенно быстрее, чем по совпадению по словам в документах.
👉 Примеры СУБД: Elasticsearch.

6️⃣ Объектно-ориентированные БД
Здесь информация представлена в виде объектов, прямо как в ООП. Объектно-ориентированные базы данных появились как способ нативной коммуникации кода написанного с использованием объектно-ориентированных языков с базой данных.
👉 Примеры СУБД: Db4o.

7️⃣ Колоночные БД (column family store)
Колоночные NoSQL-базы хранят данные по столбцам, а не по строкам, как в реляционных БД. Это упрощает добавление и удаление свойств, а также позволяет работать с данными без жесткой схемы. Колоночные БД быстро и экономно обрабатывают большие объемы информации для анализа, так как выгружают только нужные значения из столбцов.
👉 Примеры СУБД: Cassandra, Clickhouse.

📎 Ещё полезные материалы
1. Виды баз данных. Большой обзор типов СУБД
2. Базы данных: большой обзор типов и подходов. Доклад Яндекса
3. Модели данных в NoSQL
4. Использование memcached и Redis в высоконагруженных проектах
5. Как базы данных «ключ-значение» обеспечивают производительность и масштабируемость без границ
6. SQL и NoSQL. Правда ли одно лучше другого?

#бд

🏄🏻‍♂️ Балансировка нагрузки. Основные принципы

Балансировка нагрузки — это распределение трафика и задач между серверами. Сначала все компоненты веб-приложения могут быть на одном сервере, но потом его мощности может не хватить. Тогда можно улучшить сервер, добавить CPU/RAM (вертикальное масштабирование) или разделить задачи на несколько серверов (горизонтальное масштабирование).

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

✅ Что даёт балансировка нагрузки

➕ Отказоустойчивость. Если один сервер откажет, балансировщик распределит трафик между остальными элементами инфраструктуры.

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

➕ Защита от DDoS-атак. Ее обеспечивает задержка ответа, когда фоновые серверы не видят клиента до подтверждения по TCP.

Три уровня распределения нагрузки

1️⃣ Сетевой. Балансировка осуществляется по следующему принципу: нужно сделать так, чтобы за один конкретный IP-адрес сервера отвечали разные физические машины. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме. На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.

2️⃣ Транспортный (L4). Клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами: путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.

3️⃣ Прикладной (L7). В отличие от транспортного уровня, он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Примером L7-балансировщика является pgpool, который распределяет запросы к PostgreSQL по их содержанию: чтение — один сервер, запись — другой.

🆚 Балансировка или проксирование?

Балансировку нагрузки часто называют проксированием. Это не совсем так.
Всякий балансировщик – прокси-сервер, но не всякое проксирование является балансировкой
Прокси – посредник между клиентом и сервером. Принимает запрос от клиента и отправляет серверу, а затем получает ответ от сервера и передаёт клиенту
Прокси имеют другое назначение и функции: служат для повышения безопасности и производительности путем кэширования часто используемого контента и скрытия идентификации и местоположения серверов от клиентов.

Алгоритмы балансировки

🔹 Round Robin: запросы распределяются по кругу между всеми доступными серверами, без учета их загрузки или других параметров. Это самый простой и равномерный метод, но он не подходит для ситуаций, когда сервера имеют разную мощность или специализацию.

🔹Weighted Round Robin: запросы распределяются по кругу между всеми доступными серверами, но с учетом их веса, который отражает их мощность или приоритет. Это позволяет отправлять больше запросов на более производительные сервера.

🔹Least Connections: запросы направляются на тот сервер, который наименее загружен в данный момент. Это позволяет избегать перегрузки одного сервера.

🔹Least Response Time: запросы направляются на тот сервер, который имеет наименьшее суммарное время ответа. Это позволяет учитывать не только загрузку сервера, но и скорость сети.

🔹Sticky Sessions: запросы одного и того же клиента будет передаваться на один и тот же сервер. Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер.

📎 Ссылки
1. Статья от Selectel
2. Видео
3. Алгоритмы балансировки нагрузок
4. Введение в современную сетевую балансировку и проксирование
5. Как Контур балансирует нагрузку в микросервисах
6. Балансировка нагрузки в Kubernetes

#инфраструктура

Шпаргалка по выбору правильной СУБД в продолжение к посту про типы нереляционных БД.

Источник

#бд

От монолита к микросервисам. Эволюционные шаблоны для трансформации монолитной системы

✍️ Автор: Сэм Ньюмен
📅 Год: 2021
🔤 Язык: русский

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

Обзор книги

#архитектура #микросервисы #проектирование

🎙 Бесплатные подкасты из Радио "Аналитик"

Скачать любой из подкастов или весь сборник целиком можно по ссылке (Яндекс Диск).

Список подкастов

1. О развитии навыков ИТ-аналитика с Александром Чавалах

2. О работе с изменениями с Алёной Ивахновой

3. О необходимых для аналитика hard skills с Дмитрием Летяго

4. О работе с задачами по адаптации типового решения под требования заказчика с Татьяной Рыловниковой

5. Об основах работы с данными с Владимиром Ловцовым

6. О мышлении и коммуникативных навыках с Гюльнарой Антроповой

7. Об управлении обеспечением предприятий с Дмитрием Кучмой

8. Об обратной связи и её месте в развитии аналитика с Артёмом Пластининым

9. О ванильном мороженом и обучении аналитиков 1С с Анастасией Штей

10. О консалтинге в сфере 1С с Алексеем Бояршиновым

11. О создании продуктов с Сергеем Колосковым

12. О командной работе и построении эффективных коммуникаций с Маргаритой Маковеевой

13. О книге Карла Вигерса "Разработка требований к программному обеспечению" с Александром Байкиным

14. О когнитивных искажениях, сервисе UX CORE и проекте KeepSimple c Вольфом Алексаняном

15. О текстах в интерфейсах с Александром Марфициным

16. Об ожиданиях предпринимателей от автоматизации с Артёмом Вахрушевым

17. Об ожиданиях от автоматизации в сферах foodtech и e-com с Павлом Вепревым

18. О мифах, которые рождаются вокруг продуктов с Алексеем Чернышовым

19. О возможностях 1С для создания полезных отчетов с Матвеем Серёгиным

20. Про первый опыт публичного выступления с Ольгой Зубковой

21. Про путь от первого выступления до первого места в топе лучших докладов с Павлом Громовым

22. Про ожидания и реальность офлайн выступлений с Дмитрием Макаровым

23. О планировании с Владимиром Завертайловым и Екатериной Мамонтовой

24. Про интеграции с Артуром Белопольских

25. О пробелах в знаниях, недостающем опыте и новых вызовах для аналитиков из сферы 1С с Еленой Ивановой

26. Про решение проблем с Анастасией Московкиной

27. Про фасилитацию и фасилитирующее лидерство в ИТ с Алексеем Таченковым

#подборка

📝 Задачи для системных аналитиков из конкурса IT_One Cup 2022 с решениями

По ссылкам ниже можно собственноручно прорешать задания и загрузить решение — проверка автоматическая. Требуется зарегистрировать аккаунт на all cups.

Ознакомительный раунд.
1. Задача А (Камни) — решение
2. Задача B (Почта) — решение

Квалификационный раунд
1. Задача А (Авария)
2. Задача B (Кредиты)
3. Задача C (Интеграция)

Заключительный раунд: ссылка на задачу и решение от победителя конкурса прикрепляем (.pdf)

➕ Ещё соревнования:
1. IT’s Tinkoff Solution Cup (с решениями)
2. Sovcombank Challenge 2021 (Системный анализ)

Если вы знаете, какие ещё весёлые конкурсы есть для системных аналитиков, пожалуйста, напишите в комментариях ⬇️

#развитие

Agile и Waterfall: главное о методологиях разработки ПО

Разделение всех методологий на Agile и Waterfall — это общепринятый способ классифицировать подходы к организации процесса разработки ПО.

🌊 Waterfall (водопадная/каскадная модель) — это классическая методология, при которой проект делится на последовательные этапы, которые выполняются один за другим. Переход к следующему этапу возможен только после завершения предыдущего. Клиент видит результат только в конце проекта.

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

✅ Преимущества Waterfall

1. Фиксированный бюджет и сроки, так как всё фиксируется на этапе составления ТЗ

2. Простота и понятность. Каждый этап имеет четкие входные и выходные данные, сроки и ответственных. Все участники проекта знают, что и когда нужно делать, и какой результат ожидать

❌ Недостатки Waterfall

1. Отсутствие гибкости. В проект нельзя вносить изменения. Если на каком-то из этапов возникнут проблемы, изменятся требования или станет ясно, что что-то не учли, придётся начинать сначала.

2. Риски. Если на каком-то этапе возникнут ошибки или недочеты, они могут быть обнаружены только в конце проекта, когда будет поздно

3. Отсутствие обратной связи. Меньше обратной связи – меньше уверенности, что мы делаем то, что действительно нужно

Где можно применять водопадную модель

● Несложные проекты, где объём работ можно легко определить и сформулировать в ТЗ.
● Проекты с очень строгими требованиями к бюджетам и срокам.

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


🔁 Agile — это семейство гибких методологий управления проектами.

Вся суть Agile содержится в четырёх пунктах его манифеста:

1️⃣ Люди и их взаимодействие важнее процессов и инструментов проектного управления.
2️⃣ Рабочее программное обеспечение (результат проекта) важнее всеобъемлющей документации.
3️⃣ Сотрудничество с клиентами важнее переговоров по контракту.
4️⃣ Реагирование на изменения важнее следования плану.

К Agile относят Scrum, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM.

В Agile проект делится на небольшие итерации или спринты (примерно 2 недели). Каждая итерация имеет какой-либо результат – готовую функциональность. Клиент участвует в процессе разработки и может давать свою обратную связь по каждой итерации. Продукт постоянно улучшается и адаптируется к изменяющимся требованиям.

✅ Преимущества Agile

1. Гибкость к изменениям и скорость. Например, если конкуренты выпустили новую функцию, её можно быстро разработать в уже начатом проекте.

2. Риски ниже — прямо в процессе команда получает обратную связь от пользователей. А если какая-то итерация растянется, следующую можно будет адаптировать под изменившиеся сроки и условия.

3. Ориентация на людей и команду даёт большую вовлечённость в проект.

❌ Недостатки Agile

1. Сложность внедрения. Его нужно уметь использовать. С умом. К тому же, люди часто привыкают к текущему способу работы и не всегда приветствуют изменения

2. Сложно планировать бюджет и сроки по причине большей неопределённости, новые хотелки от клиента могут возникнуть в любой момент.

3. Заспамленность созвонами. Вытекает из первого пункта в случае ошибок при внедрении. Однако забитый бессмысленными встречами календарь – это бич не только аджайла. Проблема шире, чем просто подход к разработке ПО.

Как правило, применять чистую методологию скажем, Scrum или Waterfall может оказаться менее эффективным, чем использовать сочетание наиболее подходящих инструментов из различных фреймворков.

📎 Материалы
1. Битва титанов: Waterfall VS Agile
2. Agile и «водопад». Сравнение подходов
3. Управление проектом по Agile методике
4. Об оценках сроков в разработке ПО
5. Гибридное управление проектами: как смешать модный Agile с традиционным проектным менеджментом

О минусах Agile
1. Scrum ужасен
2. Обратная сторона Agile
3. Как правильно имитировать Agile?

#управление_проектами