Compute Units

By using ZettaBlock, you have the power to access and query web3 data using SQL and quickly create real-time, public-facing GraphQL APIs. These services are provided through the compute units supplied to each account.

Compute Units, as defined on the platform, are used to measure the amount of resources used to create and run analytical queries and GraphQL APIs. For example, running a query on ZettaBlock’s Query Builder, results in a call to our query engine which in turn starts off a data scan of the tables specified before producing a result for the user. Additionally, users can turn their analytical queries into GraphQL APIs using ZettaBlock’s API Builder which would involve the materialization and storage of the datasets within a virtual database for future API calls.

In the query example, compute units map directly to the data scanned when running the query as well as the time it took to fully execute the request. The same process occurs when compute units are calculated during the creation, data refreshing and usage of APIs. To clarify, compute usage units measure only the resources used to scan datasets and the execution time of queries within the query engine, while services related to data storage and the accessibility of tables are included as part of the ZettaBlock platform services.

Usage Overview

Considering how compute units are measured, let’s take a deeper dive into their account usage metrics within the Usage management section. The compute unit usage overview gives you access to the API usage metrics for all users under a specific account or organization if you purchase an enterprise plan.

There are two metrics detailed in this section, the Total Compute Units Used and the Prepaid Compute Units recorded in the last 30 days. Total Compute Units Used will be detailed below while prepaid compute units are an emerging feature and as such will be listed at 0 at this time. There will be additional context provided once this feature is launched.

Individual accounts

The example shown above illustrates an individual account and details the single main user and their usage in the last 30 days. Specifically, when reviewing the metrics for the last 30 days of usage, a user has access to a summary of the Total Compute Units Used recorded in the last 30 days. The Total Compute Units Used refers to the total amount of computational units used to support all the calls, data indexing and data refreshes for all of the GraphQL APIs and analytical queries created within this individual account.

Organization accounts

In the case of organization accounts, the Total Compute Units Used refers to the total amount of compute units used to support all the calls, data indexing and data refreshes for all of the GraphQL APIs and analytical queries for all users under the organization. For example, as shown in the image below, imagine an organization with 3 main users. Each user has a record listing the number of queries they’ve run and the number of API calls made to the APIs they’ve created. These metrics are then aggregated together to calculate the total compute units used by the organization in the last 30 days.

Compute Units Usage Breakdown

Taking a deeper dive into user metrics, users also have access to the compute units usage summary. This summary offers a breakdown of individual account usage or an overview of the organization's overall usage in the case of enterprise plans.

The API section details an aggregated view of all usage with a categorisation of compute usage units for data indexing (Indexing CU) and data refresh (Data Refresh CU).

Data indexing cost is related to the resulting dataset size, including the size of indexes created by users during configuration of APIs for better performance during data retrieval. For example, you may create an API to understand pricing of recent transactions over the last 2 months, say the resulting dataset is X GB. During the API’s creation, you specify additional field indexing of the data using the transaction_hash to facilitate faster responses when the API is called, which adds the size of the transaction_hash index to the final dataset. If the size of indexes is small (which is most likely), then the cost will be proportional to the X GB instead of number of indexes the customer choose.

The data refresh metric refers to how often the API is scheduled to refresh its base dataset as set in the initial configuration. Compute units calculated for data refreshes with no incremental refreshing (i.e. full dataset refreshes) are exactly the same as those used for analytics queries. If an incremental refresh is implemented, it drastically reduces the compute units required to process the data refresh.

The last metric included in this section is the Number of API Calls. The Compute Units for API calls are calculated as the number of records pulled during a call multiplied by the compute usage per 100 records for the specific API. This calculation is dynamically calculated based on the records requested during an API call. As illustrated above, the CU per 100 records for each API is calculated by dividing the total dataset size by the number of records. Each API will have their CU per 100 records displayed within the API’s overview page.

The ANALYTICS section refers to your organization’s usage of the ZettaBlock Query builder. There are 2 metrics listed - the Number of Queries and the Compute Units. Number of Queries relates to the number of queries, both for analytics and APIs, built and run on the platform, while the Compute Units relate to the resources used during each run of those queries. Note that a GraphQL API can also generate analytics compute units during the API’s creation. This is again calculated based on the amount of data scanned and the total execution time for these queries.

Underneath the summary section, users should have a breakdown of the metrics for API usage only. These metrics include the total API calls and compute usage units for data refresh and indexing. For each API, these metrics are added together to calculate the total compute usage units for each API.

Compute Unit Examples

Let’s review some examples of compute usage units in action through analytical queries and their equivalent GraphQL APIs. Please keep in mind that analytics compute units are calculated by taking into account the data scanned size and execution time while compute units for GraphQL APIs are calculated from adding together the compute units from indexing, data refreshing and API calls.

Looking at the first simple query and the API created from it:

• Run time: 2.945 sec
• Data scanned: 222.82 MB
• Analytics CUs: 2097
• Indexing CUs: 302.2
• CUs for Data fresh every 24 hours (without incremental refresh): 2097.8
• CUs per API call: 0.25

SELECT  
  DATE_TRUNC('day', t.timestamp) AS date_time,  
  COUNT(DISTINCT CASE WHEN success=TRUE THEN t.version END) AS number_transactions,  
  COUNT(DISTINCT t.sender) AS unique_active_users,  
  type as txn_type  
FROM  
  aptos_mainnet.transactions AS t  
WHERE  
  TYPE = 'user_transaction' -- 3 types  
  AND DATE_TRUNC('day', t.timestamp) >= current_date - INTERVAL '7' DAY  
  AND DATE_TRUNC('day', t.timestamp) \< current_date

GROUP BY  
  DATE_TRUNC('day', t.timestamp), type  
ORDER BY  
  date_time desc

For another example, let’s review a more complex query and the API created from it:

• Run time: 21.376 sec
• Data scanned: 62.25 GB
• Analytics CUs: 594019
• Indexing CUs: 302.2
• CUs for Data fresh every 24 hours (without incremental refresh): 580260.9
• CUs per API call: 3.00

SELECT  
    l.contract_address,  
    count(\*) as ct  
FROM ethereum_mainnet.logs l  
LEFT JOIN ethereum_mainnet.nft_tokens t  
    ON lower(l.contract_address) = lower(t.contract_address)  
WHERE 1=1  
    AND cardinality(l.topics) = 4  
    AND l.topics[1] = '0xc3d58168c5ae7397731d063d5bbf3d657854427343f4c083240f7aacaa2d0f62'  
    AND t.contract_address is NULL  
GROUP BY l.contract_address  
ORDER BY ct DESC  
LIMIT 100000

To summarize this information, the following table details the exact compute units used for both the simple and more complex queries.

One thing to note from this summary is that the compute units for data refreshing in both queries is comparable to the compute units required for analytics. This occurs because there is no incremental refresh implemented for either queries which results in a much higher amount of compute units used for data refreshing.