ты лишаешься всех прелестей отдачи файлов через веб-сервер

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

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

Подождите, что Вы имеете в виду? Причём здесь какие-то "умные мальчики"? Сделать ACID при хранении файлов в файловой системе + ссылок на них в БД можно, но не так уж тривиально.

Подождите, что Вы имеете в виду? Причём здесь какие-то "умные мальчики"? Сделать ACID при хранении файлов в файловой системе + ссылок на них в БД можно, но не так уж тривиально.

Особенно когда у вас таблица в 1 ТБ и онлайн система ?

Особенно когда у вас таблица в 1 ТБ и онлайн система ?

1 ТБ это много?

@SanSYS А sqltabs server-side курсоры умеет или сразу всё в память грузит?

Он клиент Запрос, как обычно, исполняет сервер

1 ТБ это много?

его надо на егаис где 1 таблица 300 тб

Особенно когда у вас таблица в 1 ТБ и онлайн система ?

Не имеет значения. Что толку в "решении", которое требованиям _не удовлетворяет_?

1 ТБ это много?

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

его надо на егаис где 1 таблица 300 тб

без партиций?

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

Я не понимаю, о чём конкретно Вы пишете. :( Что значит "перебирать всю таблицу"? В каком случае?

его надо на егаис где 1 таблица 300 тб

Вы там небось не в реалтайме то все делаете

Вы там небось не в реалтайме то все делаете

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

Я не понимаю, о чём конкретно Вы пишете. :( Что значит "перебирать всю таблицу"? В каком случае?

чтобы добавить ссылки на файлы вместо самих файлов (как я понял по структуре БД) надо обновить каждую строку в этой таблице

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

тык было тут недавно когда ритейл простаивал.

чтобы добавить ссылки на файлы вместо самих файлов (как я понял по структуре БД) надо обновить каждую строку в этой таблице

В каком случае? Если Вы один способ хранения файлов (в базе) превращаете в другой (в FS), то да, нужно. А иначе зачем?

В каком случае? Если Вы один способ хранения файлов (в базе) превращаете в другой (в FS), то да, нужно. А иначе зачем?

Считаю хранить файлы в БД неэффективным, тем более в одной таблице. Вероятно они еще в Base64 перекодированны.

Считаю хранить файлы в БД неэффективным, тем более в одной таблице. Вероятно они еще в Base64 перекодированны.

А эффективное-то решение какое в случае, если Вам нужен full-ACID? Я понимаю, что в большинстве случаев все эти файлы не важны, т.е. если изредка что-то тихо потеряется, не так обновится (или побъётся), не то выберется... пользователи потерпят. А вот если нет?

А чем благородные доны ходят в postgres чтоб запросы задавать с автодополнением и в результаты глазами смотреть? psql в консоли как-то неудобно, от datagrip опернсурцная лицензия протухла (а 200$/year жалковато), а у нового браузерного pgadmin какие-то детские проблемы с неумением прервать запрос и эпизодической потерей введённого текста.

Регаете левую почту, находите студента со студаком, и отправляете заявку на education pack )

А эффективное-то решение какое в случае, если Вам нужен full-ACID? Я понимаю, что в большинстве случаев все эти файлы не важны, т.е. если изредка что-то тихо потеряется, не так обновится (или побъётся), не то выберется... пользователи потерпят. А вот если нет?

Да понимаю такую проблему. Решений несколько. Я изначально столкнулся с такой проблемой. Как показывает практика из логов файлы нужны крайне редко. Поэтому я создал таблицу с блобами, плюс зажал все блобы в зип програмно, так же выяснилось что 20% файлов одинаковые (по MD5). Поэтому раз в 10 сократилось у меня использование диска

Он клиент Запрос, как обычно, исполняет сервер

Я о том, что клиент может запрос исполнить и ответ забрать целиком, а может его в курсор обернуть и все 10005000 строчек не забирать (ну или забирать, но хотя бы не падать по OOM от больших ответов). Так-то понятно, что клиент — это клиент :)

Да понимаю такую проблему. Решений несколько. Я изначально столкнулся с такой проблемой. Как показывает практика из логов файлы нужны крайне редко. Поэтому я создал таблицу с блобами, плюс зажал все блобы в зип програмно, так же выяснилось что 20% файлов одинаковые (по MD5). Поэтому раз в 10 сократилось у меня использование диска

Т.е. в этом случае ответ "хранить в базе". ;)

Т.е. в этом случае ответ "хранить в базе". ;)

Вариант хранить в базе был принят моим руководством. Я изначально планировать генерировать имена файлов и складывать на ресурсы (FTP) храня в БД только md5 хеш-суммы файлов.

