Google App Engine - непомерно медленное и дорогостоящее резервное копирование и восстановление?

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

В одном из наших производственных приложений у нас есть около миллиона объектов со средним размером на объект размером 1 КБ. Таким образом, общий размер данных составляет около ГБ, что не должно быть большим делом, не так ли? Вот результат работы надвального загрузчика после извлечения объектов из движка приложения по умолчанию:

[INFO] 948212 объектов (608342497 байт), переданных в 47722.7 секунд

Это почти 13 часов. Поэтому, если бы мы захотели создать почасовую систему резервного копирования для наших производственных данных, это было бы невозможно для текущего инструментария GAE.

Стоимость - это еще одна история. Я попытался использовать администратор хранилища данных для копирования объектов в другое приложение, которое, как я думал, мы могли бы использовать для резервного копирования. Сначала я определил бюджет на 2 доллара США в день, который быстро исчерпал около 5000 объектов, а затем увеличил бюджет до 10 долларов США в день, который закончился, не приближаясь к тиражированию миллионов объектов.

Я, очевидно, не собираюсь тратить 100 долларов каждый раз, когда мне нужно возвращать данные на 1 ГБ, и я не хочу ждать часов (или даже дней) только для того, чтобы мои данные были скопированы. Поэтому либо я ничего не знаю, либо Google App Engine в настоящее время просто непрактичным способом писать масштабируемые приложения для качественного производства, которые можно легко скопировать и восстановить.

Есть ли быстрый и экономичный способ резервного копирования данных из приложения GAE?

Ответ 1

Это очень хороший вопрос. Я искал эту проблему, и я думаю, что Google Cloud Storage (Экспериментальный) будет лучше подходит для данных резервного копирования по следующим причинам. Я взял их с сайта Google, чтобы помочь вам получить некоторую информацию.

Google App Engine предоставляет более простой способ чтения и записи объектов Google Cloud Storage, что позволяет приложениям создавать и обслуживать объекты данных. Эти объекты хранятся в ведрах в облачном хранилище, но могут быть дополнительно доступны приложениями Google App Engine через Google Cloud Storage API. Вы можете взаимодействовать с Google Cloud Storage API с помощью интерфейса RESTful или с помощью API-интерфейса Google Cloud Storage Python для приложений приложений Google App Engine, который обсуждается в этом документе.

О ценообразовании:
Бесплатная квота: 5 ГБ памяти (это отлично подходит для вашего случая)
Платная квота: первая 0 - 1 ТБ $0,085/ГБ/месяц

Знакомство с облачным хранилищем Google

Ответ 2

Ставка на то, что вы нашли решение на данный момент Yasser, но для кого-то еще, заканчивающегося здесь из Google, вот обновленный ответ:

Опция резервного копирования в администраторе appstore была обновлена для поддержки хранилища данных и облачных хранилищ. Он также использует mapreduce для резервного копирования, что делает запрос намного легче в системе.

Ответ 3

По платежный документ GAE, вы должны платить за следующее:

Datastore:

1 query = 2 read operations
1 Mio entity queries = 2 Mio read operations
100k read operations = $0.07

Cost: 1M entities queried = $0.14

Bandwith:

Price: $0.12 / Gb  
Cost: 1Gb data with 50% overhead (network + metadata) = 1.5Gb x $0.12 = $0.18

Резервные экземпляры:

Price: $0.08/h smallest instance
Cost: 1h = $0.08

Общая стоимость: $0.40

Кажется, что bulkloader очень неэффективен. Вы можете пересмотреть свой собственный резервный код. Это должно быть легко, если у вас есть только один тип сущностей без отношений.

Ответ 4

Я бы сказал, что большая часть ваших расходов предназначена для записи данных в другое приложение, а не для чтения данных из вашего приложения. В зависимости от вашей модели данных стоимость записи объекта в хранилище данных может легко достигать 100x стоимости прочтения его на первом месте.

Так как резервное копирование редко восстанавливалось, я предлагаю вам вместо этого сохранить резервную копию в Blobstore. Рассоедините объекты, которые вы собираетесь делать резервными копиями в потоки байтов, разделите поток на куски по 1 МБ каждый, а напишите их все в blobstore,

Запись данных в блок blobstore по-прежнему стоит вам, когда вы создаете хранилище данных, но на основе fooobar.com/info/526448/..., кажется, что вы платите только 12 операций записи за хранение объекта blobstore, Предполагая, что каждый маринованный объект имеет размер ~ 2 КБ, и каждый сущность стоит 100 операций записи на хранение в хранилище данных, это означает экономию в стоимости записи на 99,97%.