Об индексах базы данных
Индекс — это пара ключ-значение, где ключ используется для поиска данных вместо соответствующих индексированных столбцов, а значение — это указатель на соответствующие строки в таблице. Большинству баз данных требуется та или иная форма индексации для производительности. Чтобы максимально эффективно использовать БД, следует использовать тип индекса, соответствующий данной задаче.
1) B-дерево (b-tree index) — одна из наиболее часто используемых структур индексации, в которой ключи иерархически сортируются. При поиске данных дерево просматривается до листового узла, который содержит соответствующий ключ и указатель на соответствующие строки в таблице. B-дерево чаще всего используется из-за его эффективности в хранении и поиске по упорядоченным данным. Их сбалансированная структура означает, что ко всем ключам можно получить доступ за одинаковое количество шагов, что обеспечивает постоянную производительность.
2) Хэш-индексы (hash index) лучше всего использовать при поиске точных совпадений. Ключевым компонентом хэш-индекса является хэш-функция. При поиске определенного значения искомое значение передается в хэш-функцию, которая возвращает хэш-значение. Это хэш-значение сообщает БД, где в хэш-таблице находятся ключ и указатели.
3) Индексы битовой карты (bitmap index) используется для столбцов с несколькими уникальными значениями. Каждая битовая карта представляет уникальное значение. Битовая карта указывает на наличие или отсутствие значения в наборе данных с помощью 1 и 0. Для существующих значений позиция 1 в битовой карте показывает местоположение строки в таблице. Индексы битовой карты очень эффективны при обработке сложных запросов, где используется несколько столбцов.
При индексировании таблицы рекомендуется тщательно выбирать столбцы для индексации на основе наиболее часто используемых столбцов в предложениях WHERE.
Составной индекс может использоваться, когда несколько столбцов часто используются вместе в предложении WHERE. С составным индексом комбинация двух или более столбцов используется для создания конкатенированного ключа. Затем ключи сохраняются на основе стратегии индекса, например, опций, упомянутых выше.
Индекс — это пара ключ-значение, где ключ используется для поиска данных вместо соответствующих индексированных столбцов, а значение — это указатель на соответствующие строки в таблице. Большинству баз данных требуется та или иная форма индексации для производительности. Чтобы максимально эффективно использовать БД, следует использовать тип индекса, соответствующий данной задаче.
1) B-дерево (b-tree index) — одна из наиболее часто используемых структур индексации, в которой ключи иерархически сортируются. При поиске данных дерево просматривается до листового узла, который содержит соответствующий ключ и указатель на соответствующие строки в таблице. B-дерево чаще всего используется из-за его эффективности в хранении и поиске по упорядоченным данным. Их сбалансированная структура означает, что ко всем ключам можно получить доступ за одинаковое количество шагов, что обеспечивает постоянную производительность.
2) Хэш-индексы (hash index) лучше всего использовать при поиске точных совпадений. Ключевым компонентом хэш-индекса является хэш-функция. При поиске определенного значения искомое значение передается в хэш-функцию, которая возвращает хэш-значение. Это хэш-значение сообщает БД, где в хэш-таблице находятся ключ и указатели.
3) Индексы битовой карты (bitmap index) используется для столбцов с несколькими уникальными значениями. Каждая битовая карта представляет уникальное значение. Битовая карта указывает на наличие или отсутствие значения в наборе данных с помощью 1 и 0. Для существующих значений позиция 1 в битовой карте показывает местоположение строки в таблице. Индексы битовой карты очень эффективны при обработке сложных запросов, где используется несколько столбцов.
При индексировании таблицы рекомендуется тщательно выбирать столбцы для индексации на основе наиболее часто используемых столбцов в предложениях WHERE.
Составной индекс может использоваться, когда несколько столбцов часто используются вместе в предложении WHERE. С составным индексом комбинация двух или более столбцов используется для создания конкатенированного ключа. Затем ключи сохраняются на основе стратегии индекса, например, опций, упомянутых выше.
👍16🔥1👏1
Механизмы аутентификации
[1.] 𝐀𝐏𝐈 𝐊𝐞𝐲
◾️ Простые уникальные идентификаторы, присваиваемые каждому клиенту или услуге.
◾️ Отправляется как заголовок или параметр запроса с каждым запросом.
◾️ Лучше всего подходит для внутренних служб, менее конфиденциальных API или для предоставления доступа к определенным функциям.
◾️ Простота внедрения и управления.
◾️ Не так безопасно, как методы на основе токенов. Подвержены утечке и краже
[2.] 𝐁𝐚𝐬𝐢𝐜 𝐀𝐮𝐭𝐡𝐞𝐧𝐭𝐢𝐜𝐚𝐭𝐢𝐨𝐧
◾️ Имя пользователя и пароль отправляются в заголовке Authorization в виде строки в кодировке base64.
◾️ Простота в реализации, но для обеспечения безопасности требуется HTTPS.
◾️ Подходит для простых сценариев с низкими требованиями к безопасности.
◾️ Широко распространена и проста для понимания
◾️ Уязвимв к атакам типа «человек посередине», если не используется HTTPS.
◾️ Пароли отправляются открытым текстом (даже в закодированном виде).
[3.] 𝐉𝐒𝐎𝐍 𝐖𝐞𝐛 𝐓𝐨𝐤𝐞𝐧𝐬 ( 𝐉𝐖𝐓 )
◾️ Автономные токены, которые в виде JSON содержат информацию о пользователе и его атрибуты
◾️ Выдается сервером аутентификации после успешного входа в систему, затем отправляется клиентом в заголовке Authorization
◾️ Широко используется для аутентификации без сохранения состояния в микросервисах, едином входе (SSO) и авторизации
◾️ Не хранит состояние, безопасный, компактный и может содержать дополнительные атрибуты
◾️ Требуется надлежащее управление ключами для подписи и проверки
[4.] 𝐎𝐀𝐮𝐭𝐡 2.0
◾️ Система, позволяющая сторонним приложениям получать ограниченный доступ к ресурсам от имени владельца ресурса (пользователя) без предоставления учетных данных
◾️ Использует различные типы верификации (код авторизации, учетные данные клиента и т. д.) для получения токенов доступа и токенов обновления
◾️ Широко используется для авторизации пользователей и делегированного доступа к API
◾️ Предоставляет стандартизированный способ безопасного доступа к ресурсам без предоставления учетных данных.
◾️ Может быть сложным в реализации и требует тщательного рассмотрения уязвимостей безопасности
[5.] 𝐎𝐩𝐞𝐧𝐈𝐃 𝐂𝐨𝐧𝐧𝐞𝐜𝐭 (𝐎𝐈𝐃𝐂)
◾️ Уровень идентификации поверх OAuth 2.0, который обеспечивает аутентификацию пользователя и предоставляет информацию о профиле
◾️ Использует идентификационный токен вместе с токеном доступа для предоставления идентификационной информации пользователя
◾️ Используется для аутентификации совместно с OAuth 2.0 для авторизации
◾️ Упрощает аутентификацию, стандартизируя способ получения информации о пользователе
◾️ Требуется интеграция с поставщиком OIDC (например, Google, Okta)
[6.] 𝐌𝐮𝐭𝐮𝐚𝐥 𝐓𝐋𝐒 (𝐦𝐓𝐋𝐒)
◾️ Клиент и сервер аутентифицируют друг друга с помощью сертификатов X.509
◾️ Для выдачи и управления сертификатами требуется центр сертификации (CA)
◾️ Лучше всего подходит для защиты связи между внутренними службами или высокочувствительными API
◾️ Надежная защита благодаря взаимной аутентификации и шифрованию.
◾️ Более сложен в настройке и управлении по сравнению с другими механизмами.
[1.] 𝐀𝐏𝐈 𝐊𝐞𝐲
◾️ Простые уникальные идентификаторы, присваиваемые каждому клиенту или услуге.
◾️ Отправляется как заголовок или параметр запроса с каждым запросом.
◾️ Лучше всего подходит для внутренних служб, менее конфиденциальных API или для предоставления доступа к определенным функциям.
◾️ Простота внедрения и управления.
◾️ Не так безопасно, как методы на основе токенов. Подвержены утечке и краже
[2.] 𝐁𝐚𝐬𝐢𝐜 𝐀𝐮𝐭𝐡𝐞𝐧𝐭𝐢𝐜𝐚𝐭𝐢𝐨𝐧
◾️ Имя пользователя и пароль отправляются в заголовке Authorization в виде строки в кодировке base64.
◾️ Простота в реализации, но для обеспечения безопасности требуется HTTPS.
◾️ Подходит для простых сценариев с низкими требованиями к безопасности.
◾️ Широко распространена и проста для понимания
◾️ Уязвимв к атакам типа «человек посередине», если не используется HTTPS.
◾️ Пароли отправляются открытым текстом (даже в закодированном виде).
[3.] 𝐉𝐒𝐎𝐍 𝐖𝐞𝐛 𝐓𝐨𝐤𝐞𝐧𝐬 ( 𝐉𝐖𝐓 )
◾️ Автономные токены, которые в виде JSON содержат информацию о пользователе и его атрибуты
◾️ Выдается сервером аутентификации после успешного входа в систему, затем отправляется клиентом в заголовке Authorization
◾️ Широко используется для аутентификации без сохранения состояния в микросервисах, едином входе (SSO) и авторизации
◾️ Не хранит состояние, безопасный, компактный и может содержать дополнительные атрибуты
◾️ Требуется надлежащее управление ключами для подписи и проверки
[4.] 𝐎𝐀𝐮𝐭𝐡 2.0
◾️ Система, позволяющая сторонним приложениям получать ограниченный доступ к ресурсам от имени владельца ресурса (пользователя) без предоставления учетных данных
◾️ Использует различные типы верификации (код авторизации, учетные данные клиента и т. д.) для получения токенов доступа и токенов обновления
◾️ Широко используется для авторизации пользователей и делегированного доступа к API
◾️ Предоставляет стандартизированный способ безопасного доступа к ресурсам без предоставления учетных данных.
◾️ Может быть сложным в реализации и требует тщательного рассмотрения уязвимостей безопасности
[5.] 𝐎𝐩𝐞𝐧𝐈𝐃 𝐂𝐨𝐧𝐧𝐞𝐜𝐭 (𝐎𝐈𝐃𝐂)
◾️ Уровень идентификации поверх OAuth 2.0, который обеспечивает аутентификацию пользователя и предоставляет информацию о профиле
◾️ Использует идентификационный токен вместе с токеном доступа для предоставления идентификационной информации пользователя
◾️ Используется для аутентификации совместно с OAuth 2.0 для авторизации
◾️ Упрощает аутентификацию, стандартизируя способ получения информации о пользователе
◾️ Требуется интеграция с поставщиком OIDC (например, Google, Okta)
[6.] 𝐌𝐮𝐭𝐮𝐚𝐥 𝐓𝐋𝐒 (𝐦𝐓𝐋𝐒)
◾️ Клиент и сервер аутентифицируют друг друга с помощью сертификатов X.509
◾️ Для выдачи и управления сертификатами требуется центр сертификации (CA)
◾️ Лучше всего подходит для защиты связи между внутренними службами или высокочувствительными API
◾️ Надежная защита благодаря взаимной аутентификации и шифрованию.
◾️ Более сложен в настройке и управлении по сравнению с другими механизмами.
🔥11👍5❤1👏1
This media is not supported in your browser
VIEW IN TELEGRAM
уровни сетевой модели OSI и соответствующие им кибератаки
🔥10💊5❤2
Вышла новоая версия языка Go - Go 1.24.
https://go.dev/doc/go1.24
Основные изменения в новой версии:
Go 1.24 теперь полностью поддерживает псевдонимы обобщённых типов (generic type alias) — псевдоним типа может быть параметризирован, как и впервые определяемый тип (при определении псевдонима типа теперь допускается указание параметров типа);
Оптимизация среды выполнения снизила нагрузку на процессор на 2–3%. Оптимизации включают новую реализаций операций со словарями на основе хэш‑таблиц Swiss Table, более эффективное распределение памяти для небольших объектов и новую реализацию внутреннего мьютекса во время выполнения
Команда go теперь предоставляет механизм отслеживания зависимостей инструментов для модуля. Определение утилит в файле go.mod производится через директиву tool, для добавления которой в текущий модуль предложена команда go get ‑tool (например, go get ‑tool golang.org/x/tools/cmd/stringer). Для запуска утилиты, указанной в директиве tool, добавлена команда «go tool имя_утилиты».
В команды go build и go install добавлена опция ‑json для вывода в формате JSON
Добавлена переменная окружения GOAUTH для задания параметров аутентификации, необходимых для извлечения модулей, доступ к которым ограничен.
В команде go vet реализован новый анализатор тестов (test analyzer), выявляющий типовые ошибки при включении тестов, fuzzing‑инструментов, утилит проверки производительности и примеров приложений;
В стандартную библиотеку добавлены реализации криптоалгоритмов из стандарта FIPS 140–3. Помимо FIPS 140, несколько пакетов, которые ранее были в модуле x/crypto, теперь доступны в стандартной библиотеке.
В пакет testing добавлен метод B.Loop для выполнения тестов производительности. Применение for b.Loop() {... } вместо обычных циклов позволяет исключить выполнение компилятором полной оптимизации тела цикла и вынести из цикла стадии настройки и очистки теста
Добавлен тип os.Root, позволяющий изолировать операции с файловой системой заданным каталогом.
В среду выполнения добавлен новый механизм финализации runtime.AddCleanup, более гибкий и эффективный, чем runtime.SetFinalizer.
Добавлен пакет weak c реализацией слабых указателей, которые не владеют объектом, не увеличивают счётчик ссылок и не препятствуют освобождению объекта
Добавлены пакеты crypto/mlkem с реализацией криптоалгортимов ML‑KEM-768 и ML‑KEM-1024 (Kyber), стойких для подбора на квантовом компьютере; crypto/hkdf c реализацией функции формирования ключа на базе HMAC (RFC 5869); crypto/pbkdf2 c реализацией функции формирования ключа на базе пароля (PBKDF2, RFC 8018); crypto/sha3 c реализацией хэшей SHA-3;
Добавлен экспериментальный пакет testing/synctest с функциями для тестирования многопоточности;
Улучшена поддержка WebAssembly. Добавлена возможность сборки Go‑приложений в форме библиотеки или обработчика WASI (WebAssembly System Interface). Реализована директива go:wasmexport для экспорта функций для использования в WebAssembly;
В утилиту objdump добавлена поддержка дизассемблирования для архитектур LoongArch (GOARCH=loong64), RISC‑V (GOARCH=riscv64) и S390X (GOARCH=s390x).
https://go.dev/doc/go1.24
Основные изменения в новой версии:
Go 1.24 теперь полностью поддерживает псевдонимы обобщённых типов (generic type alias) — псевдоним типа может быть параметризирован, как и впервые определяемый тип (при определении псевдонима типа теперь допускается указание параметров типа);
Оптимизация среды выполнения снизила нагрузку на процессор на 2–3%. Оптимизации включают новую реализаций операций со словарями на основе хэш‑таблиц Swiss Table, более эффективное распределение памяти для небольших объектов и новую реализацию внутреннего мьютекса во время выполнения
Команда go теперь предоставляет механизм отслеживания зависимостей инструментов для модуля. Определение утилит в файле go.mod производится через директиву tool, для добавления которой в текущий модуль предложена команда go get ‑tool (например, go get ‑tool golang.org/x/tools/cmd/stringer). Для запуска утилиты, указанной в директиве tool, добавлена команда «go tool имя_утилиты».
В команды go build и go install добавлена опция ‑json для вывода в формате JSON
Добавлена переменная окружения GOAUTH для задания параметров аутентификации, необходимых для извлечения модулей, доступ к которым ограничен.
В команде go vet реализован новый анализатор тестов (test analyzer), выявляющий типовые ошибки при включении тестов, fuzzing‑инструментов, утилит проверки производительности и примеров приложений;
В стандартную библиотеку добавлены реализации криптоалгоритмов из стандарта FIPS 140–3. Помимо FIPS 140, несколько пакетов, которые ранее были в модуле x/crypto, теперь доступны в стандартной библиотеке.
В пакет testing добавлен метод B.Loop для выполнения тестов производительности. Применение for b.Loop() {... } вместо обычных циклов позволяет исключить выполнение компилятором полной оптимизации тела цикла и вынести из цикла стадии настройки и очистки теста
Добавлен тип os.Root, позволяющий изолировать операции с файловой системой заданным каталогом.
В среду выполнения добавлен новый механизм финализации runtime.AddCleanup, более гибкий и эффективный, чем runtime.SetFinalizer.
Добавлен пакет weak c реализацией слабых указателей, которые не владеют объектом, не увеличивают счётчик ссылок и не препятствуют освобождению объекта
Добавлены пакеты crypto/mlkem с реализацией криптоалгортимов ML‑KEM-768 и ML‑KEM-1024 (Kyber), стойких для подбора на квантовом компьютере; crypto/hkdf c реализацией функции формирования ключа на базе HMAC (RFC 5869); crypto/pbkdf2 c реализацией функции формирования ключа на базе пароля (PBKDF2, RFC 8018); crypto/sha3 c реализацией хэшей SHA-3;
Добавлен экспериментальный пакет testing/synctest с функциями для тестирования многопоточности;
Улучшена поддержка WebAssembly. Добавлена возможность сборки Go‑приложений в форме библиотеки или обработчика WASI (WebAssembly System Interface). Реализована директива go:wasmexport для экспорта функций для использования в WebAssembly;
В утилиту objdump добавлена поддержка дизассемблирования для архитектур LoongArch (GOARCH=loong64), RISC‑V (GOARCH=riscv64) и S390X (GOARCH=s390x).
go.dev
Go 1.24 Release Notes - The Go Programming Language
❤7🔥2👍1🥰1
Архитектурный шаблон Модульный монолит
В мире архитектуры программного обеспечения уже давно лидируют два доминирующих шаблона.
🔸 Монолитная архитектура
Классический подход, при котором все компоненты приложения тесно интегрированы в единое целое.
🔸 Архитектура микросервисов
Приложение разбито на небольшие независимые службы, которые взаимодействуют по сети.
Модульный монолит представляет собой нечто среднее, прагматичный подход, сочетающий в себе лучшее из обоих миров.
Он направлен на решение следующих проблем:
◾️ Проблемы с поддержкой монолитов
- Благодаря внедрению модульности кодовая база становится более организованной, простой для понимания и менее подверженной синдрому «big ball of mud».
◾️ Сложность микросервисов
- Он позволяет избежать операционных издержек, характерных для распределенных систем, что делает его более доступным вариантом для небольших команд или проектов, которым не требуется полный масштаб микросервисов.
📌 Основные характеристики модульных монолитов
Модульный монолит = Монолитная простота + Модульная гибкость ]
◾️ Кодовая база разделена на четко определенные модули, каждый из которых инкапсулирует определенную бизнес-возможность или домен.
◾️ Каждый модуль инкапсулирует собственные данные, логику и уровни представления, способствуя разделению задач и удобству обслуживания.
◾️ Модули взаимодействуют через понятные интерфейсы (API), способствуя слабой связанности и независимой эволюции.
◾️ Модули могут совместно использовать общие библиотеки или утилиты для повышения эффективности, сохраняя при этом инкапсуляцию.
◾️ Приложение развертывается как единое целое, что упрощает операции по сравнению с распределенными микросервисами.
📌 Когда следует рассмотреть?
◾️ Проекты на ранних стадиях
◾️ Меньшие команды или ограниченные ресурсы
◾️ Приложения средней сложности
◾️ Переход от монолита
- Модульный монолит может стать ступенькой на пути к микросервисам.
📌 Некоторые проблемы и их решения при работе с модульными монолитами
◾️ Поддержание модульности
- Требует дисциплины и постоянного рефакторинга, чтобы избежать «спагетти-кода» по мере роста приложения.
◾️ Межмодульная связь
- Разрабатывайте четкие шаблоны общения (внутрипроцессные звонки или легкие сообщения), чтобы избежать тесной связи.
◾️ Тестирование
- Тщательно протестируйте взаимодействие модулей, чтобы убедиться, что приложение работает как единое целое.
◾️ Масштабируемость
- Масштабирование отдельных модулей может оказаться более сложным, чем масштабирование независимых микросервисов.
В мире архитектуры программного обеспечения уже давно лидируют два доминирующих шаблона.
🔸 Монолитная архитектура
Классический подход, при котором все компоненты приложения тесно интегрированы в единое целое.
🔸 Архитектура микросервисов
Приложение разбито на небольшие независимые службы, которые взаимодействуют по сети.
Модульный монолит представляет собой нечто среднее, прагматичный подход, сочетающий в себе лучшее из обоих миров.
Он направлен на решение следующих проблем:
◾️ Проблемы с поддержкой монолитов
- Благодаря внедрению модульности кодовая база становится более организованной, простой для понимания и менее подверженной синдрому «big ball of mud».
◾️ Сложность микросервисов
- Он позволяет избежать операционных издержек, характерных для распределенных систем, что делает его более доступным вариантом для небольших команд или проектов, которым не требуется полный масштаб микросервисов.
📌 Основные характеристики модульных монолитов
Модульный монолит = Монолитная простота + Модульная гибкость ]
◾️ Кодовая база разделена на четко определенные модули, каждый из которых инкапсулирует определенную бизнес-возможность или домен.
◾️ Каждый модуль инкапсулирует собственные данные, логику и уровни представления, способствуя разделению задач и удобству обслуживания.
◾️ Модули взаимодействуют через понятные интерфейсы (API), способствуя слабой связанности и независимой эволюции.
◾️ Модули могут совместно использовать общие библиотеки или утилиты для повышения эффективности, сохраняя при этом инкапсуляцию.
◾️ Приложение развертывается как единое целое, что упрощает операции по сравнению с распределенными микросервисами.
📌 Когда следует рассмотреть?
◾️ Проекты на ранних стадиях
◾️ Меньшие команды или ограниченные ресурсы
◾️ Приложения средней сложности
◾️ Переход от монолита
- Модульный монолит может стать ступенькой на пути к микросервисам.
📌 Некоторые проблемы и их решения при работе с модульными монолитами
◾️ Поддержание модульности
- Требует дисциплины и постоянного рефакторинга, чтобы избежать «спагетти-кода» по мере роста приложения.
◾️ Межмодульная связь
- Разрабатывайте четкие шаблоны общения (внутрипроцессные звонки или легкие сообщения), чтобы избежать тесной связи.
◾️ Тестирование
- Тщательно протестируйте взаимодействие модулей, чтобы убедиться, что приложение работает как единое целое.
◾️ Масштабируемость
- Масштабирование отдельных модулей может оказаться более сложным, чем масштабирование независимых микросервисов.
👍4🤩4❤1👏1
Правительство РФ утвердило параметры эксперимента по внедрению системы добровольного подтверждения компетенций для разработчиков ПО. Это возможность для работодателей и образовательных учреждений точнее определять уровень ИТ-компетенций и подбирать подходящих сотрудников, а для специалистов — проверить свои знания и получить сертификат, подтверждающий их уровень. С 31 мая 2025 года любой желающий, независимо от уровня образования, сможет пройти тесты и выполнить практические задания. В этом году на платформе планируется разместить материалы по 21 направлению (Python, Java, Git и другие).
С 14 февраля 2025 года по 31 декабря 2026 года в России пройдёт эксперимент по внедрению системы добровольного подтверждения компетенций для разработчиков программного обеспечения.
Суть эксперимента заключается в предоставлении специалистам бесплатного инструмента для проверки собственного уровня владения различными ИТ-компетенциями. Речь идёт о цифровой платформе, воспользовавшись которой программисты смогут пройти тесты и выполнить практические задания.
В случае успешного прохождения испытаний они получат сертификат, подтверждающий их знания и навыки работы. Он будет отправляться в личный кабинет на портале Госуслуг. Срок его действия составит 1 год.
В ходе эксперимента компании-работодатели, образовательные учреждения и другие организации, которые станут его участниками, получат возможность подобрать подходящего программиста, а также оценить уровень профессионализма действующих сотрудников.
Участвовать в эксперименте смогут разработчики ПО независимо от уровня образования.
Оператор эксперимента будет отобран на конкурсной основе до 31 марта 2025 года. Его определением займётся президиум правительственной комиссии по цифровому развитию.
Практическая стадия эксперимента начнётся с 31 мая 2025 года, когда ИТ-специалисты получат доступ к платформе подтверждения своих компетенций и смогут пройти тесты и выполнить задания.
https://news.1rj.ru/str/mintsifry/2436
http://government.ru/news/54223/
С 14 февраля 2025 года по 31 декабря 2026 года в России пройдёт эксперимент по внедрению системы добровольного подтверждения компетенций для разработчиков программного обеспечения.
Суть эксперимента заключается в предоставлении специалистам бесплатного инструмента для проверки собственного уровня владения различными ИТ-компетенциями. Речь идёт о цифровой платформе, воспользовавшись которой программисты смогут пройти тесты и выполнить практические задания.
В случае успешного прохождения испытаний они получат сертификат, подтверждающий их знания и навыки работы. Он будет отправляться в личный кабинет на портале Госуслуг. Срок его действия составит 1 год.
В ходе эксперимента компании-работодатели, образовательные учреждения и другие организации, которые станут его участниками, получат возможность подобрать подходящего программиста, а также оценить уровень профессионализма действующих сотрудников.
Участвовать в эксперименте смогут разработчики ПО независимо от уровня образования.
Оператор эксперимента будет отобран на конкурсной основе до 31 марта 2025 года. Его определением займётся президиум правительственной комиссии по цифровому развитию.
Практическая стадия эксперимента начнётся с 31 мая 2025 года, когда ИТ-специалисты получат доступ к платформе подтверждения своих компетенций и смогут пройти тесты и выполнить задания.
https://news.1rj.ru/str/mintsifry/2436
http://government.ru/news/54223/
Telegram
Минцифры России
🚀 В России появится Национальная система подтверждения ИТ-компетенций
ИТ-специалисты смогут бесплатно пройти тестирование и подтвердить свои компетенции на отечественной платформе. Эксперимент по её внедрению начнётся 14 февраля 2025 года и продлится до…
ИТ-специалисты смогут бесплатно пройти тестирование и подтвердить свои компетенции на отечественной платформе. Эксперимент по её внедрению начнётся 14 февраля 2025 года и продлится до…
🤡16😁6👍2🔥1💊1
Представлен новый рейтинг TIOBE. Его авторы отмечают продвижение «быстрых» языков, которые позволяют обрабатывать растущие объёмы данных в условиях, когда «железо» не может удовлетворять рост потребностей.
Так, на втором месте C++, Go прочно вошёл в топ-10, а Rust достиг рекордной доли на рынке в 1,47%. В топ-50 пытаются войти языки Mojo и Zig, которые уже занимают 51-ю и 56-ю позиции соответственно.
Особняком стоит Python, который занимает 1-е место и известен как медленный язык. Это потому, что в настоящее время есть еще один драйвер, кроме производительности: насколько легко выучить новый язык программирования. Авторы рейтинга связывают это с простотой языка и с тем, что рынку требуется больше программистов, при этом вузы не закрывают потребность в инженерах ПО, а в программирование приходят специалисты из других сфер, которые предпочитают Python.
Так, на втором месте C++, Go прочно вошёл в топ-10, а Rust достиг рекордной доли на рынке в 1,47%. В топ-50 пытаются войти языки Mojo и Zig, которые уже занимают 51-ю и 56-ю позиции соответственно.
Особняком стоит Python, который занимает 1-е место и известен как медленный язык. Это потому, что в настоящее время есть еще один драйвер, кроме производительности: насколько легко выучить новый язык программирования. Авторы рейтинга связывают это с простотой языка и с тем, что рынку требуется больше программистов, при этом вузы не закрывают потребность в инженерах ПО, а в программирование приходят специалисты из других сфер, которые предпочитают Python.
9 вариантов использования баз данных NoSQL
1 - MongoDB (хранилище документов)
Используется для систем управления контентом и управления каталогами. Имеет формат BSON, дизайн без схем, поддерживает горизонтальное масштабирование с шардингом и высокую доступность с репликацией.
2 - Cassandra (хранение данных в широких столбцах)
Идеально подходит для управления данными временных рядов и рекомендательных механизмов. Предлагает широкостолбцовый формат, распределенную архитектуру и CQL для SQL-подобных запросов.
3 - Redis (хранилище ключей и значений)
Подходит для кэширования, управления сеансами и т.п. Предоставляет хранилище в памяти, поддержку сложных структур данных и параметры сохранения с RDB и AOF.
4 - Couchbase (хранилище документов с ключом-значением)
Используется для систем управления контентом и платформ электронной коммерции. Сочетает операции на основе ключей и документов с архитектурой, ориентированной на память, и репликацией между центрами обработки данных.
5 - Neo4j (БД на основе графов)
Отлично подходит для социальных сетей и обнаружения мошенничества. Соответствует требованиям ACID, имеет смежность без индексов, язык запросов Cypher и возможности кластера HA.
6 - Amazon DynamoDB (ключ-значение и документ)
Идеально подходит для бессерверных и IoT-приложений. Поддерживает как данные «ключ-значение», так и сложные данные документов, управляемые AWS, с такими функциями, как разделение данных по узлам и потоки DynamoDB.
7 - Apache Hbase (хранение данных в широких столбцах)
Используется для хранилища данных и крупномасштабной обработки данных. Создан по образцу Google Bigtable, предлагает интеграцию с Hadoop, автоматическое шардинг, сильную согласованность и региональные серверы.
8 - Elasticsearch (поисковая система)
Идеально подходит для полнотекстового поиска, анализа данных журналов и событий. Создан на базе Apache Lucene, ориентирован на документы, с возможностями шардинга и репликации, а также интерфейсом RESTful.
9 - CouchDB (хранилище документов)
Подходит для мобильных приложений и CMS. Ориентирован на документы, обеспечивает согласованность данных без блокировки, поддерживает конечную согласованность и использует RESTful API.
1 - MongoDB (хранилище документов)
Используется для систем управления контентом и управления каталогами. Имеет формат BSON, дизайн без схем, поддерживает горизонтальное масштабирование с шардингом и высокую доступность с репликацией.
2 - Cassandra (хранение данных в широких столбцах)
Идеально подходит для управления данными временных рядов и рекомендательных механизмов. Предлагает широкостолбцовый формат, распределенную архитектуру и CQL для SQL-подобных запросов.
3 - Redis (хранилище ключей и значений)
Подходит для кэширования, управления сеансами и т.п. Предоставляет хранилище в памяти, поддержку сложных структур данных и параметры сохранения с RDB и AOF.
4 - Couchbase (хранилище документов с ключом-значением)
Используется для систем управления контентом и платформ электронной коммерции. Сочетает операции на основе ключей и документов с архитектурой, ориентированной на память, и репликацией между центрами обработки данных.
5 - Neo4j (БД на основе графов)
Отлично подходит для социальных сетей и обнаружения мошенничества. Соответствует требованиям ACID, имеет смежность без индексов, язык запросов Cypher и возможности кластера HA.
6 - Amazon DynamoDB (ключ-значение и документ)
Идеально подходит для бессерверных и IoT-приложений. Поддерживает как данные «ключ-значение», так и сложные данные документов, управляемые AWS, с такими функциями, как разделение данных по узлам и потоки DynamoDB.
7 - Apache Hbase (хранение данных в широких столбцах)
Используется для хранилища данных и крупномасштабной обработки данных. Создан по образцу Google Bigtable, предлагает интеграцию с Hadoop, автоматическое шардинг, сильную согласованность и региональные серверы.
8 - Elasticsearch (поисковая система)
Идеально подходит для полнотекстового поиска, анализа данных журналов и событий. Создан на базе Apache Lucene, ориентирован на документы, с возможностями шардинга и репликации, а также интерфейсом RESTful.
9 - CouchDB (хранилище документов)
Подходит для мобильных приложений и CMS. Ориентирован на документы, обеспечивает согласованность данных без блокировки, поддерживает конечную согласованность и использует RESTful API.
👍1🤝1
Модель Pub/Sub (Издатель-Подписчик)
Распределенные системы должны управлять масштабируемыми, отвязанными друг от друга компонентами. Шаблон обмена сообщениями «публикация-подписка» (publish-subscribe) позволяет это сделать, предоставляя асинхронное, событийное распределение сообщений
В этом процессе участвуют три элемента: издатели (publishers), темы и подписчики (subscribers). Подписываясь на тему, подписчики (Subscribers) сообщают системе, какие сообщениях они хотят получать. Издатели (Publishers) отправляют сообщения по темам, не зная, кому именно отправляется сообщение. Затем брокер сообщений или шина событий пересылает эти сообщения соответствующим подписчикам.
Соцсети и мессенджеры обладают рядом функций, которые идеально подходят для этой модели.
Отправители и получатели сообщений отвязаны друг от друга в модели Pub/Sub. Это ведет к большей масштабируемости, гибкости и отказоустойчивости. В итоге эта модель часто применяется в распределенных системах с большим объемом коммуникации между узлами
Распределенные системы должны управлять масштабируемыми, отвязанными друг от друга компонентами. Шаблон обмена сообщениями «публикация-подписка» (publish-subscribe) позволяет это сделать, предоставляя асинхронное, событийное распределение сообщений
В этом процессе участвуют три элемента: издатели (publishers), темы и подписчики (subscribers). Подписываясь на тему, подписчики (Subscribers) сообщают системе, какие сообщениях они хотят получать. Издатели (Publishers) отправляют сообщения по темам, не зная, кому именно отправляется сообщение. Затем брокер сообщений или шина событий пересылает эти сообщения соответствующим подписчикам.
Соцсети и мессенджеры обладают рядом функций, которые идеально подходят для этой модели.
Отправители и получатели сообщений отвязаны друг от друга в модели Pub/Sub. Это ведет к большей масштабируемости, гибкости и отказоустойчивости. В итоге эта модель часто применяется в распределенных системах с большим объемом коммуникации между узлами
👍7🔥1👏1
Memcached представляет распространенную систему кэширования в памяти.
Memcached изначально был создан 2003 для решения проблемы производительности в LiveJournal, популярной платформе для ведения блогов. Изначално он был написан на 𝐏𝐞𝐫𝐥, но вскоре переписан на 𝐂.
Идея была проста => хранить часто используемые данные в памяти, чтобы избежать повторного обращения к базе данных.
В 2004 году Memcached стал проектом с открытым исходным кодом.
Основные характеристики:
◾️ Memcached — это быстрая распределенная система кэширования в памяти, используемая для ускорения работы приложений за счет хранения данных в оперативной памяти.
◾️ Он работает путем хранения пар «ключ-значение» и их быстрого извлечения при необходимости.
◾️ Это снижает необходимость доступа к более медленным источникам данных, таким как базы данных, что приводит к сокращению времени отклика и повышению производительности.
◾️ Memcached особенно эффективен для кэширования часто используемых данных, таких как результаты запросов к базе данных, ответы API и информация о сеансе.
Вкратце процесс работы
Приложение отправляет команду 𝐬𝐞𝐭
◾️ Приложение указывает ключ, значение и (необязательно) срок действия.
◾️ Узел Memcached вычисляет хэш ключа, чтобы определить, где хранить элемент в своей хэш-таблице.
Приложение отправляет команду 𝐠𝐞𝐭 -
◾️ Приложение предоставляет ключ.
◾️ Узел Memcached вычисляет хэш, находит элемент в хэш-таблице и возвращает значение приложению.
Основные компоненты
[1.] Хэш-таблица
◾️ Memcached использует большую хеш-таблицу, находящуюся в оперативной памяти, для хранения пар ключ-значение.
◾️ Это обеспечивает быстрый поиск со сложностью O(1).
[2.] Алгоритм удаления LRU
◾️ Memcached имеет фиксированный объем памяти.
◾️ Когда он заполняется, он применяет алгоритм LRU, который удаляет старые, наименее используемые элементы, освобождая место для новых.
[3.] Распределение памяти на блоки
◾️ Для эффективного управления памятью Memcached делит выделенную память на «блоки» разных размеров.
◾️ Это предотвращает фрагментацию памяти и повышает производительность.
[4.] Простой текстовый протокол
◾️ Memcached взаимодействует с клиентами (вашими приложениями) с помощью простого текстового протокола.
[5.] Распределенная архитектура
◾️ Memcached можно развернуть на нескольких серверах.
◾️ Это позволяет масштабировать его горизонтально и обеспечивает отказоустойчивость.
Ограничения
[1.] Данные не сохраняются
◾️ Данные теряются в случае сбоя или перезапуска сервера, поскольку Memcached хранит данные исключительно в памяти.
[2.] Отсутствие резервирования данных
◾️ Если вы используете один экземпляр Memcached, то нет встроенного резервирования для защиты от потери данных.
[3.] Ограниченные типы данных
◾️ Данные хранятся в виде простых пар «ключ-значение», что может не подходить для сложных структур данных.
Если несколько клиентов одновременно запрашивают кэшированный элемент, срок действия которого истек, они все могут одновременно обратиться к внутренней базе данных, что приведет к проблемам с производительностью.
Memcached изначально был создан 2003 для решения проблемы производительности в LiveJournal, популярной платформе для ведения блогов. Изначално он был написан на 𝐏𝐞𝐫𝐥, но вскоре переписан на 𝐂.
Идея была проста => хранить часто используемые данные в памяти, чтобы избежать повторного обращения к базе данных.
В 2004 году Memcached стал проектом с открытым исходным кодом.
Основные характеристики:
◾️ Memcached — это быстрая распределенная система кэширования в памяти, используемая для ускорения работы приложений за счет хранения данных в оперативной памяти.
◾️ Он работает путем хранения пар «ключ-значение» и их быстрого извлечения при необходимости.
◾️ Это снижает необходимость доступа к более медленным источникам данных, таким как базы данных, что приводит к сокращению времени отклика и повышению производительности.
◾️ Memcached особенно эффективен для кэширования часто используемых данных, таких как результаты запросов к базе данных, ответы API и информация о сеансе.
Вкратце процесс работы
Приложение отправляет команду 𝐬𝐞𝐭
◾️ Приложение указывает ключ, значение и (необязательно) срок действия.
◾️ Узел Memcached вычисляет хэш ключа, чтобы определить, где хранить элемент в своей хэш-таблице.
Приложение отправляет команду 𝐠𝐞𝐭 -
◾️ Приложение предоставляет ключ.
◾️ Узел Memcached вычисляет хэш, находит элемент в хэш-таблице и возвращает значение приложению.
Основные компоненты
[1.] Хэш-таблица
◾️ Memcached использует большую хеш-таблицу, находящуюся в оперативной памяти, для хранения пар ключ-значение.
◾️ Это обеспечивает быстрый поиск со сложностью O(1).
[2.] Алгоритм удаления LRU
◾️ Memcached имеет фиксированный объем памяти.
◾️ Когда он заполняется, он применяет алгоритм LRU, который удаляет старые, наименее используемые элементы, освобождая место для новых.
[3.] Распределение памяти на блоки
◾️ Для эффективного управления памятью Memcached делит выделенную память на «блоки» разных размеров.
◾️ Это предотвращает фрагментацию памяти и повышает производительность.
[4.] Простой текстовый протокол
◾️ Memcached взаимодействует с клиентами (вашими приложениями) с помощью простого текстового протокола.
[5.] Распределенная архитектура
◾️ Memcached можно развернуть на нескольких серверах.
◾️ Это позволяет масштабировать его горизонтально и обеспечивает отказоустойчивость.
Ограничения
[1.] Данные не сохраняются
◾️ Данные теряются в случае сбоя или перезапуска сервера, поскольку Memcached хранит данные исключительно в памяти.
[2.] Отсутствие резервирования данных
◾️ Если вы используете один экземпляр Memcached, то нет встроенного резервирования для защиты от потери данных.
[3.] Ограниченные типы данных
◾️ Данные хранятся в виде простых пар «ключ-значение», что может не подходить для сложных структур данных.
Если несколько клиентов одновременно запрашивают кэшированный элемент, срок действия которого истек, они все могут одновременно обратиться к внутренней базе данных, что приведет к проблемам с производительностью.
👍7❤1