Вариант хранить в базе был принят моим руководством. Я изначально планировать генерировать имена файлов и складывать на ресурсы (FTP) храня в БД только md5 хеш-суммы файлов.

И заново. :( А ACID Вы как собирались обеспечивать?

Регаете левую почту, находите студента со студаком, и отправляете заявку на education pack )

Да мне как-то неудобно совсем фродом заниматься, на одном острове с jet brains живу, пиво время от времени с частью команды пью... Лучше спрошу Макса Соболевского про лицензию за багрепорты (коих было), а то я об этом впервые слышу :-)

И заново. :( А ACID Вы как собирались обеспечивать?

Вот с этим как раз проблем не было. Транзакция открывалась только в момент. когда файл либо уже скопировался на ФТП либо он там уже имелся. Записи естественно никто не изменял (только добавление происходило), поэтому были операции только insert. Проверку наличия файла по MD5 делалось в другой транзакции

Вот с этим как раз проблем не было. Транзакция открывалась только в момент. когда файл либо уже скопировался на ФТП либо он там уже имелся. Записи естественно никто не изменял (только добавление происходило), поэтому были операции только insert. Проверку наличия файла по MD5 делалось в другой транзакции

Но все конечно зависит от необходимости и задачи.

Вот с этим как раз проблем не было. Транзакция открывалась только в момент. когда файл либо уже скопировался на ФТП либо он там уже имелся. Записи естественно никто не изменял (только добавление происходило), поэтому были операции только insert. Проверку наличия файла по MD5 делалось в другой транзакции

А если база падала и восстанавливалась из backup-а? А если подобное это случалось с FS? И если "только insert", это, конечно, куда проще.

А если база падала и восстанавливалась из backup-а? А если подобное это случалось с FS? И если "только insert", это, конечно, куда проще.

Я же не говорю, что проблем не было ?.

Я же не говорю, что проблем не было ?.

Основная проблема по опыту была связана с тем. что через ФТП закачивались пустые файлы на сервер.

Это не "были проблемы", а "таким образом задача обеспечения 100% ACID не решается". :(

Это не "были проблемы", а "таким образом задача обеспечения 100% ACID не решается". :(

да. но для задач системы этого было достаточно

Это не "были проблемы", а "таким образом задача обеспечения 100% ACID не решается". :(

С вариантом хранения в БД натолкнулись сейчас на проблему производительности. И партиционирование и все виды оптимизаций особо ситуацию не исправляют.

да. но для задач системы этого было достаточно

Т.е. это не вопрос эффективности, это решение _другой_ задачи. И если это имеет значение, сравнивать просто бесполезно, т.к. хранение в FS —- это не решение.

С вариантом хранения в БД натолкнулись сейчас на проблему производительности. И партиционирование и все виды оптимизаций особо ситуацию не исправляют.

Да, производительность будет ниже, никуда от этого не денешься —- за ACID надо платить. ;) Проще всего —- "железом". ;)

Т.е. это не вопрос эффективности, это решение _другой_ задачи. И если это имеет значение, сравнивать просто бесполезно, т.к. хранение в FS —- это не решение.

Эфективность, это в конечном пересчете - прибыль. (вместо 10к запросов получаем 15к за еденицу времени)

Эфективность, это в конечном пересчете - прибыль. (вместо 10к запросов получаем 15к за еденицу времени)

А потеря данных - это может быть и закрытие бизнеса

Эфективность, это в конечном пересчете - прибыль. (вместо 10к запросов получаем 15к за еденицу времени)

Если указанное требование есть, то его нарушение —- это существенные убытки (иначе бы его не было).

А потеря данных - это может быть и закрытие бизнеса

Тут момент связан именно в ценности данных. Самые ценные данные за 1 день (в этой системе). Остальные нужны только для статистики. Естественно за этот 1 день все дублируется и копируется. Система же не только в лог должна все писать?

Если указанное требование есть, то его нарушение —- это существенные убытки (иначе бы его не было).

Есть системы с онлайн-хранением данных в ОЗУ (один известный зеленый банк, извините за ОФФ-ТОП). Там вопрос надежности решается резервированием на уровне серверов.

Тут момент связан именно в ценности данных. Самые ценные данные за 1 день (в этой системе). Остальные нужны только для статистики. Естественно за этот 1 день все дублируется и копируется. Система же не только в лог должна все писать?

Вы путаете ACID с одной только Durability, мне кажется...

На моей практике было 3 случая потери данных. Самый простой - восстановление с бумажного носителя - 200 человекочасов.. Два других - потеря контракта

Вы путаете ACID с одной только Durability, мне кажется...

Остальное в принципе не использовалось. так как конкуренции за данные практически не было. (Только запрос на поиск по MD5 по индексу)

Есть системы с онлайн-хранением данных в ОЗУ (один известный зеленый банк, извините за ОФФ-ТОП). Там вопрос надежности решается резервированием на уровне серверов.

Решения проблемы _только_ сохранности (durability) данных в общем-то известны, можно и без СУБД обойтись (при аккуратной реализации).

Решения проблемы _только_ сохранности (durability) данных в общем-то известны, можно и без СУБД обойтись (при аккуратной реализации).

Да, но вопрос транзакционности никто не отменял.

На моей практике было 3 случая потери данных. Самый простой - восстановление с бумажного носителя - 200 человекочасов.. Два других - потеря контракта

Так кто эже спорит, что данные терять - это крайне плохо.

На моей практике было 3 случая потери данных. Самый простой - восстановление с бумажного носителя - 200 человекочасов.. Два других - потеря контракта

А мне вот как-то приходилось работать с "граммотно написанными" ("ACID? Что эта?") ERP... впрочем, потеря около 120 000$ за день —- это, пожалуй, худшее, что я там видел. ;)

А мне вот как-то приходилось работать с "граммотно написанными" ("ACID? Что эта?") ERP... впрочем, потеря около 120 000$ за день —- это, пожалуй, худшее, что я там видел. ;)

