4 ms·
We built HopsFS on NDB, not CalvinDB, because we needed performance for cross-partition transactions. Some workloads need it. In the filesystem workload, when F
by jamesblonde 8y ago
We built HopsFS on NDB, not CalvinDB, because we needed performance for cross-partition transactions. Some workloads need it. In the filesystem workload, when FS path components are normalized and stored on different partitions, practically all transactions cross partitions. So if you serialize them, then writing a file in /home/jchan will block writing a file in /home/jim. This is what most distributed filesystems already do - have a global write lock on the filesystem metadata. I like having the freedom to build my the concurrency model on top of READ_COMMITTED, as i can squeeze out 16X performance improvemnts by doing so (ref: https://www.usenix.org/conference/fast17/technical-sessions/presentation/niazi https://www.usenix.org/conference/fast17/technical-sessions/... )
- evanweaver 8y agoSure, if you don't care about serializability, you don't need to pay consensus costs to enforce it, but you will be subject to read and write skew.
- notacoward 8y ago> This is what most distributed filesystems already do - have a global write lock on the filesystem metadata Absolutely untrue. Stop lying about other systems.