DEV Community

Franck Pachot for YugabyteDB

Posted on • Updated on

YugabyteDB range sharding: ASC or DESC?

With PostgreSQL, using B-Tree indexes, scanning an index forward or backward is usually similar in performance, because the leaf pages are linked to the next and previous ones. YugabyteDB distributed SQL database stores tables and indexes in LSM-Tree structures, where entries are append only, and are navigated differently, with skip lists. They can also be scanned forward or backward but the cost of it is different.

I start a lab:

docker run --name yb --hostname yb --env PGHOSTNAME=yb \
-d --rm --cap-add=SYS_ADMIN -p7000:7000 -p9000:9000 -p5433:5433 \
yugabytedb/yugabyte:2.13.2.0-b135 bin/yugabyted start \
--daemon=false 
sleep 15
docker exec -it yb ysqlsh
Enter fullscreen mode Exit fullscreen mode

I install my ybwr utility to gather some execution statistics and create a demo table:

\! curl -s https://raw.githubusercontent.com/FranckPachot/ybdemo/main/docker/yb-lab/client/ybwr.sql | grep -v '\watch' > ybwr.sql
\i ybwr.sql
create table demo ( id int, primary key(id ASC) );
insert  into demo ( id ) select generate_series (1,1000);
Enter fullscreen mode Exit fullscreen mode

I have defined the primary key as range sharding in ASCending order.

I execute a query reading in ASCending order, like the index, and another one in DESCending order

execute snap_reset;
explain analyze select id from demo order by id ASC;
execute snap_table;
explain analyze select id from demo order by id DESC;
execute snap_table;
Enter fullscreen mode Exit fullscreen mode

The result on this 1000 rows table is:

yugabyte=# execute snap_reset;

 ybwr metrics
--------------
(0 rows)

yugabyte=# explain analyze select id from demo order by id ASC;

                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Index Scan using demo_pkey on demo  (cost=0.00..114.00 rows=1000 width=4) (actual time=4.584..5.417 rows=1000 loops=1)
 Planning Time: 5.227 ms
 Execution Time: 6.013 ms
(3 rows)

yugabyte=# execute snap_table;

                     row_name                      | rocksdb_#_db_seek | rocksdb_#_db_next
---------------------------------------------------+-------------------+-------------------
 yugabyte demo yb b701907f833d402fbe68835cdd7fc2bb |                 1 |               999
(1 row)

yugabyte=# explain analyze select id from demo order by id DESC;

                                                            QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
 Index Scan Backward using demo_pkey on demo  (cost=0.00..124.00 rows=1000 width=4) (actual time=1.778..21.633 rows=1000 loops=1)
 Planning Time: 0.102 ms
 Execution Time: 24.215 ms
(3 rows)

yugabyte=# execute snap_table;

                     row_name                      | rocksdb_#_db_seek | rocksdb_#_db_next
---------------------------------------------------+-------------------+-------------------
 yugabyte demo yb b701907f833d402fbe68835cdd7fc2bb |              2062 |              1014
(1 row)
Enter fullscreen mode Exit fullscreen mode

When fetching the rows in the order of the index, with Index Scan, I see one rocksdb_number_db_seek to go to the start of the index, to get the first row, and then 999 rocksdb_number_db_next to get the remaining rows. A next call goes to the next document in the RocksDB database, and is less expensive than a seek call that has to find the right document, from its key value.

When fetching rows in reverse order of the index, with Index Scan Backward, there is no next call to go backwards in RocksDB. This uses a seek backward. I can two seek calls per row here, in addition to one next per row.

To get an idea of the CPU cost of it, I ran the backward scan in a loop while taking flamegraph of it:

yum install -y perf git wget
perf record --call-graph fp -F99 -e cpu-cycles -p $(pgrep -d, yb-tserver) sleep 120
git clone https://github.com/brendangregg/FlameGraph.git
wget -c https://raw.githubusercontent.com/FranckPachot/ybio/main/util_flamegraph/palette.map
perf script -i perf.data | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl --colors green --width=1200 --hash --cp | tee perf.svg && chmod a+r perf.svg
echo $(curl -L --upload-file perf.svg http://transfer.sh/$(date +%Y%m%dT%H%M%S).svg)

Enter fullscreen mode Exit fullscreen mode

You can get look at the .svg and here is a screenshot:
flamegraph
This shows two important call stacks from "To Next Desired Row":

  • yb::docdb::DocRowwiseIterator::HasNext() > yb::docdb::DocRowwiseIterator::AdvanceIteratorToNextDesiredRow > yb::docdb::IntentAwareIterator::PreparePrev > yb::docdb::PerformRocksDBSeek
  • yb::docdb::DocRowwiseIterator::HasNext() > yb::docdb::DocRowwiseIterator::AdvanceIteratorToNextDesiredRow > yb::docdb::IntentAwareIterator::SeekToLatestDocKeyInternal

Note that, if you cannot run perf I show another way to get the call stacks from the tserver endpoint in: https://dev.to/yugabyte/quickly-get-short-stack-from-a-yugabytedb-tserver-2j03

The rows are stored in a document, with one sub-document per column (I simplified here with one column per row) but can accumulate multiple versions, so the timestamp is also part of the key. The structure is optimized for forward scans, with the current version first, but my guess is that backward scan needs, in addition to going to the right row, an additional seek to get the right read timestamp.

When creating a range sharded primary key or secondary index, it is recommended to think immediately about the natural order of it, for queries that has to retrieve lot of rows in this order, to avoid less efficient backward scans. But what if there are queries ordering in both way? The difference may not justify adding more indexes. Think first about critical queries which read lot of rows in a specific order, and maybe the backward scan will be acceptable for other queries reading less rows. Note that the query planner may also decide to use a forward scan and sort it later. I'll show that in a next post.

YugabyteDB has many optimizations pushed down to the storage layer. If you query only few rows out of many, the Index Scan Backward will minimize the seek operations:

yugabyte=# execute snap_reset;

 ybwr metrics
--------------
(0 rows)

yugabyte=# explain analyze select id from demo where id in (100,200,300) order by id DESC;

                                                       QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
 Index Scan Backward using demo_pkey on demo  (cost=0.00..4.12 rows=1 width=4) (actual time=1.126..1.136 rows=3 loops=1)
   Index Cond: (id = ANY ('{100,200,300}'::integer[]))
 Planning Time: 0.136 ms
 Execution Time: 1.201 ms
(4 rows)

yugabyte=# execute snap_table;

                     row_name                      | rocksdb_#_db_seek | rocksdb_#_db_next
---------------------------------------------------+-------------------+-------------------
 yugabyte demo yb b701907f833d402fbe68835cdd7fc2bb |                 6 |                 3
(1 row)
Enter fullscreen mode Exit fullscreen mode

There is still two seeks to go backward, but only for the rows that need to be accessed. This means that the importance of ASC or DESC is mostly when fetching lot of rows from the Index Scan.

You can detect this by looking at explain (analyze) output. The indexes where the order may not be the optimal one are those with an Index Scan Backward having a high number of rows in (actual ... rows= or Rows removed by filter)

I've written this post after a little test I did in last week Twitch session - the record is here: https://youtu.be/tiR1_Om_To4?t=3309

Discussion (0)