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
MySQL has a built-in functionality called MySQL replication that allows the synchronisation between 2 servers, by applying on a "slave" the operations that have been done on the "master". If no writes are done on the slave, that works pretty well and, while it has its issues, it is widely used by most MySQL users (Facebook, Twitter, etc.) for high availability, load balancing and/or testing/maintenance operations.
It is very easy to setup and has little performance impact, as it is asynchronous by default. That makes possible to perform the replication in real time or in batches, as desired.
Please note that while all "Infraestructure as a service" allows replication, some "database as a service" providers do not allow to do it outside of their servers (for example, RDS only allowed it in MySQL 5.6 servers).
If you need to write to the slave (your intranet server), that would be more complex, as you have to make a plan on how to merge the results and modify the replication settings or use an alternative technology.