Я в итоге забил на этот сервис в виду нехватки времени и других задач.
Но если бы делал сейчас, то держал бы ссылки в mariadb, статистику по кликам в redis (которую бы периодически скидывал в основную базу), и все было бы за кешем cloudflarе. В случае с CF не нужен толстый сервер, прокатит и простая ВПСка (при правильном кеше).
Да и cloudflare большей части чтобы ip спрятат и защитить от ддоса. Без него кеш nginx вытянет проект в легкую.
asmrnv777: не ограничен. В инете есть история (там в комментах к статье, описание, в блоге автора уже нету, но есть в архиве интернета), что на 3 Тб в _день_ человека попросили перейти на платный тариф. Только попросили неправильно (тариф за 2000 вместо 200, как потом выяснилось), в итоге он покинул CF на хостинг с анлим траффиком.
brainick: А что в этом плохого? Смысл или по белому и поевать или рыльце в пушку и молчать и не рыпаться. У них же написано - linux.
Пусть воюют против Ростелекома, те и так зажрались.
При создании вопроса надо указывать структуру таблиц. Чтобы люди, которые помогают не изобретали свой велосипед за вас и вы не говорили, что у вас по другому в базе связи устроены.
Rsa97: про совпадение и дубликаты я уже думал, в итоге решил два хеша хранить, sha1 и sha256, шанс получения двух одинаковых хешей по 2м алгоритмам ниже.
Я сейчас посмотрю, на сколько по времени хватит варианта с 10 битами и стоит ли использовать некий балансер (который будет указывать скрипту, в какую таблицу закинуть файл). Спасибо.
Да, хеш у меня так же будет считаться для поиска дубликатов. Преимущества базы - быстрый поиск записи по id и взятие blob'а, вместо операций чтения и записи с файлами на уровне сайта. Быстрые бекапы десятков таблиц, вместо rsync по миллиону файлов. Поэтому данные будут храниться как blob и интересует метод, по которому их распределять.
Ваш вариант с первой буквой хеша хорош, но я получаю ограничение в 36 таблиц. Если использовать 2 буквы - ограничения уже не будет, но мне придется создать 1296 таблиц, для запуска, или писать костыль. Поэтому нужно гибкое решение, которое можно масштабировать.
Условно есть 10 файлов.
JS открывает поток на чтение файла1, и открывает поток на выдачу этого файла клиенту. Затем как файл1 прочитан JS закрывает поток на чтение файла1 и открывает поток на чтение файла2, но при этом потом на выдачу клиенту остается открытым, то есть JS читает из разных мест, а пишет все в одну кучу. Итого после прочтения всех 10 файлов JS закрывает поток на выдачу данных клиенту и у него на машине один большой файл, склеенный из множества мелких. Итоговый объем от 300Мб до 20-30Гб, поэтому надо, чтобы склейка была потоковая, без формирования итогового файла в оперативке.
Тогда скорее всего дело в электронике клавы. Иначе бы была просто залипшая подложка. Попробуйте отсоединить ее и снова присоединить. Может там шлейф перетерся/отошел или статика.
Еще вариант попроще: создаете стиль CSS, в котором прописана фоновая картинка для родительского div'а, в котором расположен div с рекламой.
Но я использовал первый вариант и не для картинки, а для оверлеев. Мол если хочешь пользоваться сайтом - отключай рекламу.
Nc_Soft: в саппорт разделе описаны только лимиты на файл. Общих лимитов я не видел. У меня сейчас там примерно 10Гб кеша. Задайте им вопрос в саппорт, а ответом поделитесь:)
Но если бы делал сейчас, то держал бы ссылки в mariadb, статистику по кликам в redis (которую бы периодически скидывал в основную базу), и все было бы за кешем cloudflarе. В случае с CF не нужен толстый сервер, прокатит и простая ВПСка (при правильном кеше).
Да и cloudflare большей части чтобы ip спрятат и защитить от ддоса. Без него кеш nginx вытянет проект в легкую.