third myth in the article compares B-trees to hash tables:
"Trees are better
In general, trees aren’t faster for searching for exact matches. They’re slower, and here’s peer-reviewed evidence that compares B-trees, splay trees, and hashing for a variety of string types. So, why use a tree at all? Trees are good for inexact matches — say finding all names that begin with “B” — and that’s a task that hash tables can’t do."
There are two articles that are linked to in the text, one that describes comparisons of binary tress, self-adjusting tress, and hash tables. There's a second article that compares B-trees, hash tables, and a few other structures -- that's this one: http://ww2.cs.mu.oz.au/~jz/fulltext/acmtois02.pdf
my point is merely that as written, the article is confusing.
to paraphrase: "hashtables are faster. here's some research showing b-trees are slower than hashtables. why would you ever use a tree? prefix matching, that's why."
which misses the point that the primary reason for using a B-tree as a general purpose database index is not about prefixes, it's about block devices (prefixes is an important reason, but it's not the main one)
if the purpose of the article was to ignore implementation and spinning disks and just look at in-memory performance, then don't mention B-trees. they're an implementation-specific optimisation, and it just confuses.
"Trees are better In general, trees aren’t faster for searching for exact matches. They’re slower, and here’s peer-reviewed evidence that compares B-trees, splay trees, and hashing for a variety of string types. So, why use a tree at all? Trees are good for inexact matches — say finding all names that begin with “B” — and that’s a task that hash tables can’t do."