3 ms·
I've stopped reading database benchmarks, because they are extremely vague. Instead I spend my time optimizing my current solution/stack. For example Postgresql
by olavgg 9y ago
I've stopped reading database benchmarks, because they are extremely vague. Instead I spend my time optimizing my current solution/stack. For example Postgresql has hundreds of knobs that you can adjust for almost every scenario you can imagine. Sometimes you have a special query and increase the work_mem just for that session. Other cases you adjust the cost settings for another query/session. You can analyze your indexes and index types. And sometimes you need to rewrite parts of a big query.
Learning all this takes time, you are much better off learning more about your chosen technology stack than switching to another technology stack.
Though in a few rare races, you need a different technology to solve your business problem. In most cases they complement your existing solution, like Elasticsearch/Solr for full-text search or Clickhouse for OLAP workloads.
- maxxxxx 9y agoAgreed. Switching to another system is expensive and the benefit is pretty questionable.
- emsy 9y agoUnless you hit a very specific use-case/bottleneck, which I only ever witnessed once.
- TremendousJudge 9y agoexpand, please?
- maxxxxx 9y agoI imagine something very specific like having a lot of inserts into a table and that being your main use case. Depending on your data some databases may be better than others and that should be easy to measure. In most real-world cases the requirements however are not very clear and often conflicting so it's much harder to get data that shows the performance of one system over the other.
- gopalv 9y ago> Depending on your data some databases may be better than others and that should be easy to measure. And the performance difference could be an accidental feature of the design and completely unintentional. Postgres for instance has a native data engine, so it can store the exact row-ids for a row into an index, but this means that every update to the row needs all indexes to be updated. Mysql has many data engines (InnoDB and MyISAM to start with), to the row-id is somewhat opaque, so the index stores the primary key which can be pushed to the data engine scans and then have it lookup a row-id internally. This needs an index to be touched for the columns you modify explicitly or if the primary key is updated (which is a usual no-no due to UNIQUE lookup costs). When you have a single wide table with a huge number of indexes, where you update a lot of dimensions frequently, the performance difference between these two solutions is architectural. And if you lookup along an index with few updates, but long running open txns, that is also materially different - one lookup versus two. Though how it came about isn't really intentional.
- janemanos 9y agoWe just published an Update to the Benchmark, please find it here: https://news.ycombinator.com/item?id=16473117 https://news.ycombinator.com/item?id=16473117