Is Google App Engine so good?
On Habré did not find a lot of criticism on GAE, more and more positive reviews (for example, here and here ). Therefore, I want to diversify the situation a bit, describing some critical nuances that hinder the full-scale work in the cloud.
I use GAE for a relatively short time, about six months. Until recently, these were simple sites with static content. For them, GAE is ideal - low traffic, which does not exhaust free quotas + java. Any html / javascript web application is poured quickly and conveniently using maven. You write mvn gae: deploy and in a minute your application is already in the cloud.
It is time to use the database a little more actively for a new project, and then the rake began. Since the application is automatically scaled, it becomes necessary to synchronize data between the instances. For these purposes, a database is often used plus caching in an application or external tool (memcache). However, with this approach, free quotas for DataStore operations end very quickly. Currently, there are only 50,000 write operations and as many reads per day. Of course, if necessary, quotas can be purchased. Below is the cost quota DataStore.
')
Unfortunately, if you need to put 1 record in a table with two indices, then the number of write operations is not 1, but 6. Update 1 record will consume 9 write operations. To make it more clear, I provide a table on the expenditure of operations when working with a database.
Thus, it turns out that even taking into account optimization and caching in memcache, on average, about 30 datastore operations are spent per user request. In other words, free quotas are only enough for ~ 1600 user requests. We add to the user requests work with the database on cron tasks - it becomes very hard.
The situation is further aggravated by the fact that there are no unique keys in the DataStore, and when scaling the system, it is necessary to check the uniqueness of records manually before or after adding data to the database. Although this is a common thing for scalable systems, it additionally increases the load on the database, the quotas of which are already costly.
While dealing with limitations in GAE, I found a curious article on the Carlos Ble blog - Goodbye Google App Engine and a similar section on the GAE Cupboard . To the known limitations immediately added a few more, to which I have not yet reached. At once I will say that some of the problems described in GAE have already been fixed, but a considerable proportion of them remained:
Total:
While the code is not strongly tied to GAE, I turn to Linode. Then I will tell you what and how.
I use GAE for a relatively short time, about six months. Until recently, these were simple sites with static content. For them, GAE is ideal - low traffic, which does not exhaust free quotas + java. Any html / javascript web application is poured quickly and conveniently using maven. You write mvn gae: deploy and in a minute your application is already in the cloud.
It is time to use the database a little more actively for a new project, and then the rake began. Since the application is automatically scaled, it becomes necessary to synchronize data between the instances. For these purposes, a database is often used plus caching in an application or external tool (memcache). However, with this approach, free quotas for DataStore operations end very quickly. Currently, there are only 50,000 write operations and as many reads per day. Of course, if necessary, quotas can be purchased. Below is the cost quota DataStore.
')
| $ 0.10 | 100,000 write operations |
| $ 0.07 | 100,000 reads |
| $ 0.01 | 100000 small operations |
Unfortunately, if you need to put 1 record in a table with two indices, then the number of write operations is not 1, but 6. Update 1 record will consume 9 write operations. To make it more clear, I provide a table on the expenditure of operations when working with a database.
| High-Level Operation | Low-Level Operations Required |
|---|---|
| Read 1 entry (Entity Get) | 1 read |
| Add 1 entry (New Entity Put) | 2 writes + 2 writes per indexed property value + 1 writes per composite index value |
| Update 1 record (Existing Entity Put) | 1 write + 4 writes per modified indexed property value + 2 writes per modified composide index value |
| Delete 1 entry (Entity Delete) | 2 writes + 2 writes per indexed property value + 1 writes per composite index value |
| Request multiple entries (Query) | 1 read + 1 small per entity retrieved |
| Request keys only (Query, keys only) | 1 read + 1 small per key retrieved |
| Key creation (Key allocation) | 1 small |
Thus, it turns out that even taking into account optimization and caching in memcache, on average, about 30 datastore operations are spent per user request. In other words, free quotas are only enough for ~ 1600 user requests. We add to the user requests work with the database on cron tasks - it becomes very hard.
The situation is further aggravated by the fact that there are no unique keys in the DataStore, and when scaling the system, it is necessary to check the uniqueness of records manually before or after adding data to the database. Although this is a common thing for scalable systems, it additionally increases the load on the database, the quotas of which are already costly.
While dealing with limitations in GAE, I found a curious article on the Carlos Ble blog - Goodbye Google App Engine and a similar section on the GAE Cupboard . To the known limitations immediately added a few more, to which I have not yet reached. At once I will say that some of the problems described in GAE have already been fixed, but a considerable proportion of them remained:
- The request cannot be performed for more than 30 seconds. Especially critical for maintenance, for example, when backups or upgrades.
- Cannot execute a DELETE FROM tableA WHERE conditionB query. All entries are deleted piece by piece and it costs a lot of money.
- The database does not support queries of the form “LIKE” - denormalization of the base and pagination is necessary.
- Can not join'it table.
- The base is very slow.
- The behavior of the database in a local environment is different from the behavior in the cloud.
- Periodic crashes in DataStore and MemCache. For MemCache it's not scary, but losing data in the database is critical. With backup is also hard - backup of 50,000 records exhausts free quotas for DataStore per day, plus there is a limit of 30 seconds per operation. Give Google $ 100 for backup of your base? Yes Easy!
Total:
- GAE is ideal for personal pages or business card sites (free and reliable hosting).
- If you need a little database, the cost of hosting increases from free to $ 50 / month or more.
- In the presence of a large number of static pages, it is better to use a regular VPS with nginx.
While the code is not strongly tied to GAE, I turn to Linode. Then I will tell you what and how.
Source: https://habr.com/ru/post/150123/
All Articles