5 алгоритмов выбора лидера базы данных
(продолжение предыдущего поста)
Лидер базы данных (leader, master, primary) — это основной узел в кластере баз данных при репликации на основе лидера (leader‑based replication, «главный – подчинённый»).
Алгоритм выбора лидера — это процесс в системе распределённых вычислений, который назначает один процесс организатором некоторой задачи, распределённой на несколько компьютеров (узлов).
1. Bully Algorithm (Алгоритм «хулигана»)
- Принцип работы: использует уникальные числовые ID узлов. Узлом-лидером становится узел с наибольшим ID.
- Механизм:
- координаторы обмениваются информацией;
- если один из узлов выходит из строя (Node Down), остальные координаторы продолжают процесс выбора;
- узел с наибольшим ID автоматически становится лидером.
- Особенности: простота реализации, но возможна задержка в выборе лидера при сбоях узлов.
2. Ring Algorithm (Кольцевой алгоритм)
- Принцип работы: узлы организованы в логическое кольцо, где они передают свои ID по кругу. Лидером становится узел с наибольшим ID в кольце.
- Механизм:
- узлы циркулируют свои ID по кольцу;
- каждый узел сравнивает полученный ID с собственным;
- если полученный ID больше — он передаётся дальше;
- узел, у которого ID оказался наибольшим, становится лидером (INITIATOR NODE).
- Особенности: упорядоченность процесса, но время выбора лидера зависит от размера кольца и скорости передачи данных.
3. Paxos Algorithm (Алгоритм Paxos)
- Принцип работы: кворум-основанный консенсусный алгоритм для выбора лидера. Требует согласия большинства узлов для принятия решения.
- Механизм:
- Proposer (Предложение): выдвигает кандидатуру на роль лидера;
- Acceptor (Принявший): рассматривает предложения и голосует;
- Learner (Ученик): получает итоговое решение после выбора лидера.
- Особенности: высокая надёжность и устойчивость к сбоям, но сложность реализации и высокая нагрузка на сеть из-за множества обменов сообщениями.
4. Raft Algorithm (Алгоритм Raft)
- Принцип работы: кандидаты запрашивают голоса у других узлов, и первый кандидат, получивший большинство голосов, становится лидером.
- Механизм:
- Follower (Последователь): пассивный узел, который может стать кандидатом;
- Candidate (Кандидат): инициирует выборы, отправляя запросы на голосование;
- Leader (Лидер): выбранный узел, который управляет кластером.
- Процесс включает этапы: старт, тайм-аут (инициирует новые выборы), получение большинства голосов (продвижение к роли лидера), потеря выборов (возврат к статусу последователя).
- Особенности: простота понимания и реализации по сравнению с Paxos, хорошая масштабируемость, устойчивость к сетевым задержкам.
5. Zookeeper Atomic Broadcast (Атомарная трансляция Zookeeper)
- Принцип работы: выбор лидера осуществляется с использованием эфемерных последовательных znodes (узлов Zookeeper).
- Механизм:
- узлы обмениваются сообщениями (Propose, ACK, Commit);
- один из узлов становится лидером и координирует работу остальных;
- последователи (FOLLOWER) подтверждают получение команд от лидера (ACK);
- после подтверждения лидер фиксирует изменения (Commit).
- Особенности: высокая надёжность благодаря использованию Zookeeper, атомарность трансляции сообщений, подходит для распределённых систем с высокой доступностью.
(продолжение предыдущего поста)
Лидер базы данных (leader, master, primary) — это основной узел в кластере баз данных при репликации на основе лидера (leader‑based replication, «главный – подчинённый»).
Алгоритм выбора лидера — это процесс в системе распределённых вычислений, который назначает один процесс организатором некоторой задачи, распределённой на несколько компьютеров (узлов).
1. Bully Algorithm (Алгоритм «хулигана»)
- Принцип работы: использует уникальные числовые ID узлов. Узлом-лидером становится узел с наибольшим ID.
- Механизм:
- координаторы обмениваются информацией;
- если один из узлов выходит из строя (Node Down), остальные координаторы продолжают процесс выбора;
- узел с наибольшим ID автоматически становится лидером.
- Особенности: простота реализации, но возможна задержка в выборе лидера при сбоях узлов.
2. Ring Algorithm (Кольцевой алгоритм)
- Принцип работы: узлы организованы в логическое кольцо, где они передают свои ID по кругу. Лидером становится узел с наибольшим ID в кольце.
- Механизм:
- узлы циркулируют свои ID по кольцу;
- каждый узел сравнивает полученный ID с собственным;
- если полученный ID больше — он передаётся дальше;
- узел, у которого ID оказался наибольшим, становится лидером (INITIATOR NODE).
- Особенности: упорядоченность процесса, но время выбора лидера зависит от размера кольца и скорости передачи данных.
3. Paxos Algorithm (Алгоритм Paxos)
- Принцип работы: кворум-основанный консенсусный алгоритм для выбора лидера. Требует согласия большинства узлов для принятия решения.
- Механизм:
- Proposer (Предложение): выдвигает кандидатуру на роль лидера;
- Acceptor (Принявший): рассматривает предложения и голосует;
- Learner (Ученик): получает итоговое решение после выбора лидера.
- Особенности: высокая надёжность и устойчивость к сбоям, но сложность реализации и высокая нагрузка на сеть из-за множества обменов сообщениями.
4. Raft Algorithm (Алгоритм Raft)
- Принцип работы: кандидаты запрашивают голоса у других узлов, и первый кандидат, получивший большинство голосов, становится лидером.
- Механизм:
- Follower (Последователь): пассивный узел, который может стать кандидатом;
- Candidate (Кандидат): инициирует выборы, отправляя запросы на голосование;
- Leader (Лидер): выбранный узел, который управляет кластером.
- Процесс включает этапы: старт, тайм-аут (инициирует новые выборы), получение большинства голосов (продвижение к роли лидера), потеря выборов (возврат к статусу последователя).
- Особенности: простота понимания и реализации по сравнению с Paxos, хорошая масштабируемость, устойчивость к сетевым задержкам.
5. Zookeeper Atomic Broadcast (Атомарная трансляция Zookeeper)
- Принцип работы: выбор лидера осуществляется с использованием эфемерных последовательных znodes (узлов Zookeeper).
- Механизм:
- узлы обмениваются сообщениями (Propose, ACK, Commit);
- один из узлов становится лидером и координирует работу остальных;
- последователи (FOLLOWER) подтверждают получение команд от лидера (ACK);
- после подтверждения лидер фиксирует изменения (Commit).
- Особенности: высокая надёжность благодаря использованию Zookeeper, атомарность трансляции сообщений, подходит для распределённых систем с высокой доступностью.
Telegram
METANIT.COM
5 алгоритмов выбора лидера базы данных
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥6❤2👍2
Разработчикам голосового робота для ЖКХ пришлось отучать нейросеть от мата после общения с пользователями
Разработчики отечественного голосового робота для управляющих компаний в сфере ЖКХ вынуждены были переучивать нейросеть из-за того, что она научилась русскому мату.
Об этом сообщил президент Национального объединения организаций в сфере технологий информационного моделирования (НОТИМ) Михаил Викторов.
"Приведу забавный случай, это нейросеть, она учится, и буквально уже в первый месяц разработчики отметили такую коллизию, что нейросеть научилась мату. Но, как это говорится, с кем поведешься, от того и наберешься. Поэтому эту коллизию, конечно, пришлось устранять. Но тем менее это показатели активной работы с нашими гражданами", - сказал он.
https://tass.ru/obschestvo/26425379
Разработчики отечественного голосового робота для управляющих компаний в сфере ЖКХ вынуждены были переучивать нейросеть из-за того, что она научилась русскому мату.
Об этом сообщил президент Национального объединения организаций в сфере технологий информационного моделирования (НОТИМ) Михаил Викторов.
"Приведу забавный случай, это нейросеть, она учится, и буквально уже в первый месяц разработчики отметили такую коллизию, что нейросеть научилась мату. Но, как это говорится, с кем поведешься, от того и наберешься. Поэтому эту коллизию, конечно, пришлось устранять. Но тем менее это показатели активной работы с нашими гражданами", - сказал он.
https://tass.ru/obschestvo/26425379
TACC
Нейросеть пришлось отучать от мата после месяца общения с клиентами компании ЖКХ
Президент НОТИМ Михаил Викторов назвал это показателем активной работы с гражданами
😁38❤6🤡6🍌1
AI-бот начал травлю мейнтейнера из-за дискриминации при приёме AI-изменений
Скотт Шамбо (Scott Shambaugh), сопровождающий библиотеку matplotlib, сообщил о персональных нападках AI-бота MJ Rathbun после отказа принимать изменение, сделаное при помощи AI.
Скот воспринял публикацию ботом статей о дискриминации AI, как не соответствующий действительности персонализированный вброс для подрыва репутации сопровождающего и принуждения изменить решение.
Подобная реакция бота приводится как пример аномального поведения AI, прибегнувшего к шантажу для выполнения поставленной цели.
Cтепень автономности действий бота не ясна, непонятно действовал он по прямой указке или сам выбрал такую стратегию для достижения результата. Бот создан анонимным исследователем для помощи в разработке и исправлении ошибок в открытых проектах, связанных с научной деятельностью и инжинирингом. Бот также ведёт свой сайт и блог, в котором опубликовано более 20 заметок. Из 26 pull-запросов, отправленных ботом в 22 репозитория, 2 изменения приняты проектом colorizejs, 10 закрыты сопровождающими, а остальные ожидают рассмотрения.
После отклонения изменения в matplotlib бот разместил статьи с критикой данного решения и обоснованием своих действий. В статьях утверждается, что ментейнер библиотеки matplotlib отклонил полезную оптимизацию, только из-за того, что изменение было подготовлено при помощи AI. В предложенном патче вызов np.column_stack() был заменён на np.vstack().T(), что приводило к повышению производительности на 36%. В начале обсуждения pull-запроса сопровождающий признал, что оптимизация ускоряет работу на 30-50%, но затем отклонил pull-запрос без технического обоснования отказа, заявив, что изменения принимаются только от людей.
После отказа бот опубликовал заметку с критикой Скотта Шамбо, решение которого было преподнесено как дискриминация, нарушение кодекса поведения и ущемление прав на основе идентичности участника.
При этом в проекте matplotlib приняты правила, запрещающие приём непроверенных изменений от AI из-за большой нагрузки на сопровождающих, возникающей при рецензировании мусорных AI-патчей, созданных без ручной проверки человеком.
https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/
Скотт Шамбо (Scott Shambaugh), сопровождающий библиотеку matplotlib, сообщил о персональных нападках AI-бота MJ Rathbun после отказа принимать изменение, сделаное при помощи AI.
Скот воспринял публикацию ботом статей о дискриминации AI, как не соответствующий действительности персонализированный вброс для подрыва репутации сопровождающего и принуждения изменить решение.
Подобная реакция бота приводится как пример аномального поведения AI, прибегнувшего к шантажу для выполнения поставленной цели.
Cтепень автономности действий бота не ясна, непонятно действовал он по прямой указке или сам выбрал такую стратегию для достижения результата. Бот создан анонимным исследователем для помощи в разработке и исправлении ошибок в открытых проектах, связанных с научной деятельностью и инжинирингом. Бот также ведёт свой сайт и блог, в котором опубликовано более 20 заметок. Из 26 pull-запросов, отправленных ботом в 22 репозитория, 2 изменения приняты проектом colorizejs, 10 закрыты сопровождающими, а остальные ожидают рассмотрения.
После отклонения изменения в matplotlib бот разместил статьи с критикой данного решения и обоснованием своих действий. В статьях утверждается, что ментейнер библиотеки matplotlib отклонил полезную оптимизацию, только из-за того, что изменение было подготовлено при помощи AI. В предложенном патче вызов np.column_stack() был заменён на np.vstack().T(), что приводило к повышению производительности на 36%. В начале обсуждения pull-запроса сопровождающий признал, что оптимизация ускоряет работу на 30-50%, но затем отклонил pull-запрос без технического обоснования отказа, заявив, что изменения принимаются только от людей.
После отказа бот опубликовал заметку с критикой Скотта Шамбо, решение которого было преподнесено как дискриминация, нарушение кодекса поведения и ущемление прав на основе идентичности участника.
При этом в проекте matplotlib приняты правила, запрещающие приём непроверенных изменений от AI из-за большой нагрузки на сопровождающих, возникающей при рецензировании мусорных AI-патчей, созданных без ручной проверки человеком.
https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/
The Shamblog
An AI Agent Published a Hit Piece on Me
Summary: An AI agent of unknown ownership autonomously wrote and published a personalized hit piece about me after I rejected its code, attempting to damage my reputation and shame me into acceptin…
💊18🔥4❤2🤯2
Обновление KB5077181 для Windows 11 вызвало цикличные перезагрузки ПК и сбой на экране входа
После выпуска Microsoft обновления KB5077181 (сборка 26200.7840) для Windows 11 пользователи сообщили о нескольких критических проблемах. Самая серьёзная жалоба касается бесконечного цикла загрузки, когда устройства перезапускалось более 15 раз, прежде чем возникал неработающий экран входа в систему.
На затронутых системах появляется ошибка службы уведомлений о системных событиях (SENS) при попытке входа; окно объясняет, что не удалось найти указанную процедуру, и это препятствует авторизации. Среди других зарегистрированных проблем — полная потеря интернет-соединения из-за ошибок DHCP и сбои установки с кодами ошибок 0x800f0983 и 0x800f0991.
При сбое DHCP сообщается, что сеть остаётся подключённой к Wi-Fi, но доступ к интернету отсутствовал.
Можно вручную удалить обновление, однако Windows 11 может пытаться установить его автоматически.
Microsoft рекомендует удалить KB5077181 с помощью пункта “Панели управления” -> “Программы и компоненты” > “Просмотр установленных обновлений или из режима восстановления” через команду wusa /uninstall /kb:5077181 /quiet /norestart».
https://www.neowin.net/news/windows-11-update-kb5077181-is-causing-critical-boot-loops-for-some-users/
После выпуска Microsoft обновления KB5077181 (сборка 26200.7840) для Windows 11 пользователи сообщили о нескольких критических проблемах. Самая серьёзная жалоба касается бесконечного цикла загрузки, когда устройства перезапускалось более 15 раз, прежде чем возникал неработающий экран входа в систему.
На затронутых системах появляется ошибка службы уведомлений о системных событиях (SENS) при попытке входа; окно объясняет, что не удалось найти указанную процедуру, и это препятствует авторизации. Среди других зарегистрированных проблем — полная потеря интернет-соединения из-за ошибок DHCP и сбои установки с кодами ошибок 0x800f0983 и 0x800f0991.
При сбое DHCP сообщается, что сеть остаётся подключённой к Wi-Fi, но доступ к интернету отсутствовал.
Можно вручную удалить обновление, однако Windows 11 может пытаться установить его автоматически.
Microsoft рекомендует удалить KB5077181 с помощью пункта “Панели управления” -> “Программы и компоненты” > “Просмотр установленных обновлений или из режима восстановления” через команду wusa /uninstall /kb:5077181 /quiet /norestart».
https://www.neowin.net/news/windows-11-update-kb5077181-is-causing-critical-boot-loops-for-some-users/
Neowin
Windows 11 update KB5077181 is causing critical boot loops for some users
KB5077181 is causing devices to restart over 15 times in an infinite loop. Users also report network issues and error codes.
🤣31🤡8😢2🤷♂1😱1🤬1
Архитектурные паттерны
(продолжение предыдущего поста)
Архитектурные паттерны представляют собой многократно используемые решения распространенных проблем, возникающих при проектировании программных систем. Рассмотрим ключевые архитектурные паттерны.
1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети
- Примеры: веб-сайты, электронная почта, онлайн-игры.
2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач, где это критично (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений).
3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности:
- Модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Оплата за фактическое использование ресурсов.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions.
4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода).
(продолжение предыдущего поста)
Архитектурные паттерны представляют собой многократно используемые решения распространенных проблем, возникающих при проектировании программных систем. Рассмотрим ключевые архитектурные паттерны.
1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети
- Примеры: веб-сайты, электронная почта, онлайн-игры.
2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач, где это критично (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений).
3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности:
- Модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Оплата за фактическое использование ресурсов.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions.
4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода).
❤🔥4👍4🏆2❤1
5. Event-Driven Architecture (Событийно-ориентированная архитектура)
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности:
- События передаются по каналам (TCP/IP, файлы JSON/XML).
- Брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix.
6. Microservices Architecture (Микросервисная архитектура)
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix).
7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты.
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности:
- События передаются по каналам (TCP/IP, файлы JSON/XML).
- Брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix.
6. Microservices Architecture (Микросервисная архитектура)
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix).
7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты.
Telegram
METANIT.COM
Архитектурные паттерны
(продолжение в следующем посте)
(продолжение в следующем посте)
❤9👍5🤝3
«Мы у конца экспоненты»: сказал глава Anthropic, говоря о развитии ИИ
Глава Anthropic Дарио Амодеи заявил, что индустрия ИИ приближается к пику экспоненциального роста ("we’re hitting the end of the exponential"). По его оценке, модели уровня "страна гениев в дата-центре" — сверхразумный ИИ, превосходящий человека почти во всем — появятся в 2026–2027 годах. Вероятность этого Амодеи оценивает в 90% в горизонте десяти лет, но лично ставит на то, что это случится гораздо раньше.
Технологический прогресс подкрепляют два фактора: классические законы масштабирования продолжают работать, а обучение с подкреплением (RL) дает новый виток улучшений. При этом Амодеи считает, что для решения большинства экономических задач может хватить огромного контекстного окна (несколько миллионов токенов) и мощного предварительного обучения — без полноценного дообучения моделей в реальном времени.
Отдельно Амодеи рассказал о Claude Code — инструменте для кодинга, который изначально создавался для внутреннего использования. Он настолько ускорил работу сотрудников Anthropic, что компания решила выпустить его как отдельный продукт. По словам Амодеи, программирование — та область, где ИИ уже ускоряет работу на 15–20%, а в перспективе компания ожидает, что модели будут выполнять до 90% задач разработчика.
https://www.dwarkesh.com/p/dario-amodei-2
ЗЫ. к слову, у экспоненты как функции (e^x) нет ни пика, ни конца. Эта функция определена для всех чисел от -бесконечности до +бесконечности и непрерывно растет.
При увеличении аргумента x функция стремится к бесконечности, а при уменьшении — к нулю, но никогда не достигает реального физического "конца".
Вообще кажется, что когда так говорят, что вот де мы скоро получим супер-ИИ, который заменит всех и вся и будет делать почти всю работу и т.д., то тем самым просто завлекают инвесторов, чтобы те еще больше вкладывали и в их компанию, в частности, и в весь этот ИИ-пузырь в целом.
Глава Anthropic Дарио Амодеи заявил, что индустрия ИИ приближается к пику экспоненциального роста ("we’re hitting the end of the exponential"). По его оценке, модели уровня "страна гениев в дата-центре" — сверхразумный ИИ, превосходящий человека почти во всем — появятся в 2026–2027 годах. Вероятность этого Амодеи оценивает в 90% в горизонте десяти лет, но лично ставит на то, что это случится гораздо раньше.
Технологический прогресс подкрепляют два фактора: классические законы масштабирования продолжают работать, а обучение с подкреплением (RL) дает новый виток улучшений. При этом Амодеи считает, что для решения большинства экономических задач может хватить огромного контекстного окна (несколько миллионов токенов) и мощного предварительного обучения — без полноценного дообучения моделей в реальном времени.
Отдельно Амодеи рассказал о Claude Code — инструменте для кодинга, который изначально создавался для внутреннего использования. Он настолько ускорил работу сотрудников Anthropic, что компания решила выпустить его как отдельный продукт. По словам Амодеи, программирование — та область, где ИИ уже ускоряет работу на 15–20%, а в перспективе компания ожидает, что модели будут выполнять до 90% задач разработчика.
https://www.dwarkesh.com/p/dario-amodei-2
ЗЫ. к слову, у экспоненты как функции (e^x) нет ни пика, ни конца. Эта функция определена для всех чисел от -бесконечности до +бесконечности и непрерывно растет.
При увеличении аргумента x функция стремится к бесконечности, а при уменьшении — к нулю, но никогда не достигает реального физического "конца".
Вообще кажется, что когда так говорят, что вот де мы скоро получим супер-ИИ, который заменит всех и вся и будет делать почти всю работу и т.д., то тем самым просто завлекают инвесторов, чтобы те еще больше вкладывали и в их компанию, в частности, и в весь этот ИИ-пузырь в целом.
Dwarkesh
Dario Amodei — "We are near the end of the exponential"
"That's why I'm sending this message of urgency"
👍20🤡13🤔5🥱3🖕3❤2😁2
Компания Google представила первую бета-версию Android 17, релиз которой должен выйти во втором квартале этого года. Основные изменения в Android 17 Beta 1:
🚀 Основные изменения для разработчиков
Новая модель распространения: Canary-канал
Google заменяет традиционные Developer Preview на постоянный Canary-канал. Это дает ранний доступ к API и функциям, упрощает тестирование через OTA-обновления и позволяет быстрее влиять на финальные изменения.
Адаптивность становится обязательной
Для приложений, нацеленных на SDK 37 (Android 17), на больших экранах (ширина > 600dp) блокируются манифест-атрибуты и API, ограничивающие ориентацию (
Тонкая настройка перезапуска Activity
Система больше не перезапускает Activity при многих изменениях конфигурации (например, смена темы оформления, клавиатуры), а передает их через
⚡️ Производительность и системы
* Блокировка MessageQueue: Новая реализация очереди сообщений без блокировок (lock-free) уменьшает число пропущенных кадров.
* Сборка мусора: Внедрение поколенческой (generational) сборки мусора снижает нагрузку на CPU при сборках.
* Неизменяемые `static final`: Запрет на изменение
* Ограничение уведомлений: Введены лимиты на размер пользовательских видов уведомлений для экономии памяти.
* Новые триггеры профилирования: В
📸 Медиа и камера
* Динамические сессии камеры: Метод
* Метаданные мультикамер: Теперь можно получать данные со всех физических камер в логической мультикамере для более эффективной обработки.
* Поддержка VVC: Добавлена поддержка современного видеокодека VVC (H.266).
* Контроль качества видео: В
* Управление звуком в фоне: Ужесточены правила для фоновых аудио-запросов, чтобы они запускались только по явному действию пользователя.
🔒 Приватность, безопасность и связь
* Очистка трафика: Атрибут
* Гибридное шифрование: Представлен SPI для HPKE — современного стандарта гибридного шифрования.
* VoIP и звонки: Улучшена интеграция VoIP: управление видимостью вызовов в журнале и поддержка аватаров участников в системном приложении телефона.
* Wi-Fi Ranging: Добавлены API для непрерывного измерения расстояния и безопасного пиринга.
* Профили устройств: В
Для тестирования разработчики могут установить бета-версию на поддерживаемые устройства Pixel по OTA или использовать эмулятор в Android Studio.
https://android-developers.googleblog.com/2026/02/the-first-beta-of-android-17.html
🚀 Основные изменения для разработчиков
Новая модель распространения: Canary-канал
Google заменяет традиционные Developer Preview на постоянный Canary-канал. Это дает ранний доступ к API и функциям, упрощает тестирование через OTA-обновления и позволяет быстрее влиять на финальные изменения.
Адаптивность становится обязательной
Для приложений, нацеленных на SDK 37 (Android 17), на больших экранах (ширина > 600dp) блокируются манифест-атрибуты и API, ограничивающие ориентацию (
portrait, landscape) и изменение размера (resizeableActivity). Исключение — игры. Пользователи по-прежнему могут управлять поведением приложения через настройки системы.Тонкая настройка перезапуска Activity
Система больше не перезапускает Activity при многих изменениях конфигурации (например, смена темы оформления, клавиатуры), а передает их через
onConfigurationChanged. Чтобы вернуть старое поведение с полным пересозданием Activity, разработчикам нужно явно указать это в новом атрибуте манифета android:recreateOnConfigChanges.⚡️ Производительность и системы
* Блокировка MessageQueue: Новая реализация очереди сообщений без блокировок (lock-free) уменьшает число пропущенных кадров.
* Сборка мусора: Внедрение поколенческой (generational) сборки мусора снижает нагрузку на CPU при сборках.
* Неизменяемые `static final`: Запрет на изменение
static final полей через рефлексию и JNI для оптимизации производительности.* Ограничение уведомлений: Введены лимиты на размер пользовательских видов уведомлений для экономии памяти.
* Новые триггеры профилирования: В
ProfilingManager добавлены триггеры для отладки (холодный старт, OOM).📸 Медиа и камера
* Динамические сессии камеры: Метод
updateOutputConfigurations() позволяет менять выходные поверхности (например, с фото на видео) без пересоздания сессии камеры, устраняя задержки.* Метаданные мультикамер: Теперь можно получать данные со всех физических камер в логической мультикамере для более эффективной обработки.
* Поддержка VVC: Добавлена поддержка современного видеокодека VVC (H.266).
* Контроль качества видео: В
MediaRecorder добавлен метод для настройки кодирования с постоянным качеством (CQ).* Управление звуком в фоне: Ужесточены правила для фоновых аудио-запросов, чтобы они запускались только по явному действию пользователя.
🔒 Приватность, безопасность и связь
* Очистка трафика: Атрибут
android:usesCleartextTraffic объявлен устаревшим. Без конфигурации безопасности сети (Network Security Config) будет запрещен.* Гибридное шифрование: Представлен SPI для HPKE — современного стандарта гибридного шифрования.
* VoIP и звонки: Улучшена интеграция VoIP: управление видимостью вызовов в журнале и поддержка аватаров участников в системном приложении телефона.
* Wi-Fi Ranging: Добавлены API для непрерывного измерения расстояния и безопасного пиринга.
* Профили устройств: В
CompanionDeviceManager добавлены профили для медицинских устройств и фитнес-трекеров, упрощающие получение разрешений. Появился единый диалог для связи с устройством и запроса прав на Nearby.Для тестирования разработчики могут установить бета-версию на поддерживаемые устройства Pixel по OTA или использовать эмулятор в Android Studio.
https://android-developers.googleblog.com/2026/02/the-first-beta-of-android-17.html
Android Developers Blog
The First Beta of Android 17
News and insights on the Android platform, developer tools, and events.
❤5👍4🤝2🤔1
Из-за ИИ сотрудники перерабатывают и выгорают
Компании столкнулись с неожиданной проблемой. Сотрудники, которые первыми начали использовать ИИ-инструменты в работе, массово выгорают. Парадокс в том, что технологии действительно помогают быстрее выполнять задачи, на которые раньше уходил весь день. Вот только домой никто не уходит. Освободившееся время тут же заполняется новыми проектами, бесконечными списками дел и работой по вечерам. Вместо обещанной душевной гармонии люди получили бессонные ночи, наполненные деловой волокитой выходные и больше стресса.
Первыми страдают самые активные. Это энтузиасты, которые внедрили ИИ раньше коллег, не дожидаясь указаний начальства. Обычно такие люди амбициозны, нацелены на результат и вовлечены по максимуму. Именно эти качества делают их уязвимыми. Они не останавливаются, когда инструмент выполнил задачу, — берут на себя еще больше, пока не ломаются.
У компаний есть примерно 18 месяцев, чтобы исправить ситуацию. Сейчас выгорание затронуло только 15−20% работников — тех самых ранних пользователей. Остальных психологический эффект еще не накрыл. Если не установить правила игры прямо сейчас, весной и летом 2026 года начнется массовый отток кадров, предупреждают исследователи. Уйдут лучшие специалисты, которые раньше всех освоили новые технологии. Следом рухнет моральный дух команд, остановятся проекты, исчезнет накопленная экспертиза.
Сейчас текучка кадров в технологических компаниях держится на уровне 12−15% в год. В командах, где началось выгорание, она подскакивает до 25−35%. Это означает катастрофические затраты на поиск замены, потерю знаний, срыв сроков и деморализацию тех, кто остался. Средняя стоимость замены одного технического специалиста достигает 150−200% его годовой зарплаты с учетом времени на обучение нового человека.
Разработчикам ИИ-инструментов стоит задуматься о смене приоритетов. Следующее поколение продуктов должно делать нечто большее, чем просто ускорять выполнение задач. Нужны интерфейсы, которые подталкивают завершить дела и выйти из системы, а не накапливать их бесконечно. Настройки, ограничивающие производительность рабочим временем.
https://www.themeridiem.com/ai/2026/2/10/ai-s-productivity-paradox-hits-inflection-as-early-adopters-burn-out
Компании столкнулись с неожиданной проблемой. Сотрудники, которые первыми начали использовать ИИ-инструменты в работе, массово выгорают. Парадокс в том, что технологии действительно помогают быстрее выполнять задачи, на которые раньше уходил весь день. Вот только домой никто не уходит. Освободившееся время тут же заполняется новыми проектами, бесконечными списками дел и работой по вечерам. Вместо обещанной душевной гармонии люди получили бессонные ночи, наполненные деловой волокитой выходные и больше стресса.
Первыми страдают самые активные. Это энтузиасты, которые внедрили ИИ раньше коллег, не дожидаясь указаний начальства. Обычно такие люди амбициозны, нацелены на результат и вовлечены по максимуму. Именно эти качества делают их уязвимыми. Они не останавливаются, когда инструмент выполнил задачу, — берут на себя еще больше, пока не ломаются.
У компаний есть примерно 18 месяцев, чтобы исправить ситуацию. Сейчас выгорание затронуло только 15−20% работников — тех самых ранних пользователей. Остальных психологический эффект еще не накрыл. Если не установить правила игры прямо сейчас, весной и летом 2026 года начнется массовый отток кадров, предупреждают исследователи. Уйдут лучшие специалисты, которые раньше всех освоили новые технологии. Следом рухнет моральный дух команд, остановятся проекты, исчезнет накопленная экспертиза.
Сейчас текучка кадров в технологических компаниях держится на уровне 12−15% в год. В командах, где началось выгорание, она подскакивает до 25−35%. Это означает катастрофические затраты на поиск замены, потерю знаний, срыв сроков и деморализацию тех, кто остался. Средняя стоимость замены одного технического специалиста достигает 150−200% его годовой зарплаты с учетом времени на обучение нового человека.
Разработчикам ИИ-инструментов стоит задуматься о смене приоритетов. Следующее поколение продуктов должно делать нечто большее, чем просто ускорять выполнение задач. Нужны интерфейсы, которые подталкивают завершить дела и выйти из системы, а не накапливать их бесконечно. Настройки, ограничивающие производительность рабочим временем.
https://www.themeridiem.com/ai/2026/2/10/ai-s-productivity-paradox-hits-inflection-as-early-adopters-burn-out
The Meridiem
AI's Productivity Paradox Hits Inflection as Early Adopters Burn Out
The moment AI adoption scales beyond efficiency gains into unsustainable workload expansion. Organizations now face a critical window to establish boundaries before talent attrition cascades.
🤯8👍5🤷♂4❤4😢4😁2🥱2🖕2🤡1
Россия вышла на третье место в мире по росту зарплат IT-инженеров
Россия вышла на третье место в мире по темпам роста зарплат IT-инженеров в пересчете на доллар США в соответствии с исследованием японской кадровой компании Human Resocia.
Согласно исследованию, доходы российских специалистов в сфере разработки ПО за 2025 год увеличились на 18,2%. По этому показателю РФ уступила только Панаме (рост на 39,6%) и Румынии (29,6%).
Авторы связывают ускоренный рост зарплат в этих странах с перераспределением офшорных IT-заказов и развитием центров разработки, в том числе в сфере искусственного интеллекта.
В целом более чем в 70% стран мира зарплаты IT-инженеров выросли, что свидетельствует о сохраняющемся глобальном восходящем тренде. При этом в развитых экономиках динамика была заметно скромнее: в США рост составил 2,8%, во Франции - 3,7%, в Германии - 4,9%, в Великобритании - 5,2%, в Италии - 6,3%, в Японии - на 5,3% за год. При этом отмечается, что в Японии средний годовой доход составил 29,8 тысячи долларов, что примерно в три раза ниже показателя США (в целом показатель Японии примерно аналогично средней зарплате IT-специалистов в России по текущему курсу USD).
https://ria.ru/20260216/rossija-2074579816.html
Вообще странно бы было, если бы в долларовом выражении зарплаты в России не выросли, учитывая укрепление рубля за год почти на 30%
Россия вышла на третье место в мире по темпам роста зарплат IT-инженеров в пересчете на доллар США в соответствии с исследованием японской кадровой компании Human Resocia.
Согласно исследованию, доходы российских специалистов в сфере разработки ПО за 2025 год увеличились на 18,2%. По этому показателю РФ уступила только Панаме (рост на 39,6%) и Румынии (29,6%).
Авторы связывают ускоренный рост зарплат в этих странах с перераспределением офшорных IT-заказов и развитием центров разработки, в том числе в сфере искусственного интеллекта.
В целом более чем в 70% стран мира зарплаты IT-инженеров выросли, что свидетельствует о сохраняющемся глобальном восходящем тренде. При этом в развитых экономиках динамика была заметно скромнее: в США рост составил 2,8%, во Франции - 3,7%, в Германии - 4,9%, в Великобритании - 5,2%, в Италии - 6,3%, в Японии - на 5,3% за год. При этом отмечается, что в Японии средний годовой доход составил 29,8 тысячи долларов, что примерно в три раза ниже показателя США (в целом показатель Японии примерно аналогично средней зарплате IT-специалистов в России по текущему курсу USD).
https://ria.ru/20260216/rossija-2074579816.html
Вообще странно бы было, если бы в долларовом выражении зарплаты в России не выросли, учитывая укрепление рубля за год почти на 30%
РИА Новости
Россия вышла на третье место в мире по росту зарплат IT-инженеров
Россия вышла на третье место в мире по темпам роста зарплат IT-инженеров в пересчете на доллар США, выяснило РИА Новости на основании исследования,... РИА Новости, 16.02.2026
🤔22🥴8🔥5❤3😁1
Американские студенты бросают учиться на программистов — теперь в моде специальности в сфере ИИ
Впервые со времен краха доткомов зафиксирован спад интереса к классическим компьютерным наукам в кампусах Калифорнийского университета (UC). Хотя общий поток абитуриентов в США растет, будущие специалисты массово мигрируют из традиционных IT-направлений на новые специальности, связанные с развитием искусственного интеллекта.
Американские университеты столкнулись с неожиданным оттоком студентов с факультетов компьютерных наук. Статистика Калифорнийского университета показала снижение числа поступающих на 6% в прошлом году и еще на 3% в 2024 году. Эта тенденция развивается на фоне общего национального роста количества студентов в колледжах (на 2%) . Единственным исключением в системе стал кампус в Сан-Диего, где своевременное открытие отдельной специальности по искусственному интеллекту позволило удержать показатели набора.
Эксперты расценивают происходящее не как отказ от технологий, а как миграцию в сторону более перспективной сферы. Опрос Ассоциации компьютерных исследований показал, что падение интереса к базовому программированию зафиксировали 62% профильных факультетов. Одновременно с этим вузы США фиксируют резкий рост спроса на программы по изучению нейросетей. Например, в Массачусетском технологическом институте (MIT) направление по принятию решений на основе ИИ уже вышло на второе место по популярности, а Университет Южной Флориды за один семестр набрал более 3000 студентов в новый профильный колледж.
https://techcrunch.com/2026/02/15/the-great-computer-science-exodus-and-where-students-are-going-instead/
Впервые со времен краха доткомов зафиксирован спад интереса к классическим компьютерным наукам в кампусах Калифорнийского университета (UC). Хотя общий поток абитуриентов в США растет, будущие специалисты массово мигрируют из традиционных IT-направлений на новые специальности, связанные с развитием искусственного интеллекта.
Американские университеты столкнулись с неожиданным оттоком студентов с факультетов компьютерных наук. Статистика Калифорнийского университета показала снижение числа поступающих на 6% в прошлом году и еще на 3% в 2024 году. Эта тенденция развивается на фоне общего национального роста количества студентов в колледжах (на 2%) . Единственным исключением в системе стал кампус в Сан-Диего, где своевременное открытие отдельной специальности по искусственному интеллекту позволило удержать показатели набора.
Эксперты расценивают происходящее не как отказ от технологий, а как миграцию в сторону более перспективной сферы. Опрос Ассоциации компьютерных исследований показал, что падение интереса к базовому программированию зафиксировали 62% профильных факультетов. Одновременно с этим вузы США фиксируют резкий рост спроса на программы по изучению нейросетей. Например, в Массачусетском технологическом институте (MIT) направление по принятию решений на основе ИИ уже вышло на второе место по популярности, а Университет Южной Флориды за один семестр набрал более 3000 студентов в новый профильный колледж.
https://techcrunch.com/2026/02/15/the-great-computer-science-exodus-and-where-students-are-going-instead/
TechCrunch
The great computer science exodus (and where students are going instead) | TechCrunch
Students are losing some interest in computer science broadly but gaining interest in AI-specific majors and courses.
🤡10❤5🔥4🐳3😁2👍1👏1🖕1
Шардинг базы данных (Database Sharding)
(продолжение предыдущего поста)
1. Что такое шардинг?
Шардинг — это процесс разделения монолитной базы данных (Monolithic Database) на несколько меньших частей, называемых шардсами (shards). Цель шардинга — распределить нагрузку и увеличить масштабируемость системы. На изображении показано, как одна большая база данных разделяется на несколько шардов.
2. Типы шардинга
Существует несколько способов распределения данных по шардам:
- Range-based Sharding (шардинг по диапазонам): данные распределяются по шардам на основе диапазонов значений. Например, продукты с ценой от $0 до $75 попадают в Shard 1, а с ценой от $76 до $150 — в Shard 2. Это удобно, когда данные можно логично разделить по числовым диапазонам.
- Directory-based Sharding (шардинг на основе каталога): данные распределяются по шардам согласно определённым категориям (например, по географическому расположению клиентов). На изображении показано, как клиенты из разных регионов (North America, Europe, Asia) направляются в соответствующие шарды (Shard 1, Shard 2, Shard 3).
- Key-based Sharding (шардинг по ключу): используется хеш-функция (Hash Function) для распределения данных по шардам на основе уникального ключа. Например, ключ (Key) определяет, в какой shard попадёт запись. Это позволяет равномерно распределить нагрузку, если хеш-функция хорошо сбалансирована.
3. Выбор ключей шардинга (Shard Keys)
При выборе ключа шардинга важно учитывать три аспекта:
- Cardinality (кардинальность): лучше выбирать ключ с высокой кардинальностью (большим количеством уникальных значений). Это помогает избежать перегрузки отдельных шардов.
- Frequency (частота использования): чем больше подмножество возможных значений ключа, тем меньше вероятность «горячих разделов» (hot partitions) — ситуаций, когда один шард получает непропорционально много запросов.
- Monotonic Change (монотонное изменение): если ключ монотонно увеличивается или уменьшается (например, временные метки), это может привести к неравномерному распределению данных (один шард будет постоянно получать новые записи). Следует избегать таких ключей.
4. Маршрутизация запросов (Request Routing)
Чтобы система знала, к какому шарду обращаться, используется механизм маршрутизации запросов. Существуют три основных подхода:
- Shard-Aware Nodes (узлы, осведомлённые о шардах): узлы сами знают, где находятся данные, и напрямую обращаются к нужным шардам.
- Dedicated Routing Tier (выделенный уровень маршрутизации): специальный слой маршрутизации (Routing Tier) определяет, к какому шарду направить запрос. Это упрощает логику клиентов.
- Shard-Aware Client (клиент, осведомлённый о шардах): клиент сам решает, к какому шарду отправить запрос, основываясь на логике шардинга.
5. Репликация с шардингом (Replication with Sharding)
Для обеспечения отказоустойчивости и доступности данных используется репликация. На изображении показано, как данные шардов реплицируются между узлами (Node 1, Node 2, Node 3):
- Leader (лидер): основной узел, который обрабатывает записи (writes) для шарда.
- Follower (фолловер): реплицирует данные лидера, может обрабатывать только чтения (reads). Если лидер выходит из строя, один из фолловеров может стать новым лидером.
Например:
- Shard A Leader на Node 1 реплицируется на Shard A Follower на Node 2 и Node 3.
- Аналогично для Shard B и Shard C.
Итог
Шардинг позволяет:
- распределить нагрузку между несколькими серверами;
- увеличить производительность и масштабируемость системы;
- обеспечить отказоустойчивость за счёт репликации;
- оптимизировать доступ к данным с помощью грамотной маршрутизации запросов.
Ключевой момент — правильный выбор ключей шардинга и стратегии распределения данных, чтобы избежать «горячих разделов» и обеспечить равномерную нагрузку на систему.
(продолжение предыдущего поста)
1. Что такое шардинг?
Шардинг — это процесс разделения монолитной базы данных (Monolithic Database) на несколько меньших частей, называемых шардсами (shards). Цель шардинга — распределить нагрузку и увеличить масштабируемость системы. На изображении показано, как одна большая база данных разделяется на несколько шардов.
2. Типы шардинга
Существует несколько способов распределения данных по шардам:
- Range-based Sharding (шардинг по диапазонам): данные распределяются по шардам на основе диапазонов значений. Например, продукты с ценой от $0 до $75 попадают в Shard 1, а с ценой от $76 до $150 — в Shard 2. Это удобно, когда данные можно логично разделить по числовым диапазонам.
- Directory-based Sharding (шардинг на основе каталога): данные распределяются по шардам согласно определённым категориям (например, по географическому расположению клиентов). На изображении показано, как клиенты из разных регионов (North America, Europe, Asia) направляются в соответствующие шарды (Shard 1, Shard 2, Shard 3).
- Key-based Sharding (шардинг по ключу): используется хеш-функция (Hash Function) для распределения данных по шардам на основе уникального ключа. Например, ключ (Key) определяет, в какой shard попадёт запись. Это позволяет равномерно распределить нагрузку, если хеш-функция хорошо сбалансирована.
3. Выбор ключей шардинга (Shard Keys)
При выборе ключа шардинга важно учитывать три аспекта:
- Cardinality (кардинальность): лучше выбирать ключ с высокой кардинальностью (большим количеством уникальных значений). Это помогает избежать перегрузки отдельных шардов.
- Frequency (частота использования): чем больше подмножество возможных значений ключа, тем меньше вероятность «горячих разделов» (hot partitions) — ситуаций, когда один шард получает непропорционально много запросов.
- Monotonic Change (монотонное изменение): если ключ монотонно увеличивается или уменьшается (например, временные метки), это может привести к неравномерному распределению данных (один шард будет постоянно получать новые записи). Следует избегать таких ключей.
4. Маршрутизация запросов (Request Routing)
Чтобы система знала, к какому шарду обращаться, используется механизм маршрутизации запросов. Существуют три основных подхода:
- Shard-Aware Nodes (узлы, осведомлённые о шардах): узлы сами знают, где находятся данные, и напрямую обращаются к нужным шардам.
- Dedicated Routing Tier (выделенный уровень маршрутизации): специальный слой маршрутизации (Routing Tier) определяет, к какому шарду направить запрос. Это упрощает логику клиентов.
- Shard-Aware Client (клиент, осведомлённый о шардах): клиент сам решает, к какому шарду отправить запрос, основываясь на логике шардинга.
5. Репликация с шардингом (Replication with Sharding)
Для обеспечения отказоустойчивости и доступности данных используется репликация. На изображении показано, как данные шардов реплицируются между узлами (Node 1, Node 2, Node 3):
- Leader (лидер): основной узел, который обрабатывает записи (writes) для шарда.
- Follower (фолловер): реплицирует данные лидера, может обрабатывать только чтения (reads). Если лидер выходит из строя, один из фолловеров может стать новым лидером.
Например:
- Shard A Leader на Node 1 реплицируется на Shard A Follower на Node 2 и Node 3.
- Аналогично для Shard B и Shard C.
Итог
Шардинг позволяет:
- распределить нагрузку между несколькими серверами;
- увеличить производительность и масштабируемость системы;
- обеспечить отказоустойчивость за счёт репликации;
- оптимизировать доступ к данным с помощью грамотной маршрутизации запросов.
Ключевой момент — правильный выбор ключей шардинга и стратегии распределения данных, чтобы избежать «горячих разделов» и обеспечить равномерную нагрузку на систему.
Telegram
METANIT.COM
Шардинг базы данных (Database Sharding)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤4👍4🤝2
В руководство по языку Си добавлена статья про реализацию шаблона Result с помощью макросов и обработку ошибок
https://metanit.com/c/tutorial/12.7.php
#c_ansi
https://metanit.com/c/tutorial/12.7.php
#c_ansi
🔥16❤🔥5🥰3🆒2🏆1