Re: big, fast, etc, was is Vax addressing sane today

John Levine wrote:

According to Lawrence D'Oliveiro  <ldo@nz.invalid>:

On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:
>

Then there is the issue of cheap PC’s that fail, and a mainframes have a
higher level of redundancy and failover. Failed business transactions
can cost millions, more than the machine is worth, so saving pennies on
hardware is stupid.

>
You solve that by having multiple units of the cheap machines to achieve
the same level of redundancy, or even more. That ends up being more cost-
effective than the mainframe.

 That's fine for workloads that work that way.
 Airline reservation systems historically ran on mainframes because when they were invented
that's all there was (original SABRE ran on two 7090s) and they are business critical so
they need to be very reliable.
 About 30 years ago some guys at MIT realized that route and fare search, which are some of
the most demanding things that CRS do, are easy to parallelize and don't have to be
particularly reliable -- if your search system crashes and restarts and reruns the search
and the result is a couple of seconds late, that's OK. So they started ITA software which
used racks of PC servers running parallel applications written in Lisp (they were from
MIT) and blew away the competition.
 However, that's just the search part. Actually booking the seats and selling tickets stays
on a mainframe or an Oracle system because double booking or giving away free tickets would
be really bad.

You could replicate much of that part as well, for most of the time, by setting aside chunks of seats to parallel servers, so that they can book/sell within that chunk until they start to run out. This way the expensive system is mostly needed only when the front ends run out?

 There's also a rule of thumb about databases that says one system of performance 100 is
much better than 100 systems of performance 1 because those 100 systems will spend all
their time contending for database locks.

10-15 years ago I talked to another speaker at a conference, he told me that he was working on high-end open source LDAP software using _very_ large memory DBs: Their system allowed one US cell phone company to keep every SIM card (~100M) on a single system, while a similar-size competitor had been forced to fall back on 17-way sharding (presumably using a hash of the SIM id).
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"