3 ms·
I think this is too reductive. A b-tree isn't the only indexing strategy, and it's well understood that an index is intended to improve read performance at the
by ljm 3y ago
I think this is too reductive. A b-tree isn't the only indexing strategy, and it's well understood that an index is intended to improve read performance at the expense of write performance because the common case is that your DB handles a lot more reads than writes.
> but when you realize you're just adding one tree on top of another you're just masking the problem.
What is the problem and how do you propose to solve it without touching indexes? They are a hard requirement for any decent sized table.
- tonymet 3y agoIf you are using oracle, mysql , mssql you are typically using b-tree index. mysql supports hash index but i rarely see it applied in prod (probably just habits or lack of familiarity).
- roetlich 3y agoYes, but a lot of the cool, new DBs use LSM trees. The post we're currently discussing also spends more time explaining LSM trees + WAL, than it does B-trees. But your point is still valid. :)
- tonymet 3y agoUsing data structures that match the performance profile. if the DB doesn't support that, using another solution.