Pre-Query Statistic Feasibility

## SPIKE Description

As part of the query experience project, a common theme discussed was offering users the ability to see the shape of their data by some sort of schema browsing capability.

As the team started to envision this, there were some interesting ideas floated about what type of information we could give the user (pre-query) about their data. This included things like:

**For Buckets**

- First (Oldest) Point

- Newest (Most Recent Point)

- First Point Time Stamp

- Newest Point Time Stamp

- Number of Points

- Cardinality

- List of Measurements in the bucket

- Number of Tags in each measurement

- Number of Fields in each measurement

**For Measurements**

- List of Tags in that Measurement

- List of Fields in that Measurement

- Preview of X points with that Measurement

**For Tag List**

- Number of Points with that Tag

- Preview of X points with that Tag

**For Field List**

- Number of Points with that Field

- Data Type of the field

- Preview of X points with that Field

See attached sketch from Balaji for sample implementation (slides 4,5,6)

This spike is for determining the feasibility of gathering this information in a user/schema browsing type operation.

For each of the items listed, we want to know things like:

1) Would this information be feasible to be gathered within a short time window (3 seconds)?

2) Would this information be feasible to be gathered within a long time window (60 seconds)?

3) Assuming that some of the actions will greatly vary based on the number of points, tags, fields, etc. - which items are only feasible with smaller amounts of data?

4) If many of the functions are not feasible to pull quickly while the user is navigating the schema information, would a "gather schema" information function that might take a minute or two or less to pre-gather this information be feasible?

5) For "lists" that would be returned (list of measurements, tags, fields), if it would take too long because of the size, would it be feasible to bring in "chunks" and allow the user to get more? Or would obtaining this information really require a full query to complete before we could show it?

6) Could we do these metaquery information gathering without it costing hidden usage fees to the customer?

7) Would it be feasible to predict whether the data for a given bucket would be too overwheming or not to do some of the functions (like list all fields, etc.) and then not give that option to just those buckets?

8) If not feasible, are there enhancements that could be made to underlying APIs that *could* make it feasible?

## Spike Deliverables

- General Answers to the questions posed in this spike

- General Report on the feasibility of this type of data gathering

#