You've never written a relational database application with millions of rows of data that is queried, inserted and updated at a high rate and that needs to be (pseudo) real time, have you?
you're mistaken. I designed and now maintain 2 such dbs. One of them has tens of millions of rows in some tables (this one is mssqlserver on some 2 year old 2 x quadcore). The other has millions of rows in one of the main tables. I run quite complicated search and update queries on that one (based on http requests). Performance simulations showed >40 of the most complicated search/update/insert_into_multiple tables combos per second on. While production is deployed on ok hardware (single quadcore), these performance tests were done on a fucking single ATOM 350 (dualcore) with nfs-mounted volumes (!!). No oracle magic either, just simple mysql innodb.
For reference: mtgox aggregated order book (acquired by fulldepth api call) currently has about 10,000 entries. Can't be more than 50,000 individual orders in the orderbook.
Maybe I'm missing something, but I still think I could do it on my nexus 4.
Anyone knows how Gox moves people's deposits around? If you use http://www.bitcoinmonitor.com/ , you would notice that whenever a trade is executed, a lot of transfers take place on the blockchain, in principle it should be just bookkeeping, no real transaction should happen. I don't know why and if it has anything to do with their sluggishness.
Anyone who could answer my question?
No. The trade engine doesn't concern itself with the blockchain
