Introducing “Database Performance at Scale”: A Free, Open Source Book

Re:Introducing “Database Performance at Scale”: A Free, Open... by WesleyJohnson on Thursday October 05, 2023 @01:28PM (#37781398)

Curious how you approach business units asking for reports that require multiple joins and can "filter by any column" and "sort by any column" and also offer pagination and then complain about why it's so slow? This is MySQL by the way.

The sorting by any column and pagination is really killer. Can't do cursor-based pagination so you get LIMIT/OFFSET which is terrible for performance, at least in this context. Indexes are often useless in this circumstance as well due to the filter by any column. We get lucky sometimes with a hard-coded WHERE clause as baseline filter for the entire report that hits an index, but not always. Just for fun, add in plenty of LIKE '%X%' because we limiting them to STARTS WITH is out of the question; it must be CONTAINS.

It's a constant source of frustration for the business and for the dev team.

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by pbowyer on Thursday October 05, 2023 @01:44PM (#37781596)

In our case we switched to holding that data in Elasticsearch. Now we have 2 problems: running Elasticsearch and keeping the data in Elasticsearch in sync with MySQL. We took an application-level approach to triggering record sync to ES but somewhere in our ORM it's doing some magic and doesn't sync in certain places. Database triggers are the next stop.

If we could do away with ES and go back to MySQL for what are glorified data grids with 20+ column filtering, sorting, and no full text requirements, we would.

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by WesleyJohnson on Thursday October 05, 2023 @04:46PM (#37784084)

We use ElasticSearch in a very limited capacity for keyword searches against consumer product metadata. We haven't ventured into using it for BI reporting, but I'm interested. I'm sure there is plenty of knowledge I can google, but any early insights or traps to avoid when moving from SQL-based reporting to something in ES?

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by stvltvs on Thursday October 05, 2023 @02:00PM (#37781827)

Sounds like the job for a denormalized OLAP data structure (e.g. star schema) with a BI tool. This is the kind of use case they were made for. In other words, you've rediscovered the motivation for data warehouses.

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by WesleyJohnson on Thursday October 05, 2023 @04:48PM (#37784109)

Thank you for the feedback. I'll do some research along these lines. We have moved a report or two to Power BI which has been must faster than similar reports built using dynamic queries. Keeping the data in sync and the Power BI learning curve have not been easy.

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by mr_toad on Thursday October 05, 2023 @10:25PM (#37786563)

The lazy approach is to denormalise the data in advance and load the result into memory. If it’s small enough you can simply return the entire result set to a reporting tool and query it locally.

[ Parent | on HN ]

Re:Introducing “Database Performance at Scale”: A Free, Open... by erulabs on Friday October 06, 2023 @12:19AM (#37787082)

If you want to sort by any column and paginate on any column (so you can have your cursor), a BTREE (MySQL index) is sort of the wrong structure in the first place. You probably want a document store for something like this. Scylla!

More pragmatically, just force bookmarked scans - limit the columns that can be sorted by - use a replica with indexes that the writer doesn’t have - pay for fast disks - use one of the new parallel query engines like Aurora or Vitess - just tell the business people to wait a dang minute, computer is thinking!

[ Parent | on HN ]