Назад | Перейти на главную страницу

Лучшая практика для хранения данных экземпляра только для чтения?

Итак, в настоящее время я пишу свою бакалаврскую диссертацию, и моя работа заключается в облачении веб-сервиса, который рекомендует саундтрек для изображений. Основная часть процесса рекомендации - это поиск в индексном файле размером ~ 40 ГБ. Индексный файл доступен только для чтения, и его чтение должно быть максимально быстрым. Я также хочу автоматически запускать дополнительные экземпляры по запросу. Я провел небольшое исследование и у меня есть 3 возможных способа сделать это

  1. Увеличьте корневой раздел экземпляра ec2 (до ~ 50 ГБ), сохраните индексный файл в корневом разделе и создайте AMI. Преимущество этого подхода состоит в том, что очень легко запустить новый экземпляр, поскольку все включено в AMI. Но я также читал, что скорость корневого раздела очень низкая.
  2. Сохраните данные на томе EBS, создайте его снимок, и всякий раз, когда я запускаю новый экземпляр, я создаю новый том EBS из снимка и присоединяю его к экземпляру. Я полагаю, это лучший способ сделать это, но запуск нового экземпляра немного сложнее
  3. Сохраняя индексный файл на S3, и всякий раз, когда запускается новый экземпляр ec2, я загружаю файл в временное хранилище экземпляра. Проблема с этим подходом заключается в том, что до того, как новый экземпляр станет работоспособным, требуется больше времени, а также затраты на трафик.

Я также думал о настройке Raid0, чтобы улучшить производительность чтения индексного файла. Итак, какой подход я должен использовать?

Номера комментариев соответствуют указанным выше вариантам.

  1. Я всегда рекомендую размещать данные на отдельном томе EBS из корня, но если он доступен только для чтения и его легко получить при создании AMI, я могу сделать исключение. Я не понимаю, почему корневой том EBS должен быть медленнее, чем любой другой том EBS.

  2. Это легко, если вы правильно настроите свой AMI. См. Параметры настройки блочных устройств в регистре ec2. Amazon может автоматически создавать тома для вас на основе снимков состояния и прикреплять их к новому экземпляру, как это делается для корневого тома.

  3. За трафик между экземплярами EC2 и S3 в конечной точке, относящейся к региону, плата не взимается. За тома EBS и ввод-вывод для томов EBS взимается плата.

Тот факт, что том EBS, созданный из моментального снимка, готов к использованию до завершения полной загрузки большого файла из S3, не обязательно означает, что EBS работает быстрее. Том готов к приему операций почти сразу, но вы будете испытывать высокий уровень iowait, пока блоки заполняются из снимка.

В зависимости от требований к производительности вашего приложения вам может потребоваться «разогреть» том EBS, прежде чем вы сможете запустить его в производство. Фактически это то же самое, что загрузить его с S3. (Мне бы хотелось увидеть несколько тестов производительности этих опций.)

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

В зависимости от того, что вы индексируете и как вы к нему обращаетесь, вы также можете взглянуть на SimpleDB, RDS, ElastiCache.

Этот веб-сервис уже существует, или вы что-то делаете, или ...? Потому что мой ответ был бы совсем не затуманивать его. Я бы получил приличный сервер с SSD для максимальной производительности чтения.

Но вам также необходимо выяснить, что вы получаете с «облачной» стороны. «Облака» просто позволяют вам создавать множество экземпляров в географически разнообразных центрах обработки данных; даже в этом случае вы не гарантируете, что ваши конечные пользователи получат хорошее время отклика (как в случае с Amazon, как обеспечить стабильную производительность, если кто-то зайдет на ваш сервер в центре обработки данных в Нью-Йорке, а ваш клиент находится в Австралии?)

Где ваши узкие места в производительности и как разделить элементы для повышения производительности? О чтении с диска позаботятся SSD. «Облака» не увеличивают производительность волшебным образом; это во многом функция архитектуры приложения. Я не тестировал его и хотел бы знать общие цифры, если у кого-то есть, но предложение запускать различные экземпляры по запросу, когда вы ищете повышенную производительность, похоже, повлечет за собой большие накладные расходы, которые снизят производительность вашей базы данных.

Кроме того, вы сосредотачиваетесь на диске, когда вам, возможно, захочется взглянуть на кеширование @ #% из него. Независимо от того, насколько высока производительность вашего диска, вы не сможете обогнать хороший набор серверов кэширования, чтобы сохранять записи в памяти «горячими» по сравнению с «холодными» на диске. Опять же, функция архитектуры приложения. И это еще одна вещь, которая может навредить вам при запуске большего количества виртуальных машин; раскручивание виртуальных машин может уничтожить кеши и вызвать задержку до того, как кеши будут "загружены", так сказать.

Если вас беспокоит скорость, я предлагаю использовать InstanceStore, а не EBS.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html