ПОчитай.

Ну это один вариант из сотен.

в базу стучать при запросе файла ну и раз в сутки подчищать например

в базу стучать при запросе файла ну и раз в сутки подчищать например

Мне нужно жёстко прописать "время загрузки + 24 часа".

А не так что б залитое в 23 часа через час удалилось

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html Вот тебе ещё одно решение из тысяч.

Я думаю всякие Beanstalk это тоже умеют.

в базу стучать при запросе файла ну и раз в сутки подчищать например

При запросе вариант, конечно, но что если файл залили и к нему ни разу не обратились? Надо ж мусор подчищать

Мне нужно жёстко прописать "время загрузки + 24 часа".

ну логику любую напишешь

При запросе вариант, конечно, но что если файл залили и к нему ни разу не обратились? Надо ж мусор подчищать

см выше мусор раз в сутки

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html Вот тебе ещё одно решение из тысяч.

У меня не амазон.

У меня не амазон.

А что юзаете для очередей задач?

А что юзаете для очередей задач?

¯\_(ツ)_/¯

http://beanstalkc.readthedocs.io/en/latest/tutorial.html

Вроде тоже есть delayed jobs.

?

Тут просто миллиарды вариантов.

Ну вот мне бы такой вариант, что б и с Go совместимо и в докере работало и без лишних телодвижений где-то сбоку (типа того же nginx)

Поставь Beanstalk, напиши worker на Go, который будет слушать tube из Beanstalk и пускай Beanstalk плюёт delayed задачами. Когда worker получит отложенную задачу, тогда и удаляет файл.

Beanstalk можно заменить Amazon SQS и прочим подобным.

ма-ма

просто мама

Поставь Beanstalk, напиши worker на Go, который будет слушать tube из Beanstalk и пускай Beanstalk плюёт delayed задачами. Когда worker получит отложенную задачу, тогда и удаляет файл.

Окей, гляну что это вообще. Но мне правда не очень хочется присабачивать какие-то удалённые инструменты, потому что это лишние запросы, время и вообще.

еще бинстолк влез

ма-ма

Что не так? Очереди задач есть в любом проекте.

в чем задача-то, на человеческом языке?

И я выше сказал, что способо миллионы. ?

Queue management один из вариантов, в зависимости от среды, где программа работать будет.

Какие есть варианты проверять время файл на предмет истечения срока с момента его загрузки? Допустим файл должен жить сутки, после чего удаляться.

По совету @kirilldanshin пытался изящно выкрутиться через подписки RethinkDB, но ничего не вышло. Пробовал записать в базу время загрузки файла и время его выпиливания, а через changefeed автоматически получать список объектов, чьё записанное время удаления оказывалось меньше текущего локального времени.

Что не так? Очереди задач есть в любом проекте.

вообще-то нет. и вообще-то надо их избегать, пока возможно

По совету @kirilldanshin пытался изящно выкрутиться через подписки RethinkDB, но ничего не вышло. Пробовал записать в базу время загрузки файла и время его выпиливания, а через changefeed автоматически получать список объектов, чьё записанное время удаления оказывалось меньше текущего локального времени.

Если я всё правильно понял то у rethinkdb есть "key expiration" https://github.com/rethinkdb/rethinkdb/issues/5823

вообще-то нет. и вообще-то надо их избегать, пока возможно

Ладно, согласен, как last resort покатит.

Какие есть варианты проверять время файл на предмет истечения срока с момента его загрузки? Допустим файл должен жить сутки, после чего удаляться.

время создания файла лежит в его метаинформации. в чем проблема?

время создания файла лежит в его метаинформации. в чем проблема?

Простукивать это ежесекундно? Не очень как-то

а сколько файлов?

Если я всё правильно понял то у rethinkdb есть "key expiration" https://github.com/rethinkdb/rethinkdb/issues/5823

А чёрт, вернее.. будет :) https://github.com/rethinkdb/rethinkdb/issues/746

Неограничено по количеству, до 2гб размером

тут дело не в байтах, а в штуках

тысячи, тесятки тысяч, сотни тысяч - это одно, можно раз в минуту просто сканировать дерево и удалять лишнее.

тысячи, тесятки тысяч, сотни тысяч - это одно, можно раз в минуту просто сканировать дерево и удалять лишнее.

Угу, и мучать диски.

миллионы - это другое, надо придумывать какой-то индекс и средства поддержания его актуальности

Как-то не очень элегантно.

Простукивать это ежесекундно? Не очень как-то

Кстати, а зачем тебе ежесекундно? Почему не смотреть раз в день, удаляя файлы "старше чем N"? Зачем вся эта "риалтаймовость" в этой задаче?

миллионы - это другое, надо придумывать какой-то индекс и средства поддержания его актуальности

Timestamp в БД — и есть индекс. ? Выше уже 3 человека сказали ему.

Угу, и мучать диски.

я знаю, о чем говорю. диски тут практически не мучаются

SELECT created_at FROM file WHERE create_at + 24 hours; Всё! И это делать раз в N минут.

так вот - дело в штуках

Ага, ну короче задача реально простая.

