Паттерны проектирования для облачных сервисов

Шпаргалка по перенаправлениям в Linux #linux

Ровно двадцать лет назад, 7 апреля 2005 года, Линус Торвальдс сделал самый первый коммит в новую систему контроля версий под названием Git. Торвальдс, как известно, написал Git всего за десять дней после того, как разработчики ядра Linux потеряли доступ к своему фирменному инструменту BitKeeper из-за лицензионных разногласий. Фактически, в том первом коммите он написал достаточно Git, чтобы использовать Git для совершения коммита!

Нестандартный и децентрализованный дизайн Git — в настоящее время распространен повсеместно и, казалось бы, довольно очевиден, но в то время он был революционным и изменил то, как команды разработчиков программного обеспечения сотрудничают и разрабатывают. (А именно, GitHub)

Оглядываясь назад, Линус Торвальдс говорит, что для него Git не был чем-то особенным, просто вещь, которая необходима в повседневной работе.
https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/
#git

Российской экономике необходимо дополнительно минимум 600 тыс. в IT-специалистов до 2030 года, сообщил вице-премьер - руководитель аппарата правительства РФ Дмитрий Григоренко.

"На сегодняшний день самая, наверное, востребованная специальность в мире - это специальность в сфере IT. И только в Российской Федерации мы делаем прогноз о дополнительной потребности в IT-специалистах до 2030 года, и необходимо минимум 600 тыс. таких работников", - сказал Григоренко на торжественном открытии Международной ИТ-олимпиады для школьников, которое состоялось во вторник в координационном центре правительства РФ.

"На сегодняшний день любая компания, которая занимается бизнесом, не только в РФ и не только крупная, но и мелкая, любая, так или иначе либо в штате должна иметь специалиста по IT-технологиям, либо соответствующего специалиста покупать на рынке", - добавил он.
https://www.interfax.ru/digital/1018751

Как работает межпроцессная коммуникация через pipe в Linux #linux

Я так понимаю, StackOverflow в РФ тоже замедлился...

Дорожная карта по изучению API

Некоторые распространеные методы оптимизации SQL-запросов:

1. Создавайте индекс для огромных таблиц (>1.000.000 строк)
2. Используйте EXIST() вместо COUNT(), чтобы найти элемент в таблице.
3. Используйте выборку отдельных полей с помощью SELECT вместо использования SELECT *
4. Избегайте подзапросов в предложении WHERE
5. Избегайте SELECT DISTINCT, где это возможно.
6. Используйте предложение WHERE вместо HAVING
7. Создавайте объединения с помощью INNER JOIN (не WHERE)
8. Используйте LIMIT для выборки результатов запроса
9. Используйте UNION ALL вместо UNION везде, где это возможно.
10. Используйте UNION where вместо запроса типа "WHERE ... OR ...".
11. Выполняйте запрос в часы наименьшей нагрузки
12. Избегайте использования OR в запросах на соединение.
14. Выберите GROUP BY вместо оконных функций (window function)
15. Используйте производные и временные таблицы
16. Удаляйте индекс перед загрузкой большого объема данных
17. Используйте материализованные представления (materialized views) вместо представлений
18. Избегайте операторов != или <> ( не равно)
19. Минимизируйте количество подзапросов.
20. Используйте INNER joinе как можно реже, если вы можете получить тот же результат с помощью LEFT/RIGHT join
21. Часто пытайтесь использовать временные источники для извлечения одного и того же набора данных.
#sql #database

(Иллюстрация к предыдущему посту - порядок выполнения SQL-команд)

Шпаргалка по системному дизайну

ВКонтакте переходит на Go и открывает набор Go-разработчиков для перехода на новую архитектуру

"ВКонтакте запускает технологический проект по переводу соцсети на сервисную архитектуру и построению единой платформы разработки. Компания планирует привлечь больше 100 Go-разработчиков на проект. Они будут заниматься развитием современного технологического стека и писать новую архитектуру на языке программирования Go.
Переход на единую платформу разработки ускорит процесс создания новых продуктов. Она позволяет переиспользовать набор функций в нескольких продуктах компании, не задействуя дополнительные технологии.
«Go-разработчики усилят команду технической трансформации ВКонтакте для осуществления перехода на сервисную архитектуру. Участвуя в обновлении одного из самых крупных сервисов рунета, разработчики получат уникальный опыт и будут работать над стратегическими задачами. Нам важно создавать технические продукты, отвечающие трендам в разработке. Переход на новую архитектуру — один из таких проектов», — поделился CTO ВКонтакте и бизнес-группы «Социальные платформы и медиаконтент» VK Сергей Ляджин.
https://vk.com/press/go-meet-up

8 ключевых структур данных, на которых основаны современные базы данных

