Create Overview #2591
Open
Create Overview #2591
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Allow 10 minutes from last push for the staging site to build. If the link doesn't work, try using incognito mode instead. For internal reviewers, check web-documentation repo actions for staging build status. Link to build for this PR: http://docs-dev.timescale.com/docs-dev-overview-lana |
Signed-off-by: Lana Brindley <[email protected]>
|
Site build failed. For Timescale internal contributors, check the logs in the web-documentation repo to see the failure reason. For help, contact the docs team. |
|
Site build failed. For Timescale internal contributors, check the logs in the web-documentation repo to see the failure reason. For help, contact the docs team. |
mkindahl
reviewed
Sep 13, 2023
| Continuous aggregates require a `time_bucket` on the time partitioning column of | ||
| the hypertable. | ||
|
|
||
| By default, views are automatically refreshed. You can adjust this by setting |
There was a problem hiding this comment.
Suggested change
| By default, views are automatically refreshed. You can adjust this by setting | |
| By default, views are automatically refreshed when they are created. You can adjust this by using |
| the [WITH NO DATA](#using-the-with-no-data-option) option. Additionally, the | ||
| view can not be a [security barrier view][postgres-security-barrier]. | ||
|
|
||
| Continuous aggregates use hypertables in the background, which means that they |
There was a problem hiding this comment.
Suggested change
| Continuous aggregates use hypertables in the background, which means that they | |
| Continuous aggregates use hypertables internally, which means that they |
Comment on lines
+1
to
+7
| Research has shown that when data is newly ingested, the queries are more likely | ||
| to be shallow in time, and wide in columns. Generally, they are debugging | ||
| queries, or queries that cover the whole system, rather than specific, analytic | ||
| queries. An example of the kind of query more likely for new data is "show the | ||
| current CPU usage, disk usage, energy consumption, and I/O for a particular | ||
| server". When this is the case, the uncompressed data has better query | ||
| performance, so the native PostgreSQL row-based format is the best option. |
There was a problem hiding this comment.
Hmm... not sure if "debugging queries" is the best categorization of this.
Suggested change
| Research has shown that when data is newly ingested, the queries are more likely | |
| to be shallow in time, and wide in columns. Generally, they are debugging | |
| queries, or queries that cover the whole system, rather than specific, analytic | |
| queries. An example of the kind of query more likely for new data is "show the | |
| current CPU usage, disk usage, energy consumption, and I/O for a particular | |
| server". When this is the case, the uncompressed data has better query | |
| performance, so the native PostgreSQL row-based format is the best option. | |
| For newly ingested data, the queries are usually | |
| shallow in time, and wide in columns. At this stage, the queries delve into details of the system. An example of the kind of query more likely for new data is "show the | |
| current CPU usage, disk usage, energy consumption, and I/O for a particular | |
| server". When this is the case, the uncompressed data has better query | |
| performance, so the native PostgreSQL row-based format is the best option. |
Comment on lines
+15
to
+17
| The result is transparent queries across standard PostgreSQL storage and S3 | ||
| storage, so your queries fetch the same data as before, with minimal added | ||
| latency. |
There was a problem hiding this comment.
Work focus on the utility, not on performance.
Suggested change
| The result is transparent queries across standard PostgreSQL storage and S3 | |
| storage, so your queries fetch the same data as before, with minimal added | |
| latency. | |
| As a result, you can write queries seamlessly reading and involving both tiered and untiered data.``` |
Comment on lines
+1
to
+2
| When you create and use a hypertable, it automatically partitions data by time, | ||
| and optionally by space. |
There was a problem hiding this comment.
Suggested change
| When you create and use a hypertable, it automatically partitions data by time, | |
| and optionally by space. | |
| Hypertables are used to automatically partition data: traditionally using time, but hypertables can also be used to partition data in other dimensions.``` |
Comment on lines
+4
to
+7
| Each hypertable is made up of child tables called chunks. Each chunk is assigned | ||
| a range of time, and only contains data from that range. If the hypertable is | ||
| also partitioned by space, each chunk is also assigned a subset of the space | ||
| values. |
There was a problem hiding this comment.
You can partition using multiple time dimensions and multiple space dimensions, so suggest to elaborate a little on this.
Suggested change
| Each hypertable is made up of child tables called chunks. Each chunk is assigned | |
| a range of time, and only contains data from that range. If the hypertable is | |
| also partitioned by space, each chunk is also assigned a subset of the space | |
| values. | |
| Each hypertable is made up of child tables called chunks. Each chunk is assigned | |
| a range of time, and only contains data from that range. If the hypertable is | |
| also partitioned by other dimensions, each chunk is also assigned a subset of the values in that dimension. |
Comment on lines
+1
to
+3
| Timescale is the database platform built for developers. It's engineered to | ||
| deliver speed and scale for your resource-intensive workloads—like those using | ||
| time series, event, and analytics data. |
There was a problem hiding this comment.
I think that we also want to push more on the ease of use. Hypertables are performing well, but they are also hassle-free because they can handle automatic partititioning and manage data in different stages of the life-cycle.
Suggested change
| Timescale is the database platform built for developers. It's engineered to | |
| deliver speed and scale for your resource-intensive workloads—like those using | |
| time series, event, and analytics data. | |
| Timescale is the database platform built for developers. It's engineered to | |
| without hassle deliver speed and scale for your resource-intensive workloads—like those using | |
| time series, event, and analytics data. |
Comment on lines
+5
to
+7
| * _PostgreSQL++_ - Timescale is the PostgreSQL you know and love, giving you | ||
| access to the entire PostgreSQL ecosystem, but Timescale has additional | ||
| features like hypertables, compression and continuous aggregates. |
There was a problem hiding this comment.
I wonder if we want to add a bullet around something like "Designed for Data Intensive Applications".
Comment on lines
+13
to
+16
| Time-series data grows very quickly, and as the data grows, analyzing it gets | ||
| slower and uses more resources. Timescale solves the slow-down with continuous | ||
| aggregates. Based on PostgreSQL materialized views, continuous aggregates are | ||
| incrementally and continuously updated, to make them lightning fast. |
There was a problem hiding this comment.
Suggested change
| Time-series data grows very quickly, and as the data grows, analyzing it gets | |
| slower and uses more resources. Timescale solves the slow-down with continuous | |
| aggregates. Based on PostgreSQL materialized views, continuous aggregates are | |
| incrementally and continuously updated, to make them lightning fast. | |
| For data-intensive applications the amount of of data that needs to be managed grows very quickly, and as the data grows, analyzing it gets | |
| slower and uses more resources. Timescale solves the slow-down with continuous | |
| aggregates. Based on PostgreSQL materialized views, continuous aggregates are | |
| incrementally and continuously updated, to make them lightning fast. |
Comment on lines
+37
to
+38
| When you are working with time-series and event data, storage costs can easily | ||
| spiral out of control. With Timescale, you never have to worry about hidden |
There was a problem hiding this comment.
Maybe talk more about "data-intensive applications that collect large amounts of time-series and events data".
|
Reopening this PR as it seems to have been closed by accident |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
[Short summary of why you created this PR]
Links
Writing help
For information about style and word usage, see the style guide
Review checklists
Reviewers: use this section to ensure you have checked everything before approving this PR:
Subject matter expert (SME) review checklist
Documentation team review checklist
and have they been implemented?