АИС «Налог-3»: почему это одна из самых мощных государственных IT-систем России
За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.
Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.
Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»
Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.
Читать: https://habr.com/ru/articles/982504/
#ru
@database_design | Другие наши каналы
За последнее десятилетие Федеральная налоговая служба (ФНС) совершила фундаментальный переход от традиционной модели администрирования к подходу, основанному на анализе больших баз данных.
Если вы соприкасались с налоговой системой - проходили проверки, бывали на комиссиях в инспекциях, общались с налоговыми органами, то вы слышали про АИС «Налог-3», одну из самых масштабных государственных IT-платформ в России.
Я проработал в системе налоговых органов 12 лет - от рядового инспектора в ИФНС до заместителя начальника отдела проведения налоговых проверок Управления ФНС - и наблюдал эту трансформацию изнутри. В этой статье я хочу показать, насколько эта система действительно мощная, как она эволюционировала, что она реально умеет сегодня и почему, несмотря на весь объём данных, это пока не «искусственный интеллект, который всё делает сам»
Сразу обозначу границу: я не раскрываю никакой служебной информации. Всё, о чём в статье пойдёт речь, это обобщение моего опыта работы в службе и данные, которые размещены в открытом доступе. Из налоговых органов я ушёл относительно недавно (2 месяца назад), и за это время мало, что могло поменяться, поэтому информация все еще остается актуальной.
Читать: https://habr.com/ru/articles/982504/
#ru
@database_design | Другие наши каналы
Как не стоит проектировать API (или как Mak.by сливает адреса своих пользователей)
P.S. в ходе написания статьи не было использовано ни одно ИИ.
В один день я захотел посмотреть как работают купоны в приложении Mak.by в программистском смысле. Для этого я просто посмотрел какие запросы отправляет приложение на сервер с помощью тулы для перехвата HTTP трафика.
Читать: https://habr.com/ru/articles/982594/
#ru
@database_design | Другие наши каналы
P.S. в ходе написания статьи не было использовано ни одно ИИ.
В один день я захотел посмотреть как работают купоны в приложении Mak.by в программистском смысле. Для этого я просто посмотрел какие запросы отправляет приложение на сервер с помощью тулы для перехвата HTTP трафика.
Читать: https://habr.com/ru/articles/982594/
#ru
@database_design | Другие наши каналы
Почему внедрение LLM в АИС «Налог-3» неизбежно — и что это изменит в налоговом контроле
После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.
Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».
В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.
Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.
Читать: https://habr.com/ru/articles/982686/
#ru
@database_design | Другие наши каналы
После моей статьи про АИС «Налог-3» (как одну из самых мощных государственных IT-систем России) в комментариях больше всего спорили не про масштабы данных и вопроса, «видит ли ФНС всё». Основной скепсис вызвал мой тезис о необходимости внедрения больших языковых моделей (LLM) в работу налоговых органов.
Основной аргумент в противовес моей позиции звучал так: «Зачем там нужен Искусственный Интеллект? Всё формализовано, достаточно жестких алгоритмов и грамотных шаблонов. Экспертная система справится сама, не надо усложнять».
В этой статье я постараюсь привнести ясность в то, как происходит сбор доказательственной базы по налоговым правонарушениям и как формируется итоговый документ (акт и решение по налоговой проверки). Потому что в реальной налоговой проверке проблема не в том, чтобы найти риск или подсветить признаки. Это АИС «Налог-3» уже умеет делать достаточно хорошо. Проблема в другом - превратить массив фактов в доказательства и выводы, а затем изложить это в юридически выверенном тексте, который выдержит спор сначала на стадии возражений, потом в вышестоящем налоговом органе, а при необходимости и в суде.
Если вы читаете меня впервые: я не аналитик со стороны и не «диванный эксперт». За моими словами 12 лет работы в налоговых органах, в том числе на руководящих должностях. Из системы я ушёл совсем недавно и прекрасно понимаю, как это работает изнутри.
Читать: https://habr.com/ru/articles/982686/
#ru
@database_design | Другие наши каналы
Кривая забывания эббингауза в пользовательских приложениях
Кривая забывания Эббингауза часто упоминается в теории обучения, но редко в прикладном контексте. В статье разбираю саму модель и показываю, как её можно реализовать на SQL и Python для управления повторениями в пользовательском приложении.
Читать: «Кривая забывания эббингауза в пользовательских приложениях»
#ru
@database_design | Другие наши каналы
Кривая забывания Эббингауза часто упоминается в теории обучения, но редко в прикладном контексте. В статье разбираю саму модель и показываю, как её можно реализовать на SQL и Python для управления повторениями в пользовательском приложении.
Читать: «Кривая забывания эббингауза в пользовательских приложениях»
#ru
@database_design | Другие наши каналы
Какие навыки прокачать IT-специалисту на новогодних каникулах: подборка курсов от Selectel
Привет, Хабр! Новый год — хороший повод научиться чему-то новому. Длинные каникулы позволяют выйти из рутины, выспаться и наконец разобраться с тем, на что в обычные дни не хватает времени. В подборке собрали семь полезных курсов, которые помогут освоить нужные навыки. И главное — все бесплатно.
Читать: https://habr.com/ru/companies/selectel/articles/980990/
#ru
@database_design | Другие наши каналы
Привет, Хабр! Новый год — хороший повод научиться чему-то новому. Длинные каникулы позволяют выйти из рутины, выспаться и наконец разобраться с тем, на что в обычные дни не хватает времени. В подборке собрали семь полезных курсов, которые помогут освоить нужные навыки. И главное — все бесплатно.
Читать: https://habr.com/ru/companies/selectel/articles/980990/
#ru
@database_design | Другие наши каналы
Как я пытался создать «конструктор налоговых проверок» для повышения эффективности работы ФНС
Для начала - немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм-канал и теперь работаю в налоговом консалтинге.
Эта статья - история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все-таки попробовал создать инструмент, который мог бы изменить работу инспектора.
Читать: https://habr.com/ru/articles/982938/
#ru
@database_design | Другие наши каналы
Для начала - немного контекста. Я не программист и не разработчик. Последние 12 лет я проработал в Федеральной налоговой службе. Начинал с низов, занимался выездными и камеральными проверками (проводил лично и курировал). Два месяца назад я уволился, завел свой телеграм-канал и теперь работаю в налоговом консалтинге.
Эта статья - история о том, как я попытался решить огромную проблему государственной системы с помощью домашнего ноутбука и нейросетей. О том, как я переоценил свои силы, недооценил масштаб задачи, но все-таки попробовал создать инструмент, который мог бы изменить работу инспектора.
Читать: https://habr.com/ru/articles/982938/
#ru
@database_design | Другие наши каналы
Как мы загрузили историю 287 валютных пар с лимитом 8 запросов в минуту
Попробуйте найти исторические курсы для пар вроде «доллар к афгани» или «евро к таджикскому сомони». Данные либо платные, либо их просто нет в виде готового датасета. Мы решили эту проблему в рамках своего проекта, хотя единственный подходящий API диктовал суровые условия: 8 запросов в минуту и 5000 дней за раз.
Получилось! Наш Python-скрипт аккуратно, чанк за чанком, собрал историю всех 287 пар за 4.5 часа, ни разу не превысив лимит. Теперь все эти данные — более миллиона строк — лежат в открытом доступе на GitHub. В статье делюсь техническими деталями, как выстроить такую загрузку, и уроками, которые мы извлекли.
Читать: https://habr.com/ru/articles/983024/
#ru
@database_design | Другие наши каналы
Попробуйте найти исторические курсы для пар вроде «доллар к афгани» или «евро к таджикскому сомони». Данные либо платные, либо их просто нет в виде готового датасета. Мы решили эту проблему в рамках своего проекта, хотя единственный подходящий API диктовал суровые условия: 8 запросов в минуту и 5000 дней за раз.
Получилось! Наш Python-скрипт аккуратно, чанк за чанком, собрал историю всех 287 пар за 4.5 часа, ни разу не превысив лимит. Теперь все эти данные — более миллиона строк — лежат в открытом доступе на GitHub. В статье делюсь техническими деталями, как выстроить такую загрузку, и уроками, которые мы извлекли.
Читать: https://habr.com/ru/articles/983024/
#ru
@database_design | Другие наши каналы
How to speed up mass data inserts in PostgreSQL when using Spring
A common task in enterprise systems is to load large volumes of data into PostgreSQL — sometimes tens or even hundreds of millions of rows. At first glance, this seems simple: just write a loop in Java and call save() for every record. But in reality, such an approach can be painfully slow. Even a perfectly tuned PostgreSQL instance won’t help if the application is sending data inefficiently.
This article explains how to significantly accelerate bulk inserts when working with PostgreSQL through Spring and Hibernate. We’ll walk through which Spring and Hibernate settings are worth enabling, why they matter, and how much performance they can actually unlock. We’ll also look at how to build your own data-insertion layer for PostgreSQL — one that lets you switch between different insertion strategies, leverage PostgreSQL’s custom capabilities, and parallelize the process. Finally, we’ll see how to integrate this layer with Spring and what real gains each approach can deliver.
Читать: https://habr.com/ru/companies/postgrespro/articles/981938/
#ru
@database_design | Другие наши каналы
A common task in enterprise systems is to load large volumes of data into PostgreSQL — sometimes tens or even hundreds of millions of rows. At first glance, this seems simple: just write a loop in Java and call save() for every record. But in reality, such an approach can be painfully slow. Even a perfectly tuned PostgreSQL instance won’t help if the application is sending data inefficiently.
This article explains how to significantly accelerate bulk inserts when working with PostgreSQL through Spring and Hibernate. We’ll walk through which Spring and Hibernate settings are worth enabling, why they matter, and how much performance they can actually unlock. We’ll also look at how to build your own data-insertion layer for PostgreSQL — one that lets you switch between different insertion strategies, leverage PostgreSQL’s custom capabilities, and parallelize the process. Finally, we’ll see how to integrate this layer with Spring and what real gains each approach can deliver.
Читать: https://habr.com/ru/companies/postgrespro/articles/981938/
#ru
@database_design | Другие наши каналы
Каким будет энтерпрайз-СУБД в эпоху ИИ
Существует опасное заблуждение, что «ванильный» Open Source — это серебряная пуля для энтерпрайза. Однако жесткий краш-тест последних лет показал: когда уходят привычные гиганты вроде Oracle, чистый Postgres превращается в тыкву под нагрузками крупного бизнеса. Руководитель отдела технического консалтинга Postgres Professional Марк Ривкин делится своим авторским видением того, почему нам приходится заново изобретать велосипеды, дописывая миллионы строк кода в ядро, и почему будущее за конвергентными системами. Дисклеймер: это частный взгляд эксперта.
Читать: https://habr.com/ru/companies/postgrespro/articles/981696/
#ru
@database_design | Другие наши каналы
Существует опасное заблуждение, что «ванильный» Open Source — это серебряная пуля для энтерпрайза. Однако жесткий краш-тест последних лет показал: когда уходят привычные гиганты вроде Oracle, чистый Postgres превращается в тыкву под нагрузками крупного бизнеса. Руководитель отдела технического консалтинга Postgres Professional Марк Ривкин делится своим авторским видением того, почему нам приходится заново изобретать велосипеды, дописывая миллионы строк кода в ядро, и почему будущее за конвергентными системами. Дисклеймер: это частный взгляд эксперта.
Читать: https://habr.com/ru/companies/postgrespro/articles/981696/
#ru
@database_design | Другие наши каналы
Инструмент перехвата медленных запросов StarRocks
Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.
Читать: https://habr.com/ru/articles/983314/
#ru
@database_design | Другие наши каналы
Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.
Читать: https://habr.com/ru/articles/983314/
#ru
@database_design | Другие наши каналы
Парсинг тарифов интернета и ТВ: Архитектура БД и бэкенд на SQL
За 5 лет работы в B2B и B2C сегментах у телеком-провайдеров я столкнулся с одной из проблем: абоненты годами сидят на архивных дорогих тарифах или пользуются услугами операторов, которые не идут на уступки, не снижают цены на тарифы, пользователи просто не знают, что в их же доме есть альтернативные провайдеры с тарифами более выгодными для них.
Я решил объединить свой опыт в телекоме с навыками в программировании. Так появилась идея по парсенгу тарифов. Цель — создать инструмент, который автоматически мониторит провайдеров, избавляя пользователей от ручного сравнения и помогая им находить оптимальные условия по тарифу.
Сейчас я работаю аналитиком БД, параллельно изучаю архитектуру, построение данных. Решил начать проект с проектирования структуру на PostgreSQL по схеме "Звезда". Таблицей фактов у меня будет таблица со связью города с провайдером, таблицы измерений – таблица с информацией о тарифах, городами и провайдерами.
Читать: https://habr.com/ru/articles/983324/
#ru
@database_design | Другие наши каналы
За 5 лет работы в B2B и B2C сегментах у телеком-провайдеров я столкнулся с одной из проблем: абоненты годами сидят на архивных дорогих тарифах или пользуются услугами операторов, которые не идут на уступки, не снижают цены на тарифы, пользователи просто не знают, что в их же доме есть альтернативные провайдеры с тарифами более выгодными для них.
Я решил объединить свой опыт в телекоме с навыками в программировании. Так появилась идея по парсенгу тарифов. Цель — создать инструмент, который автоматически мониторит провайдеров, избавляя пользователей от ручного сравнения и помогая им находить оптимальные условия по тарифу.
Сейчас я работаю аналитиком БД, параллельно изучаю архитектуру, построение данных. Решил начать проект с проектирования структуру на PostgreSQL по схеме "Звезда". Таблицей фактов у меня будет таблица со связью города с провайдером, таблицы измерений – таблица с информацией о тарифах, городами и провайдерами.
Читать: https://habr.com/ru/articles/983324/
#ru
@database_design | Другие наши каналы
Как JOIN изменил наш подход к инфраструктуре данных в NAVER
После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.
Читать: https://habr.com/ru/articles/983356/
#ru
@database_design | Другие наши каналы
После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.
Читать: https://habr.com/ru/articles/983356/
#ru
@database_design | Другие наши каналы
Изнанка бэкапов YDB: что остаётся за кадром
Решил собрать нюансы создания резервных копий и восстановления таблиц в YDB. Это не замена документации, а раскрытие деталей, которые не очевидны для тех, кто начинает работать с этой базой данных.
Читать: https://habr.com/ru/articles/983512/
#ru
@database_design | Другие наши каналы
Решил собрать нюансы создания резервных копий и восстановления таблиц в YDB. Это не замена документации, а раскрытие деталей, которые не очевидны для тех, кто начинает работать с этой базой данных.
Читать: https://habr.com/ru/articles/983512/
#ru
@database_design | Другие наши каналы
Очень странные дела или подключаем YDB в AWS NoSQL Workbench
При работе с Yandex Database (YDB) часто возникает потребность в удобном визуальном инструменте для работы с данными. AWS NoSQL Workbench — популярное приложение для моделирования и тестирования NoSQL баз можно использовать и с YDB благодаря DynamoDB-совместимому Document API.
Читать: https://habr.com/ru/articles/983678/
#ru
@database_design | Другие наши каналы
При работе с Yandex Database (YDB) часто возникает потребность в удобном визуальном инструменте для работы с данными. AWS NoSQL Workbench — популярное приложение для моделирования и тестирования NoSQL баз можно использовать и с YDB благодаря DynamoDB-совместимому Document API.
Читать: https://habr.com/ru/articles/983678/
#ru
@database_design | Другие наши каналы
Реляционные шарады: превращаем фильмы в таблицы
Реляционная модель обычно ассоциируется с аккуратными строками и столбцами, но на практике ей регулярно пытаются скормить то, для чего она будто бы не предназначена. В этой статье — эксперимент на грани здравого смысла: разложить фильм на пиксели, превратить кадры в строки и посмотреть, что получится, если к видео применить привычный SQL. Без обещаний пользы и универсальности — зато с честным разбором того, где такой подход неожиданно работает, а где начинает сопротивляться сама природа данных.
Перейти к материалу
Читать: https://habr.com/ru/companies/otus/articles/982114/
#ru
@database_design | Другие наши каналы
Реляционная модель обычно ассоциируется с аккуратными строками и столбцами, но на практике ей регулярно пытаются скормить то, для чего она будто бы не предназначена. В этой статье — эксперимент на грани здравого смысла: разложить фильм на пиксели, превратить кадры в строки и посмотреть, что получится, если к видео применить привычный SQL. Без обещаний пользы и универсальности — зато с честным разбором того, где такой подход неожиданно работает, а где начинает сопротивляться сама природа данных.
Перейти к материалу
Читать: https://habr.com/ru/companies/otus/articles/982114/
#ru
@database_design | Другие наши каналы
Создаем пет-проект по аналитике в связке с GitHub Actions. Часть 2
Привет, Хабр! Продолжаю обозревать GitHub Actions на примере пет проекта для аналитика.
Статья будет полезна начинающим аналитикам в поисках хорошего проекта для своего портфолио. В этой части разбираю подход к выбору проекта и источника данных, к сбору и анализу данных и представлении результатов своей работы.
Читать: https://habr.com/ru/articles/983926/
#ru
@database_design | Другие наши каналы
Привет, Хабр! Продолжаю обозревать GitHub Actions на примере пет проекта для аналитика.
Статья будет полезна начинающим аналитикам в поисках хорошего проекта для своего портфолио. В этой части разбираю подход к выбору проекта и источника данных, к сбору и анализу данных и представлении результатов своей работы.
Читать: https://habr.com/ru/articles/983926/
#ru
@database_design | Другие наши каналы
Объектные хранилища: чем заменить minio?
Как говорят у меня на родине: корпоративная жадность — двигатель миграций. И именно это мы сейчас можем наблюдать на примере MinIO — некогда любимого инструмента DevOps-инженеров для развёртывания S3-совместимого хранилища. В 2021 году они втихушку сменили лицензию на AGPL v3, а в 2025 году и вовсе выпилили веб-интерфейс из бесплатной версии. Ну и, наверное, можно подумать, что за такой удобный инструмент можно и заплатить. Но тогда встаёт вопрос: какова цена коммерческой лицензии? От $96 000 в год)
В этой статье мы разберём, чем можно заменить MinIO, сравним альтернативы в разных сценариях и, конечно же, развернём их руками — потому что теория без практики, как вайбкодер без гпт.
Читать: https://habr.com/ru/companies/ruvds/articles/981790/
#ru
@database_design | Другие наши каналы
Как говорят у меня на родине: корпоративная жадность — двигатель миграций. И именно это мы сейчас можем наблюдать на примере MinIO — некогда любимого инструмента DevOps-инженеров для развёртывания S3-совместимого хранилища. В 2021 году они втихушку сменили лицензию на AGPL v3, а в 2025 году и вовсе выпилили веб-интерфейс из бесплатной версии. Ну и, наверное, можно подумать, что за такой удобный инструмент можно и заплатить. Но тогда встаёт вопрос: какова цена коммерческой лицензии? От $96 000 в год)
В этой статье мы разберём, чем можно заменить MinIO, сравним альтернативы в разных сценариях и, конечно же, развернём их руками — потому что теория без практики, как вайбкодер без гпт.
Читать: https://habr.com/ru/companies/ruvds/articles/981790/
#ru
@database_design | Другие наши каналы
Если UPDATE столкнулся с заблокированной строкой
В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.
Читать: https://habr.com/ru/articles/983998/
#ru
@database_design | Другие наши каналы
В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.
Читать: https://habr.com/ru/articles/983998/
#ru
@database_design | Другие наши каналы
Дефрагментация HDD ускоряет скорость работы, но на сколько? Расчет скорости HDD в зависимости от фрагментации
Что такое фрагментация?
Фрагментация — это состояние, при котором файлы физически располагаются на разных участках диска, а не непрерывно друг за другом. Из-за этого магнитная головка вынуждена совершать лишние движения, тратя значительное время на поиск нужных участков. По мере накопления фрагментов файлов снижается общая скорость работы накопителя, ухудшается отклик системы и увеличивается износ самого устройства.
Введение процедуры дефрагментации способно кардинально изменить ситуацию. Суть дефрагментации заключается в объединении отдельных фрагментов файлов в единую область на диске, сокращая путь движения головок и уменьшая среднее время доступа к данным. Этот процесс оказывает непосредственное влияние на повышение общей производительности системы, снижение нагрузки на аппаратуру и продление срока службы HDD.Далее мы подробно изучим механизм воздействия фрагментации и дефрагментации на показатели скорости работы жесткого диска, используя конкретные расчеты и наглядные примеры.
Характеристики HDD
Основные характеристики HDD:
-Объем, Гб;
-Линейная скорость чтения/записи, Mb/s ;
-Количество оборотов диска в минуту, rpm;
-Время перехода track to track, ms.
Возьмем для моделирования HDD со следующими характеристиками
/
Читать: https://habr.com/ru/articles/984100/
#ru
@database_design | Другие наши каналы
Что такое фрагментация?
Фрагментация — это состояние, при котором файлы физически располагаются на разных участках диска, а не непрерывно друг за другом. Из-за этого магнитная головка вынуждена совершать лишние движения, тратя значительное время на поиск нужных участков. По мере накопления фрагментов файлов снижается общая скорость работы накопителя, ухудшается отклик системы и увеличивается износ самого устройства.
Введение процедуры дефрагментации способно кардинально изменить ситуацию. Суть дефрагментации заключается в объединении отдельных фрагментов файлов в единую область на диске, сокращая путь движения головок и уменьшая среднее время доступа к данным. Этот процесс оказывает непосредственное влияние на повышение общей производительности системы, снижение нагрузки на аппаратуру и продление срока службы HDD.Далее мы подробно изучим механизм воздействия фрагментации и дефрагментации на показатели скорости работы жесткого диска, используя конкретные расчеты и наглядные примеры.
Характеристики HDD
Основные характеристики HDD:
-Объем, Гб;
-Линейная скорость чтения/записи, Mb/s ;
-Количество оборотов диска в минуту, rpm;
-Время перехода track to track, ms.
Возьмем для моделирования HDD со следующими характеристиками
/
Читать: https://habr.com/ru/articles/984100/
#ru
@database_design | Другие наши каналы
Как правильно «готовить» RAG: рецепт умного ассистента для вашего отдела
Уверены, что вы уже слышали об этой технологии, но сегодня поговорим о ней с практической точки зрения. В этой статье наша Команда AI дает советы тем, кто еще не погружен в технические детали — рассказывает о сложностях, которые могут возникать при работе с этой технологией и о том, как их избегать.
Читать: https://habr.com/ru/companies/bitrix/articles/980748/
#ru
@database_design | Другие наши каналы
Уверены, что вы уже слышали об этой технологии, но сегодня поговорим о ней с практической точки зрения. В этой статье наша Команда AI дает советы тем, кто еще не погружен в технические детали — рассказывает о сложностях, которые могут возникать при работе с этой технологией и о том, как их избегать.
Читать: https://habr.com/ru/companies/bitrix/articles/980748/
#ru
@database_design | Другие наши каналы
Как DuckDB обрабатывает 1 ТБ данных менее чем за 30 секунд
Команда Python for Devs подготовила перевод статьи о том, как DuckDB ломает привычные представления о масштабах аналитических данных. Автор на реальных бенчмарках показывает, что 1 ТБ данных можно агрегировать за считанные секунды — без Spark, без распределённых кластеров и без сложной инфраструктуры.
Читать: https://habr.com/ru/articles/984040/
#ru
@database_design | Другие наши каналы
Команда Python for Devs подготовила перевод статьи о том, как DuckDB ломает привычные представления о масштабах аналитических данных. Автор на реальных бенчмарках показывает, что 1 ТБ данных можно агрегировать за считанные секунды — без Spark, без распределённых кластеров и без сложной инфраструктуры.
Читать: https://habr.com/ru/articles/984040/
#ru
@database_design | Другие наши каналы