3 ms·
Just came here to post this. It's frustrating, because a configuration like that makes the numbers completely irrelevant, unless you don't care whether your da
by knightni 14y ago
Just came here to post this.
It's frustrating, because a configuration like that makes the numbers completely irrelevant, unless you don't care whether your data gets persisted or not. I'd much rather see a more like-for-like comparison, and perhaps an unsafe configuration included for interest's sake.
- linuxhansl 14y agoNobody 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.