104 lines
4.2 KiB
Markdown
104 lines
4.2 KiB
Markdown
|
|
An {{< product-name >}} database is a named location where time series data is
|
|
stored. Each database can contain multiple tables.
|
|
|
|
> [!Note]
|
|
> **If coming from InfluxDB v1**, the concepts of databases and retention policies
|
|
> have been combined into a single concept--database. Retention policies are no
|
|
> longer part of the InfluxDB data model.
|
|
> However, {{% product-name %}} does
|
|
> support InfluxQL, which requires databases and retention policies.
|
|
> See [InfluxQL DBRP naming convention](/influxdb3/version/admin/databases/create/#influxql-dbrp-naming-convention).
|
|
>
|
|
> **If coming from InfluxDB v2, InfluxDB Cloud (TSM), or InfluxDB Cloud Serverless**,
|
|
> _database_ and _bucket_ are synonymous.
|
|
|
|
<!--
|
|
## Retention periods
|
|
|
|
A database **retention period** is the maximum age of data stored in the database.
|
|
The age of data is determined by the timestamp associated with each point.
|
|
When a point's timestamp is beyond the retention period (relative to now), the
|
|
point is marked for deletion and is removed from the database the next time the
|
|
retention enforcement service runs.
|
|
|
|
The _minimum_ retention period for an InfluxDB database is 1 hour.
|
|
The _maximum_ retention period is infinite meaning data does not expire and will
|
|
never be removed by the retention enforcement service.
|
|
-->
|
|
|
|
## Database, table, and column limits
|
|
|
|
{{< product-name >}} places the following limits on databases, tables, and columns:
|
|
|
|
### Database limit
|
|
|
|
**Maximum number of databases**: {{% influxdb3/limit "database" %}}
|
|
|
|
### Table limit
|
|
|
|
**Maximum number of tables across all databases**: {{% influxdb3/limit "table" %}}
|
|
|
|
{{< product-name >}} limits the number of tables you can have across _all_
|
|
databases to {{% influxdb3/limit "table" %}}. There is no specific limit on how
|
|
many tables you can have in an individual database, as long as the total across
|
|
all databases is below the limit.
|
|
|
|
Having more tables affects your {{% product-name %}} installation in the
|
|
following ways:
|
|
|
|
{{< expand-wrapper >}}
|
|
{{% expand "**May improve query performance** <em style='opacity:.5;font-weight:normal;'>View more info</em>" %}}
|
|
|
|
Schemas with many tables that contain
|
|
[focused sets of tags and fields](/influxdb3/version/write-data/best-practices/schema-design/#design-for-performance)
|
|
can make it easier for the query engine to identify what Parquet files contain
|
|
the queried data, resulting in better query performance.
|
|
|
|
{{% /expand %}}
|
|
{{% expand "**More PUTs into object storage** <em style='opacity:.5;font-weight:normal;'>View more info</em>" %}}
|
|
|
|
When using cloud-based object storage as your data backend, the more tables you
|
|
have, the more `PUT` requests there are into your object store as InfluxDB
|
|
persists data to Parquet files. Each `PUT` request incurs a monetary cost and
|
|
increases the operating cost of {{< product-name >}}.
|
|
|
|
{{% /expand %}}
|
|
{{% expand "**More work for the compactor** _(Enterprise only)_ <em style='opacity:.5;font-weight:normal;'>View more info</em>" %}}
|
|
|
|
To optimize storage over time, InfluxDB 3 Enterprise has a compactor that
|
|
routinely compacts Parquet files.
|
|
With more tables and Parquet files to compact, the compactor may need to be scaled
|
|
to keep up with demand, adding to the operating cost of InfluxDB 3 Enterprise.
|
|
|
|
{{% /expand %}}
|
|
{{< /expand-wrapper >}}
|
|
|
|
### Column limit
|
|
|
|
**Maximum number of columns per table**: {{% influxdb3/limit "column" %}}
|
|
|
|
Each row must include a time column, with the remaining columns representing
|
|
tags and fields.
|
|
As a result, a table can have one time column and up to {{% influxdb3/limit "column" -1 %}}
|
|
_combined_ field and tag columns.
|
|
If you attempt to write to a table and exceed the column limit, the write
|
|
request fails and InfluxDB returns an error.
|
|
|
|
Higher numbers of columns has the following side-effects:
|
|
|
|
{{< expand-wrapper >}}
|
|
{{% expand "May adversely affect system performance" %}}
|
|
|
|
InfluxData identified {{% influxdb3/limit "column" %}} columns as the safe limit
|
|
for maintaining system performance and stability.
|
|
Exceeding this threshold can result in
|
|
[wide schemas](/influxdb3/version/write-data/best-practices/schema-design/#avoid-wide-schemas),
|
|
which can negatively impact performance and resource use,
|
|
depending on your queries, the shape of your schema, and data types in the schema.
|
|
|
|
{{% /expand %}}
|
|
{{< /expand-wrapper >}}
|
|
|
|
{{< children hlevel="h2" readmore=true hr=true >}}
|