bench

@Dhruv - The significant increase in number of rows is because of throughput. The experiment was run for the same length for all three databases, but MemSQL sustained a higher throughput, resulting in more data inserted. Refer to the simulation code (https://github.com/memsql/bench/blob/master/benchmark.py) to see exactly what is going on. - We actually print information about row overhead to stderr/memsql_tracelog. The best way to find out is to run this experiment yourself :-) - Data gets inlined for smaller types.

Referring to https://github.com/memsql/bench/blob/master/sql_database.py , we use _mysql, not mysqldb. Here's some code that demonstrates: In [1]: import _mysql In [2]: c = _mysql.connect(host='127.0.0.1', user='root') In [3]: c.query("SELECT @@session.autocommit") In [4]: c.store_result().fetch_row(1) Out[4]: (('1',),)

> It seems as if it's designed for situations where you're doing a lot of table scans. This is not quite true. Lockfree data structure work exceptionally well for a lot of small concurrent reads and writes. If you look at the benchmarking code: https://github.com/memsql/bench/blob/master/sql_database.py you will notice that there are a lot of queries like "fetch by pk/guid". The trade-offs are: taking a hit the first time you run the query, being limited to the amount of RAM, limited set of features for this release. The benefits are throughput for "fetch by pk/guid" transactions and predictably low latencies.

Hey Dhruv, In the case of the 24 core machine... The database is initialised with 560000 players. For every action an event is written to the database, so at the end of the 10 minute run there are ~aps * 600 = 1.2 million rows for MySQL and 40 million rows for MemSQL. Then there's the active games: MySQL ends with a million active games, and MemSQL ends with the steady of 5.6 million games. The total number of rows at the end is around 2.8 million for MySQL and around 48 million for MemSQL. MySQL VSZ ends and peaks at 6 gB, RSS ends and peaks at 2GB. For MemSQL, the RSS and VSZ end and peak at 18 gB and 19 gB, respectively. MySQL keeps each of the 24 cores at 25% utilization. MemSQL runs with all cores at 100%. On the 8 core machine, MySQL keeps each core 80% utilized. The number of inserts and queries can be easier explained when looking