emilv
Joined 15 years ago
Joined 15 years ago
Databases have inherent locking problems that takes more resources to resolve with more machines, more so in some database systems than others. When scaling you often hit a point where you get down to macro logistics, so imagine a car highway: You can get more throughput by adding more lanes. But what that all cars are going to merge to one lane at some point in the middle of the trip (because of a tunnel, bridge or something: it's impossible to have more than one lane at that point)? Now you won't get any throughput benefits of the multiple lanes after all! Just more latency because you get queues up until the single lane and because of the queues all cars are going slow and need to accelerate on the single lane, so the average speed is low too. You are also having too much resources after the single lane because you can never fill all those lanes. It might be better to have one beefed-up single-lane road all the way that people can go fast on. Basically: Remove locks and you get better overall performance.
Yes, this is on the expense of HA. Yes, the costs of scaling up grows asymptotically faster than the costs of scaling out. So this is definitely a trade-off in some sense.
I still believe I'm with the 25% that didn't prefer asynchronous messaging.
The number of significant digits on the Castille version is ridiculous compared to the others. Could it be that Castille still uses this unit and therefore have such a specific translation value?
I learned a lot by reading the source code for Python dicts (which also comes with a lengthy motivation for why it was implemented that way) and any Haskell library (Hackage links from the manual page directly to the source code for the respective function, which makes it very easy to see what is happening).
Tampering with the data, however, is not OK at all. In the U.S. I believe it may make the ISP exempt from for example the safe harbor clauses in the DMCA.