Tesmond's Useful Design

As I alluded to in my previous post there are many reasons to pick a database, performance is only one of them, but as it is the easiest to objectively assess that it where I am starting. So here is a quick look at query performance. So we have our 1,010,000 strong pair of databases. So how about a count of the number of editions which have a 1 in them (about 47000). MongoDB - 0.906 seconds Intersystems Cache - 2.247 seconds Well MongoDB takes a healthy lead in this respect. It should be said that by default MongoDB has its own query language, where as Intersystems Cache can be accessed through iteration or via SQL queries. Now I could have biased the query strategy, for example Intersystems Cache is significantly faster at selecting whole phrases, e.g. searching a specific property which appears multiple times can be returned faster that MongoDB, but in both cases I was looking at 0.010 seconds VS 0.007 seconds. It was consistently faster although it was in the magnitude of...

While looking through stackoverflow I noticed an interesting question about the differences between Intersystems Cache and MongoDB. Now these databases are substantially different in many respects, but both do allow for a more direct object mapping approach than you will normally experience in a standard SQL environment. Having read that MongoDB had recently secured $150M in financing I was curious as to what the platform was like. Picking a database is never just about raw performance, but it is one of the most important aspects so I thought I would start with this aspect. What I thought would be interesting would be to compare the insert performance of objects in Intersystems Cache VS the insert performance in MongoDB. I took a very simple example, inserting 10,000 objects each with 3 properties, performed both tests 3 times on my laptop and averaged the results. There were no indexes defined. This is not exactly a great test but as Cache was significantly faster at doing ...