Например какие?

minio

Сколько у вас картинок? Проблемма вымывания кеша может стоять остро.

тут надо понимать, у вас куча народу хочет посмотреть один файл или у вас есть много файлов и много народу равномерно всё это смотрит?

во втором случае кеш вам не сильно поможет

обычно храним в субд md5/sha1 от картинки и при рендринге html подставляем сформированный url исходя из md5. (только не кладите всё в одну папку)

тут надо понимать, у вас куча народу хочет посмотреть один файл или у вас есть много файлов и много народу равномерно всё это смотрит?

Скорее вот этот вариант.

во втором случае кеш вам не сильно поможет

this

тогда лучше вам в СУБД не класть и даже не пытаться приложением читать файл и отдавать nginx'у

тут увы не pg_dump ошибки находит а сам postgres

там ошибка pg_toast, которая вылезла на 5е сутки бекапа, данные не страшно потерять, главное перенести на ssd сервер. Я сделал REINDEX pg_toast.toast_234532 <- вот эта цифра, это какой-то последовательный ID всех тостов от 0 и вверх, или случайная фигня типа OID? Как определить все битые тосты - только последовательным перебором всех записей в БД? Проще было бы игнорировать все эти ошиьки и пропускать битые записи.

если конечно у вас не асинхронное приложение

OID - то же инкремент....

обычно храним в субд md5/sha1 от картинки и при рендринге html подставляем сформированный url исходя из md5. (только не кладите всё в одну папку)

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

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

кладите всё и везде, можете в СУБД ещё записать номер или имя сервера куда картинка ушла.

okay.jpg ? То есть не отходим от классики.

И я не думаю, что в угоду MVP надо терять здравый смысл. Насколько я помню MVP оно не про отдачу крупных файлов и картинок...

а вы уверены что у вас такой rps будет что кеш не справится ?

там ошибка pg_toast, которая вылезла на 5е сутки бекапа, данные не страшно потерять, главное перенести на ssd сервер. Я сделал REINDEX pg_toast.toast_234532 <- вот эта цифра, это какой-то последовательный ID всех тостов от 0 и вверх, или случайная фигня типа OID? Как определить все битые тосты - только последовательным перебором всех записей в БД? Проще было бы игнорировать все эти ошиьки и пропускать битые записи.

недавно сам столкнулся с повреждёнными записями в БД, пришлось тупо select-ом искать битые строки в таблице и удалить их.

там ошибка pg_toast, которая вылезла на 5е сутки бекапа, данные не страшно потерять, главное перенести на ssd сервер. Я сделал REINDEX pg_toast.toast_234532 <- вот эта цифра, это какой-то последовательный ID всех тостов от 0 и вверх, или случайная фигня типа OID? Как определить все битые тосты - только последовательным перебором всех записей в БД? Проще было бы игнорировать все эти ошиьки и пропускать битые записи.

тоаст это же какое то конкретное поле конкретного тюпла... как его выбросить то? Что вместо него показать?

а вы уверены что у вас такой rps будет что кеш не справится ?

Не уверен, здесь пальцем в небо, может не будет роста никакого и тогда нагрузка будет вообще мизерная

тоаст это же какое то конкретное поле конкретного тюпла... как его выбросить то? Что вместо него показать?

весь тупл удалить

недавно сам столкнулся с повреждёнными записями в БД, пришлось тупо select-ом искать битые строки в таблице и удалить их.

блин фигово, у меня очень большая база и очень медденные диски на старом сервере, долго делать select на каждую запись

а вы уверены что у вас такой rps будет что кеш не справится ?

Мне кажется что можно сделать с кешем и файлами в СУБД но это будет блоатить СБУД и это не масштабируемо, не говоря о том, что медленно даже при наличии кеша.

блин фигово, у меня очень большая база и очень медденные диски на старом сервере, долго делать select на каждую запись

а остановить сервер и просто сделать cp/rsync на другой нельзя? Он под нагрузкой?

а остановить сервер и просто сделать cp/rsync на другой нельзя? Он под нагрузкой?

угу я бы так и хотел, но разве можно так делать?

или там уже другая верся сервера?

можно

версия та же точно

ох, попробую

если мажорная версия та жа то всё должно быть ок

и у вас там одна архитектура процессора

ну так дело то в том, что на destination сервере чпу вообще не загружен, узкое горлышко это исходный сервер с магнитными дисками. но блин, 2ТБ переносить более 4 суток это что-то дикое вообще. Будто бы он не последовательно читает, а рандомно

ну возьмите blktrace + iowatcher да посмотрите как там оно бегает по смещениям.

в смысле между 32битами и 64 битами нельзя

