|
|
|
|
|
|
by Rohansi
427 days ago
|
|
|
Serial execution makes the most sense from a database perspective because they work off a transaction log. Parallel execution may require separate transaction logs (basically durable queues) to accomplish sharding but that introduces a whole new set of issues because tables can only be mutated from a single transaction log. Code that needs to access multiple suddenly gets a lot more complex. There was actually a post on HN the other day about this: https://news.ycombinator.com/item?id=43661181 |
|
|
Rather the main thing is mainly about coupling storage and sharding decisions with the simulation, since both a sharded simulator and sharded storage system will need logic for sharding and time-versioning, it's silly to duplicate work (or worse have out of sync semantics). In addition cohabiting simulation and storage will lessen latency and other issues w.r.t. to separating them.
Now, it's entirely possible that I'm barking up the wrong tree but considering that many are exploring this design-space means that there is interest and merits even if only the Spacetime and a few others have taken the leap yet.