🔹 Skiplist: общий тип индекса в памяти. Используется в Redis
🔹 Хэш-индекс: очень распространенная реализация структуры данных «Карта» (или «Коллекция»)
🔹 SSTable: неизменяемая реализация «Map» на диске
🔹 Дерево LSM: Skiplist + SSTable. Высокая пропускная способность записи
🔹 B-tree: решение на основе диска. Постоянная производительность чтения/записи
🔹 Инвертированный индекс: используется для индексации документов. Используется в Lucene
🔹 Дерево суффиксов: для поиска по шаблону строки
🔹 R-дерево: многомерный поиск, например, поиск ближайшего соседа

Вкратце о нулевых указателях

Расположение различных частей программы в различных частях памяти на примере кода на Си

Автономные системы и микросервисы

Автономные системы (𝗦𝗲𝗹𝗳-𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗱 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 или 𝗦𝗖𝗦) представляют подход к архитектуре программного обеспечения, который отдает приоритет децентрализации приложений в независимые системы,
каждая из которых имеет свою доменную логику, пользовательский интерфейс и хранилище данных. В отличие от микросервисов, которые являются более мелкими сервисами, ориентированными исключительно на
бизнес-логику, SCS более значительна и охватывает более широкую область в пределах определенного домена.
SCS — это системы, представляющие автономные веб-приложения. Они включают веб-интерфейс, бизнес-логику и базу данных, а также могут иметь API-интерфейс сервиса. Обычно ими управляет одна команда.

Основными преимуществами таких систем являются:

𝟭. Автономность - Каждая SCS работает независимо со своей базой данных, бизнес-логикой и пользовательским интерфейсом.
𝟮. Упорядочение доменов - SCS структурирована вокруг конкретных бизнес-доменов, гарантируя, что каждое подразделение представляет собой согласованный и значимый набор функций.
𝟯. Децентрализованное управление данными - Отдельные базы данных в каждой SCS обеспечивают согласованность данных в пределах своих границ, снижая межсервисные зависимости.
𝟰. Технологическая разнородность - Позволяет использовать различные технологические стеки в других SCS, отвечая конкретным потребностям каждого домена.
𝟱. Общедоступный API - Четко определенные интерфейсы для взаимодействия с другими системами, поддерживающие четкий контракт и сохраняющие инкапсуляцию.
𝟲. Независимое развертывание - Каждую SCS можно развертывать, масштабировать и обновлять независимо, не влияя на другие системы.

Такие системы хорошо сочетаются с доменным дизайном (𝗗𝗼𝗺𝗮𝗶𝗻-𝗱𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝘀𝗶𝗴𝗻 или 𝗗𝗗𝗗).
Первым шагом в создании таких систем является анализ домена, который можно провести путем выявления ограниченных контекстов, соответствующих конкретным бизнес-доменам.
Каждый ограниченный контекст затем инкапсулируется в SCS, которая включает в себя собственное управление данными, бизнес-логику и пользовательский интерфейс, гарантируя, что каждая система является автономной, но при этом способна взаимодействовать с другими через четко определенные API при необходимости.

Почему автономные системы имеют преимущество перед микросервисами:

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

(Иллюстрация к предыдущему посту - монолит vs микросервисы vs автономные системы)

Как работают каналы (pipes) в Linux #linux
Каналы осуществляюь межпроцессное взаимодействие путем отправки данных из вывода одного процесса (stdout) на ввод другого (stdin).
Существуют односторонние каналы, где данные передаются в одном направлении — от писателя (генератора данных) к читателю (потребителю данных).
Концептуальный поток: Процесс A (stdout) → [КАНАЛ] → (stdin) Процесс B

Некоторые типы каналов
1) Анонимные каналы
Представляют временный, односторонний канал связи между двумя связанными процессами.
Являются односторонними: Данные передаются в одном направлении.
Область видимости: Существует только во время выполнения процессов.
Создание: Создается программно с помощью системного вызова pipe() или неявно с помощью оператора | в командной строке.
Использование: Обычно используется для объединения команд в конвейер.

ПРимер создания канала:
$ cat file.txt | grep "keyword" | wc -l

Здесь cat читает файл. Вывод фильтруется grep.
Отфильтрованные строки подсчитываются с помощью wc.

2)Именованные каналы или Named Pipes (Также известны как FIFO (First In, First Out))
Представляют постоянный канал связи, который существует как специальный файл в файловой системе, позволяющий несвязанным процессам общаться.
Являются односторонними: Как в анонимных каналах, данные передаются в одном направлении.
Постоянство: Остается в файловой системе до явного удаления.
Создание: Создается с помощью команд mkfifo или mknod.
Область видимости: Может быть доступен через разные сеансы или несвязанные процессы.

Создание именованного канала:
$ mkfifo my_pipe

Запись в канал:
$ echo "Hello, World!" > my_pipe &

Считывание из канала:
$ cat < my_pipe


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

(Иллюстрация к предыдущему посту - Как работают каналы в Linux)

Зависимости основных сетевых протоколов

Дорожная карта для изучения технологий по работе с данными #database

Компоненты MAC-адреса