сколько штук файлов мы планируем разместить?

Timestamp в БД — и есть индекс. ? Выше уже 3 человека сказали ему.

Да сохраняю Я таймстамп и что? Разница либо в простукивании диска, либо в простукивании базы.

Да сохраняю Я таймстамп и что? Разница либо в простукивании диска, либо в простукивании базы.

Эм, так в чём проблема? Простукивай базу. Это разве медленно будет? Прикрути простой database iterator (data provider; или как будет правильно в терминологии библиотек Go Lang?), и удаляй файлы.

сколько штук файлов мы планируем разместить?

Вариант когда база сама будет стучать Go успехом не увенчалась.

а как бы она могла это делать?

нет, правда, как, вы думаете, работаеt record TTL?

а как бы она могла это делать?

В rethink есть changefeeds, когда после запроса отстается открытый поток, рассылающий данные если что-то внутри произошло.

продолжайте...

продолжайте...

Ну и всё.

нет, правда, как, вы думаете, работаеt record TTL?

не все

вообще-то нет. и вообще-то надо их избегать, пока возможно

мммм... а где та граница, когда возможно? я вот прямо сейчас озадачен

Кстати, а зачем тебе ежесекундно? Почему не смотреть раз в день, удаляя файлы "старше чем N"? Зачем вся эта "риалтаймовость" в этой задаче?

Я люблю усложнять себе жизнь.

Угу, и мучать диски.

любая FS в 2017 году закэширует список

там, где тебе реально нужна очередь - там и придется ее использовать :)

любая FS в 2017 году закэширует список

зависит от размера списка

там, где тебе реально нужна очередь - там и придется ее использовать :)

Именно.

да

очередь - это у нас что?

ERROR: S client not available

там, где тебе реально нужна очередь - там и придется ее использовать :)

а каковы критерии, когда она нужна или нет?

Ну правильно. Если подходить с точки зрения предметной области, то вот это оно и всё и есть. ? Задача: «Удалить файл в будущем» Payload дополнительный: «Через N секунд после создания» Отправляем задачу, забываем про неё. В будущем она приходит worker'у и он её выполняет.

очередь - это FIFO по определению

Я люблю усложнять себе жизнь.

Ну это трейдофф тогда между правильностью реализации и возможностями текущего окружения. Если база не умеет в key expiration то приходится обходиться тем что есть. И надёжнее всего здесь будет именно "простукивание" с некоторой периодичностью

вот смотришь на свою задачу, и думаешь - а если это будет не FIFO что изменится?

если ничего - значит тебе не нужна очередь

иногда нужна "куча задач". но я такого термина не слышал

я так понимаю это имеет смысл только если ты тредишься. в однопотоке нет

Всмысле? Меня много гороутин и в каких-то я читаю, в каких-то пишу в мапу

Ну это трейдофф тогда между правильностью реализации и возможностями текущего окружения. Если база не умеет в key expiration то приходится обходиться тем что есть. И надёжнее всего здесь будет именно "простукивание" с некоторой периодичностью

а если умеет?! еще раз: в какой момент происходит этот самый expiration?

Всмысле? Меня много гороутин и в каких-то я читаю, в каких-то пишу в мапу

если они в рамках одного треда - похрену.

Всмысле? Меня много гороутин и в каких-то я читаю, в каких-то пишу в мапу

GOMAXPROC выставлял в 1? если да - можешь ничего не защищать

GOMAXPROC выставлял в 1? если да - можешь ничего не защищать

во, да. как раз пошёл гуглить как этот параметр зовется

а если умеет?! еще раз: в какой момент происходит этот самый expiration?

Ну по описанным условиям, если умеет то можно попробовать. Меньше забот будет

ну-ну

если ничего - значит тебе не нужна очередь

я например очередью пытаюсь избежать многоэтажной транзакции в базе и вообще раздраконить функциональные части по разным базам

я например очередью пытаюсь избежать многоэтажной транзакции в базе и вообще раздраконить функциональные части по разным базам

а это зачем?

Из слака по RethinkDB

любая FS в 2017 году закэширует список

Не fs, а vfs

а это зачем?

что конкретно? зачем избегать многоэтажных SELECT FOR UPDATE или зачем по разным базам раконить?

Какие есть варианты проверять время файл на предмет истечения срока с момента его загрузки? Допустим файл должен жить сутки, после чего удаляться.

/dir/year/month/day/sha1_from_file

что конкретно? зачем избегать многоэтажных SELECT FOR UPDATE или зачем по разным базам раконить?

и то, и другое

Не fs, а vfs

ну... даже не знаю... тебе лучше знать. я вообще конкретно отличия не знаю

/dir/year/month/day/sha1_from_file

И?

Лучше даже схлопнуть до /dir/yyyymmdd/

И?

Что и? Можно просто 2-3 раза в сутки сканировать пару каталогов по mtime

У удалять

Обычным find -delete

/dir/year/month/day/sha1_from_file

Лучший вариант.

KISS и вообще.

+1

Лучший вариант.

Ну, только схлопнуть лучше до 1 каталога