Read Ops calculation logic

Help
1

I’m struggling to understand how to calculate / check the number of Read Ops.

When I executed the query below, then I saw in the dashboard that it has consumed 99 Read Ops.

      q.Let(
        {
          nodes: q.Select(
            ["data"],
            q.Map(
              q.Paginate(q.Match(q.Index("all_topic_details")), {
                size: 10000,
              }),
              q.Lambda("result", {
                id: q.Select("id", q.Select([1], q.Var("result"))),
                name: q.Select([0], q.Var("result")),
              })
            )
          ),
          links: q.Select(
            ["data"],
            q.Map(
              q.Paginate(q.Match(q.Index("all_topic_relationship_details")), {
                size: 10000,
              }),
              q.Lambda("result", {
                from: q.Select("id", q.Select([0], q.Var("result"))),
                to: q.Select("id", q.Select([1], q.Var("result"))),
              })
            )
          ),
        },
        {
          data: {
            nodes: q.Var("nodes"),
            links: q.Var("links"),
          },
        }
      )

Which is much higher than I thought. This is my (thought) calculation:

  • 2 indexes read = 2 Read Ops
  • A read request (by default strongly consistent and transactional) of up to 4KB requires one transactional read op (TRO). For items larger than 4KB, additional TROs are required. → my dataset is less than 10KB = max 4 Read Ops

Thus 6 Read Ops in total. Or do I overlook something?

2

Where are you seeing the 99 ops? When running the query in the shell?

3

After I have executed, then I see 99 Read Ops in Fauna dashboard (after about 4 hours). Is there a “fine-grained” audit logs?

4

Try running the query straight in the shell of the dashboard and then open the info tooltip on the left.

image
image1248×684 91 KB

You can paste your JS query as it is (unless you have some JS variables which you will have to hardcode).

5

Prior to our November 2020 release (API v4), index reads were one read op. Now, they are one read op per 4k read per index partition. If your index has 8 partitions, then you get 8 read ops per index “read”, which is typically one page of results from Paginate.

This is described in some detail on our billing page: Billing | Fauna Documentation
“Legacy billing” is prior to November 2020, “current billing” is today.

1 Like
6

@pier: I see 19 byteReadOps. It is still huge difference than what has been shown in the dashboard. I will shutdown my website to be 100% sure that there are no other API calls, and retry again.

image

1 Like
7

Note that the tooltip in the Dashboard’s shell that shows query metrics is showing the counts specifically for that query. The Dashboard’s home page shows cumulative metrics for the month. Use of the Dashboard to view/modify/delete documents also contributes to the cumulative metrics.

8

Will it also consume Read Ops if I only check the metrics?

image
image3780×1098 214 KB

9

Yes. In order to show the list of available databases, the Dashboard has to run the equivalent of Map(Paginate(Databases()), Lambda("db", Get(Var("db")))).

Results are cached as needed. The rules are a bit complex, but the TL;DR is: we do try to avoid needless queries while trying to reflect the current state of your database.

10

Ok thanks for your explanation. This explains where these additional Read Ops are coming from.