We Replaced an SSD with Storage Class Memory(engineering.mongodb.com) |
We Replaced an SSD with Storage Class Memory(engineering.mongodb.com) |
but i totally agree, rethinking how data is stored is going to be key to the adoption of these types of new media. there's a company called vast data that has built out a full storage solution utilizing the unique properties of SCM, very cool https://vastdata.com/
However, even their 6-DIMM test produces only 300 Gbps, which is insufficient to saturate a modern 400 GbE network adapter for either reads or writes.
This would be most relevant on a "single master" system storing some sort of simple data where consistency requirements means that the "writer" cannot be distributed. In a situation like this, the NIC and the storage bandwidth are the ultimate limits.
In general, Intel SSDs and Intel Optane have poor but consistent bandwidth, and consistently low latency. Coupled with the high price and small capacity, they have their niche, but they're not a clear winner in any category.
As a reference point for how crazy high bandwidths are these days, NVIDIA sells a turnkey solution with 200 GB/sec network bandwidth (1.6 Tbps!): https://www.nvidia.com/en-au/data-center/dgx-a100/
For a database system like mongodb this could be perfect depending on workload.
I'm still wondering if that interview costed me a level.
It is better to play along and only mention the real solution at the end, to finish on a high note.
> I'm still wondering if that interview costed me a level.
Unlikely. Candidate level is decided before the interview.
By this point we had both realised that this was a battle of wits: could he come up with a problem that i couldn't solve with a pipeline?
At the end of the interview, i had a pipeline that took up most of a piece of A4 paper to write out. I had won the battle, and was offered the job.
Of course, i would not advise you to actually write a pipeline like that in production, but it's a fun exercise.
Anyway, the moral of this story is that if the interviewer wants you to solve a problem a certain way, and you can solve it in a simpler way, then a good interviewer will mark you up, not down. Perhaps at Google they didn't; they don't really seem like a company that has it together.
Why did he have concrete numbers. Couldn't he simply have increased those numbers when you proposed single machine solution.
(RAM is obviously volatile.)
If you are storing data to disk at that speed, you fill even the biggest optane drives in a couple of minutes. So it would be an application where you need to overwrite a huge amount of data over and over again.
It reminds me of the Bugatti Veyron situation, its tires lasting 15 minutes at top speed yet it runs out of fuel in 12.
As for write speed, you don't really need it unless you're doing file/data recovery, but even then you can just make indexes to the disk image.
AFAIK, very few (if none) are using SCM in their forensic expert workstations, so I can't really tell if you'd saturate the storage capacity or the bandwidth. But in digital forensics, NVMe's have been a must for a while, so this would definitely help.
Another use is to have local storage. You want most of the communication to be between your CPU and RAM/SCM and networking only to transmit results. In case of mongodb that would be something like very heavy aggregation that needs to look at a lot of data but transfers relatively small amount of results to the client (think counting number of objects meeting an arbitrary set of specifications). MongoDB actually requires storage for writing intermediate results of some types of operations so it is not purely about read speed.
I'm trying to address this with my versioned Open Source DBMS project, where only page-fragments are stored and bunch of them is read in-parallel to reconstruct a full page in-memory. Adding mini-page ps plus a simple cache at some point with hot data from several page fragments at least is orthogonal:
Most of the _data_ is also not going to fit in 256 bytes anyway.
http://www.mongodb-is-web-scale.com/
(I can get better results for Key-Value storage by using an SQL Database--Postgres or MariaDB--for key/values over MongoDB. And if you know SQL well, you can get even better results using a real relational database and optimal queries than pulling out keys/values and ad-hocking your relations in some Javascript code or whatever these web kids are doing.)
So, it might well be that someone is only interested in only one or a few records. Why then fetch and cache a whole 4Kb page if latency is good in both cases (4kb and 256 bytes)? On the other hand I agree that you should probably cache more data from a hot page.
> would not advise you to actually write a pipeline like that in production,
So when you are interviewing for a production job, why would you fight for non-production quality solutions?
I have interviewed couple candidates that were offended by the fact that I am asking hard questions that I know answers to.
This resulted in remarks like "I have never seen this question on the Internet" or "So what is the answer to this question anyway?" or "If I knew questions would be this hard I would not bother to come".
Somebody explain to people that it doesn't matter how hard the questions are but how the candidates compare. I am fully prepared that the candidates study questions that are available on the Internet, I want to see how they deal with something that requires a bit more than couple hours of effort and rote memorization.
In real heterogenous-workload production clusters, every available machine likely has several VMs scheduled on it if the cluster isn't idle. There is never a full machine that's free unless some special effort has been taken to make it so.
To make things more complicated, a long-lived cluster is going to be made up of different classes of machines, from different CPU micro-architecture, so 'single machine' is overly constraining. Eg it's not interesting that a job with a 4 MiB requirement can always run if your job needs 32 GiB.
"Rather than making your computation go faster, the systems introduce substantial overheads which can require large compute clusters just to bring under control.
In many cases, you’d be better off running the same computation on your laptop."
My limited experience fits this in that a bit of smarts on a single box beats a bunch of boxes.
(the link is a very good read BTW)
Of course, for a batch job with a runtime under 11 minutes, that probably doesn't really matter too much. Just don't generalize that too much.
I can't hire a person that can't restrain their ego for the duration of the interview and an interviewer that is focusing on anything else than figuring out if the candidate is right person for the job is causing disservice to everybody.
They may look clever, but they're often not the ideal solution compared to a simpler to understand, and often easier to optimise iterative solution. I write plenty of DSP, GPGPU programming, and computer vision, and I can't honestly remember the last time I wrote a recursive function.
Unclear if that means we need candidates who are better at recursion, or better at avoiding recursion.
Not remotely surprising is it. Hopefully if you went for a suitable job they wouldn't ask unsuitable questions. Then again, writing a recursive factorial should pain no-one.
Think about IQ test which shows some abstract puzzles that have no connection with the real world. They are part of the test because they provide measurement points on tasks that require different types of abstract thinking without prerequisite knowledge.
Again, it is not possible to verify you have all the necessary knowledge for the job, nor would it be useful (no candidate knows everything for the position and if he did he would likely be overqualified).
I of course ask questions that test candidate's knowledge in the most useful areas, but at least part of the interview I want to devote to finding out how smart he/she is on abstract tasks that don't require some special knowledge.
If our per-callstack frame is 10k bytes, and we can spend 1 megabyte of stack on recursion (both are pessimistic).. we can go 100 levels deep. Which means we can expect to run into problems when there are more than ~5E29 elements.
This assumes we don't write the recursion in a way that the compiler can elide it entirely with tail-call optimization.
I'm not a huge fan of recursion, but let's not resort to too much hyperbole in our arguments against it. :P
This is incorrect.
Your limit is only for fully balanced trees. On a fully unbalanced tree your solution will crash at about 100 elements.
Do we see a lot of unbalanced trees? Yes, most of the time in my experience. If there's a balanced tree, there's probably a data structure and the function is already supplied. Writing a tree traversal function come up when working with unbalanced things like program ASTs, JSON/HTML/XML parsed data, Lisp-style lists, filesystem traversal, etc.
> This assumes we don't write the recursion in a way that the compiler can elide it entirely with tail-call optimization.
The compiler cannot elide away tree traversal with tail-call optimisation. Only one branch.
A really smart compiler could transform it into a loop with an explicit node-stack using an array, or avoid the stack and use in-place pointer-reversal if concurrency rules permit and there's a spare bit. But I've never seem a really smart compiler do either of those things.
5E29 assumes not-quite-balanced. Yes, I'm assuming some kind of balanced binary tree data structure, not other things that are tree-like. There are some things that are much better than 5E29, like btrees. :P
If you have really deep unbalanced trees, you may want to have a smaller stack frame and/or pay the pain of doing things iteratively with your own stack. (Or have upward links in your tree and do it purely iteratively but slow).
> The compiler cannot elide away tree traversal with tail-call optimisation. Only one branch.
Yah, sorry. Just for search, not for full traversal.
They're handy for some parsing and scripting scenarios however, I'll grant you that.
Back in the mid 80's on DOS I had no problem recursing 30+ levels deep.
If I were writing a server that needed better memory requirements, I could certainly transform my code if desired.