[HN Gopher] Scalable OLTP in the Cloud: What's the Big Deal?
___________________________________________________________________
Scalable OLTP in the Cloud: What's the Big Deal?
Author : SchwKatze
Score : 59 points
Date : 2025-01-27 01:24 UTC (3 days ago)
(HTM) web link (muratbuffalo.blogspot.com)
(TXT) w3m dump (muratbuffalo.blogspot.com)
| taeric wrote:
| Fun read. I am a bit curious on not mentioning OLAP, at all?
|
| From my experience, the vast majority of complications in systems
| is people not realizing they are asking an OLAP question while
| wanting parts of OLTP semantics.
|
| I'm also curious how much of this extra complication comes from
| having a central database that tries to be a source of truth for
| everything? As an easy example, inventory systems that try and
| have a cloud source of truth have obvious problems when on the
| ground inventory issues crop up. That is, a lot of the
| complication is between the distributed nature of the application
| and database, sure. But, another large source is the non-
| distributed abstraction that a central database can represent not
| centralized activity.
| honestSysAdmin wrote:
| > From my experience, the vast majority of complications in
| systems is people not realizing they are asking an OLAP
| question while wanting parts of OLTP semantics.
|
| If you could elaborate on this further, I and others are
| probably very interested in reading more about it.
| juancn wrote:
| The main data access difference between OLAP systems and OLTP
| systems is how many records on average do you need to access:
|
| - OLAP: most queries need most records (aggregations span
| large swaths of data)
|
| - OLTP: most queries access just a few records
|
| Also, in OLAP, in many cases, you can live with a single-
| updater model without much trouble, where OLTP, the strength
| is to have many concurrent updaters (but mostly non-
| overlapping).
| hobs wrote:
| OLAP - Most queries need an aggregate of records. Generally
| you do NOT need most records, but simply the records
| grouped by dimensions per interval (for almost all olap
| reporting). You do not change the data, you observe it. If
| you change it, you are not dealing with OLAP data.
|
| OLTP - You are dealing with the ins and outs of people
| using stuff to do things. You buy something, you check out
| something, you some way perturb the state of things. This
| should not require large amount of row lookups in 99.9% of
| cases.
| greggyb wrote:
| - OLAP: read-mostly, table-scan heavy, many queries run ad-
| hoc by users
|
| - OLTP: write-mostly, index-seek heavy, ~all queries pre-
| defined up front
| yoda97 wrote:
| So the first focuses on analytics and reporting, the second
| on transactions and performance. They are not meant to
| replace each other, they serve different purposes. Some
| teams may need both.
| taeric wrote:
| As the sibling says, it is easy to think about in terms of
| what you are doing with the data. Reporting on how many
| transactions of a type have happened over a duration?
| Probably OLAP. Really, if the word "report" shows up, at all,
| probably OLAP. Executing parts of a workflow for an active
| transaction? OLTP.
|
| Briefly looking, I can't find the books that I thought
| covered a lot of this in a good way. Will keep looking,
| apologies.
| datadrivenangel wrote:
| Designing Data Intensive Applications is a very good book
| in this space.
| datadrivenangel wrote:
| I agree that analytical queries cause a significant portion of
| the complication in transactional systems.
|
| However, at global/twitter scale, just basic CRUD operations
| become pretty hard for OLTP, so scalable OLTP in the cloud is a
| pretty big deal, especially when you get fun things like
| phantom read/writes as writes may take time to get to
| distributed read replicas, so a user may send a tweet and then
| not see it on their profile for a while.
| taeric wrote:
| I mean, sure? I hesitate to take the global/twitter scale
| debates seriously, unfortunately. They are dominated by straw
| men arguments that you can get sub 50ms latency on every
| action for all viewers. :(
| tharkun__ wrote:
| You can't and it shouldn't matter and I don't care if
| everyone sees my upvotes on Reddit right away / at the same
| time as others or if I see theirs or when exactly my
| comments show up.
|
| But global/twitter/reddit etc. scale does matter in that I
| don't really remember a PHPBB or slashdot or HN swallowing
| my comments, ever. Even if you get an error you can always
| just go back in the browser and your input box is there
| with your comment.
|
| But reddit has been effing atrocious over the last few
| months. You get "Internal Server Error" when trying to do
| any voting or commenting a _lot_ and it won 't go away
| until you refresh the page like 17 times (until presumably
| you round robin get to some BE server that actually works.
| It's also been swallowing comments, where about every third
| or fourth comment it accepts the comment instead of
| throwing an Internal Server Error at you (which would be
| preferable) and instead it "accepts" it but it will never
| show up. Ever. Only chance is to copy every comment before
| submitting, in case you have to re-submit it from scratch.
| taeric wrote:
| Exactly on that first statement.
|
| I think I agree across the board. HN and Stack Overflow
| are both amusing examples of much simpler architectures
| that kind of get to the point, though? Such that I'm not
| clear if we are on the same page, there.
|
| (And I, sadly, have zero experience with Reddit.)
| mamcx wrote:
| > I'm also curious how much of this extra complication comes
| from having a central database that tries to be a source of
| truth for everything?
|
| You can reverse this as 'how much extra complication comes from
| having many disparate databases, so now you push all ACID
| complications at the company level instead of the
| software(rdbms)'
|
| It is a tricky problem!
|
| Having a single source of truth is a tremendous simplification,
| especially for the _people_.
|
| It should be ideal that the other databases are _pure_
| materializations on top of it, but then not matter what you
| have the need to _input_ more stuff that is not part of the
| central one, and now you _have both problems_.
| taeric wrote:
| A single source of truth for facts is fine. A single source
| of truth that has to be reflected by external reality? Less
| fine. At that point, you pretty much have to have
| reconciliation processes to account for when they don't
| match.
|
| Oddly, I'd argue that the better way to view this is that the
| central database is the materialization of the data sources
| scattered around where work actually happens. As such, you
| have to have constructs that account for provenance and
| timing introduced there that aren't as necessary at the
| edges.
| nyrikki wrote:
| Single source of truth is different in distributed systems,
| well the costs are different.
|
| Using the language of 'software architecture: thee hard
| parts' this forces your entire system into a single
| 'architectural quanta', basically it is a monolith.
|
| There are situations where monoliths are acceptable or even
| the least worst option.
|
| The 'Fallacies of distributed computing' covers most of
| these.
|
| It can work better if you use a hierarchical model, but OLTP
| is almost exclusively the relational model.
|
| ACID transactions become pretty brittle, software becomes set
| in stone etc...
|
| There are use cases, but the value proposition is typically
| much weaker
| honestSysAdmin wrote:
| I could be wrong here, I'm not an expert with databases, but I
| believe -- this is a belief, please help me disconfirm it if you
| think it is wrong -- that CitusDB's approach that shards Postgres
| across redundant mirrors, should successfully scale horizontally
| for OLTP without sacrificing consistency.
| dangoodmanUT wrote:
| Others can do it too: Spanner, FoundationDB. SI just has
| generally better performance because there is less to check,
| and you can always opt-in to row locking if you need (because
| of write-write conflicts)
| AlexB138 wrote:
| Citus still has a centralized coordinator that all requests go
| through to be routed to their shard, or at least it did several
| years ago when I last ran it in production. It definitely
| scales further than single instances, but it's not a magic
| bullet.
| whartung wrote:
| Maybe someone can answer how this is done.
|
| Simply, the mad crushing dash to get the last bit of committed
| inventory.
|
| Ticketmaster has 50,000 General Admission Taylor Swift tickets
| and 1M fans eager to hoover them up.
|
| This is a crushing load on a shared resource.
|
| I don't know if there's any reasonable outcome from this besides
| the data center not catching on fire.
| dangoodmanUT wrote:
| You build systems designed for this workload, you don't
| foolishy try to use the same patterns as a CRUD app.
| dangets wrote:
| Sharding, pre-allocating leases of blocks of tickets across
| available resources, and eventual consistency. You don't need
| to keep the UX transactionally correct; you are able to say "0
| tickets remaining" and then a minute or hour or day later say
| "100 tickets remaining". For something as popular as Taylor
| Swift, the fans will keep checking.
| immibis wrote:
| You, as a business entity, have to figure out how you want to
| allocate them. They aren't going to get sold the normal way, so
| you get to choose whether you want to acknowledge that and
| design the system, or not design it and let nature take its
| course.
|
| I've been to events that used a lottery. You order a ticket any
| time in, say, a month window. At the end, they tell you if you
| actually got a ticket. They have a process for linking orders
| together so you can choose to get a ticket if and only if your
| friends do.
|
| I've also been to C3, which (in the second phase) knowingly
| used a first-come-first-serve three times, putting some kind of
| lightweight proxy in front of the actual shop that would only
| allow a certain number of people to access it at a time (this
| is important because you don't know how many tickets each user
| is going to order). In the first phase, they use a system of
| "self-replicating vouchers" for various trusted C3-affiliated
| groups: one voucher is given to each group, allowing an order;
| at the end of each day until this portion of the ticket pool
| runs out, a new voucher is given to whoever made an order the
| previous day. I don't know the reasons why self-replicating
| vouchers are designed exactly that way, but it means each group
| gets to run down their own self-determined priority order and
| gets punished for inefficiency.
|
| The capitalist approach is, of course, raise the price to
| twenty thousand dollars or whatever level it takes for only
| 50,000 people to _want_ to buy a ticket.
| ndriscoll wrote:
| Add a rate limit in nginx so that a single client has bounded
| work on your backend (e.g. 1/1-10s), and batch your requests
| into ~100/transaction using an in-memory queue. 1 server has
| been able to deal with ~1M connections for many years. No fires
| needed.
|
| On a business side, they drastically lower the request load and
| make scalping unprofitable by holding a Dutch auction.
| riku_iki wrote:
| > ticketmaster has 50,000 General Admission Taylor Swift
| tickets and 1M fans eager to hoover them up.
|
| I think something like trivial postgres setup can handle this
| thing..
___________________________________________________________________
(page generated 2025-01-30 23:00 UTC)