As we approach our general availability release, we’re starting to see popular usage scenarios for ScaleBase. I thought this would be a great time to publish three of the common scenarios we see. I’ll probably publish more in the next blog post.

Machine Generated Data

I personally love this term, coined by Curt Monash (see here). It means that the data is generated by machines (sensors, RFID tags, etc) and the amount of data is growing at a much faster pace than human generated data. In my previous, pre-startup, life I’ve seen some examples of machine generated data – and all the applications had major database issues owing to the incredible number of writes the databases had to handle.

ScaleBase looks like a perfect solution to this situation – as it demonstrated at numerous POCs of companies who do Machine Generated Data. I’m still not at liberty to discuss specific customers, but that will change soon, I promise.

The concept of massive writes (machine generated data systems can reach 60% and even 70% writes) is supported very nicely with ScaleBase. Because each database feels only a small portion of the overall system write operations, unlimited database hits/second can be supported. In some POCs, we have reached thousands of writes per second – and the ScaleBase instances weren’t even close to choking.

Online Gaming

Online Gaming is another topic altogether. Massive writes are accompanied by a massive number of reads, and latency of reads is critical. Many social gaming applications work on cloud environments (like Amazon EC2) and basically try to keep most of their data in the database cache. This is a good technique, but limited by the size of machines that Amazon supports – which is not too large (read more in the great Baron Schwartz post here).

That scenario is ScaleBase bread and butter. Since we make every database smaller in size,  each database can store most of its data in cache, resulting in a major performance improvement.

On a personal note, as a long time gamer I am very excited to see which companies are evaluating ScaleBase. My only regret is that Sierra Online didn’t survive to run Quest For Glory 15 on ScaleBase

SaaS Solutions

Well, of course SaaS solutions can suffer from massive writes or from overly large databases, but I want to address a different topic – multi-tenancy.

We hardly ever talk about multi-tenancy with ScaleBase, but we offer great multi-tenancy solutions. We can store data on a specific customer in the nearest geographic database, or ensure that an EU customer’s details are stored in an EU data center. So you can meet regulatory demands, or improve database response time – in a way that is transparent to the application.

This is just another capability of our sharding solution; instead of dividing data based on a hash function you can shard data based on a predefined list or range of values. We saw quite a few POCs that targeted this feature – and they worked like a charm.

I was always told about the “rule of three” – so I just focused on the most popular scenarios we’ve seen. I’ll look into some other scenarios in my next post, which will probably be published next week.