As I observed previously, we need a term that means “like OLTP but not necessarily transactional”, to help describe a category of use cases that can reasonably be addressed by NoSQL or scale-out SQL systems alike.* So here’s a candidate phrase: Internet Request Processing (IRP). If we use that, I’ll call Schooner, Cassandra, Couchbase , et al. IRP DBMS, while other people will probably call them IRP databases.
In my proposed terminology, an internet request processing (IRP) use case is one in which:
- The tasks are simple. Within that stipulation, there’s a lot of flexibility. For example:
- Tasks can be lookups or updates.
- Updates can be transactional or not.
- Data can be managed as rows or objects.
- Queries can bring back single records or small numbers of them.
- I.e., tasks are not “analytic.”
- Queries are not complex.
- Any calculations are simple, and done on small volumes of data. For example, calculating a percentage discount is fine, and so is updating a counter.
- The tasks are high in volume or the tasks are requested across a wide-area network. The “or” is of course inclusive.
- The system is interactive. It’s not just a matter of banging data into a log file.
So in essence I’m suggesting that Simple + Wide Area Network + Interactive ==> Internet and also that Simple + High Volume + Interactive ==> Internet. Hopefully the first part of that is uncontroversial. As for the second, what would be a counterexample?
If we accept this definition, then an internet request processing database management system (IRP DBMS) is simply a DBMS optimized for internet request processing. Examples of IRP DBMS include Schooner (in both its MySQL and Membrain* versions), Cassandra, HBase, Couchbase (and its predecessors Membase* and CouchDB), MongoDB, Riak* and — assuming they ever ship — ScaleDB, Akiban, and NimbusDB. But graph DBMS such as Neo4j or Infinite Graph would be excluded, as they’re on the analytic side. dbShards and ScaleBase are more like quasi-DBMS, but they’re definitely also geared to IRP.
*I consider key-value stores to be DBMS, albeit ones with very simple data manipulation languages.
What do you think of this terminology? Comments will be extremely welcome. But please be so kind as to recall one thing — no technology category definition can ever be perfect.