Так что с файлами в базе в 2018, хранить или нет?

[katit]

Вот мы храним(SQL 2008) но появляются кое-какие проблемы. Размер базы есс-но растет, тяжелее с бэкапами.
Производительность системы вроде как не проблема, все работает хорошо, но может и есть проблема а мы не знаем (ну типа если бы файлы были на диске то меньше ресурсов все жрало бы)

В нашем случае файлы это фотки и документы. Размером до пару метров. Но много.

Вот это актуально или сегодня все в базе хранится?
https://web.archive.org/web/20150216014 ... ystem.html

В нашем случае все хостится в Амазоне, я думаю сделать следующее:
1. Убрать файлы в S3, красиво их там по каталогу раскидать
2. Дать клиентам доступ R/О к каталогу. Таким образом они смогут все файлы смотреть не только из аппликухи
3. Смогу там-же создавать "архив" т.к. у нас есть палици на хранение файлов.

Т.е. реально просто на уровне подсознания напрягает размер баз и "невидимость/недоступность" файлов когда они в базе. Стоит заморочиться и вынести в FS?

[VovaK98]

В нашем случае все хостится в Амазоне, я думаю сделать следующее:
1. Убрать файлы в S3, красиво их там по каталогу раскидать
2. Дать клиентам доступ R/О к каталогу. Таким образом они смогут все файлы смотреть не только из аппликухи
3. Смогу там-же создавать "архив" т.к. у нас есть палици на хранение файлов.

Т.е. реально просто на уровне подсознания напрягает размер баз и "невидимость/недоступность" файлов когда они в базе. Стоит заморочиться и вынести в FS?

Главный плюс S3 - это существенное удешевление хранения и доступа по сравнению с сервером и тем более хранением в db, хоть бы и на том же AWS. Другой офигенный плюс - это децентрализованность S3. Или, другими словами, "облачность".
Еще один плюсик, который я у себя еще не имплементировал, но собираюсь - можно напустить Lambda на этот S3 и автоматизировать, скажем, создание thumbnails.

По поводу №2 - любой открытый доступ к AWS S3, даже R/O, чреват последствиями. Если один клиент, скажем, выложил где-то в открытом доступе линк на принадлежащий им внутренний документ, который вдруг прочтёт другой кастомер - вот и готовый litigation. Чтобы избежать этого, средствами S3 API весьма просто формируется pre-signed link с ограничением по времени.

№3 - для архивации можно даже в glacier заливать. Ну или удалять файлы. Удаление по времени, помнится, в S3 конфигурируется в 2-3 клика.

В обычной FS гораздо меньше преимуществ перед хранением документов в DB, если вообще какие-то есть.

[katit]

Главный плюс S3 - это существенное удешевление хранения и доступа по сравнению с сервером и тем более хранением в db, хоть бы и на том же AWS.

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

По поводу №2 - любой открытый доступ к AWS S3, даже R/O, чреват последствиями. Если один клиент, скажем, выложил где-то в открытом доступе линк на принадлежащий им внутренний документ, который вдруг прочтёт другой кастомер - вот и готовый litigation. Чтобы избежать этого, средствами S3 API весьма просто формируется pre-signed link с ограничением по времени.

Ну да. Тоже проблема. Но и не хочется на самом деле углубляться в их API хотя бы чтобы небыло vendor lock. Т.е. если и будем использовать то как FS, разве что сделаем "прослойку" чтобы потом если что легко уйти.

№3 - для архивации можно даже в glacier заливать. Ну или удалять файлы. Удаление по времени, помнится, в S3 конфигурируется в 2-3 клика.

Мне недавно родственник рассказывал ужасы как он в глациер загрузил свои архивы. И сколько это стоило и как потом было геморно(дорого) их просто удалить
Мне надо держать файлы только определенное время. Но я планирую пока это немного стOит держать все что есть. Но сказать клиентам (уже сказано) что мы держим вот за такое-то время. Все остальное идите и качайте. Можем удалить когда нам захочется. Думал делать бэкапы в зип помесячно и давать доступ на скачку. А потом их удалять через какое-то время

В обычной FS гораздо меньше преимуществ перед хранением документов в DB, если вообще какие-то есть.

Но я именно и рассматриваю FS как альтернативу. Просто легче увидеть файл если надо, меньше базы..

[tessob]

Дать клиентам доступ R/О к каталогу.

Там еще можно заставить S3 работать как раздавалку статического веб контента. Т.е. оно начнет обрабатывать веб запросы к файлам как Nginx, но все это включается "одной галочкой". Рекомендую глянуть этот кейс в документации.

