METANIT.COM

Типы архитектуры базы данных (продолжение предыдущего поста) Рассмотрим четыре основных типа архитектуры баз данных: 1. Single Node architecture (одноузловая архитектура): * состоит из одного узла (Primary Node), который включает компоненты: compute1 (вычисления), cache (кэш) и data1 (хранилище данных); * все операции (от обработки запросов до хранения данных) выполняются на одном узле; * проста в реализации, но имеет ограничения по масштабируемости и отказоустойчивости — если узел выходит из строя, вся система становится недоступной; * подходит для небольших проектов с низкой нагрузкой. 2. Shared Nothing Architecture (архитектура без общего доступа): * включает несколько независимых узлов (Node 1, Node 2, Node 3), каждый из которых имеет собственные компоненты: compute (вычисления), cache (кэш) и data (локальное хранилище данных); * запросы от клиента распределяются с помощью Load Balancer (балансировщика нагрузки) между узлами; * узлы не делят ресурсы — каждый работает автономно, что обеспечивает высокую масштабируемость и отказоустойчивость (выход из строя одного узла не влияет на работу остальных); * используется в системах с высокой нагрузкой, где требуется распределение нагрузки и независимость узлов (например, в распределённых СУБД). 3. (Decoupled) Shared Nothing Architecture (развязанная архитектура без общего доступа): * похожа на классическую Shared Nothing, но имеет разделение на вычислительные узлы (с компонентами compute и cache) и узлы хранения (Storage Nodes с компонентами data); * вычислительные узлы взаимодействуют с узлами хранения через сеть; * такая декомпозиция позволяет ещё лучше масштабировать систему — можно независимо наращивать вычислительные мощности и объём хранилища; * подходит для сложных распределённых систем, где требуется чёткое разделение между обработкой и хранением данных (например, в Big Data решениях). 4. Shared Storage Architecture (архитектура с общим хранилищем): * состоит из нескольких вычислительных узлов (Node 1, Node 2, Node 3 с компонентами compute и cache), которые обращаются к единому централизованному хранилищу данных — Object Store (например, AWS S3); * балансировщик нагрузки (Load Balancer) распределяет запросы между вычислительными узлами; * все узлы имеют доступ к одним и тем же данным, что упрощает синхронизацию, но создаёт «бутылочное горлышко» на уровне хранилища при высокой нагрузке; * преимущества: простота управления данными, централизованное хранение; * недостатки: потенциальная точка отказа (если хранилище становится недоступным), ограничения по пропускной способности хранилища; * применяется в системах, где важна централизованность данных, но не требуется экстремальная масштабируемость (например, в корпоративных системах с умеренной нагрузкой). Ключевые отличия между архитектурами: * Single Node — минимализм, простота, низкая отказоустойчивость; * Shared Nothing — независимость узлов, высокая масштабируемость, но сложность синхронизации данных; * (Decoupled) Shared Nothing — чёткое разделение ролей (вычисления/хранение), максимальная гибкость масштабирования; * Shared Storage — централизованное управление данными, простота, но потенциальные проблемы с производительностью и отказоустойчивостью.

Типы архитектуры базы данных (продолжение в следующем посте)

Сервис DB-Engines обновил рейтинг популярности систем баз данных, который отслеживает популярность 428 различных СУБД. Методика расчета рейтинга учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объем обсуждений на популярных дискуссионных площадках и социальных сетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей. Первые 5 мест продолжают занимать Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. По сравнению с январем 2025 года в десятке лидеров произошли две перестановки: Elasticsearch спустился с 8 на 10 место, а Databricks поднялся с 13 на 8 место. Остальные лидеры сохранили свои позиции в рейтинге, но снижение популярности наблюдается для MySQL (-130 баллов), MS SQL Server (-92), Elasticsearch (-27), MongoDB (-25), Oracle (-21) и Redis (-9). Рост популярности фиксируется для Snowflake (+53), Databricks (+53) и PostgreSQL (+3). https://db-engines.com/en/ranking

