Где в AWS хранить большие фрагменты HTML-контента, связанного с записями базы данных - PullRequest
0 голосов
/ 26 ноября 2018

У меня есть веб-приложение, которое использует записи базы данных MySQL для отображения страниц.

Каждая запись имеет следующее:

  • ID (первичный ключ)
  • Дополнительные поля различных типов (целое, varchar, long и т. Д.)
  • Поле типа text (или mediumtext) для хранения фрагментов статического HTML, отображаемого на странице

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

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

База данных MySQL работает в AWS RDS.Итак, я подумал об использовании другого сервиса AWS для хранения текстовых данных.Итак, мои текущие параметры:

  • Сохраняйте все в MySQL, не беспокоясь о размере таблицы (в настоящее время она приближается к 1 гигабайту и быстро растет).
  • Используйте объекты S3 для текстовых данных HTML иссылаться на них либо по первичному ключу, либо по типу UUID, который хранится в таблице
  • Использовать DynamoDB для текстовых данных HTML и ссылаться на значения с ключами, хранящимися в базе данных (или по тому же первичному ключу)

Меня беспокоит вариант 1 - размер таблицы.Проблема с вариантами два и три связана с проблемами синхронизации и необходимостью сделать дополнительный вызов на стороне сервера для получения данных при отображении страницы.Насколько я понимаю, что DynamoDB будет быстрее, чем S3 для извлечения данных, но он имеет ограничение по размеру для каждой записи и может стать дорогостоящим и беспорядочным в работе с единицами емкости и тому подобным.

Любое руководство поможет.Благодарю.

1 Ответ

0 голосов
/ 26 ноября 2018

Я думаю, что вы точно определили компромиссы между DynamoDB и S3.

Я думаю, что самое простое решение - использовать S3.Синхронизация между S3 и MySQL не так сложна или подвержена ошибкам, как вы думаете.Одно из приложений, над которыми я профессионально работаю, использует эту стратегию (для другого варианта использования), и у нас никогда не было никакого операционного бремени, связанного с несинхронизацией данных S3 из нашей основной базы данных.

Да, задержка от S3 выше, чем у DynamoDB.Вы можете ожидать <10 мс от DynamoDB против десятков до нескольких сотен миллисекунд от S3 (при условии, что объект <= 400 кБ, предел размера элемента DynamoDB).Однако S3 не требует от вас предоставления емкости, и практически не существует ограничений на размеры файлов.(Технически, один файл не может быть больше 5 ТБ, но вы вряд ли достигнете этого в этом случае.) </p>

Если вы не знаете, что вам нужно задержка в одну цифру миллисекунды , вы должны использовать S3.Он предназначен именно для этого.

S3 гарантирует строгую согласованность при создании объекта, но только возможную согласованность при его обновлении.Если это вас беспокоит, убедитесь, что вы просто создаете новый объект каждый раз, когда вы обычно его обновляете.Так как вы храните ключ в своей базе данных, вы не привязаны к определенному имени файла, и каждый раз, когда вы изменяете html, легко генерировать новый ключ.

Если вы строите его с S3, и задержка оказывается слишком высокой, вы можете поместить кеш перед S3 или вы можете попробовать перейти на модель без сервера, используя Lambda @ Edge с CloudFront для обслуживания статическогоресурсы от S3.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...