Когда обсуждают Google AppEngine и его стоимость, то обычно ведут речь об оплате процессорного времени. Изначально биллинг считал, сколько процессорного времени тратилось на обработку запросов, и за эти самые секунды выставлял счёт. В последствии, когда AppEngine вышел из стадии бета-тестирования, модель поменялась: Google стали брать за время работы инстансов, обслуживающих запросы. Но это всё на самом деле не интересно, и заметка будет совсем о другом :)
Один из основных компонентов AppEngine — это хранилище данных. Стандартным для новых приложений является High Replication Datastore, о нём и пойдёт речь. Замечу, что есть ещё Google Cloud SQL (по сути — «MySQL в облаке»), но он пока что находится на стадии тестирования, и сколько он будет стоить через год, ещё неизвестно довольно дорогой, да и кому этот SQL нужен (шутка). Модель рассчётов за использование хранилища данных такова:
|
|
Стоимость
|
Бесплатная квота
|
|
Хранение данных
|
$0.24/гигабайт/месяц
|
1 гигабайт
|
|
Операции записи
|
$0.10 за 100k операций
|
50k операций/день
|
|
Операции чтения
|
$0.07 за 100k операций
|
50k операций/день
|
|
«Малые» операции
|
$0.01 за 100k операций
|
50k операций/день
|
В приведённой выше таблице под операцией чтения или записи имеются в виду низкоуровневые операции. К примеру, выполнение запроса к базе — это одна операция чтения + операция чтения на каждую возвращённую запись. Если же делать запрос, возвращающий не записи, а только ключи, то это будет посчитано как операция чтения + малая операция на каждую запись. Создание новой записи — это 2 операции записи + 2 операции записи на каждое индексированное поле + 1 операция записи на каждый композитный индекс.
Тут мы приходим к интересному выводу: если вы пробуете делать различные «игрушечные» проекты на AppEngine (чем я занимался в последнее время), и не хотите выходить за пределы бесплатных квот, то приходится довольно сильно ограничивать себя в количестве объектов, которые хочется поместить в базу: стоит туда запихнуть какую-то тысячу записей, как вы уже приближаетесь к суточному пределу операций записи. А если эти объекты ещё и должны несколько раз обрабатываться в течении дня, то уж точно нужно задумываться о переходе на платную модель.
Для серьёзных проектов, конечно, желательно приблизительно знать, с каким объёмом данных вам придётся работать в течении дня, и во сколько это будет обходиться. В принципе, можно очень приблизительно прикинуть, что запись несколько тысяч объектов (в пределах одной Django-модели) будет обходиться в 10 центов, что в принципе не так уж и много. Учитывая, что перейдя на платную модель, приходится тратить не менее 8 долларов в месяц, в пределах этого бюджета можно оперировать довольно большими объёмами данных.
На самом деле, при определённых объёмах данных (несколько тысяч записей) довольно легко хранить их в обыкновенных списках и словарях, которые можно сериализовать в JSON или pickle-объекты, и хранить в memcache, время от времени сохраняя в базу. Для волатильных данных такой подход будет очень даже актуален.
Самое главное — данная модель ценообразования основана на принципе «плачу за то, что использую». Если в один день у вас большой поток данных, то на следующий вы вполне можете уложиться в бесплатные квоты, никакие настройки при этом менять не надо. Amazon Dynamo DB, к примеру требует резервировать определённый набор ресурсов, и постоянно за них платить. Если на том же Amazon EC2 хостить инстансы с MongoDB, то принцип тарификации будет тот же. В итоге, использование AWS требует определять максимальную нагрузку, и всегда её оплачивать, с AppEngine’овским же датастором вы задаёте лимиты, но платите только за те ресурсы, которые потребили.
View Comments
