How about “Short Request Processing”?
While 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 processing” part, but there are issues with the modifier, including:
- “Internet” doesn’t really cover everything.
- “Network” in practice sounds too low-level, and is also too general.
- “Online” is also too general.
So how about just going with “short”? OLTP requests are inherently short. “GET” and “SET” are certainly short. 🙂 In general, queries that do not involve JOINs are probably short requests. Analytic queries, however, are generally not short. Even better, all that can apply to the syntax and the execution time alike. 🙂
Please note that I’m focused more here on describing use cases than products. Whether products generally used to do one kind of thing can also be stretched to do another — e.g., complex analytics hardwired into a Cassandra application — is not my primary concern.
Comments
11 Responses to “How about “Short Request Processing”?”
Leave a Reply
Online (OL) is there in OLTP and OLAP. So it could be OLRP. The online used to differentiate the batch processing, but now the difference between online and batch are thinning the OL part can be done away with. How about Transaction Processing (TP), Analytical Processing (AP) and Request Processing (RP)?
I also realize that three to four letter acronyms are easier to distinguish compared to two letter ones. Got to add a generic letter or two – is OL a candidate just by being there for sometime?
Rapid Request Processing
David,
The Requests are Short in more than time. (Less true of the Processing.)
Geordee,
OnLine Request Processing was the first suggestion. But frankly, the OLAP term was problematic almost from the getgo, and that was almost 20 years ago. So I don’t think we should go out of our way to preserve the tradition of using the term “OnLine”.
All,
I just got off the phone w/ the MongoDB guys. They seem happy with the term “short”.
Hi Curt,
my initial interpretation of short in respect to request processing would be “simple”. Although there can be very simple queries with short run-time, I guess there can be more complex ones too.
Maybe I am missing the point, but wouldn’t it be better to look for a term that focuses on the execution time more than on the complexity of the query?
What’s about “instant request processing”?
Michael,
I hate things that overpromise immediacy. 🙂
How about Micro Request Processing? It implies request is short, but also the response time is short.
Liran,
I don’t see what that adds. In particular, I don’t buy the implication.
Anyhow, my real question is whether you’ll adopt whatever I end up with. 😉
Simple Interactive Net Database = SIN DBMS
“Net” could be exchanged with “Cloud” but the result is less catchy. This is more applicable to key-value stores than SQL DBMS though.
@Micheal – no, if we want a stable classification system then it would be a mistake to focus on execution times; execution times already vary significantly where similar requests are executed on different technologies – and with the rise of new, complimentary approaches to information processing, these differences can be expected to increase and even accelerate. We should classify first on the problem space – and then assess how well different technologies address the various problems.
[…] an ideal way to do things, he’s surely right. That still leaves a lot of options for massive short-request databases, however, including transparently sharded RDBMS, scale-out in-memory DBMS (whether or not […]
[…] rapid request processing […]