|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Знатоки PostgreSQL подскажите есть ли возможность в PostgreSQL создавать хранилище файлов, аналогичное filestreem в sqlserver? Я вроде читал что есть механизм, а сейчас не могу найти. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 09:37 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
это не то. есть именно файл стрим специально для файлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 12:04 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
хотя там файлы можно хранить... но больще ничего нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 12:07 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Петр хотя там файлы можно хранить... но больще ничего нет? Хранение файлов средствами реляционной СУБД - то еще извращение. Если у вас возникают такие задачи - повод серьезно задуматься над архитектурой. Почему это распространено в решениях основанных на проприетарных БД (Oracle, MSSQL)? Потому, что там уже уплачено за дорогущий комбайн и его стараются выжимать по-максимуму. При работе с opensource решениями вы не ограничены одним инструментом. Для хранения больших объектов вполне можно выбрать средство которое будет работать только с ними, и будет работать хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 12:40 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
mefman Петр хотя там файлы можно хранить... но больще ничего нет? Хранение файлов средствами реляционной СУБД - то еще извращение. Если у вас возникают такие задачи - повод серьезно задуматься над архитектурой. Почему это распространено в решениях основанных на проприетарных БД (Oracle, MSSQL)? Потому, что там уже уплачено за дорогущий комбайн и его стараются выжимать по-максимуму. При работе с opensource решениями вы не ограничены одним инструментом. Для хранения больших объектов вполне можно выбрать средство которое будет работать только с ними, и будет работать хорошо. не буду тут дискутировать о извращениях, само по себе хранение файлов в СУБД имеет главный недостаток, что тот же sql server просто загружает все эти 100-ни ГГб-тов в память - хотя там им совершенно не место. И бесплатные версии (express) не подходят для этих целей в виду ограничения по объему. Одновременно есть куча преимуществ хранения файлов а БД - например репликация - позволяющая синхронизировать базы данных. Но хочется услышать советы про практической реализации хранения файлов. Какие именно средство вы можете посоветовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 12:58 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Петр это не то. есть именно файл стрим специально для файлов? И что не так? Large object это и есть отдельный файл. Принципиальной разницы не вижу Код: sql 1. 2. 3. 4. 5. 6. 7.
Код: sql 1. 2. 3. 4. 5.
вместо поля chart типа blob , используем ссылку на large object chart_id , в прочем если размер файлов < 1Гб, можно и так: chart bytea, правда если Вы хотите именно репликацию, то large object не реплицируются... ЗЫ: varbinary(max) это скока? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 13:42 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
fte если Вы хотите именно репликацию, то large object не реплицируются... Мммм, в смысле? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 14:13 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Melkij, Извиняюсь за неточность, читать: то large object не реплицируются, при использовании логической репликации... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 14:18 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
fte Принципиальной разницы не вижу разница вот в чем: Код: html 1.
Если хранить файлы в просто в БД они кешируются в оперативной памяти, съедая ее полностью, что очень плохо сказывается на производительности. А хранить нужно сканы размер которых достигать несколько Мб. Соответственно уже при нескольких тысячах файлов они забивают всю оперативку. Вот и нужно решение - файлового хранилища. Даже репликацией я могу пожертвовать - реализовав ее через саму БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2020, 15:09 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Петр fte Принципиальной разницы не вижу разница вот в чем: Если хранить файлы в просто в БД они кешируются в оперативной памяти, съедая ее полностью, что очень плохо сказывается на производительности. А хранить нужно сканы размер которых достигать несколько Мб. Соответственно уже при нескольких тысячах файлов они забивают всю оперативку. Вот и нужно решение - файлового хранилища. Даже репликацией я могу пожертвовать - реализовав ее через саму БД. Нет. PG блобы умеет стримить там другие проблемы ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2020, 06:03 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
dimonz80, я так понял у вы так же столкнулись с выбором способа хранения файлов (pdf документов). На чем остановились? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2020, 21:16 |
|
File Streem в PostgreSQL
|
|||
---|---|---|---|
#18+
Петр dimonz80, я так понял у вы так же столкнулись с выбором способа хранения файлов (pdf документов). На чем остановились? Я уже сделал выбор когда-то давно: хранить в базе. В процессе эксплуатации выяснилось, что решение не очень удачное из-за частых удалений. Если бы файлы не удалялись или были бы сравнимы с размеров кортежа в pg_largeobject (2Кб), то все было бы хорошо. Для себя сделал выводы: 1) Если нет удалений (или их мало) или файлы не очень большие, то можно хранить в базе. В виде профита имеем согласованные бэкапы и потоковую репликацию. 2) Если есть постоянные удаления и объемы большие (т/е время на отдачу файла существенно, например стриминг видео), то лучше в хранить файлами Кроме того, в случае миллионов файлов в одной папке файловой системе тоже может быть не очень хорошо, в отличие от БД с миллионами записей в таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2020, 12:49 |
|
|
start [/forum/topic.php?desktop=1&fid=53&tid=1994629]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 291ms |
total: | 424ms |
0 / 0 |