Ищу желающих заполнять карточки товаров на ВБ! Работа полностью на удаленке с зп до150 000 рублей в месяц. Без опыта, нужен только телефон, занятость 3-6 часов в день. Всему обучат на бесплатном курсе и после возьму на работу: ✅ 3 дня уроков по 30 минут ✅ Домашки с проверкой и оплатой бонусами ✅ Плачу 10 тыс за каждую выполненную домашку Все кто пройдет курс, получат сертификат от школы с образовательной лицензией. ⚡ Набор заканчивается завтра. 👍 Для регистрации жмите кнопку "Зарегистрироваться" Зарегистрироваться #реклама 16+ course.wildmanager.ru О рекламодателе

Сервис по поиску работы LinkedIn опубликовал список из 25 профессий, на которые за последние три года спрос в США вырос сильнее всего. Лидерами рейтинга оказались ИИ‑инженеры. Весь топ-5: 1. Artificial Intelligence Engineers (ИИ‑инженеры) 2. AI Consultants and Strategists (ИИ‑консультанты и стратеги) 3. New Home Sales Specialists (специалисты по продаже недвижимости) 4. Data Annotators (специалисты по разметке данных для обучения ИИ) 5. AI/Machine Learning Researchers (исследователи ИИ и машинного обучения) Таким образом, в топ-5 есть лишь одна специальность, не связанная с ИИ. В целом опубликованный LinkedIn список показывает, что связанные с ИИ‑профессии стали наиболее востребованными на рынке в последние годы. Из специальностей, связанных с ИТ, в 25 также Data center technicians (технические специалисты дата‑центров), что опять же связано с ИИ. Другие данные LinkedIn выявили проблемы на рынке труда для многих людей: количество соискателей на одну открытую вакансию в среднем увеличилось более чем вдвое с весны 2022 года, в то время как объем найма по состоянию на ноябрь был на 23% ниже допандемического уровня. https://www.linkedin.com/pulse/linkedin-jobs-rise-2026-25-fastest-growing-roles-us-linkedin-news-dlb1c/ https://www.businessinsider.com/fastest-growing-jobs-in-the-us-linkedin-2026-1

30 незаменимых приемов при программировании на Python

Telegram-канал LB Ceramics Быстрая доставка и европейское качество. Ваш идеальный керамогранит от LB Ceramics уже ждет. Подпишитесь на наш канал! Узнать больше #реклама О рекламодателе