[VovaK98]

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

У меня есть сайт с ~60GB/day траффиком, который практически нереально весь держать на MSSQL на EC2, можно разориться. Поэтому база в Win+SQL на t2-small EC2, а аттачменты на S3. Цена вопроса в месяц - $35-45 за всё.

По поводу №2 - любой открытый доступ к AWS S3, даже R/O, чреват последствиями..

Ну да. Тоже проблема. Но и не хочется на самом деле углубляться в их API хотя бы чтобы небыло vendor lock. Т.е. если и будем использовать то как FS, разве что сделаем "прослойку" чтобы потом если что легко уйти.

Логично.
Я у себя имплементировал оба варианта хранения файлов, а затем добавил переменную в web.config. Сейчас она установлена на S3. Кроме того, в каждой записи в SQL таблице FILES добавил флаг isaws=true/false. Надоест, или найду хороший colocation дил - переключу обратно в local FS, и сайт постепенно сам переползёт на локалку.

На самом деле, S3 API call там тривиальный. В 10 строк кода:
https://docs.aws.amazon.com/AmazonS3/la ... etSDK.html

Мне недавно родственник рассказывал ужасы как он в глациер загрузил свои архивы. И сколько это стоило и как потом было геморно(дорого) их просто удалить
Мне надо держать файлы только определенное время. Но я планирую пока это немного стOит держать все что есть. Но сказать клиентам (уже сказано) что мы держим вот за такое-то время. Все остальное идите и качайте. Можем удалить когда нам захочется. Думал делать бэкапы в зип помесячно и давать доступ на скачку. А потом их удалять через какое-то время

Про Glacier не знаю, никогда не использовал. Хотя и он эволюционирует неплохо. Сейчас они обещают восстановление из Glacier в течение 5ти минут.
Мне вполне достаточно того, что S3 размазан в пространстве. Для супернадежного бекапа достаточно включить репликацию в другую availability zone (читай: другой датацентр в том же регионе). Ну и на десерт можно вообще на другой регион на другое побережье реплицировать. Все операции с S3 весьма cost-efficient.
EC2 instance я периодически копирую в AMI.

[VovaK98]

Дать клиентам доступ R/О к каталогу.

Там еще можно заставить S3 работать как раздавалку статического веб контента. Т.е. оно начнет обрабатывать веб запросы к файлам как Nginx, но все это включается "одной галочкой". Рекомендую глянуть этот кейс в документации.

Да.
Но тогда уж договаривайте про репликацию вёдер во CloudFront. Ещё дешевле будет.
Если S3, к примеру, $1/mo, то CloudFront будет центов 5-10 за тот же траффик. Да и контент будет выдаваться с бешеной скоростью с оптимизацией по регионам.

[katit]

У меня есть сайт с ~60GB/day траффиком, который практически нереально весь держать на MSSQL на EC2, можно разориться. Поэтому база в Win+SQL на t2-small EC2, а аттачменты на S3. Цена вопроса в месяц - $35-45 за всё.

У нас уже сильно больше, но это за ресурсы а не за хранение. Причем MSSQL стоит на моей лицензии, сервер просто Win

Надоест, или найду хороший colocation дил - переключу обратно в local FS,

В нашем случае AWS это брэнд, думаю на цоло никогда не перейдем, хотя уже было бы дешевле. Но клиентам нравится слово "Амазон"

[katit]

О, похоже что у Амазона есть продукт как раз как надо. CloudFront позволит клиентам качать архивы

https://stackoverflow.com/questions/309 ... entication


Хотя мне больше вот это нравится:
https://docs.aws.amazon.com/cli/latest/ ... esign.html

Ну да, не супер как секьюрно, но наверное ОК? Показать народу список файлов. Они тыкают, создаю линк на 5 минут к примеру. Они тыкают и скачивают.
Никаких вроде проблем нет с таким подходом? Теоретически если все через SSL то никакие хакеры линк не перехватят а за 5 минут не подберут.

[VovaK98]

Хотя мне больше вот это нравится:
https://docs.aws.amazon.com/cli/latest/ ... esign.html

Ну да, не супер как секьюрно, но наверное ОК? Показать народу список файлов. Они тыкают, создаю линк на 5 минут к примеру. Они тыкают и скачивают.
Никаких вроде проблем нет с таким подходом? Теоретически если все через SSL то никакие хакеры линк не перехватят а за 5 минут не подберут.

