Something the author(s) don't seem to fully consider when creating composite indices is how B-trees work. The leanest and almost always fastest composite index for MariaDB/MySQL is one where the columns are ordered first to last relative to lowest and highest <i>cardinality</i>, i.e. how divergent they are. You <i>usually</i> want a B-tree index that's as little branchy as possible in the start, and then branches out increasingly the deeper into it you get, in order to traverse its components as fast as possible. The performance difference between a correctly ordered composite index and one that's ordered seemingly on random, as in the article, can be not-insignificant.
Keeping low latency for an online data service with more than 5 billion records can be a challenge. Features like query the database with natural language(<a href="https://ossinsight.io/explore).This" rel="nofollow">https://ossinsight.io/explore).This</a> makes it easier for users to access the data without having to know SQL. But the generate SQL could be pretty heavy(many Full table scan and index scan).