и то, и другое

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

С какой то версии Go он автоматически выставляется по числу ядер проца.

1. SELECT FOR UPDATE сложно составлять и поддерживать. Может у кого-то мозг заточен, но когда у меня любое изменение 1-2 рабочих дня занимает, это трындец. Плюс многоэтажный SELECT выдаёт большую неудобную простыню. Или её резать, или дублировать селекты потом. И транзакция обязывает это всё вместе держать, очевидно. 2. Раздраконить по разным базам. Небольшие базы легче реплицировать (если например к pgsql/mysql этот термин вообще применим). Их легче восстанавливать. Некоторые данные можено лить в те базы, которые для этого предназначены. Хоть в аэроспайк, хоть в S3. Да, да, я знаю, что в MySQL можно держать индексы, а в S3 саму картинку. Но пункт (1) :)

но можно же и покрутить

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

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

Да. Просто раньше нужно было выставлятьстобы использовать многочдерность, а сейчас наоборот. Кажется в 1.6 поменялось.

Нет, там по числу cpu

тогда защищай и чтение, и запись

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

зачем левелдб, а?

а про раздраконить - ввопрос в размере.

По поводу задачи Максима. Ставишь LevelDB - key/value хранилище с персистентностью. При закачки файла записываешь его атрибуты - путь, время создания. Запускаешь отдельную горутину с таймером, которая запускает периодически воркер. Воркер тупо пробегает по списку, проверяет экспирейшин тайм и асинхронно удалят файлы. Я думаю что на миллион файлов будет пригодин тупой for без изъебов. 1 кбайт кода и одна полезная билиотека.

Персистетность

а, делайте что хотите

По поводу задачи Максима. Ставишь LevelDB - key/value хранилище с персистентностью. При закачки файла записываешь его атрибуты - путь, время создания. Запускаешь отдельную горутину с таймером, которая запускает периодически воркер. Воркер тупо пробегает по списку, проверяет экспирейшин тайм и асинхронно удалят файлы. Я думаю что на миллион файлов будет пригодин тупой for без изъебов. 1 кбайт кода и одна полезная билиотека.

и табличка "сарказм"

я на любом языке сделал бы ровно то же самое

По поводу задачи Максима. Ставишь LevelDB - key/value хранилище с персистентностью. При закачки файла записываешь его атрибуты - путь, время создания. Запускаешь отдельную горутину с таймером, которая запускает периодически воркер. Воркер тупо пробегает по списку, проверяет экспирейшин тайм и асинхронно удалят файлы. Я думаю что на миллион файлов будет пригодин тупой for без изъебов. 1 кбайт кода и одна полезная билиотека.

Короче, если совсем отказаться от БД, то либо распределять файло по системе директориев, либо сканить сами файлы на предмет их свойств и от этого прыгать дальше, я так понял.

И то и другое. При записи файла создавать yyyy/mm/dd/hh/a..b..z. При запуске демона - делать рескан.

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

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

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

Привет, как определить новое поведение методов для именованных типов? type Celsius float64 var c Celsius var p Celsius = 14.2 func main() { fmt.Println(p) } func (p Celsius) String() string { return fmt.Sprintf("%g°C", p) } я вот так делаю, но это только для p

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

Какие пакетики могут мне помочь со сканом файлов рядом?

Кто что и куда загрузил. Мы на какой стороне? Ни хера же не понятно

В каком смысле только для p? https://play.golang.org/p/BPUt_ElDOU

Если мы в чате про Го, то мы всегда на серверной стороне :)

Если мы в чате про Го, то мы всегда на серверной стороне :)

В общем - хочешь-не-хочешь, а какой-нибудь процесс с периодичной проверкой вешать надо. Ладно, я понял.

Можно для тупых? К нам пришел файл. Мы его сохранили в ФС. Потом мы иногда читаем этот файл. Мы не должны читать файл, если он старше 24 часов, так?

Мы должны удалить файл если он достиг старости в 24 часа.

Это глупо

Это надо.

Это иллюзия

по-моему проще сделать обычный FIFO буфер, куда пихать имена файлов и проверять только тот что на выходе, т.к. все что за ним явно будут моложе

Мою библу для Telegraph ретвитнул чувак с косарём фолловеров. 0_0

В одном потоке го особо не имеет смысла

Мою библу для Telegraph ретвитнул чувак с косарём фолловеров. 0_0

по-моему проще сделать обычный FIFO буфер, куда пихать имена файлов и проверять только тот что на выходе, т.к. все что за ним явно будут моложе

а что в библе?

Кстати, правильно. Можно вобще функцию проверки вставить в обработчик обращения к файлу, поскольку операция копеешная по времени. Но мы ТЗ до конца до сих пор не знаем. Ни сколько миллионов файлов, ни какая нагрузка планируется :) Ни требования к надежности или размеру хранилища.

Тогда cron find ...

find /opt/files/ -mtime +1|xargs rm -f - не благодари!

find /opt/files/ -mtime +1|xargs rm -f - не благодари!

это проход по всем файлам и удаление всех, изменённых более суток назад

Кстати, правильно. Можно вобще функцию проверки вставить в обработчик обращения к файлу, поскольку операция копеешная по времени. Но мы ТЗ до конца до сих пор не знаем. Ни сколько миллионов файлов, ни какая нагрузка планируется :) Ни требования к надежности или размеру хранилища.

Почему бы не завести какую-нибудь СУБД, пихать в неё id файла, а потом допустим раз в час делать запрос и удалять старые файлы?

Почему бы не завести какую-нибудь СУБД, пихать в неё id файла, а потом допустим раз в час делать запрос и удалять старые файлы?

уже предлагали. субд для отслеживания возраста файла, если он и так есть в метаданных — это оверкилл

уже предлагали. субд для отслеживания возраста файла, если он и так есть в метаданных — это оверкилл