Именно так. См ПМ.

[katit]

Файлы таки убрал из базы, все вроде работает. Плохо только то что всеравно они достаются через моы веб сервер когда клиенту надо. Потом подумаю как сделать может через их REST API чтобы клиент с S3 напрямую скачивал, по идее нагрузка на мой сервер упадет здорово.


Вопрос по MS SQL на амазоновском RDS. Стоит или нет? У меня лицензия есть и я сервер поставил и сам им занимаюсь. Как этот RDS работает? Они просто дают IP и там можно создавать сколько угодно баз? Есть ли смысл?

[VovaK98]

Файлы таки убрал из базы, все вроде работает. Плохо только то что всеравно они достаются через моы веб сервер когда клиенту надо. Потом подумаю как сделать может через их REST API чтобы клиент с S3 напрямую скачивал, по идее нагрузка на мой сервер упадет здорово.

Дык вроде же ты и при чтении генеришь signed URL, а дальше редирект юзера на S3, откуда они уже и сливают файл. Или я ошибаюсь ?
Я тут недостатков особо не вижу. Наоборот, плюс такой архитектуры не только в разграничении доступа к файлу, но и статистика, и geolocation (у меня).

Вопрос по MS SQL на амазоновском RDS. Стоит или нет? У меня лицензия есть и я сервер поставил и сам им занимаюсь. Как этот RDS работает? Они просто дают IP и там можно создавать сколько угодно баз? Есть ли смысл?

Я сам сейчас в процессе переезда на RDS, но в другом проекте. Мне кажется, в RDS таки есть ограничения по доступу к базе, и вот эти детали я сейчас выясняю. К концу недели, скорее всего, буду уже полностью в курсе.

Вкратце, делается бекап базы в BAK файл, заливается в bucket, потом из RDS восстанавливается в базу. RDS даёт тебе типа connection string, и в бой. Цена вопроса начинается от $30/mo.

Смысл в том, что они сами бекапят и вообще поддерживают базу в рабочем состоянии, индексы ребилдят, итп. Опять же, не надо грузить свой EC2 инстанс лишними процессами.
У себя на EC2 можно продолжать юзать SQL Mgmt Studio или любой другой клиентский пакет, из которого можно работать с базой в RDS как локальной.

По самым свежим слухам (я был 13го на Atlanta AWS summit) у них Aurora мощно продвинулась в производительности. Теперь она чуть ли не на 2 порядка быстрее самого шустрого MySQL кластера. Я этот вопрос тоже внимательно изучаю.

[alex_127]

Скорее всего вы говорите про aurora parallel query (pushdown of scans, filters, etc to storage nodes). Это очень круто но это не для всех - пожалуйста не ожидайте что вообще все внезапно стало в 100 раз быстрее. С радостью разберусь если что то не так работает.

[VovaK98]

Скорее всего вы говорите про aurora parallel query (pushdown of scans, filters, etc to storage nodes). Это очень круто но это не для всех - пожалуйста не ожидайте что вообще все внезапно стало в 100 раз быстрее. С радостью разберусь если что то не так работает.

Чувак вроде вещал про write transactions. См фото. Но я могу ошибаться в деталях.
(Синие графики - MySQL, оранжевые - Aurora)

aurora_performance.jpg

[katit]

Дык вроде же ты и при чтении генеришь signed URL, а дальше редирект юзера на S3, откуда они уже и сливают файл. Или я ошибаюсь ?

Нет, пока у меня написана прослойка которая в зависимости от конфига пишет и читает файлы либо из базы либо из S3 или FS
Файлы сами мелкие, документы в основном. Доступ частый, как-то стремно генерить signed URL. Я планировал задействовать signed URL для месячных архивов, те побольше.

Проблема в том что мы до сих пор на Silverlight, а я из него не могу REST использовать. Как только переползем сразу сделаю чтобы сами файлы через мой сервер не шли.

Я сам сейчас в процессе переезда на RDS, но в другом проекте. Мне кажется, в RDS таки есть ограничения по доступу к базе, и вот эти детали я сейчас выясняю. К концу недели, скорее всего, буду уже полностью в курсе.

Я уже выяснил. Лимит - 30 баз. У нас уже больше. Таким образом их РДС-ов не напасешься. Сейчас у нас больше нагрузка на веб сервер чем на базу.. Все бекапы и т.д. уже и так настроены. Ладно, с этим пока расслаблюсь. Мне там понравилось только replication into multiple zones. Но можно и самому настроить. По деньгам нифига не дешево..