Listen IT

📚 А вот и первая лекция по AI! Напомню, что мы начинаем цикл лекций от Никиты Кудряшова (Head of Data Science и специалист в области машинного обучения и нейронных сетей), где будем подробно разбирать тему искусственного интеллекта. А в первой лекции мы начнём, конечно, с базы: ❓Что такое ИИ ❓Почему искусственный интеллект не совсем "интеллект" ❓История развития ИИ ❓Неужели ИИ придумали так давно, и тогда почему ChatGPT появился только сейчас Ну а аудио-версию лекции, конечно, тоже приложили постом выше (хотя там, конечно, нет красивых исторических графиков из видео). Очень хочется увидеть вашу реакцию и отзывы по лекции. Понравилось? Хотелось бы ещё таких лекций? https://www.youtube.com/watch?v=5L7eLnAY7aA

🫙 Основные понятия баз данных. Главное Понимание принципов работы и основ проектирования БД – это основа всех 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, БД будет целостна только тогда, когда она будет содержать все результаты успешных запросов, выполненных в транзакции. БД гарантирует, что в случае ошибки в транзакции, данные не будут изменены. Про типы связей и нормализацию данных расскажем в следующих постах. Если вы хотите увидеть эти материалы поскорее, ставьте ⚡️ Ссылки на полезные материалы по основам БД в следующем посте👇 #бд

🎓 Так, давненько не было никаких новостей! Всё нормально, я просто был в отпуске, поэтому активно возвращаюсь и сразу с анонсом: Тема всяких AI, машинных обучений, нейронных сетей и дата-саенсов сейчас просто везде. Да даже если этим вообще не интересоваться, то всё равно тебя это заденет - все новые модели телефонов/ОС/приложений сейчас щеголяют какой-то новой AI-фичей. Но мы-то как раз обычно всем интересуемся и хотим во всём разобраться! Поэтому возникло желание рассказать вам о том, что такое AI, историю его появления и развития, как это вообще работает, ну и дальше уже глубже в нюансы. Но рассказать чуть с большим погружением, чем обычно, и в новом формате - в формате цикла лекций от реального специалиста в области ML и DS, который занимает должность Head of Data Science, преподавал машинное обучение и нейронные сети в Политехе и работает с этим на практике каждый день. Пока планируем цикл из трёх лекций, первая из которых будет про самые основы: что такое AI, какие есть заблуждения, когда мы расшифровываем эту аббревиатуру, и как он развивался до современного состояния какого-нибудь ChatGPT. Эта лекция у меня уже в монтаже. Интересно было бы послушать такое?

🎚 Очередной чит-лист по проектированию систем от Alex Xu (ByteByteGo) в LinkedIn. На этот раз я перевёл для вас его пост про масштабируемость, пропускную способность и доступность системы. Нам часто говорят, что нужно проектировать сервисы высокодоступными, хорошо масштабируемыми и с высокой пропускной способностью. Но что это означает на практике? 1️⃣ Высокая доступность Это означает, что нам нужно добиться наиболее высокого аптайма (суммарное время работы системы без сбоев и отключений за определённый период времени). Обычно при проектировании проговаривается целевой показатель доступности "3 девятки" или "4 девятки". 4 девятки (аптайм 99,99%) означает, что сервис может быть недоступен только 8,64 секунды в день. Чтобы достичь высокой доступности, мы должны использовать избыточность при проектировании системы. Есть несколько способов это сделать: 🔹 Hot-hot: два экземпляра системы (инстанса) получают одно и то же на вход и отдают одно и то же на выход для сервиса в последующий сервис. В ситуации, когда один из инстансов "упадёт", то второй сможет сразу его подменить. Т. к. оба инстанса отправляют данные в последующий сервис, то этому сервису нужно сделать так, чтобы на его стороне не было дубликатов данных. 🔹 Hot-warm: два инстанса получают одинаковые данные на вход, но только один из них (hot) отправляет исходящие данные в последующий сервис. В случае, если hot-инстанс "упал", warm-инстанс подхватывает работу и начинает слать исходящие данные в последующий сервис. 🔹 Single-leader-кластер (кластер с одним лидером): данные на вход получает только один лидер-инстанс, а потом он дублирует данные на другие экземпляры сервиса. 🔹 Leaderless-кластер (кластер без лидера): в этом типе кластера лидера нет вообще. Любая запись данных дублируется на все инстансы. Пока сумма инстансов для записи и инстансов для чтения будет больше, чем общее количество инстансов, то кластер может гарантировать согласованность данных. 2️⃣ Высокая пропускная способность Это означает, что сервису нужно обрабатывать большое количество запросов в заданный период времени. Обычно используются метрики QPS (query per second - запросов в секунду) или TPS (transaction per second - транзакций в секунду). Чтобы добиться высокой пропускной способности, часто используется кэширование, чтобы запрос мог обработаться без участия медленных устройств ввода-вывода, таких как базы данных и диски. Также можно увеличить количество потоков для задач, требующих интенсивных вычислений. Тем не менее, добавление слишком большого количества потоков может ухудшить производительность. В этом случае нам нужно будет найти узкие места в системе и увеличить их пропускную способность. Использование асинхроной обработки часто может эффективно изолировать "тяжеловесные" ресурсоёмкие компоненты. 3️⃣ Высокая масштабируемость Это означает, что система может быстро и просто расширяться для обработки больших объёмов данных (горизонтальное масштабирование) или большего числа функций (вертикальная масштабируемость). Обычно смотрят на время отклика, чтобы решить, нужно ли масштабировать систему.

