Terminology: Internet Request Processing (IRP)
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.
*Consider, for example, the overlapping use cases for Schooner, dbShards, ScaleBase, Couchbase, and DataStax/Cassandra.
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.
Comments
8 Responses to “Terminology: Internet Request Processing (IRP)”
Leave a Reply
[…] commonly used to describe scaled-out MySQL in Internet Request Processing use cases. This one has the advantage of being concise, but is beginning to mean two different […]
I like the term, I think is concise. Drizzle can also be in the list (you may have implicitly considered with Akiban but it could also be explicitly listed)
Ivo,
That “include” at the end was originally “include but are not limited to”, but I decided that such redundancy might get in the way of readability. 🙂
I’ll confess to not having kept up closely with Drizzle or MariaDB. Indeed, you’re the first person to raise either one to me in quite a while …
Well, it could be any network, not just (a) the big-I Internet, or even (b) a network based on the Internet Protocol (IP) that might not be connected to the Internet. So, maybe it should be “Network Request Processing”. However, you could take the position that these days, all networks run IP. In the world I’m in, that’s true. I’d slightly prefer NRQ but it’s a picky detail. Anyway, I love terminology that is used consistently and defined clearly. It’s not something to be taken for granted!
Dan,
The companion post that I just failed to get written was one that explained why all product category names were imperfect, in an even strong form than Monash’s First Law of Commercial Semantics. 😉
As for “network” — I think it usually has the connotation of lower tiers of the network stack only. And “social network” just confuses the “network” term further.
Hello Curt,
This is a great question, NoSQL is an awful term 🙂
However I agree with Dan, Internet Request Processing, under my point of view, limitates a bit the scope and also, deviate the focuss; well, being not perfect sounds a very good candidate!
For the second counterexample, what about mixvolume databases? (as for mixworkload for transactional/batch)
Finally, regarding the internet “replacement” I was thinking on Multinode, or Distributed, but then I was falling in a too generic terminology again… 🙂
I know, none of them sound perefct neither, and I actually do not have a clear view, but maybe one of these proposals could fit?
Regards!
As you can see from the note I added to the end, the companion post has since been written. 🙂
[…] my other terminology posts seem to have gone pretty well, the internet request processing name is proving a bit problematic. People seem pretty cool with the “request […]