В этой статье я хочу поделиться своим стыдом, вызванным попыткой создания библиотеки поиска. В этом стыде и вы можете прочувствовать смирение и осознание того, что реальный качественный поисковый движок, а не создаваемый как хобби-проект, должен делаться для того, чтобы лексический поиск был быстрым.
BEIR — это бенчмарки поиска информации, ориентированные на сценарии использования в формате «вопрос-ответ».
Мой хобби-проект SearchArray добавляет в Pandas полнотекстовый поиск. Поэтому естественно, чтобы ощутить трепет от моих потрясающих навыков разработчика, я решил использовать BEIR для сравнения SearchArray с Elasticsearch (с тем же запросом + токенизацией). Поэтому я потратил субботу на интеграцию SearchArray в BEIR и измерение релевантности и производительности с корпусом MSMarco Passage Retrieval (8 миллионов документов).
Барабанная дробь...
Современные компании оперируют терабайтами или даже петабайтами данных. Но часто эти данные имеют разный формат, степень структурированности и не нужны в «горячем» доступе, поэтому зачастую хранить весь массив в традиционных БД не только невозможно, но и нерационально. Как результат, бизнес все чаще использует объектные S3-хранилища.
Меня зовут Андрей Капустин. Я менеджер продукта Tarantool в компании VK Tech. В этой статье я расскажу об объектном хранилище VK Cloud, его архитектуре и месте Tarantool в ней.
В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.
Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.
В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.
Оказалось, что это проблема масштабируемости Git, влияла на всех его пользователей с крупными репозиториями. Ниже мы расскажем историю о том, как выявили и устранили проблему.
В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.
Резервуарное сэмплирование — это методика выбора справедливого случайного образца, когда неизвестен размер множества, из которого выполняется выборка. К концу этой статьи вы будете знать:
• Когда может потребоваться резервуарное сэмплирование.
• Математика его работы на основании лишь базовых операций: вычитания, умножения, умножения и деления. Никаких сложных математических формул, обещаю.
• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.
Привет, Хаброжители!
Инфраструктурный слой большинства облачных платформ — та часть айсберга, которая остается глубоко под водой и никогда не видна простым обывателям. Вместе с тем именно IaaS-сервисы в целом и дисковые хранилища в частности являются основой для построения пользователями своих инфраструктур в облаке.
Привет, Хабр. Меня зовут Василий Степанов. Я руководитель команды разработки Storage в VK Cloud. В этой статье я расскажу о том, как устроено наше дисковое хранилище: какие диски используются в VK Cloud и как мы с ними работаем.
Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах.
Для этого будем использовать систему резервного копирования (СРК) RuBackup.
Пятый, юбилейный выпуск нашего исследования «Круги Громова» выходит в момент, когда рынок отечественных BI-платформ переживает волну бурного роста и трансформации. За два года, прошедшие с публикации предыдущего отчёта, импортозамещение перестало быть формальностью и стало стратегической необходимостью: доля внедрений российских BI-систем выросла почти в восемь раз, а зарубежных — упала до 23 %[1]. На этом фоне особенно важны объективные ориентиры, позволяющие ИТ-директорам и бизнес-пользователям выбрать платформу, которая останется актуальной на ближайшие несколько лет. Именно такую навигационную карту мы и предлагаем.
Новости о крупных утечках данных больше никого не удивляют. Компании вкладывают миллионы в безопасность, проводят аудиты, но число таких инцидентов продолжает расти. Только в 2024 году Роскомнадзор зафиксировал 135 утечек — это более 710 миллионов записей о россиянах в базах данных. Но что происходит с данными после взлома? Куда они утекают? Кто и как их покупает?
Большинство новостей на тему утечек ограничиваются банальным «взломали, утекло, делайте выводы». Но утечка данных — это не конец истории, а только ее начало. После взлома данные начинают жить своей жизнью: их разбивают на части, объединяют с другими базами, разыгрывают на аукционах. Теневой рынок, построенный вокруг сбыта таких данных, напоминает отдельную экосистему, которая до сих пор слабо изучена даже среди ИБ-специалистов.
В этой статье разберем, как на практике выглядит жизненный цикл украденных данных. Представьте: вы — опытный специалист по киберразведке, помогающий компаниям справляться с последствиями утечек. Ранним июньским утром вас будит внезапный телефонный звонок. На другом конце провода — гендиректор ООО «Нас никогда не взломают». Судя по голосу, он явно встревожен...
Привет! Я Ангелина Сулерова, работаю аналитиком и с недавнего времени пишу тексты для FemTech Force . Это моя первая статья на Хабре, которая затронет одну из важных тем в сфере фемтех — безопасность данных.
Правда ли, что женские данные нужно хранить надёжнее, чем мужские? Что будет, если этого не делать? Какие фемтех-приложения уделяют особое внимание вопросам обеспечения безопасности? Обо всём этом расскажу в своем личном исследовании.
Неважно, новичок вы в этой области, просто интересующийся или активная пользовательница фемтех-продуктов — добро пожаловать под кат!
Кстати, рассказывать буду не только я. Специально для статьи взяла комментарий у Кати Меркуловой — основательницы крупнейшего российского трекера цикла Clatch. Так что забегайте за инсайдерской информацией.
Вы знаете, что такое прогрессивный JPEG? Можете почитать хорошее объяснение. Идея заключается в том, что вместо загрузки изображения сверху вниз оно сначала грузится размытым, а потом постепенно становится чётче.
Что, если мы применим тот же принцип к передаче JSON?
В современном мире мы ежедневно сталкиваемся с потоком информации: ссылки, фото, видео, документы — всё это быстро накапливается и теряется в хаосе закладок, медиатеки или чатов. Я устал от этой проблемы и решил её раз и навсегда, создав Telegram-бота Favie. Это инструмент, который упрощает хранение данных, предлагает умный поиск по тегам и работает на любом устройстве, и в этой статье я расскажу о нём и как он появился.
Статья рассказывает о том, как облачное объектное хранилище S3 можно интегрировать с Kubernetes с помощью решений от Deckhouse и файловой системы GeeseFS. Автор объясняет, зачем вообще подключать S3 как том для контейнерных приложений, какие задачи это решает и почему для этого выбран именно GeeseFS. А ещё честно указывает на подводные камни — ограничения по скорости, отсутствие привычных файловых атрибутов, особенности кэширования и диагностику.
Сегодня VK — это технологическая компания с комплексом цифровых продуктов и сервисов, объединяющая десятки миллионов пользователей с разными интересами. Среди наших сервисов — ВКонтакте, VK Видео, VK Музыка, Одноклассники, Дзен, RuStore, Почта Mail, а также игровые, образовательные и облачные платформы. Каждый продукт генерирует огромные объёмы контента: видео, статьи, приложения, почтовый трафик, стримы и многое другое.
По мере роста компании и появления новых направлений для каждого крупного продукта мы создавали собственные решения по доставке контента. В итоге внутри VK возникла россыпь частных CDN, что осложняло развитие и сопровождение инфраструктуры. В 2024 году мы решили изменить подход и сделали первые шаги к созданию единой CDN для всей VK. Это инфраструктура, которая сможет эффективно обслуживать все наши сервисы и миллионы пользователей по всей стране.
Меня зовут Андрей Старченков, я руковожу командой разработки единой CDN в VK. В этой статье расскажу, как мы подошли к проектированию единой CDN-инфраструктуры, какие технологии и архитектурные решения используем и с какими вызовами сталкиваемся на этом пути.
Мой фотоархив к 2025 году превратился в настоящую головоломку. 40 тысяч снимков были разбросаны по трём внешним дискам, трём облачным хранилищам и давно забытым папкам на старом ноутбуке. Проблема усугублялась тем, что устройств стало больше, и каждый – смартфон, фотоаппарат, дрон, добавляют горы файлов в разных форматах и с противоречивыми метаданными. Например, геотеги из отпуска в Турции показывали координаты с ошибкой в 200 метров, а даты в EXIF не совпадали с реальными из-за смены часовых поясов.
С масштабом проблемы я впервые столкнулся, когда попытался найти фотографии с первого дня школы сына. Вместо нужных кадров с линейки обнаружил огромное количество странных снимков – с размытыми лицами, случайные скриншоты с сайтов и мессенджеров, даже фото чужой собаки. Весь этот хлам незаметно копился годами, растворяясь между нормальными фотографиями. Знакомая ситуация?
В тот момент я понял — нужна система, которая работает в реалиях 2025 года, где объёмы данных уже достигают гигантских размеров, а ручная сортировка вряд ли поможет расчистить эти «Авгиевы конюшни». Ведь это тысячи фото, сваленных в множество самых разных папок на разных устройствах, многие из которых даже толком не подписаны. Здесь, наверное, вы заглянули в свой фотоархив и тоже ужаснулись.
Ссылки, скриншоты, статьи, заметки на ходу, важные сообщения — всё это появляется спонтанно, быстро, в разных местах. А потом так же быстро теряется. Закладки, «Избранное» в Telegram, «Посмотреть позже» — удобны в моменте, но со временем превращаются в захламлённые корзины. И главное — всё это разбросано по разным сервисам.
Я искал инструмент, который позволял бы мне фиксировать все интересное быстро, удобно и централизованно. И таким инструментом стал Google Keep — инбокс, точка входа для всего. Расскажу, почему выбрал именного его и как сделал интеграцию с Telegram.
Обмен данными между компаниями-партнерами при реализации совместных проектов — стандартная практика. Но часто есть сценарии, которые требуют особого подхода — например, из-за необходимости подстраивать формат отображения данных под специфику работы с информацией на стороне партнера. Более специфической такая задача становится, если готовых решений под такие запросы нет. С подобной ситуацией сталкивались и мы в VK.
Меня зовут Елена Климанова. Я ведущий дата-аналитик в компании VK. В этой статье расскажу, как и почему мы прошли путь от использования excel-файлов при работе с внешними партнерами-вендорами до создания собственного продукта.
