This statement is also myopic and bordering on cliche. While true, there are a lot of times want to hire for a specific skill set. For instance, if there's a problem that needs solving right now, or a team that needs a new lead (assuming you must bring on outside leads), or a whole number of scenarios.
> You should care about the delta of an engineer's career and knowledge
This is, often times, a great indication of how competent an engineer will be.
> InfiniSQL currently is an in memory database. This means that all records are stored in system memory, and not written to disk. This provides very high performance--but it also means that InfiniSQL currently lacks the property of Durability. If the power goes out, all data is gone. This limitation is temporary.
They do mention that they'll implement persistence, but that's likely to lower performance, as you're limited to how fast the write ahead log can be written, even if updates to on-disk structures are batched.
They also mention:
> No sharding is necessary with InfiniSQL: it partitions data automatically across available hardware. Connect to any node, and all of the data is accessible.
I haven't looked at how joins are done across large tables that span over multiple nodes (or if it's even supported), but that's not likely to be fast either, for obvious reasons.
1) persistence: battery-backed UPS and synchronous replication. No WAL anywhere. I'm thinking about ways to do disk-based storage without synchronous IO, to provide decent performance with higher storage capacity
2) no joins supported yet. However, the benchmark that I performed (on the blog) involves 3 updates across random nodes. I designed InfiniSQL specifically to perform multi-node transactions very well, because that's the Achilles' heel of every other distributed OLTP system. I plan to implement joins, but expect them to perform decently for the workload you describe.
Gotcha, it's for OLTP, don't know how I missed that.
Should be quite easy to do equijoins especially if you're joining a couple thousand rows at most at a time; it only gets hairier when you're joining all records of very large tables that don't necessarily fit in memory, which is not very OLTP-y.
With regards to persistence, I'm really curious to hear how you're planning to have durability without writing something to disk on every transaction. It could work if you're relaxing the definition of durable to mean written to memory on at least $n$ nodes, though that's likely to be surprising to someone with a stricter definition of durable.
Edit: By the way, it's really cool that you have a C++ implementation of actors, I'll have to look into it. Have you thought about turning that into a library?
I've thought about having an actor library, or minimally, to have the actor basis of InfiniSQL independent of specific workload, but haven't thought it through entirely. I'd be supportive of any efforts to that effect if you want to work on it!
The point about dumb questions feels cliche to me. I ask my advisors (what I think are) smart questions that sometimes turn out to be dumb. Project yourself as an intelligent, confident person if you want to be judged as such (you do) and remember that your advisors are really busy too so don't waste their time!
This statement is also myopic and bordering on cliche. While true, there are a lot of times want to hire for a specific skill set. For instance, if there's a problem that needs solving right now, or a team that needs a new lead (assuming you must bring on outside leads), or a whole number of scenarios.
> You should care about the delta of an engineer's career and knowledge
This is, often times, a great indication of how competent an engineer will be.