🔥 Большая подборка материалов по микросервисной архитектуре Призываем активно делится материалами в комментариях, если у вас есть, что показать ☺️ 📑 Статьи (теория) 1. Просто о микросервисах — Хабр, блог Райффайзен Банка 2. Простым языком о микросервисной архитектуре для начинающих — VK Cloud 3. Архитектура микросервисов 4. Шпаргалка по миграции монолита на микросервисы 5. Полный перечень паттернов проектирования MSA от Криса Ричардсона 6. 26 основных паттернов микросервисной разработки на русском 7. Какого размера должен быть микросервис 8. Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности 9. Сравнение подходов к реализации распределенных транзакций для микросервисов 📝 Статьи (практика) 1. Микросервисы глазами аналитика 2. Микросервисы: опыт использования в нагруженном проекте 3. Не бойся микросервиса: Алексей Баитов об использовании микросервисной архитектуры на практике 4. Kafka и микросервисы: обзор 5. Путь IVI от монолита к микросервисам 6. Переход от монолита к микросервисам: история и практика Райффайзен Банка 7. Предметно-ориентированная микросервисная архитектура от Uber 8. Распределённая трассировка: мы всё делали не так ⏯ Видео и вебинары 1. Что такое Микросервисы || Объяснение от Мартина Фаулера (пересказ на русском) 2. Микросервисная архитектура, подходы и технологии — Кирилл Ветчинкин 3. Введение в архитектуру микросервисов — Дмитрий Голых 4. Микросервисы с нуля — Семен Катаев (Авито) 5. ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам — Андрей Половов (Флант) 6. Современная Микросервисная архитектура в банковской сфере — доклад Александр Соляра (Иннотех) на конференции Analyst Days-13 7. Аналитика микросервисов. Практический опыт аналитика в enterprise — доклад Валерия Разномазова на конференции Analyst Days-14 8. Проектируем приложение в микросервисной архитектуре. Разбор кейсов — доклад Максима Цепкова на конференции Analyst Days-12 9. Шаблоны проектирования микросервисов на примере Авито 10. Целостность данных в микросервисной архитектуре — Николай Голов (Avito) 11. Мастер-класс: использование брокеров сообщений в сервисной архитектуре — Андрей Бураков 12. Микросервисы vs монолит: разбираемся в архитектуре приложений — демо-занятия от Яндекс Практикум 13. Микросервисная архитектура, когда нужна, а когда нет — открытый вебинар курса «Microservice Architecture» от OTUS 14. Тестирование в микросервисной архитектуре — демо-занятие курса «Microservice Architecture» 15. Авторизация и аутентификация в микросервисной архитектуре — открытый вебинар курса «Microservice Architecture» от OTUS Вот ссылка на плейлист в Ютубе, где собраны все видео выше + ещё несколько 📚 Книги 1. Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга 2. Сэм Ньюмен. Создание микросервисов 3. Беллемар Адам. Создание событийно-управляемых микросервисов 4. Сэм Ньюмен. От монолита к микросервисам 5. Парминдер Кочер. Микросервисы и контейнеры Docker ⛔️ Про недостатки MSA 1. Хватит везде делать микросервисы 2. Остановитесь!!! Вам не нужны микросервисы 3. Микросервисы. Не всё то золото, что хайп 4. Видео Ах, как хочется вернуться, ворваться в монолит! — Павел Лакосников (Авито) 5. Верните мне мой монолит #подборка #микросервисы #архитектура

👔 Я сейчас в процессе подготовки нового формата, а точнее, отдельного плейлиста с углублёнными лекциями по машинному обучению - скоро расскажу вам о нём. А пока есть немного интересного для тех, кто хочет прокачаться в скилле проходить собеседования в IT. Проходить собеседования — это навык. Если в 2024-м вы хотите — меньше волноваться на собесах, — эффективнее отвечать на вопросы и грамотно задавать их, читайте канал про собеседования в IT, где собран опыт и кандидата, и работодателя. —————— 🔹Булат ходит на собесы из азарта и интереса и пишет, что да как: какие были этапы, какие задавали вопросы. Лонгрид раз — про интервью к поставщику и разработчику технологий для бирж Два — про интервью в финтех Три — в Medtech 🔹Булат сам нанимает сотрудников и рассказывает, почему кандидату отказали. Лонгрид раз — про закрытые ответы  Два — про улыбку и болтовню Три — про кандидата, который спорил ————— ✅Подписывайтесь, чтобы быть готовыми к собеседованию, а в случае отказа — сохранять здравую самооценку. https://t.me/tryoutonadancefloor 👆

📢 И снова новенькое! На этот раз сравниваем RPC, REST, GraphQL и SOAP. Вкратце пробежимся по четырем основным популярным протоколам/стилям для построения интеграции, рассмотрим их плюсы-минусы, кейсы применения, а также подумаем, в каком случае что из этого лучше выбрать. В конце ролика дана неплохая табличка-шпаргалка с быстрым сравнением. Это такой ролик - сборная солянка со сравнением, а практически по каждому из них у нас уже было отдельное видео: 🔹REST 🔹RPC / gRPC 🔹GraphQL 🔹REST vs SOAP Аудио-версия, как всегда, постом выше.

📣 Денормализация уже на канале! Обсудим, что это за денормализация БД такая, зачем и когда её делать, а также разберём на примере денормализацию небольшой базы. https://youtu.be/RbUdncgeCjI Аудио-версия статьи, как всегда, постом выше.