Earlier quoted context omitted.
Two. The number is two. You always need a backup server :)
Three. So you can do maintenance on one while still having HA.
*Sometimes three.
Go back to two when maintenance is done.
A lot of complex “scalable” systems can be done with a simple, single C++ server
201–210 of 376 posts
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#202Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…
Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point). Are you saying this can be optimised to f…
Not sure which DB you are using, but you can load the csv file into the DB directly on a single thread using something like LOAD DATA INFILE.
If you have some good indexes and do some push-down work (give the database aggregation tasks to do instead of your python code), you should probably be more than fine.
For a 250Gb file.. should be ok.. maybe add some partitioning too.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#203Earlier quoted context omitted.
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about. I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.
Yes shared_ptr is relatively expensive; avoid it in your inner loops, but know that it's there for the other 80% of your code.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#204Earlier quoted context omitted.
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
C++ shared_ptr unfortunately is artificially slowed down by multithreaded synchronizations. The count in the control block is always updated atomically. But I frequently need to use them not because my data is shared by multiple threads, but because the ownership situation isn't static. Consider for example implementing a single-threaded persistent tree. This means people frequently need to reinvent their own referen…
To be fair, std::shared_ptr is just a high-level component that's a part of the STL. Although it's defined in the C++ standard, it's just a generic shared pointer implementation designed to be as robust and bullet-proof as possible.
As with everything in the C++ STL, if you care about bleeding edge performance then you should be prepared to use more perform any (and less generic) components, whether it's data structure implementations or shared pointers.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#205Horizontal scalability carries a lot of overhead. Probably a factor of 10, easily. But the clue is in the name: eventually you'll get to a point where you have to scale. Back in 2010 I worked for a company whose system, in Java, ran on a single web server (with one identical machine for failover). We laughed at our nearest rivals, who were using Ruby, and apparently needed 60(!) machines to run their system, which ha…
Web servers are usually trivially horizontally scalable.
You must have had significant in-memory shared state to encounter that problem. Right?
Had you adopted a less stateful model, you'd have looked rather pretty with two Java servers.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#206Earlier quoted context omitted.
This is fine as long as you can convince management to spend the money to rewrite your software. That's usually a hard sell though. In my experience this plan usually ends up with a python monstrosity that everyone hates but is forced to deal with forever.
Type hints and dataclasses are a game-changer for Python. Much easier to reason about programs that use them.
> Type hints and dataclasses are a game-changer for Python. Much easier to reason about programs that use them.
Type hints made large python codebase switch from "Any change will blow up to my face" to "I can touch it carefully with protection gloves".
Through, it is still pretty easy to fool mypy and very far of the compile time guarantees that provide most static typed AOT compiled language.
And unfortunately, it also does not bring any advantage in term of performance.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#207wow, so much speculation, zero empirical evidence.
His entire comment was based on empirical evidence. Which is why people are disputing it - because there is room to do so.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#208Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…
Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point). Are you saying this can be optimised to f…
250GB data is tiny. There are laptops with 128GB RAM, let alone servers.
Obligatory read: https://aadrake.com/command-line-tools-can-be-235x-faster-th...
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#209This is precisely the point made by McSherry, Isard and Murray in their lovely paper, "Scalability! But at what COST?" (Usenix HotOS '15). They demonstrate how much performance headroom there is in modern CPU and memory, and show how simple cache-sensitive batch algorithms running on a single core can outperform hundreds of cores running distributed map-reduce style jobs. https://www.usenix.org/system/files/conferenc…
Big data is about I/O not CPU I’m a C++ veteran btw and understand the point but big data is about how to process petabytes of I/O not how to consume CPU.
Correct me if I’m wrong, but isn’t the point of writing cache coherent code the fact that memory I/O is the bottleneck these days?
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#210Earlier quoted context omitted.
Its more like 'Here at BigCo, we do x because it scales. We have learned it from various incidents that we won't tell you about, but trust us we have to do it this way."
I've worked at BigCo. It's resume padding with the fear of looking like an idiot for not knowing about the new tech. We were going to go all in on Snowflake with everyone on the team being for it. I sat down, read the original whitepaper, wrote a simulation of what the costs would look like with the current read/write statistics and tested a small batch of data on it to double check. Turns out we would have paid betw…
I'm starting to wonder if there is market to do "technology laundering", use things like PostgreSQL, SQLite, standard Unix tools, put it under some cloud marketing and charge a x10 premium.
Or perhaps not only there is market, but that's more or less what everyone is already doing.