3 ms·
Nobody in their right mind hits a key value store for each single key value (an RPC for each key value). You'd be limited by the network latency. You batch you
by linuxhansl 14y ago
Nobody in their right mind hits a key value store for each single key value (an RPC for each key value). You'd be limited by the network latency.
You batch your changes in the client and then you commit them to the server. When that commit succeeds your data is persisted; until such time any client application must consider the data uncommitted. This is not unlike a client application would deal with transactions to a relational database.
So the benchmark is completely valid here.
(Well, only that here we also have deferred log flush, which means the changes will take a second or two to actually make it to the file system, but that still demands the same aggregate throughput from the HBase. That is where this test is not fair).
Edit: Spelling
- knightni 14y ago> (Well, only that here we also have deferred log flush, which means the changes will take a second or two to actually make it to the file system, but that still demands the same aggregate throughput from the HBase. That is where this test is not fair). That was actually the bit that I was concerned about - I failed to read the parent comment properly and assumed it had the exact same concern I did. If you don't have to do a disk write because you're not guaranteeing durability, you have a completely unfair comparison.