> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cognite.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Best practices and troubleshooting

> Get the most out of your OData client with these best practices and troubleshooting tips for optimal performance.

<a id="performance" />

## Performance

The performance of the <span translate="no">OData</span> services depends on the type of data you access. For example, reading 1M data points takes about 2:30 to 3:00 minutes (6K data points per second). Each full request takes an average of 120 ms, and the <span translate="no">OData</span> client might add additional overhead for processing and data handling.

Follow these general best practices to make sure you get the best and most reliable performance:

* Don't use `OR` expressions or expanding tables.
* Use multiple queries when possible.
* Use incremental refresh.
* Partition data sets if possible.
* Keep only the data you need. Remove unnecessary columns and data.
* Keep historical data in a separate report if you don't need it daily. Refresh the historical data report when you need it.

<a id="write-performant-queries" />

## Write performant queries​

The <span translate="no">OData</span> services accept multiple concurrent requests, and processes the requests in parallel. <span translate="no">OData</span> clients can also dispatch multiple queries concurrently when possible.

It's better to compose and use **multiple queries** instead of a single complex query with, for example, `OR` expressions or expands. A single complex query must be iterated sequentially with the added round-trip latency for each request.

Download the data using multiple queries and join the resulting tables in your <span translate="no">OData</span> client to work with the tables as if they were a single table.

<a id="use-incremental-refresh" />

## Use incremental refresh​

Incremental refresh enables large datasets with the following benefits:

* Only changed data needs to be refreshed.
* You don't have to maintain long-running connections to source systems.
* Less data to refresh reduces the overall consumption of memory and other resources.

Each <span translate="no">OData</span> client might have different incremental refresh features. For <span translate="no">Microsoft Power BI</span>, see [Incremental refresh for semantic models in Power BI](https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview).

<a id="partition-large-data-sets" />

## Partition large data sets​

If you need to download large data sets, partition them and have a separate query to read each partition. Some <span translate="no">OData</span> clients, like <span translate="no">Microsoft Power BI</span>, can process multiple queries concurrently. Partitioning the data set can significantly improve performance.

For example, if you read data points from the last two years, try splitting the query into two queries, each reading one year of data. Then, merge (concatenate) the tables in <span translate="no">Power BI</span>.

<a id="property-naming-in-metadata-and-cdf-raw" />

## Property naming in metadata and <span translate="no">CDF RAW​</span>

Property keys for metadata and the <span translate="no">CDF</span> staging area (<span translate="no">RAW</span>) must be valid identifiers and can only contain letters, numbers, or underscores. The <span translate="no">OData</span> services rewrite other characters to an underscore. For the best and most predictable results, make sure that ingested data follow this naming convention for property keys: `^[a-zA-Z][_a-za-z0-9]\*[a-zA-Z0-9]\$`.

<a id="troubleshooting" />

## Troubleshooting​

Find information to help you troubleshoot issues using <span translate="no">CDF</span> as a data source for <span translate="no">OData</span> clients.

<a id="queries-take-too-long" />

### Queries take too long​

A <span translate="no">CDF</span> project can contain hundreds of millions of rows of data, and loading them all into an <span translate="no">OData</span> client isn't feasible. If your query takes hours, you're likely trying to load too much data.

See [Filter items in data models](/cdf/dashboards/references/odata/dm_odata#filter-items-in-data-models) and [Filtering asset-centric resource types](/cdf/dashboards/references/odata/classic_odata#filtering-asset-centric-resource-types) to learn about the filtering capabilities supported by the <span translate="no">OData</span> services.

<a id="not-getting-all-results" />

### Not getting all results​

If you get fewer results than expected, you may be using a filter function that <span translate="no">CDF</span> doesn't support, for example, `startswith` on the **Name** column for **TimeSeries**.

See [Filter items in data models](/cdf/dashboards/references/odata/dm_odata#filter-items-in-data-models) and [Filtering asset-centric resource types](/cdf/dashboards/references/odata/classic_odata#filtering-asset-centric-resource-types) to learn about the filtering capabilities supported by the <span translate="no">OData</span> services.

<a id="unable-to-retrieve-minimal-values-from-cdf-raw" />

### Unable to retrieve minimal values from <span translate="no">CDF RAW​</span>

If you're using data from the <span translate="no">CDF</span> staging area, <span translate="no">CDF RAW</span>, in an <span translate="no">OData</span> client, you can experience issues retrieving small numbers in exponential notation.

<span translate="no">CDF RAW</span> doesn't have a schema, but the <span translate="no">OData</span> libraries in some <span translate="no">OData</span> clients, like <span translate="no">Power BI</span>, try to select the correct format for the data. Currently, <span translate="no">Power BI</span> chooses the wrong decoder for small numbers in exponential notation, and you may get an error similar to this:

```
DataSource,Error: OData: Cannot convert the literal '2.89999206870561 to the expected type 'Edm.Decimal',
```

To resolve the issue, ingest the values into <span translate="no">CDF RAW</span> as **strings** instead of **numbers**, and convert the strings back to numbers in <span translate="no">Power BI</span>, for example, using the `Decimal.From` <span translate="no">Power Query</span> M-function. You won't lose precision, and because most JSON decoders accept strings for numbers, clients that expect numbers will still work.
