
How To Make An Infinitely Scalable RDBMS - jpmc
http://highscalability.com/blog/2013/11/25/how-to-make-an-infinitely-scalable-relational-database-manag.html
======
glogla
There was very interesting presentation by one professor. I'm not sure about
what university, but he seemed to know his work.

He talked about how databse world is about to change. ACID is really expensive
in terms of resources, and so are the more difficult things about relational
schema (foreign keys, checks, etc). And architecture of classic RDBMSes is
pretty wasteful -- they use on-disk format but cache it in memory.

He talked about how there are basically three new paths for DBMSes to follow.
1) Some drop the restrictions to become faster. This is the NoSql stuff,
because you don't really need ACID for writing to Facebook wall.

This is called NoSql database.

2) OLAP, in data warehousing, the usual way to do things is that you load
ridiculous amount of data into database, and then run analytical queries, that
tend to heavily use aggregation and sometimes use just few dimmensions, while
the DWH data tend to be pretty wide.

For this, column store makes perfect sense. It is not very quick on writes,
but it can do very fast aggregation and selection of just few columns.

This is called Column store.

3) In OLTP, you need throughtput, but the question is, how big are your data,
and how fast do they grow? Because RAM tends to get bigger exponentially,
while how many customers you have will probably grow linearly or maybe fuster,
but not much. So your data could fit into memory, now, or in future.

This allows you to make very fast database. All you need to do is to switch
the architecture to memory-based, store data in memory format in memory and on
disk. You don't read the disk, you just use it to store the data on shutdown.

This is called Main memory database.

No, that was the presentation. It was awesome, and if someone can find it,
please give us a link! My search-fu was not strong enouhg.

...

What interests me is that we have NoSql databases for some time already, and
we have at least one huge (are very expensive) column store: Teradata. But
this seems to be first actual Main memory database.

My dream would be to switch Postgres to main memory or column store mode, but
I guess that's not happening very soon :)