Потери данных случаются .... ?

Потери данных случаются .... ?

Это не потеря данных, это была попытка работать на READ COMMITTED в случае, когда это было на самом деле недопустимо. :( И зачастую довольно трудно такие ошибки в коде потом находить, по моему опыту.

Это не потеря данных, это была попытка работать на READ COMMITTED в случае, когда это было на самом деле недопустимо. :( И зачастую довольно трудно такие ошибки в коде потом находить, по моему опыту.

Согласен

Я о том, что клиент может запрос исполнить и ответ забрать целиком, а может его в курсор обернуть и все 10005000 строчек не забирать (ну или забирать, но хотя бы не падать по OOM от больших ответов). Так-то понятно, что клиент — это клиент :)

Не в курсе на счёт фетчинга, прям вообще Варешарком не проверял Но если в выборке 1к строк, то рисует лишь, ну 40, остальные по мере прокрутки

Да, производительность будет ниже, никуда от этого не денешься —- за ACID надо платить. ;) Проще всего —- "железом". ;)

Acid тут иногда не нужен

Acid тут иногда не нужен

Тогда в базе тоже можно хранить, если этих blob-ов будет немного / они небольшие / обращения к ним редки.

Тогда в базе тоже можно хранить, если этих blob-ов будет немного / они небольшие / обращения к ним редки.

Все зависит от задачи. Когдато надо чтобы файло менялось транзакционнои, когда-то нет. Горизонально бд типа пг тяжело скалировать.

Поэтому и выбирают фс

Поэтому и выбирают фс

Да, но только в строго определенных случаях

Все зависит от задачи. Когдато надо чтобы файло менялось транзакционнои, когда-то нет. Горизонально бд типа пг тяжело скалировать.

Я имел в виду, что даже если транзакционность не нужна, но ожидаемая нагрузка, связанная с хранением blob-ов, невелика/не важна, можно и в базе хранить, просто потому что проще.

Я имел в виду, что даже если транзакционность не нужна, но ожидаемая нагрузка, связанная с хранением blob-ов, невелика/не важна, можно и в базе хранить, просто потому что проще.

У меня сейчас проект, где надо хранить и сверять цифровые подписи. Сдесь вариант только в бд их хранить. Основная причина - безопасность.

Все зависит от задачи. Когдато надо чтобы файло менялось транзакционнои, когда-то нет. Горизонально бд типа пг тяжело скалировать.

ФС тоже так себе скалируется - несколько миллиардов файлов - предел локальных... потом начинаются распределенки... а там же свои костыли

У меня сейчас проект, где надо хранить и сверять цифровые подписи. Сдесь вариант только в бд их хранить. Основная причина - безопасность.

Хмм... а как это связано с безопасностью? Т.е. чем хранение в directory, доступной пользователю, под которым работает PostgreSQL, менее безопасно, чем хранение в базе?

Хмм... а как это связано с безопасностью? Т.е. чем хранение в directory, доступной пользователю, под которым работает PostgreSQL, менее безопасно, чем хранение в базе?

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

Если бы все было гуд со скейлингом по перформансу у rdbms толькоб так и хранили. И еслиб везде мультимастер на вставку/апдей не проседал.

У меня сейчас проект, где надо хранить и сверять цифровые подписи. Сдесь вариант только в бд их хранить. Основная причина - безопасность.

Размер цифподписей большой? А по количеству? Или еще и сканы их рапечаток в пдф хранится %))?

Размер цифподписей большой? А по количеству? Или еще и сканы их рапечаток в пдф хранится %))?

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