Архитектура микросервисов (продолжение предыдущего поста) Архитектура микросервисов состоит из ряда звеньев/уровней. Рассмотрим типичную архитектуру микросервисов. 1. Уровень клиента (Client) На верхнем уровне находятся клиентские приложения, которые взаимодействуют с системой: * Web (веб-браузер); * Mobile (мобильное приложение); * PC (десктопное приложение). Клиенты отправляют запросы в систему, которые затем проходят через промежуточные компоненты. 2. Промежуточный уровень (инфраструктура доставки контента и балансировки нагрузки) * CDN (Content Delivery Network) — распределённая сеть доставки статического контента (изображений, CSS, JS-файлов), ускоряет загрузку за счёт кэширования данных ближе к пользователю. * Static Content — хранилище статических ресурсов, обслуживаемых через CDN. * Load Balancer (балансировщик нагрузки) — распределяет входящие запросы между микросервисами для оптимизации производительности и обеспечения отказоустойчивости. 3. API Gateway (шлюз API) * Единая точка входа для клиентских запросов. * Выполняет маршрутизацию запросов к соответствующим микросервисам. * Агрегирует ответы от микросервисов. * Обеспечивает сквозные функции: аутентификацию, авторизацию, мониторинг, логирование. * Взаимодействует с Identity Provider (поставщиком идентификации) для управления доступом пользователей. 4. Уровень микросервисов (Microservices) * Система разбита на домены (Domain 1, Domain 2) — логически связанные группы сервисов, отвечающие за отдельные бизнес-задачи. * Внутри доменов работают микросервисы (Service A, Service B, Service C): * каждый сервис — независимый модуль с собственной логикой и базой данных; * сервисы взаимодействуют друг с другом через API или брокер сообщений; * могут разрабатываться, развёртываться и масштабироваться независимо. 5. Сервисная регистрация и обнаружение (Service Registry and Discovery) * Хранит информацию о всех запущенных микросервисах (IP-адреса, порты, статусы). * Позволяет сервисам динамически находить друг друга без жёсткой привязки к адресам. * Ключевой компонент для обеспечения гибкости и масштабируемости системы. 6. Координация сервисов (Service Coordination, Zookeeper) * Обеспечивает согласованность работы микросервисов. * Управляет распределёнными блокировками, конфигурациями и состоянием сервисов. * Использует Apache Zookeeper или аналогичные инструменты. 7. Брокер сообщений (Message Broker) * Обеспечивает асинхронную коммуникацию между сервисами. * Примеры: RabbitMQ, Kafka, ActiveMQ. * Позволяет сервисам обмениваться событиями и сообщениями без прямого соединения. * Повышает устойчивость системы к временным сбоям. 8. Уровень хранения данных (Databases) * Каждый домен или сервис может использовать собственную базу данных (Database A, Database B): * обеспечивает изоляцию данных и независимость развёртывания; * позволяет выбирать оптимальные СУБД для каждой задачи (например, MongoDB для документов, PostgreSQL для реляционных данных). 9. Дополнительные компоненты * Identity Provider — управляет учётными записями пользователей, аутентификацией и авторизацией. * API Gateway, Load Balancer и CDN работают совместно для обеспечения высокой доступности и безопасности системы. В итоге микросервисная архитектура, представленная на схеме, обеспечивает: * модульность (каждый сервис независим); * масштабируемость (можно масштабировать отдельные сервисы); * устойчивость (сбои в одном сервисе не влияют на работу других); * гибкость (можно использовать разные технологии для разных сервисов); * эффективное распределение нагрузки (благодаря балансировщику и CDN); * безопасный доступ (через API Gateway и Identity Provider).

Архитектура микросервисов (продолжение в следующем посте)

Запустите рекламу в телеграм-каналах с Яндекс Директом Перфоманс-реклама теперь в телеграм-каналах ⚡ Яндекс Директ знает, как привлечь целевую аудиторию 💰👌 Попробовать #реклама yandex.ru О рекламодателе

Google добавил Gemini 3 в Gmail - теперь ИИ будет копаться в переписке за пользователей Google запустил в Gmail новую модель Gemini 3, превратив почтовый клиент в "персонального проактивного ассистента" для 3 миллиардов пользователей. Главное нововведение — AI Overviews. Теперь почте можно задавать вопросы на естественном языке, и Gemini найдет нужные письма и выдаст готовый ответ, а не список из десятков сообщений, которые пришлось бы перечитывать вручную. При открытии длинных веток переписки система автоматически генерирует резюме с ключевыми моментами. Функция Help Me Write, которая помогает писать письма с нуля или редактировать черновики, теперь доступна всем бесплатно. Suggested Replies (обновленная версия Smart Reply) анализирует контекст переписки и предлагает ответы в стиле пользователя. Proofread проверяет грамматику, тон и стиль перед отправкой — но эта функция только для подписчиков Google AI Pro и Ultra. Добавлен AI Inbox - своего рода персональный фильтр, который отсеивает шум и выделяет важное (пока доступен только тестировщикам, широкий запуск обещают в ближайшие месяцы). Новые функции начали обкатывать в США на английском языке. Часть возможностей бесплатна, расширенные — для подписчиков Google AI Pro и Ultra. Другие регионы и языки — позже. https://blog.google/products-and-platforms/products/gmail/gmail-is-entering-the-gemini-era/ PS. Интересно, как скоро все эти данные можно будет увидеть в ответах Gemini или в открытом поиске...