~~~
JeffDClark
Is this the talk that you are referring to?
[http://slideshot.epfl.ch/play/suri_stonebraker](http://slideshot.epfl.ch/play/suri_stonebraker)

~~~
nl
Note that Stonebraker makes some good points, but there are many ways to build
scalability and Stonebraker is too fast to dismiss many.

In particular, his criticism of traditional databases seems based more on
philosophy rather than evidence.

I'd advise reading both sides of the story:

[http://lemire.me/blog/archives/2009/09/16/relational-
databas...](http://lemire.me/blog/archives/2009/09/16/relational-databases-
are-they-obselete/)

[http://lemire.me/blog/archives/2009/07/03/column-stores-
and-...](http://lemire.me/blog/archives/2009/07/03/column-stores-and-row-
stores-should-you-care/)

[http://architects.dzone.com/articles/stonebraker-talk-
trigge...](http://architects.dzone.com/articles/stonebraker-talk-triggers)

[http://gigaom.com/2011/07/11/amazons-werner-vogels-on-the-
st...](http://gigaom.com/2011/07/11/amazons-werner-vogels-on-the-
stonebrakernewsql-debate/)

[http://dom.as/2011/07/08/stonebraker-
trapped/](http://dom.as/2011/07/08/stonebraker-trapped/)

The date on some of those posts in interesting. 2009 is quite a while ago now,
and I'd suggest that columnar datastores haven't exactly taken over. Some
implementations have made some progress (eg Cassandra), but OTOH many non-
traditional datastores have added traditional-database like features (eg,
Facebook's SQL front end on their NoSQL system), and traditional databases
have added NoSQL features too.

~~~
army
Stonebraker is a very smart person but he's also not shy about promoting his
own companies/research. You generally get a well-informed but very opinionated
take on things from him.

VoltDB, for example, is good for certain complex workloads over large but not-
too-large data sets. For a lot of situations it isn't really an alternative to
memcache+MySQL or a NoSQL solution.

------
alanctgardner2
I'm a little skeptical:

\- a bunch of the novel components (the UPS aware persistence layer, for
example) aren't actually built yet

\- they're pushing for people to build businesses on it already. I would
characterize it as "bleeding-edge with bits of glass glued on", so this
doesn't seem entirely honest.

\- there's mostly a lot of breathless talk about how great and fast and
scalable it is, but no mention of CAP theorem. To boil down their feature set,
it's an in-memory RDBMS using the Actor model.

~~~
mtravis
Hi, Alan. Yes, many things are not built yet. Nowhere am I pushing anybody to
build their business on it yet, but I am looking for hackers and early
adopters/alpha testers. I've gone through pains on every doc that I've created
that this is early, alpha, needs lots of work--including the 2nd paragraph of
the linked-to article: "InfiniSQL is still in early stages of development--it
already has many capabilities, but many more are necessary for it to be useful
in a production environment."

Regarding CAP, I'm not addressing multi-site availability at this stage--I
want to get single site fully operational, redundant, and so on.

And, yes, to boil it down, it's an in-memory RDBMS using the Actor model.

The most important feature is that it performs transactions involving records
on multiple nodes better than anything. This is the workload that keystores
functionally cannot do, and which other distributed RDBMS' suffer under. It's
also open source, has over 100 pages of technical docs, and is functional
enough for people to pound on with some workloads--but not something to put
into production yet.

~~~
brianpgordon
When I see a new distributed database, the first thing I want to know is "Is
it AP or CP?"

If you haven't answered that question yourself, it's likely you have a
partition-intolerant system, and that in real-life scenarios people will lose
data.

~~~
mtravis
CP in a single site. Between sites, I haven't considered it too much.

------
yid
> UPS systems will stay active for a few minutes, based on their capacity, and
> the manager process will gracefuly shut down each daemon and write data to
> disk storage. This will ensure durability--even against power failure or
> system crash--while still maintaining in memory performance.

How does a UPS ensure durability against system or program crashes, disk
corruption in large clusters, and other failures that can affect a simple
write()?

> The real killer for database performance is synchronous transaction log
> writes. Even with the fastest underlying storage, this activity is the
> limiting factor for database write performance. InfiniSQL avoids this
> limiting factor while still retaining durability

How do you plan to implement this (since it appears it hasn't been
implemented)? What is your fundamental insight about synchronous transaction
logs that makes InifiSQL capable of being durable while (presumably) not
having a synchronously written transaction log? If your answer is the UPS,
please see my first question.

Edit: I don't see any mention of Paxos anywhere. Could you explain what you're
using for consensus?

~~~
mtravis
Hi, yid. UPS protects against multiple simultaneous system crashes. Single
system crash gets failed over, no problem. If both UPS systems detect their
upstream PDU's as being out, then the InfiniSQL management protocol will
initiate graceful shutdown, including persisting to disk. For write() issues,
at least intially, I think that stuff in commodity hardware (such as ECC
memory) is sufficient protection in most cases. Attaching a high end storage
array, or using ZFS, also protects against low level disk problems. I don't
see those problems as needing to be solved for a 1.0 relase, but am very much
open to contributions that address those issues any time you want!

The fundamental insight about not needing transaction logs is pretty simple
actually: if the power is guaranteed to either stay on, or to allow the system
to quiesce gracefully, then the cluster will not suddenly crash. That's the
motivator for transaction logs--to make sure that the data will still be there
if the system suddenly crashes. Get rid of the need for transaction logs, get
rid of the transaction logs.

Regarding consensus, I expect that there will be a quorum protocol in use
amongst an odd number greater than 2 of manager processes, each with redundant
network and power. But the specific protocol I haven't ironed out. If there's
something I can grab off the shelf then it may be preferable to implementing
from scratch, but I haven't gotten there yet.

This stuff hasn't been implemented yet, but the core around which it can be
implemented, has been.

Do I sense a volunteer? ;-)

~~~
yid
I feel like you're banking a little too heavily on external measures for error
protection/durability like UPSes and ECC memory, rather than embracing the
inevitable fact that corruption and failures will occur. In short, I'd really
need to see a white paper on why you're not reinventing the wheel before I'd
use InifiSQL.

Kudos for engaging the community though; please do keep us posted as you
progress.

~~~
mtravis
Actually, there's precious little that an application can do if a memory chip
fails, or if ECC gets too many corrupted bits. If it gets too many corrupted
bits, the kernel will generally do something like halt the system. I am not
familiar with any application which does a write-read-write (or similar) to
memory, but would be curious to learn about them. I'm sure such an algorithm
can also be used in InfiniSQL.

I am familiar with applications such as IBM WebSphere MQ which does a triple-
write to disk for every transaction, to overcome corruption problems. But even
IBM will recommend turning that parameter off for performance reasons if the
storage layer performs that kind of verification, such as HDS or EMC arrays.
So, if an InfiniSQL user wants that level of storage protection, they can buy
it.

Regarding InfiniSQL's planned use of UPS systems, that's pretty much the
identical design to how the above-mentioned storage arrays protect block
storage from power loss. I'm just moving the protection up to the application
level.

Thanks for the conversation and thoughtful comments. Please go to
[http://www.infinisql.org/community/](http://www.infinisql.org/community/) and
find the project on Twitter, sign up for newsletter, hit me on LinkedIn.

\----

Hi, yid. For some reason I can't reply to your last comment. I think I didn't
explain things well enough--I do plan to implement synchronous replication to
protect against single replica failure. I describe the plan somewhat in
[http://www.infinisql.org/docs/overview/](http://www.infinisql.org/docs/overview/)

Much of the code for the replication is in place (and it actually worked a few
thousand lines of code ago) but it's currently not functional.

I have a big backlog to work on, but n-way synchronous replication is
definitely in there.

~~~
yid
> Actually, there's precious little that an application can do if a memory
> chip fails, or if ECC gets too many corrupted bits.

That's where replication and (distributed) consensus comes in, usually at the
application level.

~~~
spof3
Or Resilient Distributed Datasets
[https://www.usenix.org/system/files/conference/nsdi12/nsdi12...](https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf)

------
gopalv
GNU AFPL?

Clause 13 is a real pain to deal with when exposing this over the network.

I guess the developer wants to sell a license (like the mysql java client
GPL'ing).

Can't blame him, he needs to get paid.

~~~
mtravis
Hi, gopalv. What samspenc said. My understanding of the AGPL is that only the
modifications made to the source code itself of the covered project would need
to be opened up (or have a commercial license). Meaning that merely using
InfiniSQL won't require you to open source your app. MongoDB has the same
license BTW, and lots of people use it without being forced to open their
code. And, yes, I want to get paid somehow--but the AGPL won't stop anybody
from using my work how they see fit. But if they modify it and distribute it,
then they'll have to comply with the license (or contact me directly for an
alternate arrangement).

~~~
gopalv
I fully understand what this means and I hope you do get calls about alternate
licensing, but remember that people like me do not make these decisions.

I thankfully don't have to - this means I don't need to talk to lawyers about
this.

Because AGPL took away the most important bit of unassailable ground I had to
argue with when it came to deploying GPL - "Using this code implies no
criteria we have to comply to, only if we distribute it".

Clause 12 and 13 - basically took that away from me completely.

Look, I'm not going to tell you what license to use.

But leave me enough room to complain that I have had trouble convincing people
that we can use AGPL code in a critical function without obtaining a previous
commercial license by paying the developer.

~~~
mtravis
Hi, gopalv. I'm glad to talk to you further privately if you wish. You can go
to InfiniSQL's site to send me your email, connect on LinkedIn, or whatever:
[http://www.infinisql.org/community/](http://www.infinisql.org/community/)

I'm not too religious about licensing--if I can get early
adopters/contributors, and so on, I'm willing to consider changing the license
terms.

I'm looking for open doors.

~~~
samspenc
Personally, I think the choice of AGPL is good. It enables you to give to the
community and get useful community involvement, while allowing commercial
companies to have proprietary forks (for a cost) as well as commercial
support.

All the best!

~~~
mtravis
Thanks!

------
MichaelGG
In-memory distributed database? VoltDB is already way past 500Ktx/sec on a
12-node cluster.

On their site though, it says no sharding and that it can do these 500Ktx/sec
even when each transaction involves data on multiple nodes. Does this
performance degrade directly in relation to the number of nodes a tx needs to
touch?

A simple, straightforward, wire-level description of how things work when
coordinating and performing transactions across would be very useful. There's
a lot of excited talk about actors, but nothing that really examines why this
is faster, or any sort of technical analysis.

~~~
mtravis
Hi, Michael. Yes, VoltDB is very fast, but they self-admittedly _do not_
perform well if transactions contain records spanning across multiple nodes.
That is the key feature difference between InfiniSQL and VoltDB (along, of
course, that their project is functionally much further along).

If you want more details about how things work when performing transactions, I
think that the overview I created would be a good starting point. It probably
doesn't have everything you'd ask for, but I hope that it answers some of your
questions:
[http://www.infinisql.org/docs/overview/](http://www.infinisql.org/docs/overview/)

And to answer your question about performance degradation pertaining to number
of nodes each transaction touches, I have not done comprehensive benchmarks of
InfiniSQL measuring that particular item. However, I do believe that as multi-
node communication increases, throughput will tend to decrease--I expect that
the degradation would be graceful, but further testing is required. The
benchmark I've performed and referenced has 3 updates and a select in each
transaction, all very likely to be on 3 different nodes.

I'd like to invite you to benchmark InfiniSQL in your own environment. I've
included the scripts in the source distribution, as well as a guide on how I
benchmarked, as well as details on the specific benchmarking I've done so far.
All at [http://www.infinisql.org](http://www.infinisql.org)

I'd be glad to assist in any way, give pointers, and so on, if there are tests
that you'd like to do. I also plan to do further benchmarking over time, and
I'll update the site's blog (and twitter, etc) as I do so.

Please communicate further with me if you're curious.

Thanks, Mark

~~~
jbellis
So basically, VoltDB acknowledges that cross-partition transactions are Hard
and has put a lot of effort into minimizing them. (This is basically the
entire point of the original HStore paper.)

InfiniSQL says don't worry, we'll just use 2PC. But not just yet, we're still
working on the lock manager.

I look forward to your exegesis of how you plan to overcome the well-
documented scaling problems with 2PC. Preferably after you have working code.
:)

~~~
mtravis
I'm not doing 2PC. I'm curious what gave you that impression, and I'll clarify
any documents that seem to give off that impression.

I'd like InfiniSQL to handle hard workloads as well as it can, to minimize the
amount that developers need to redesign their applications.

Please go to
[http://www.infinisql.org/community/](http://www.infinisql.org/community/) and
follow the project on Twitter, and sign up for the newsletter, to keep
apprised of progress.

Thanks for the input!

~~~
jbellis
[http://www.infinisql.org/docs/overview/#idp37097184](http://www.infinisql.org/docs/overview/#idp37097184)
gave me that impression.

~~~
mtravis
Oh, I thought you said 2PC (two-phased commit).

Yes, InfiniSQL uses two phase locking. The Achilles' Heel is deadlock
management. By necessity, the deadlock management will need to be single-
threaded (at least as far as I can figure). No arguments there, so deadlock-
prone usage patterns may definitely be problematic.

I don't think there's a perfect concurrency management protocol. MVCC is
limited by transactionid generation. Predictive locking can't get rolled back
once it starts, or limits practical throughput to single partitions.

2PL works. It's not ground-breaking (though incorporating it in the context of
inter-thread messaging might be unique). And it will scale fine other than for
a type of workload that tends to bring about a lot of deadlocks.

~~~
leif
HAT ([http://www.bailis.org/papers/hat-
vldb2014.pdf](http://www.bailis.org/papers/hat-vldb2014.pdf)) looks pretty
promising in terms of multi-term transactions. It turns out that you can push
the problem off to garbage collection in order to make transaction id
generation easy, and garbage collection is easier to be sloppy and heuristic
about. The only problem is it isn't clear yet that HATs are as rich as 2PL-
based approaches, and that nobody's built an industrial strength
implementation yet.

------
eksith
Looking at the "About and Goals" section of their docs
[http://www.infinisql.org/docs/overview/#idp37033600](http://www.infinisql.org/docs/overview/#idp37033600)

I can't seem to find the word "Reliable" or any variation thereof anywhere in
there.

In fact, that word is no where to be found on the blog post or on the entire
InfiniSQL page (not in the Overview, Guides, Reference or even FAQ). I find
this quite remarkable since reliability is the true virtue of an RDBMS, not
speed or even capacity. At least that's what PostgreSQL aims for and this
being another RDBMS, and is also open source, I see it as InfiniSQL's only
direct competitor.

It's nice that this is scalable, apparently, to ridiculous levels, but if I
can't retrieve what I store in exactly the same shape as I stored it, then
that's a bit of a buzz kill for me.

Can we have some assurance that this is the case?

There's a note on "Durability" and a shot at log file writing for
transactions, and presumably InfiniSQL uses concurrency and replicas, to
provide it. In the Data Storage section, it mentions that InfiniSQL is still
an in-memory database for the most part
[http://www.infinisql.org/docs/overview/#idp37053600](http://www.infinisql.org/docs/overview/#idp37053600)

What they're describing is a massively redundant, UPS backed, in-memory cache.

Am I wrong?

~~~
mtravis
Hi, eksmith. I talk a bit about plans for durability in that overview
document.

I promise that I have every intention of making InfiniSQL a platform that does
not lose data. I have a long career working in environments that demand 100%
data integrity. If I de-emphasized it, it was not intentional.

PostgreSQL doesn't scale for OLTP workloads past a single node. There are a
handful of products similar to InfiniSQL (google for the term NewSQL for a
survey of them).

And yes, a redundant UPS-backed in-memory cache. I have some ideas on how to
do regular disk backing as well (which I'm sure you've read).

And if a more traditional log-based storage layer is added, InfiniSQL will
still scale nearly linearly across nodes horizontally. Multi-node scale and
in-memory are not dependent on one another. Though I believe that redundant
UPS systems managed by a quorum of administrative agents, and provide
durability just like writing to disk.

Are you familiar with high end storage arrays, such as from HDS or EMC? They
write to redundant memory, battery backed and managed by logic in the arrays.
I'm just moving that type of design to protect the database application
itself, up from the block layer.

And some people trust their datacenter power--they use pure in-memory
databases without UPS already, or they do things like asynchronously write
transaction log, which also sacrifices durability. For those groups, InfiniSQL
ought to be just fine, without UPS systems.

------
leif
The write bottleneck for traditional databases has never been the write-ahead
log, with group commit and a battery-backed RAID controller you'll have a hard
time saturating the disk with log writes. The bottleneck has always been
random I/O induced by in-place updating indexes based on B-trees. You don't
need to be in-memory if you use better data structures. TokuDB and TokuMX are
proof of that.

~~~
mtravis
Hi, Leif. It's not hard to get to the throughput limits of a single log
device, even on a fast array. I've done it on Sybase, WebSphere MQ, Oracle,
MySQL, basically on enough platforms that I assume it to be the general case.
The log writes don't saturate the array itself--but the log file has a limit
to how many blocks can be appended--even on fast arrays. But imagine getting
rid of the transaction log entirely--the entire code path. That will be faster
even than a transaction log write to memory-backed filesystem.

But I agree that other write (and read) activity going on in the background
and foreground, also limits performance--and in fact, I've seen the index
write bottleneck that you describe in real life, more-so than simple
transaction log writes. So, you're correct.

I've read about Toku, but I really doubt that it writes faster to disk than
writing to memory. Are you really trying to say that?

I think it would be great for InfiniSQL to be adapted to disk-backed storage,
in addition to memory. The horizontal scalability will also apply, making for
a very large group of fast disk-backed nodes.

I think your input is good.

~~~
leif
I'm not talking about the speed of the array, rather a battery backed
controller. With one of those, as long as you're under the sequential write
bandwidth of the underlying array, it pretty much doesn't matter how much you
fsync the log, so that bottleneck (commit frequency) goes away.

If you're planning to write data faster than disk bandwidth, then you have no
hope of being durable and we're talking about problems too different to be
worth comparing, and in that case I retract my comment.

I don't understand what distinction you're trying to make between the "array
itself" and the "log file has a limit to how many blocks can be appended". Can
you clarify what limit you're talking about?

~~~
mtravis
Well, array=battery backed controller with a bunch of disks hanging off of it.
Actually, there is latency associated with every sync. What I've seen on HDS
arrays with Linux boxes and 4GB fibre channell adapters is about 200us per 4KB
block write. That is very very good for disk. It's also slower than memory
access by many orders of magnitude. This was about 3 years ago. Things are
bound to be faster by now, but still not as fast as RAM.

I don't think it's unreasonable to want to write faster than an I/O subsystem
can handle. Maybe it's not for every workload, but that doesn't mean it's for
no workload.

The distinction I wasn't being clear about was that the storage array (the
thing with the RAID controller, cache and disks hanging off of it) is not
being saturated if a single transaction log file is being continuously
appended to. But that headroom in the array does not translate to more
throughput for the transaction log. I don't know if it's an important
distinction.

------
brianberns
An in-memory RDBMS hardly seems to be "infinitely scalable". How would this
work with DBs in the terabyte size or larger?

~~~
MichaelGG
A terabyte of RAM is pretty cheap. Around $12K for the RAM. Last I quoted out
a system for VoltDB, the total cost (complete servers with CPU, disk, RAM)
came to ~$17/GB to $22/GB.

If you actually have transaction processing at this scale and need that
performance, the RAM cost is not a major issue.

------
amalag
This is what Clustrix (YC company) claims to do.

~~~
mtravis
Hi, amalag. Yes, Clustrix is very similar to InfiniSQL (not to mention having
been around longer). I believe that InfiniSQL has _vastly_ higher performance
at least for the type of workloads that InfiniSQl is currently capable of.
InfiniSQL is also open source.

I hope there's room for competition in this space still.

~~~
sergei
What do you base your performance claim vs Clustrix on?

~~~
mtravis
Here is some back of napkin analysis:

Starting with this benchmark report: [http://www.percona.com/files/white-
papers/clustrix-tpcc-mysq...](http://www.percona.com/files/white-
papers/clustrix-tpcc-mysql-benchmark.pdf)

Basically, InfiniSQL does not currently support complex indices, so it can't
do a TPC-like transaction.

The maximum throughput on 9 nodes is 128,114 per node per second. I don't know
if that's 4 or 8 core nodes. If roughly 10% of transactions are multi-node
transactions, then 12,811/node/s for multi-node, and 115,303/node/s for
single-node transactions.

I don't know if full redundancy for Clustrix was configured, or a hot spare,
so I don't know how many actual usable nodes were configured, but likely fewer
than 9. But I don't know the precise number.

Roughly 10% of those transactions are contain records on multiple nodes. Based
on 9 nodes, that means about 12811/node/s for distributed transactions
combined with 115303/node/s for single node transactions.

InfiniSQL maxsed at over 530,000 multi-node transactions on 12 x 4-core nodes.
[http://www.infinisql.org/blog/2013/1112/benchmarking-
infinis...](http://www.infinisql.org/blog/2013/1112/benchmarking-infinisql)

That's 44,167 per node.

\---------

These were not apples-apples benchmarks, but Clustrix performed about 12,000
multi-node transactions per node per second, along with a whole bunch more
single-node transactions.

I don't know how it would perform on the benchmark I used. And I intend to do
a tpcc benchmark once InfiniSQL is capable of complex keys (among whatever
else it it currently is missing).

~~~
sergei
Several problems here:

1\. Unlike your dataset, the tpcc dataset for the benchmark was not memory
resident. Total dataset size was 786G. Just shrinking the dataset to fit in
memory would substantially change the numbers.

2\. The tpcc workload is much more complex than your benchmark. It doesn't
make sense to compare a tpcc transaction, of which there are multiple flavors,
to your workload.

3\. All Clustrix write transactions are multi-node transactions. There's a 2x
data redundancy in the test. We do not have a master-slave model for data
distribution. Docs on our data distribution model:
[http://docs.clustrix.com/display/CLXDOC/Data+Distribution](http://docs.clustrix.com/display/CLXDOC/Data+Distribution).

\-----

Now we've also done tests where the workload is a simple point updates and
select on memory resident datasets. For those kinds of workloads, a 20 node
cluster can do over 1M TPS.

------
jeremycole
What's up with the weird coding standards? Include files named infinisql_*.h
and #line statements... strange.

~~~
mtravis
Oh, the infinisql_*.h is because I deploy all header files as part of "make
install", when what I really should do is boil it down to just the api header.
The api is for stored procedure programming. Yes, I have it on backlog to fix.
I give them all that name in case somebody installs to /usr/local (which you
probably oughtn't) it's clear what application they all belong to. Yes, I
could create a subdirectory, too. But the fix will be when I clean up api.cc
to only have to pull in the one header instead of several of them.

#line statements because I get compiler messages from time to time putting
things on the wrong line after having imported headers.

------
flatfilefan
What is the difference to Teradata or Netezza except this is open source and
lack the burden of universality yet?

~~~
mtravis
Those are analytics databases, also known as data warehouses. Optimized for
batch reporting. InfiniSQL is geared for operational/transactional (OLTP)
kinds of workloads.

