There probably is a performance difference, but it's probably pretty small.
Here's what I found (all based on the the Google Docs for Python).
BigTable does not support PolyModel information natively. Instead, it's implemented using a 'class' property. So, when you try to perform a search, for example, to find a base class, you will be searching on this 'class' property.
All queries that use the PolyModel class have an extra filter applied that filters by the given class (using the 'class' property).
Any indexes created for a PolyModel class, must take into account the extra 'class' column.
Essentially, the PolyModel class takes care of the 'class' property on its own, inserting it into queries and utilizing for other queries. Other than that, it works identical to standard BigTable usage.
So, the difference is really just adding and maintaining one extra column.
Is there a performance difference? Yes, probably so. Every column you add to any database system is going to have a performance impact. But, is it significant? Probably not.
I'd like to chime in on what has been said in the question and in the comments.
XEROUND
Exactly one year ago today, I wrote an answer about the Xeround DB Service : Database as a service (DbaaS) over dimensions--performance, scalability, & reliability?
Granted, you have the following:
I just instantiated a Xeround Free Version Sevice and ran SHOW ENGINES; and got this
mysql> show variables like '%innodb%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| have_innodb | NO |
| ignore_builtin_innodb | OFF |
+-----------------------+-------+
2 rows in set (0.01 sec)
mysql> show engines;
+---------+---------+-----------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+---------+---------+-----------------------------------------------------------+--------------+------+------------+
| Xeround | DEFAULT | Xeround MySQL storage engine | YES | NO | NO |
| MyISAM | YES | Default engine as of MySQL 3.23 with great performance | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
+---------+---------+-----------------------------------------------------------+--------------+------+------------+
3 rows in set (0.01 sec)
mysql>
No InnoDB ??? Not much has changed.
How about variables for the Storage Engine?
mysql> show variables like 'xeround%';
+------------------------------------+-------------------------------------------+
| Variable_name | Value |
+------------------------------------+-------------------------------------------+
| xeround_alloc_pages | 1 |
| xeround_alloc_stats | 0 |
| xeround_conditional_filtering | off |
| xeround_conf_dir | etc |
| xeround_database_schema_size_limit | 2 |
| xeround_database_size_limit | 10 |
| xeround_enable_client_socket_check | ON |
| xeround_index_stat_is_approximate | ON |
| xeround_instance_id | 35644 |
| xeround_maintenance_mode | OFF |
| xeround_query_row_cache | 0 |
| xeround_record_count_adjust | 12 |
| xeround_records_in_range_mode | off |
| xeround_schema_id | 115 |
| xeround_throughput_credit | 100 |
| xeround_throughput_credit_seconds | 10 |
| xeround_transaction_memory_limit | 128 |
| xeround_transactional_ddl | OFF |
| xeround_xdapc_ip | |
| xeround_xdapc_socket | /opt/xeround/sys_35412/xdapc/xdapc_socket |
+------------------------------------+-------------------------------------------+
20 rows in set (0.01 sec)
mysql>
Looking at the API, I do not believe you can tune anything. You are basically at the mercy of the Storage Engine.
I have also tried loading data into it and using the INFORMATION_SCHEMA database to report back to me space usage. For the XEROUND Storage Engine, I get back nothing. MyISAM is OK.
There are still other limitations with Xeround (Oct 12, 2012) you have to read and consider.
Amazon RDS
While the service bears the hallmarks of a well-trusted brand name, the service must still be evaluated in terms of two things:
- Cost
- Configuration
- Performance
While cost is at one's discretion, I will discuss the other aspects
CONFIGURATION
- You have no access to a my.cnf
- Any variables to be configured beyond default requires an API call to the DB Parameters Group followed by a restart of the RDS Instance.
- There are two things you cannot change no matter what Memory Class you choose
- See my post from
Aug 02, 2012 : Local database vs Amazon RDS
PERFORMANCE
This goes hand-in-hand with CONFIGURATION. Any tuning aspects you wish to make are subject to the limitations and functionality of the RDS API. Not all Performance enhancements for InnoDB are possible because of Amazon's policies meant to provide a share-everything environment for normal RDS users (unless you can come up with more $$$ for more IOPs and things of this nature).
EPILOGUE
Amazon EC2 may be your best option if your want more flexibility/autonomy for
- configuring MySQL
- voluntarily paying
- tuning InnoDB
Given the times you just reported in the question, nothing short of due diligence is required for tuning (possibly rearchitecting) your app for Cloud Usage.
Best Answer
I'm also working with the GAE datastore right now, you should check this article if you haven't already. If you have found something useful, please update your question.
EDIT:
I found this today, check it out.