Анализ исправления ошибок в ядре Linux - в среднем ошибки замечают через 2 года В результате анализа исправления 125 тысяч ошибок, помеченных в Git-репозитории тегом "Fixes:", оказалось, что среднее время обнаружения ошибок в ядре Linux составило 2.1 года. Если рассматривать только ошибки, исправленные в 2025 году, данный показатель составил 2.8 года. 30% ошибок были исправлены теми же разработчиками, что и внесли ошибки. 56.9% ошибок устраняют в течение года. 13.5% ошибок оставались незамеченными более 5 лет (если рассматривать только ошибки, исправленные в 2025 году - 19.4%). Из-за неравномерности распределения медианное время существования ошибки в коде ядра составило 8 месяцев для выборки с 2005 года и 1 год для ошибок, исправленных в 2025 году. Наиболее долго сохранявшейся в коде ошибкой стало переполнение буфера в ethtool, устранённое спустя 20.7 лет. Cреднее время обнаружения ошибок, связанных с состояниями гонки, составило 5.1 лет, целочисленным переполнением - 3.9, обращением после освобождения памяти - 3.2, переполнением буфера и утечкой памяти - 3.1, подсчётом ссылок - 2.8, разыменованием нулевого указателя и взаимными блокировками - 2.2 года. https://pebblebed.com/blog/kernel-bugs

Ограничение скорости по API (rate limiting) (продолжение предыдущего поста) Ограничение скорости по API (rate limiting) — это механизм контроля числа запросов к API, который защищает сервер от перегрузки и злоупотреблений. На изображении показаны основные методы ограничения скорости, каждый из которых работает по-своему: 1. Time Windows (временные окна): * устанавливает фиксированные интервалы времени, в течение которых ограничивается количество запросов; * если лимит запросов в заданный интервал превышен, система возвращает ошибку «RATE LIMIT EXCEEDED!»; * подходит для контроля частоты обращений к API. 2. Quota-Based (квотирование): * задаёт общее количество запросов, разрешённых за определённый период времени (например, в день или месяц); * как только квота исчерпана, дальнейшие запросы блокируются с сообщением «REQUEST LIMIT REACHED!»; * позволяет равномерно распределить нагрузку на API в течение заданного периода. 3. Token Bucket (алгоритм «ведра с токенами»): * использует систему токенов для контроля потока запросов: клиент может отправлять запросы только при наличии токенов; * токены накапливаются с фиксированной скоростью, что обеспечивает равномерный доступ к API; * если токенов нет, запросы задерживаются до их появления; * эффективно сглаживает пики нагрузки. 4. IP-Based Rate (ограничение по IP-адресу): * ограничивает количество запросов, исходящих с одного IP-адреса; * помогает предотвратить злоупотребления со стороны отдельных клиентов или ботов; * система анализирует IP-адрес источника запроса и блокирует дальнейшие обращения, если лимит превышен. 5. API Key-Based (ограничение по ключу API): * связывает лимиты с конкретным API-ключом, выданным клиенту; * позволяет настраивать индивидуальные квоты и интервалы для разных пользователей или приложений; * обеспечивает гибкое управление доступом — например, премиум-клиентам можно выделить больше запросов; * защищает от несанкционированного использования API. 6. Exponential Backoff (экспоненциальное замедление): * механизм, который заставляет клиента увеличивать интервал между повторными запросами в случае ошибок или превышения лимитов; * интервал ожидания растёт экспоненциально с каждой неудачной попыткой; * снижает нагрузку на сервер при массовых ошибках или перегрузках. Эти методы могут использоваться по отдельности или в комбинации для создания гибкой и надёжной системы ограничения скорости API. Они защищают сервер, обеспечивают справедливое распределение ресурсов и улучшают стабильность работы API для всех пользователей.

Ограничение скорости по API (rate limiting) (продолжение в следующем посте)

Авто из Европы! Европейские автомобили по цене ниже рынка РФ на 30%💰 Честные авто с подтвержденным пробегом✅ Без предоплаты! Договор, доставка 7-10 дней в любой регион Купить #реклама О рекламодателе