блин фигово, у меня очень большая база и очень медденные диски на старом сервере, долго делать select на каждую запись

ну таблицу вы уже можете определить легко, на ней у вас pg_dump падает. И уже в таблице искать. Если упало сразу после начала бекапа этой таблицы, в формате директории бекап делайте и можно будет оценить в какой части таблицы падает, чтобы не сканить всю таблицу селектом.

обычно храним в субд md5/sha1 от картинки и при рендринге html подставляем сформированный url исходя из md5. (только не кладите всё в одну папку)

почему?

что бы было уникальное имя файла не привязанное к его реальному имени

в том числе для безопасности

адрессация

Мне кажется что можно сделать с кешем и файлами в СУБД но это будет блоатить СБУД и это не масштабируемо, не говоря о том, что медленно даже при наличии кеша.

я не совсем понял, но я к тому что кеш на уровне nginx или иного прокси, если там не высокий RPS к статике, соберет нормально всю нагрузку.

что бы было уникальное имя файла не привязанное к его реальному имени

ну вы же храните sha1 от тела. если sha1 совпали, то либо вы бесплатно получите дедупликацию, либо вам сказочно повезло и вы нашли коллизию.

я не совсем понял, но я к тому что кеш на уровне nginx или иного прокси, если там не высокий RPS к статике, соберет нормально всю нагрузку.

нет.

я не совсем понял, но я к тому что кеш на уровне nginx или иного прокси, если там не высокий RPS к статике, соберет нормально всю нагрузку.

всё зависит от колличество файлов, их размера и собственно характеристик железа

ну вы же храните sha1 от тела. если sha1 совпали, то либо вы бесплатно получите дедупликацию, либо вам сказочно повезло и вы нашли коллизию.

ну да

в моём слуачае правда, дубликаты запрещены

я по этому беру ещё md5 от пикселей картинки после декодирования

нет.

обоснуйте ?

обоснуйте ?

Вот мне тоже интересно. У меня весьма положительный опыт от кеша nginx

Вот мне тоже интересно. У меня весьма положительный опыт от кеша nginx

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

всё зависит от колличество файлов, их размера и собственно характеристик железа

Железка будет слабенькая, на уровне дешевых VDS. Файлы 5-10 мб., количество думаю не больше нескольких сотен, ну может пара тысяч. Когда подрастем, возьмем и железку помощнее.

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

Но ведь кеш nginx это по сути те же файлы, которые он хранит у себя где-нибудь в /var и довольно эффективно их отдает.

Но ведь кеш nginx это по сути те же файлы, которые он хранит у себя где-нибудь в /var и довольно эффективно их отдает.

он их не отдаёт, он говорит ОС "сунь этот файл в этот сокет"

Ну мы одно и то же имеем в виду :)

Но ведь кеш nginx это по сути те же файлы, которые он хранит у себя где-нибудь в /var и довольно эффективно их отдает.

и? кеш там - это иерархия каталогов. если каталога не будет в dentry cache, это это readdir() и 1 сик по диску. если содержимого файла нет в page cache - это снова будет сик по диску.

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

с чего бы ? если нагрузка низкая, чтение с диска будет быстрым, да не как из file cache но все же быстрая.

с чего бы ? если нагрузка низкая, чтение с диска будет быстрым, да не как из file cache но все же быстрая.

ой, всё...

denty cache будет, потому что файлов не много

и? кеш там - это иерархия каталогов. если каталога не будет в dentry cache, это это readdir() и 1 сик по диску. если содержимого файла нет в page cache - это снова будет сик по диску.

А вот все эти readdir и seek это точно имеет смысл рассуждать в случае когда на сайт заходит человек 500 в день максимум ? :)

denty cache будет, потому что файлов не много

с чего бы вдруг? dentry cache вполне неплохо так вымывается page cache.

вы сейчас говорите что т ов духе "если у нас чего то нет в памяти, это работает медленно" - извините это дурь.

Если нагрузка низкая, то хоть с диска, хоть из "кеша" дискового — одна фигня, хотья через энжинкс отдавать, а не сендфайлом.

Если нагрузка низкая вообще можно хоть с дискет отдавать. :о)

Если нагрузка низкая, зачем вообще кеш городить?

вообщем я свой способ рекоммендую если: 1. вы думаете масштабироваться к десяткам и сотням тысячам файлов 2. если вам жалко СУБД которая будет пухнуть.

Если нагрузка низкая, зачем вообще кеш городить?

бинго!

потому что файлики в бд ? ))

3. низкая нагрузка ИМХО не повод делать специально медленно когда, другое решение ну пара часов кодинга.