Количество около 100к в день

В тестовом режиме

Размер цифподписей большой? А по количеству? Или еще и сканы их рапечаток в пдф хранится %))?

Но как часто бывает, в пиковые нагрузки все хотят быстро ?

Если бы все было гуд со скейлингом по перформансу у rdbms толькоб так и хранили. И еслиб везде мультимастер на вставку/апдей не проседал.

Задачи разные. Где-то (очень много где, кстати) только так и хранят, несмотря на "проблемы".

Может кто сталкивался с переездом с постгреспро на обычный постгрес через репликацию? Версии одинаковые реплика поднялась. При попытке преконектиться в консоле пишет: psql: ВАЖНО: bogus pg_index tuple Только pg_dumpall переезжать?

Да. Не совместимый pg_index, если память не изменяет.

ФС тоже так себе скалируется - несколько миллиардов файлов - предел локальных... потом начинаются распределенки... а там же свои костыли

+1 лучше сразу хранилище файлов делать как черный ящик с доступом например по http.

на текущей работе храним файлы в базе. потому что в отличие от распределенных fs postgresql предсказуемей

но не используем large objects. потому что оно выделяет одну toast-таблицу если я не ошибаюсь

еще немного тут написано: https://wiki.postgresql.org/wiki/BinaryFilesInDB

но не используем large objects. потому что оно выделяет одну toast-таблицу если я не ошибаюсь

+ "pg_largeobject" - "system" и многие операции на нем запрещены

еще немного тут написано: https://wiki.postgresql.org/wiki/BinaryFilesInDB

Большие, главное, не храни, а то там и останутся. До 300 мегов норм bytea. дальше спортлото.

у меня жопг. хватает.

Большие, главное, не храни, а то там и останутся. До 300 мегов норм bytea. дальше спортлото.

А в чём спортолото-то? Я помню были какие-то баги c pg_dump... но вроде достаточно давно, неужели их ещё не исправили?

Да. Не совместимый pg_index, если память не изменяет.

Спасибо, я так и понял. Благо бд не большая и дамп рестор пройдет быстро.

Баги в том что не выгружаются bytea больше чем 500 мегов черз pg_dump и copy

А залится запросто

Привет всем ,а как на сайте сделать проверку товара по номеру серийному

?

EXIST( Select 1 FROM product WHERE serial = 12345) проверка на существование

А чем благородные доны ходят в postgres чтоб запросы задавать с автодополнением и в результаты глазами смотреть? psql в консоли как-то неудобно, от datagrip опернсурцная лицензия протухла (а 200$/year жалковато), а у нового браузерного pgadmin какие-то детские проблемы с неумением прервать запрос и эпизодической потерей введённого текста.

DBeaver же...

У dataGrip есть еще один большой минус - он не могет работать больше, чем с одной базой одновременно. То есть 1 connection = 1 база

Это вообще говно пока.... Красивое, но говно.

DBeaver же...

+

Это вообще говно пока.... Красивое, но говно.

плюс убогое описание полей индексов и т.д. для таблиц. Хотя бы в древовидной форме сделали бы, а то все в одной ветке.

господа, насколько извращение делать vacuum и create index на одной таблице одновременно?)

плюс убогое описание полей индексов и т.д. для таблиц. Хотя бы в древовидной форме сделали бы, а то все в одной ветке.

Да ладно, у меня она с Postgres просто не работала, не показывала поля с русским текстом .... Была моментов выпилина после обнаружения этого факта. Это ж надо, умудриться написать на Java что-то, что не поддерживает русские буквы!

господа, насколько извращение делать vacuum и create index на одной таблице одновременно?)

Зачем???? ?

Зачем???? ?

вопрос теоретического характера ? интересно как себя вакуум поведет в таком случае

Простая команда VACUUM (без FULL) только высвобождает пространство и делает его доступным для повторного использования. Эта форма команды может работать параллельно с обычными операциями чтения и записи таблицы, так она не требует исключительной блокировки. Однако освобождённое место не возвращается операционной системе (в большинстве случаев); оно просто остаётся доступным для размещения данных этой же таблицы. VACUUM FULL переписывает всё содержимое таблицы в новый файл на диске, не содержащий ничего лишнего, что позволяет возвратить неиспользованное пространство операционной системе. Эта форма работает намного медленнее и запрашивает исключительную блокировку для каждой обрабатываемой таблицы.

то есть vacuum без full особо не уменьшит размер БД, а vacuum full блочит таблицу, соответственно пока не выполнится никакие операции с ней будут недоступны, включая create index

разумеется я это читал, но спасибо)

В реале иногда полезней индексы пересобирать, а не вакуум делать. (ИМХО)

немного не понял, как это поможет мусор очистить?