Lenovo представила первый в мире складной игровой ноутбук - Legion Pro Rollable Его главная особенность - уникальный сворачиваемый OLED-экран. Дисплей диагональю 16 дюймов может плавно расширяться с двух сторон до 21,5 или даже 24 дюймов. Правда, с учетом начинки (высокопроизводительная начинка от Intel и видеокарта NVIDIA GeForce RTX 5090 и т.д.) цена, наверное, будет космическая https://hi-tech.mail.ru/news/140485-lenovo-predstavila-pervyj-v-mire-skladnoj-igrovoj-noutbuk-i-portativnuyu-konsol-na-steamos

Базы данных NoSQL (продолжение предыдущего поста) Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL. 1. MongoDB (Document Store) - Тип: Документоориентированная БД. - Особенности: - использует формат BSON (Binary JSON); - схема не фиксирована (schema-less); - горизонтальное масштабирование (sharding); - репликация для высокой доступности. - Сценарии использования: - системы управления контентом (CMS); - управление каталогами. 2. Cassandra (Wide-Column Store) - Тип: Колоночная БД. - Особенности: - столбцы могут варьироваться в разных строках (wide-column); - распределённая архитектура; - язык запросов CQL (SQL-подобный для NoSQL); - оптимизирована для аналитических запросов. - Сценарии использования: - управление временными рядами данных; - рекомендательные системы. 3. Redis (Key-Value Store) - Тип: Хранилище «ключ-значение». - Особенности: - работает в оперативной памяти (in-memory store); - поддерживает сложные структуры данных; - механизмы персистентности (RDB, AOF); - репликация (primary-replica). - Сценарии использования: - кэширование данных; - управление сессиями; - таблицы лидеров в играх (gaming leaderboard). 4. Couchbase (Document Store with Key-Value Capabilities) - Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»). - Особенности: - работает в режиме памяти (memory first); - репликация между центрами обработки данных (XDCR); - сочетает операции с документами и хранилищем «ключ-значение». - Сценарии использования: - системы управления контентом (CMS); - платформы электронной коммерции. 5. Neo4j (Graph DB) - Тип: Графовая БД. - Особенности: - поддерживает ACID-транзакции; - использует язык запросов Cypher; - индексация без дополнительных таблиц (index-free adjacency); - кластеризация (HA cluster). - Сценарии использования: - социальные сети; - системы обнаружения мошенничества (fraud detection). 6. Amazon DynamoDB (Key-Value and Document Store) - Тип: Хранилище «ключ-значение» с поддержкой документов. - Особенности: - автоматическое масштабирование; - управление через AWS; - распределение данных между узлами; - поддержка DynamoDB Streams. - Сценарии использования: - бессерверные приложения (serverless applications); - IoT-приложения. 7. Apache HBase (Wide-Column Store) - Тип: Колоночная БД. - Особенности: - основана на Google Bigtable; - интеграция с Hadoop; - автоматическое шардирование (auto-sharding); - сильная согласованность (strong consistency). - Сценарии использования: - хранилища данных (data warehouse); - крупномасштабная обработка данных (large-scale data processing). 8. Elasticsearch (Search Engine) - Тип: Поисковая система на основе документов. - Особенности: - построена на Apache Lucene; - ориентирована на документы; - шардирование и репликация; - RESTful API. - Сценарии использования: - полнотекстовый поиск (full-text search); - анализ логов и событий (log and event data analysis). 9. CouchDB (Document Store) - Тип: Документоориентированная БД. - Особенности: - обеспечивает согласованность данных без блокировок; - использует RESTful API; - модель согласованности «в конечном счёте» (eventual consistency). - Сценарии использования: - мобильные приложения; - системы управления контентом (CMS). В итоге каждая NoSQL БД оптимизирована под конкретные задачи: - документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS; - колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов; - хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий; - графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации); - поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.

Базы данных NoSQL (продолжение в следующем посте)

Продвижение в Telegram с помощью Яндекс Директа ⚡Запустите продвижение в телеграм-каналах и привлекайте целевую аудиторию 📱 Таргетинг по тематикам, регионам и каналам в Telegram Попробовать #реклама yandex.ru О рекламодателе