у Postgres вообще проблеммы большие с файлами

Если нагрузка низкая, зачем вообще кеш городить?

Во-первых, кеш все-же значительно ускорит отдачу файлов из БД в случае хоть сколько конкурентного доступа. Во-вторых, цена введения такого кеша - это минут 20 прописать в nginx опции.

3. низкая нагрузка ИМХО не повод делать специально медленно когда, другое решение ну пара часов кодинга.

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

Во-первых, кеш все-же значительно ускорит отдачу файлов из БД в случае хоть сколько конкурентного доступа. Во-вторых, цена введения такого кеша - это минут 20 прописать в nginx опции.

Это смотря как кеш настроить, при особенно прямых руках может и замедлить, если будет miss близок к 100%. Опять же, головная боль про инвалидацию, расчёт правильного размера и ещё куча других вопросов

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

Это смотря как кеш настроить, при особенно прямых руках может и замедлить, если будет miss близок к 100%. Опять же, головная боль про инвалидацию, расчёт правильного размера и ещё куча других вопросов

да, инвалидация будет проблемой, и в бесплатном nginx кроме прилеенного сбоку purge cache ничего нет. и cache:level действительн опридется выбрать адекватный.

но это везде и всегда так )

В общем, я думаю что все же решусь на эту авантюру, потом расскажу как прошло, если что-то вообще получится ;)

а если файлы каждый ра грузятся с новым id то вобще нет проблемы.

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

minio

++ (а еще проще вообще внешнего провайдера взять)

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

Система мультитенантная. Есть два приложения: "A" - админское грубо говоря, где работают администраторы, регистрируются клиенты. И "C" - клиентское (это и есть тенанты) - где клиенты после регистрации уже работают. Все это живет в одной базе, public схема для приложения A, и множество схем для копий приложения "C". Клиенты из админской части могут загружать файлы в свое приложение - вот тут и возникает проблема с распределенностью.

При загрузке файла просто засунуть его в базу - это намного проще чем работать с объектным хранилищем, думать про пермишены всякие и целостность. В этом случае все что надо для целостности - просто регулярно делать бэкап всей базы.

Даже в случае если все сервера вдруг погорят и поломаются - просто раскатываем бэкап на новом сервере, приложение вместе с nginx само нагреет кеш - и все работает :)

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

прямо напрашивается ответ "возьмите уже внешнее хранилище и не стреляйте в ногу"

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

Ну так оно все само греется же, не надо никаких лишних телодвижений.

Причем на любой новой машине.

По-моему дешево и сердито ;)

"выберу-ка я из вариантов греть или не греть вообще первый, так хоть чая вскипячу"

SSD <-> GPU DMA http://kaigai.hatenablog.com/entry/2016/09/08/003556

боян :)

А вообще мне идея AMD нравится больше, когда они ssd прям в видео карту воткнули.

жалко, что у нас особо некому таким пользоваться...

Добрый вечер

Может кто знает, есть ли в постгрес аналог DBCC INDEXDEFRAG?

И нужен ли он тут?

https://www.postgresql.org/message-id/5797D5A1.5030009%40agliodbs.com почти мой случай

https://www.postgresql.org/message-id/5797D5A1.5030009%40agliodbs.com почти мой случай

ну это если очень много обновлений

в остальном кажется ваакуума хватает

А я все еще борюсь с мертвыми pg_toast, не могу из-за них перенести последнюю таблицу profiles на новый сервер, и крашится все на вот этом тосте: pg_toast_16455. Делал REINDEX pg_toast.pg_toast_16455, но не помогло. Теперь сделал VACUUM FULL profiles - вакуум только что завершился с той же ошибкой, с которой прерывается pg_dump: vw=# VACUUM FULL profiles; ERROR: missing chunk number 0 for toast value 38643697 in pg_toast_16455 Поможет ли pg_repack? Остается наверное написать скрипт с хандлингом exception для перебора каждой записи таблице, да?

А я все еще борюсь с мертвыми pg_toast, не могу из-за них перенести последнюю таблицу profiles на новый сервер, и крашится все на вот этом тосте: pg_toast_16455. Делал REINDEX pg_toast.pg_toast_16455, но не помогло. Теперь сделал VACUUM FULL profiles - вакуум только что завершился с той же ошибкой, с которой прерывается pg_dump: vw=# VACUUM FULL profiles; ERROR: missing chunk number 0 for toast value 38643697 in pg_toast_16455 Поможет ли pg_repack? Остается наверное написать скрипт с хандлингом exception для перебора каждой записи таблице, да?

Да, как я и делал. Только мне лень было писать скрипт. Я руками за полчаса перебрал.