4 ms·
This line of thought works for storage in isolation, but does not hold up if write speed is a concern.
by DixieDev 9mo ago
This line of thought works for storage in isolation, but does not hold up if write speed is a concern.
- convolvatron 9mo agoas a line of thought, it totally does. you just extend the workload description to include writes. where this get problematic is that the ideal structure for transactional writes is nearly pessimal from a read standpoint. which is why we seem to end up doubling the write overhead - once to remember and once to optimize. or highly write-centric approach like LSM I'd love to be clued in on more interesting architectures that either attempt to optimize both or provide a more continuous tuning knob between them
- cannonpalms 9mo agoSo long as (fast/optimal) real-time access to new data is not a concern, you can introduce compaction to solve both problems.
- bob1029 9mo ago> (fast/optimal) real-time access to new data https://en.wikipedia.org/wiki/Optimal_binary_search_tree#Dynamic_optimality https://en.wikipedia.org/wiki/Optimal_binary_search_tree#Dyn...
- deleted 9mo ago[deleted]
- sandworm101 9mo agoSpeed can always be improved. If a method is too slow, run multiple machines in parralel. Longevity is different as it cannot scale. A million cd burners are together very fast, but the CDs wont last any longer. So the storage method is is the more profound tech problem.