Комментарии 11
Молодцы, что справились, конечно. Но мне сама идея хранения файлов в базе кажется очень странной. Подключить s3 сразу сейчас к любому фреймворку очень просто и интересно, почему сразу так не сделали.
Изрядно покопавшись в чертогах разума, так и не вспомнил аргументов к такому решению. И вы абсолютно правы, такое решение было не просто странным, оно было ошибочным. Однако мы ошибок не боимся, признаем их и всегда готовы исправлять
ну бывает, сперва в базу тексты кладут, потом фоточки, а потом понеслась
Если я правильно понял:
- изначально архитектор решил хранить бинарники в базе.
- баз было 2+.
- данных вместе с бинарниками в 1TB???.
Когда базы начали закономерно тупить вы решили:
- перенести бинарники в S3, хостимый в облаке
- объединить все базы на единый сервер или кластер, также хостимый в облаке.
Я бы постеснялся это решение описывать как красивое.
За хранение бинарников в базе архитектора на курсы.
Переход в облако с имеющегося железа - решение для 2014, но не 2024, когда достоинства и недостатки on-prem vs cloud в детских книжках.
S3 можно поднять локально, или просто файловое хранилище.
Некоторые базы поддерживают работу с файлами как File Storage - бинарники на диске с контролем из базы.
Спасибо за комментарий!
Вся инфраструктура нашей компании хостится в Облаке, поэтому мы ничего не уносили с железок.
Насчет просчета с хранилищем на старте, даже не буду спорить, я честно описал наш провал )
Наше решение тоже не претендует на роль красивого, оно оптимальное и больше рассказывает как мы проделали работу над ошибками прошлого. И, как мы видим спустя время, не без спотыканий на старте мы справились
Некоторые базы поддерживают работу с файлами как File Storage - бинарники на диске с контролем из базы.
А можно примеры? особенно из opensource
Фраза "Перенос в S3 удешевил затраты на хранение файлов в шесть раз" - мало говорит о реалиях, стоимость одного терабайта хранения сейчас может быть несколько тысяч рублей. Стоимость труда программиста для выполнения миграции может быть сильно выше годовой экономии.
Спасибо, это очень точное замечание. Но я постарался этот вопрос раскрыть в тезисе:
При подготовке процесса стоит учитывать, что и перенос файлов в S3, и миграция БД в кластер обычно не требуют много ресурсов. В нашем случае один разработчик оказался вполне способен в спокойном режиме перевезти один сервис за день.
То есть, сама процедура не трудозатратная при внимательном подходе. Мы немного поспешили и один раз вляпались, дальнейшие шаги прошли гладко. В дополнение - экономия тут кроется не только в ресурсах на хранение файлов, но и в ресурсах на поддержку постоянно растущих и, как следствие, подтупливающих баз.
Можете рассказать, пришлось ли что-то настраивать для поддержки достаточного максимального числа соединений к кластеру по сравнению с 13 отдельными базами?
Наводим порядок с базами данных. Переносим файлы в S3, мигрируем в единый кластер