4 ms·
I'd like to argue that conventional notions of OLTP are ill fitted to modern CRUD/SaaS apps. OLAP claims to be optimized for read-heavy workloads. But looking
by gavinray 4y ago
I'd like to argue that conventional notions of OLTP are ill fitted to modern CRUD/SaaS apps.
OLAP claims to be optimized for read-heavy workloads. But looking at access patterns for SaaS/CRUD apps, data shows the read/write ratio is along the order of 90/10
Additionally, OLTP purportedly deals in entire rows while OLAP is selective about columns and may contain aggregate functions/derived data.
But think about things like GraphQL, Firebase/Supabase, OData, etc
It's common in modern APIs to ask for a selective, minimal number of columns and also calculate derived information to display on a page
To me, the types of apps I've built my entire career sound much more like OLAP than OLTP, but we wouldn't call them that?
- advisedwang 4y agoOLAP vs OLTP is more than just read vs write -heavy or column vs row -oriented (although it certainly is those things). RDBMSs used for OLTP also provide consistency and transaction semantics, which are critical to application correctness, but not needed for OLAP uses.
- gavinray 4y agoRealistically what OLAP DBs do you know that don't provide correctness guarantees too though? For example: https://cloud.google.com/bigquery/docs/reference/standard-sql/transactions https://cloud.google.com/bigquery/docs/reference/standard-sq...
- advisedwang 4y agoTrue transaction semantics are rare in OLAP world. As for BigQuery: > If a transaction mutates (update or deletes) rows in a table, then other transactions or DML statements that mutate rows in the same table cannot run concurrently. Kind of a non-starter.
- jimcavel888 4y agoAlmost none that are less than $500k/year to rent, next to none.
- andrewf 4y agoI think the OLAP vs OLTP distinction is most interesting when you run into constraints and are forced to optimize for one at the expense of the other. Computers are so big and fast today, many applications won't hit that point.
- gunnarmorling 4y ago> It's common in modern APIs to ask for a selective, minimal number of columns and also calculate derived information to display on a page Yes, but still for common OLTP use cases you're only interested in a very small amount of data, say, the purchase orders of one customer. Whereas for OLAP, your queries touch on vast amounts of data, e.g. all purchase orders by month and product category. That's why typically a row-based storage model makes sense for OLTP, whereas for OLAP typically column-oriented models make sense.