Новости и разборы
Сканы на 70 страниц и фото машины со всех сторон: диск, объектное хранилище или Drive
Cloudflare переделала выдачу больших файлов, Fly.io сменила файловую систему, EchoFile связывает Drive и SharePoint. Где я храню сканы, фото и скриншоты заказчиков.
Cloudflare переделала кеширование частичных запросов к большим файлам, Fly.io рассказала, как её самодельная файловая система поверх объектного хранилища теряла данные, а стартап EchoFile запускает пилот по переносу файлов между Google Drive, Dropbox и SharePoint. Для владельца бизнеса за всем этим один вопрос: где должны лежать сканы, фото и PDF, которых у компании становится больше каждый день, и кто за них отвечает.
Что вышло
Cloudflare 23 октября открыла Origin Range Requests на всех тарифах. Range-запрос это когда плеер или менеджер загрузок просит кусок файла, байты с такого-то по такой-то, и сервер отвечает 206 Partial Content. Раньше Cloudflare резала файл на диапазоны фиксированного размера, заданного в настройках зоны, и запрос на несколько мегабайт мог заставить её вытянуть с origin 128 МиБ. После переезда кеша на Pingora диапазоны совпали с чанками, которыми кеш и так хранит файлы на диске, и настраивать стало нечего. Для их хранилища R2 p99 времени до первого байта упал примерно вдвое, трафик между уровнями кеша сократился примерно на 6 %. Включается одним Cache Rule.
Fly.io 22 октября описала замену файловой системы для своих Sprites. Корень диска у них по-прежнему объектное хранилище, чтобы машина могла уснуть и проснуться на другом сервере. Но объектное хранилище не умеет менять часть объекта, а Linux-программы переписывают байты в середине файла постоянно. На старте это делал переделанный JuiceFS с метаданными в SQLite и образом диска на 100 ГБ с ext4 внутри. В writeback-режиме он сначала записывал метаданные, потом выгружал чанк; если машину убивали между этими шагами, метаданные указывали на чанк, которого нет, ext4 уходила в read-only, а чекпоинты не спасали, потому что делили те же чанки. Они прогнали 400 машин примерно через 5000 циклов записи и восстановления, часть навсегда потеряла возможность делать чекпоинты, и систему заменили на Sprites Block Device.
CustomerThink 18 октября написал про пилот EchoFile: коннектор, который переносит файлы между Google Drive, Dropbox и Microsoft SharePoint, не заставляя скачивать, перепаковывать и заливать заново. Основательница Lauren Spivey Smith называет его трубой между двумя системами; участников пилота набирают.
Зачем это бизнесу
Возьмём прокат автомобилей. При каждой выдаче и приёмке машину фотографируют со всех сторон, восемь-десять снимков с телефона. Двадцать выдач в неделю, и за год набираются тысячи фото. Если класть их в базу данных, база раздувается и копии становятся тяжёлыми. Если на диск сервера, диск заканчивается в самый неподходящий момент. Если в общий Google Drive, через год никто не найдёт фото конкретной выдачи.
Вывод: у файла должно быть три свойства, записанные заранее. Где он лежит, кто имеет к нему доступ и когда его можно удалить. База хранит ссылку и эти три ответа, а сами байты живут там, где они дешевле и надёжнее: в объектном хранилище, на диске или в Drive, в зависимости от того, кто ими потом пользуется. История Fly.io про то же: когда метаданные и байты лежат раздельно, за их согласованность отвечаете вы.
Как это устроено у меня
В PDR-компании в США, где я работаю с 2021 года, входящие страховые документы бывают до 60–70 страниц, а приходят как PDF, скан или фото с телефона. Их читают мои парсеры на Python, фото-парсеры распознают VIN. Сейчас около 99,9 % документов проходят без ручной правки, и это освобождает около 60 часов работы в неделю. PDF в обратную сторону, акты, сметы и счета, я генерирую на Puppeteer.
В сервисе «Кофе вместе», который я сделал в сентябре и октябре 2026 года, сотрудники прикладывают скриншоты оплат. Лежат они в приватном bucket Yandex Object Storage и открываются только через gateway на Node.js, напрямую их не получить. Сервер общий, с 2 ГБ памяти, у контейнеров жёсткие лимиты, и файлы живут снаружи.
Для консалтинговой компании в Лондоне в 2023–2024 годах я делал Quote Finder: Puppeteer и headless Chrome открывали статью, подсвечивали цитату и снимали скриншот и видео. Готовые файлы уходили в Google Drive, потому что дальше с ними работали люди. У той же компании система субтитров брала видео из папки Google Drive, а временные файлы после загрузки удаляла.
В прокате в Кейптауне фото машины со всех сторон загружаются при осмотре и видны в бронировании, а платёж проверяется по скриншоту. Это проверка по изображению; с банком ничего не сверяется, и я об этом говорю прямо.
Origin Range Requests и блочное устройство Fly.io у себя я не проверял. Но принцип «база хранит ссылку, байты лежат отдельно» у меня во всех этих проектах.
Что я бы сделал
Посчитать, сколько файлов появляется в неделю и сколько они весят. Без этой цифры разговор о хранилище не имеет смысла.
Разделить файлы по тому, кто ими пользуется. Программы читают из объектного хранилища или с диска по ссылке из базы. Люди работают в Drive или SharePoint, и туда файл попадает копией или ссылкой.
Записать срок жизни. Скриншот оплаты можно удалить через год, акт с подписью хранится столько, сколько требует закон, временный файл обработки удаляется сразу.
Закрыть прямой доступ. Файлы из приватного хранилища отдаются только через ваш сервер, который проверяет, кому можно.
Проверить, что копия базы и копия файлов делаются вместе, иначе после восстановления ссылки укажут в пустоту.
Как я проверяю результат распознавания и когда передаю решение человеку, я писал в статье AI в обработке данных: извлечение и проверка. Направления: обработка документов и данных на Python и инфраструктура, которую можно выпускать и восстанавливать. Кейсы: парсеры документов и фото с VIN, прокат в ЮАР с осмотром машин и Quote Finder. По той же теме: бэкап, который никто не восстанавливал и извлечение данных из документов в 2026 году. Раньше я писал про поиск по PDF с таблицами и диаграммами. Если у вас сканы и фото копятся без правил, расскажите, откуда они приходят и кто их потом смотрит: Обсудить задачу.