Топ-7 самых тупых хакерских атак в истории
Самые нелепые хакерские атаки в истории. Взлом через аквариум, звуковая атака ядерного объекта, загрузка отпечатков в систему и другие атаки. Ошибки и просчеты хакеров.
Читать: «Топ-7 самых тупых хакерских атак в истории»
#ru
@database_design | Другие наши каналы
Самые нелепые хакерские атаки в истории. Взлом через аквариум, звуковая атака ядерного объекта, загрузка отпечатков в систему и другие атаки. Ошибки и просчеты хакеров.
Читать: «Топ-7 самых тупых хакерских атак в истории»
#ru
@database_design | Другие наши каналы
Данные на продажу: что происходит с информацией после утечек
Новости о крупных утечках данных больше никого не удивляют. Компании вкладывают миллионы в безопасность, проводят аудиты, но число таких инцидентов продолжает расти. Только в 2024 году Роскомнадзор зафиксировал 135 утечек — это более 710 миллионов записей о россиянах в базах данных. Но что происходит с данными после взлома? Куда они утекают? Кто и как их покупает?
Большинство новостей на тему утечек ограничиваются банальным «взломали, утекло, делайте выводы». Но утечка данных — это не конец истории, а только ее начало. После взлома данные начинают жить своей жизнью: их разбивают на части, объединяют с другими базами, разыгрывают на аукционах. Теневой рынок, построенный вокруг сбыта таких данных, напоминает отдельную экосистему, которая до сих пор слабо изучена даже среди ИБ-специалистов.
В этой статье разберем, как на практике выглядит жизненный цикл украденных данных. Представьте: вы — опытный специалист по киберразведке, помогающий компаниям справляться с последствиями утечек. Ранним июньским утром вас будит внезапный телефонный звонок. На другом конце провода — гендиректор ООО «Нас никогда не взломают». Судя по голосу, он явно встревожен...
Читать: https://habr.com/ru/companies/bastion/articles/915892/
#ru
@database_design | Другие наши каналы
Новости о крупных утечках данных больше никого не удивляют. Компании вкладывают миллионы в безопасность, проводят аудиты, но число таких инцидентов продолжает расти. Только в 2024 году Роскомнадзор зафиксировал 135 утечек — это более 710 миллионов записей о россиянах в базах данных. Но что происходит с данными после взлома? Куда они утекают? Кто и как их покупает?
Большинство новостей на тему утечек ограничиваются банальным «взломали, утекло, делайте выводы». Но утечка данных — это не конец истории, а только ее начало. После взлома данные начинают жить своей жизнью: их разбивают на части, объединяют с другими базами, разыгрывают на аукционах. Теневой рынок, построенный вокруг сбыта таких данных, напоминает отдельную экосистему, которая до сих пор слабо изучена даже среди ИБ-специалистов.
В этой статье разберем, как на практике выглядит жизненный цикл украденных данных. Представьте: вы — опытный специалист по киберразведке, помогающий компаниям справляться с последствиями утечек. Ранним июньским утром вас будит внезапный телефонный звонок. На другом конце провода — гендиректор ООО «Нас никогда не взломают». Судя по голосу, он явно встревожен...
Читать: https://habr.com/ru/companies/bastion/articles/915892/
#ru
@database_design | Другие наши каналы
🕊1
Пятый, юбилейный выпуск исследования «BI-круг Громова»
Пятый, юбилейный выпуск нашего исследования «Круги Громова» выходит в момент, когда рынок отечественных BI-платформ переживает волну бурного роста и трансформации. За два года, прошедшие с публикации предыдущего отчёта, импортозамещение перестало быть формальностью и стало стратегической необходимостью: доля внедрений российских BI-систем выросла почти в восемь раз, а зарубежных — упала до 23 %[1]. На этом фоне особенно важны объективные ориентиры, позволяющие ИТ-директорам и бизнес-пользователям выбрать платформу, которая останется актуальной на ближайшие несколько лет. Именно такую навигационную карту мы и предлагаем.
Читать: https://habr.com/ru/articles/915906/
#ru
@database_design | Другие наши каналы
Пятый, юбилейный выпуск нашего исследования «Круги Громова» выходит в момент, когда рынок отечественных BI-платформ переживает волну бурного роста и трансформации. За два года, прошедшие с публикации предыдущего отчёта, импортозамещение перестало быть формальностью и стало стратегической необходимостью: доля внедрений российских BI-систем выросла почти в восемь раз, а зарубежных — упала до 23 %[1]. На этом фоне особенно важны объективные ориентиры, позволяющие ИТ-директорам и бизнес-пользователям выбрать платформу, которая останется актуальной на ближайшие несколько лет. Именно такую навигационную карту мы и предлагаем.
Читать: https://habr.com/ru/articles/915906/
#ru
@database_design | Другие наши каналы
Что стоит знать перед тем, как стать архитектором решений? В статье на MongoDB Blog опытный специалист делится важными уроками: влияние строится на понимании клиентов, успех зависит от командной работы и умения слушать. Роль постоянно развивается, главное – быть готовым учиться и адаптироваться. Luna AI трансформировалась в продвинутую платформу для стратегического управления продуктами с глубокой интеграцией Jira и мощными AI-модулями. Основу системы составляет MongoDB Atlas, обеспечивающий гибкость, масштабируемость и безопасность данных.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
Как с помощью RuBackup сделать резервное копирование систем виртуализации oVirt, ROSA, zVirt, РЕД Виртуализация, HOSTVM
Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах.
Для этого будем использовать систему резервного копирования (СРК) RuBackup.
Читать: https://habr.com/ru/companies/astralinux/articles/916004/
#ru
@database_design | Другие наши каналы
Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах.
Для этого будем использовать систему резервного копирования (СРК) RuBackup.
Читать: https://habr.com/ru/companies/astralinux/articles/916004/
#ru
@database_design | Другие наши каналы
❤1
Приоткрываем завесу: о принципах работы дисковых хранилищ VK Cloud
Инфраструктурный слой большинства облачных платформ — та часть айсберга, которая остается глубоко под водой и никогда не видна простым обывателям. Вместе с тем именно IaaS-сервисы в целом и дисковые хранилища в частности являются основой для построения пользователями своих инфраструктур в облаке.
Привет, Хабр. Меня зовут Василий Степанов. Я руководитель команды разработки Storage в VK Cloud. В этой статье я расскажу о том, как устроено наше дисковое хранилище: какие диски используются в VK Cloud и как мы с ними работаем.
Читать: https://habr.com/ru/companies/vktech/articles/916036/
#ru
@database_design | Другие наши каналы
Инфраструктурный слой большинства облачных платформ — та часть айсберга, которая остается глубоко под водой и никогда не видна простым обывателям. Вместе с тем именно IaaS-сервисы в целом и дисковые хранилища в частности являются основой для построения пользователями своих инфраструктур в облаке.
Привет, Хабр. Меня зовут Василий Степанов. Я руководитель команды разработки Storage в VK Cloud. В этой статье я расскажу о том, как устроено наше дисковое хранилище: какие диски используются в VK Cloud и как мы с ними работаем.
Читать: https://habr.com/ru/companies/vktech/articles/916036/
#ru
@database_design | Другие наши каналы
Нашел, проверил, убедил: как мы организовали генерацию SQL-запросов, проверку сложных данных и при чем здесь Allure
Привет, Хабр!
Я, Михаил Герасимов, инженер РСХБ-Интех. Уже два года занимаюсь автоматизацией тестирования, и за это время успел написать (и переписать) немало SQL-запросов. Вместе с моим коллегой Михаилом Палыгой мы развиваем инструменты для автоматизированного тестирования, и сегодня расскажем вам о том как мы справляемся с построением сложных SQL-запросов и проверкой объектов в базе данных, на примере нашей библиотеки CheckMateDB для автоматизации тестирования банковской системы ЦФТ-Банк.
В статье опишем проблемы, с которыми сталкивались при ручном написании SQL-запросов и проверке данных: дублирование кода, сложность поддержки, отсутствие единого стиля и низкая информативность тестов. Для решения этих проблем мы разработали инструмент QueryBuilder, который позволяет динамически генерировать SQL-запросы с помощью Java-кода.
Мы создали иерархию классов CriteriaBasic и Table для удобного описания критериев поиска данных в базе, используя паттерн fluent interface. Также мы разработали кастомные классы проверок на базе AssertJ с поддержкой Allure-шагов, которые позволяют проверять сложные многоуровневые объекты с возможностью погружения во вложенные структуры. Для облегчения рутинной работы создали плагин, автоматически генерирующий классы DTO и Table на основе структуры базы данных. Библиотека интегрирована с Hibernate через DaoCommon, что обеспечивает удобное выполнение SQL-запросов и управление сессиями. Результатом стало существенное улучшение читаемости тестов, повышение переиспользуемости кода, стандартизация подхода к тестированию и создание информативных Allure-отчетов.
Читать: https://habr.com/ru/companies/rshb/articles/916148/
#ru
@database_design | Другие наши каналы
Привет, Хабр!
Я, Михаил Герасимов, инженер РСХБ-Интех. Уже два года занимаюсь автоматизацией тестирования, и за это время успел написать (и переписать) немало SQL-запросов. Вместе с моим коллегой Михаилом Палыгой мы развиваем инструменты для автоматизированного тестирования, и сегодня расскажем вам о том как мы справляемся с построением сложных SQL-запросов и проверкой объектов в базе данных, на примере нашей библиотеки CheckMateDB для автоматизации тестирования банковской системы ЦФТ-Банк.
В статье опишем проблемы, с которыми сталкивались при ручном написании SQL-запросов и проверке данных: дублирование кода, сложность поддержки, отсутствие единого стиля и низкая информативность тестов. Для решения этих проблем мы разработали инструмент QueryBuilder, который позволяет динамически генерировать SQL-запросы с помощью Java-кода.
Мы создали иерархию классов CriteriaBasic и Table для удобного описания критериев поиска данных в базе, используя паттерн fluent interface. Также мы разработали кастомные классы проверок на базе AssertJ с поддержкой Allure-шагов, которые позволяют проверять сложные многоуровневые объекты с возможностью погружения во вложенные структуры. Для облегчения рутинной работы создали плагин, автоматически генерирующий классы DTO и Table на основе структуры базы данных. Библиотека интегрирована с Hibernate через DaoCommon, что обеспечивает удобное выполнение SQL-запросов и управление сессиями. Результатом стало существенное улучшение читаемости тестов, повышение переиспользуемости кода, стандартизация подхода к тестированию и создание информативных Allure-отчетов.
Читать: https://habr.com/ru/companies/rshb/articles/916148/
#ru
@database_design | Другие наши каналы
Как разработать простое приложение и тратить на него 2000$ в месяц
Разработчик показывает, как из простого приложения сделать дорогостоящее — за счет трат на сервера, инфраструктуру и многое другое.
Читать: «Как разработать простое приложение и тратить на него 2000$ в месяц»
#ru
@database_design | Другие наши каналы
Разработчик показывает, как из простого приложения сделать дорогостоящее — за счет трат на сервера, инфраструктуру и многое другое.
Читать: «Как разработать простое приложение и тратить на него 2000$ в месяц»
#ru
@database_design | Другие наши каналы
Внутристраничная очистка в индексах PostgreSQL
Внутристраничная очистка (HOT cleanup) – это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.
Читать: https://habr.com/ru/companies/tantor/articles/916318/
#ru
@database_design | Другие наши каналы
Внутристраничная очистка (HOT cleanup) – это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.
Читать: https://habr.com/ru/companies/tantor/articles/916318/
#ru
@database_design | Другие наши каналы
Шардирование баз данных: проблемы, альтернативы, практические рекомендации
Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.
Читать: https://habr.com/ru/articles/916394/
#ru
@database_design | Другие наши каналы
Данных в современных приложениях становится все больше, прямо как снежный ком. И рано или поздно многие системы начинают задыхаться – база данных не справляется. Когда старые добрые методы вроде подкрутки запросов, добавления индексов или покупки сервера помощнее уже не помогают (или стоят как крыло от самолета), на помощь приходит горизонтальное масштабирование.
Читать: https://habr.com/ru/articles/916394/
#ru
@database_design | Другие наши каналы
MySQL репликация: проблемы, решения, практические рекомендации
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
Читать: https://habr.com/ru/articles/907876/
#ru
@database_design | Другие наши каналы
Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.
Читать: https://habr.com/ru/articles/907876/
#ru
@database_design | Другие наши каналы
«Попал в Яндекс через опенсорс»: как коммиты в опенсорсные СУБД помогают развивать продукт и команду
Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.
Но из этих историй часто ускользает человеческая сторона: мы занимаемся опенсорсом не только для того, чтобы сделать решения с открытым кодом более облачными, не только потому, что это модно, но и потому, что это приносит пользу не только продукту, но и самим разработчикам‑контрибьюторам.
На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).
В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.
Читать: https://habr.com/ru/companies/yandex/articles/916800/
#ru
@database_design | Другие наши каналы
Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.
Но из этих историй часто ускользает человеческая сторона: мы занимаемся опенсорсом не только для того, чтобы сделать решения с открытым кодом более облачными, не только потому, что это модно, но и потому, что это приносит пользу не только продукту, но и самим разработчикам‑контрибьюторам.
На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).
В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.
Читать: https://habr.com/ru/companies/yandex/articles/916800/
#ru
@database_design | Другие наши каналы
Книга: «Масштабируемые данные. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд.»
Привет, Хаброжители!
Издательство Sprint book представляет второе издание книги Питхейна Стренгхольта «Масштабируемые данные» — фундаментальное руководство по построению современных архитектур данных в эпоху цифровой трансформации.
Время централизованного хранения информации, например, в хранилищах данных (data warehouse) уходит в прошлое. Сегодня компании сталкиваются с необходимостью обрабатывать огромные объемы информации в реальном времени, обеспечивая при этом гибкость, безопасность и согласованность данных. Датафикация происходит повсюду: в смартфонах, телевизорах, электронных книгах, промышленных машинах, автомобилях с автопилотами, роботах и т. д. Она стремительно меняет нашу жизнь. А темы, заложенные в книге Стренгхольта, становятся новым стандартом для организаций, стремящихся построить гибкую, безопасную и ориентированную на бизнес-ценности инфраструктуру данных.
Читать: https://habr.com/ru/companies/piter/articles/905540/
#ru
@database_design | Другие наши каналы
Привет, Хаброжители!
Издательство Sprint book представляет второе издание книги Питхейна Стренгхольта «Масштабируемые данные» — фундаментальное руководство по построению современных архитектур данных в эпоху цифровой трансформации.
Время централизованного хранения информации, например, в хранилищах данных (data warehouse) уходит в прошлое. Сегодня компании сталкиваются с необходимостью обрабатывать огромные объемы информации в реальном времени, обеспечивая при этом гибкость, безопасность и согласованность данных. Датафикация происходит повсюду: в смартфонах, телевизорах, электронных книгах, промышленных машинах, автомобилях с автопилотами, роботах и т. д. Она стремительно меняет нашу жизнь. А темы, заложенные в книге Стренгхольта, становятся новым стандартом для организаций, стремящихся построить гибкую, безопасную и ориентированную на бизнес-ценности инфраструктуру данных.
Читать: https://habr.com/ru/companies/piter/articles/905540/
#ru
@database_design | Другие наши каналы
Резервуарное сэмплирование и собачки
Резервуарное сэмплирование — это методика выбора справедливого случайного образца, когда неизвестен размер множества, из которого выполняется выборка. К концу этой статьи вы будете знать:
• Когда может потребоваться резервуарное сэмплирование.
• Математика его работы на основании лишь базовых операций: вычитания, умножения, умножения и деления. Никаких сложных математических формул, обещаю.
• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.
Читать: https://habr.com/ru/companies/ruvds/articles/916250/
#ru
@database_design | Другие наши каналы
Резервуарное сэмплирование — это методика выбора справедливого случайного образца, когда неизвестен размер множества, из которого выполняется выборка. К концу этой статьи вы будете знать:
• Когда может потребоваться резервуарное сэмплирование.
• Математика его работы на основании лишь базовых операций: вычитания, умножения, умножения и деления. Никаких сложных математических формул, обещаю.
• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.
Читать: https://habr.com/ru/companies/ruvds/articles/916250/
#ru
@database_design | Другие наши каналы
Рекомендации Oracle по выбору между ArrayList и LinkedList
В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.
Читать: https://habr.com/ru/articles/912632/
#ru
@database_design | Другие наши каналы
В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.
Читать: https://habr.com/ru/articles/912632/
#ru
@database_design | Другие наши каналы
Новые возможности наблюдаемости ИИ с MongoDB и Langtrace
Langtrace AI совместно с MongoDB улучшает мониторинг и оптимизацию приложений на базе ИИ. Их интеграция обеспечивает глубокий анализ производительности моделей и эффективное управление данными, что повышает точность и масштабируемость решений. Путь архитектора решений в MongoDB: важнее технических знаний — понимание бизнес-задач и умение слушать клиента. Успех строится на эмпатии, командной работе и способности адаптироваться в быстро меняющемся мире технологий. Архитектура — это не просто схемы, а реальные решения для людей.
Читать подробнее
#en
@database_design | Другие наши каналы
Langtrace AI совместно с MongoDB улучшает мониторинг и оптимизацию приложений на базе ИИ. Их интеграция обеспечивает глубокий анализ производительности моделей и эффективное управление данными, что повышает точность и масштабируемость решений. Путь архитектора решений в MongoDB: важнее технических знаний — понимание бизнес-задач и умение слушать клиента. Успех строится на эмпатии, командной работе и способности адаптироваться в быстро меняющемся мире технологий. Архитектура — это не просто схемы, а реальные решения для людей.
Читать подробнее
#en
@database_design | Другие наши каналы
Как мы снизили время создания бэкапов Git с 48 часов до 41 минут
В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.
Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.
В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.
Оказалось, что это проблема масштабируемости Git, влияла на всех его пользователей с крупными репозиториями. Ниже мы расскажем историю о том, как выявили и устранили проблему.
Читать: https://habr.com/ru/articles/917018/
#ru
@database_design | Другие наши каналы
В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.
Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.
В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.
Оказалось, что это проблема масштабируемости Git, влияла на всех его пользователей с крупными репозиториями. Ниже мы расскажем историю о том, как выявили и устранили проблему.
Читать: https://habr.com/ru/articles/917018/
#ru
@database_design | Другие наши каналы
Оптимизация векторного поиска с MongoDB и Voyage AI
MongoDB Atlas и Voyage AI внедряют автоматическую квантование эмбеддингов, ускоряя поиск и снижая требования к памяти без потери качества. Это улучшение масштабируется для миллионов векторов и подходит для больших AI-приложений.
Читать подробнее
#en
@database_design | Другие наши каналы
MongoDB Atlas и Voyage AI внедряют автоматическую квантование эмбеддингов, ускоряя поиск и снижая требования к памяти без потери качества. Это улучшение масштабируется для миллионов векторов и подходит для больших AI-приложений.
Читать подробнее
#en
@database_design | Другие наши каналы
Работа аналитиком данных: задачи, зарплата, плюсы, минусы и где учиться — в 2025
Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма.
Аналитика данных — одна самых востребованных специализаций сегодня, особенно в России, где цифровизация бизнеса идет полным ходом. Если задумываетесь о карьере в этой сфере, но не знаете, с чего начать — эта статья для вас.
Ниже разбираем, кто такой аналитик данных, чем он занимается, какие плюсы и минусы есть в этой профессии, сколько можно зарабатывать в России в 2025 году, а еще где найти бесплатное и платное обучение для старта.
Читать: https://habr.com/ru/companies/habr_career/articles/917314/
#ru
@database_design | Другие наши каналы
Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма.
Аналитика данных — одна самых востребованных специализаций сегодня, особенно в России, где цифровизация бизнеса идет полным ходом. Если задумываетесь о карьере в этой сфере, но не знаете, с чего начать — эта статья для вас.
Ниже разбираем, кто такой аналитик данных, чем он занимается, какие плюсы и минусы есть в этой профессии, сколько можно зарабатывать в России в 2025 году, а еще где найти бесплатное и платное обучение для старта.
Читать: https://habr.com/ru/companies/habr_career/articles/917314/
#ru
@database_design | Другие наши каналы
Влияние маленьких файлов на Big Data: HDFS vs S3
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.
Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).
Тесты, графики, инсайды
Читать: https://habr.com/ru/companies/arenadata/articles/915684/
#ru
@database_design | Другие наши каналы
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.
Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).
Тесты, графики, инсайды
Читать: https://habr.com/ru/companies/arenadata/articles/915684/
#ru
@database_design | Другие наши каналы
Смотрим под капот объектному хранилищу VK Cloud: что скрывает архитектура Object Storage
Современные компании оперируют терабайтами или даже петабайтами данных. Но часто эти данные имеют разный формат, степень структурированности и не нужны в «горячем» доступе, поэтому зачастую хранить весь массив в традиционных БД не только невозможно, но и нерационально. Как результат, бизнес все чаще использует объектные S3-хранилища.
Меня зовут Андрей Капустин. Я менеджер продукта Tarantool в компании VK Tech. В этой статье я расскажу об объектном хранилище VK Cloud, его архитектуре и месте Tarantool в ней.
Читать: https://habr.com/ru/companies/vktech/articles/917190/
#ru
@database_design | Другие наши каналы
Современные компании оперируют терабайтами или даже петабайтами данных. Но часто эти данные имеют разный формат, степень структурированности и не нужны в «горячем» доступе, поэтому зачастую хранить весь массив в традиционных БД не только невозможно, но и нерационально. Как результат, бизнес все чаще использует объектные S3-хранилища.
Меня зовут Андрей Капустин. Я менеджер продукта Tarantool в компании VK Tech. В этой статье я расскажу об объектном хранилище VK Cloud, его архитектуре и месте Tarantool в ней.
Читать: https://habr.com/ru/companies/vktech/articles/917190/
#ru
@database_design | Другие наши каналы