# Starting out with cratedb

**URL:** <https://community.cratedb.com/t/starting-out-with-cratedb/492>\
**Category:** CrateDB\
**Created:** [September 17, 2020, 9:22pm UTC](https://community.cratedb.com/t/starting-out-with-cratedb/492 "2020-09-17T21:22:47Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![proddata](https://sea2.discourse-cdn.com/flex020/user_avatar/community.cratedb.com/proddata/32/1379_2.png) [@proddata](https://community.cratedb.com/u/proddata)\
**Post date:** [May 31, 2022, 4:57pm UTC](https://community.cratedb.com/t/starting-out-with-cratedb/492/4 "2022-05-31T16:57:38Z")

</div>

I am afraid, there probably is no simple answer to that question, as it depends a bit on how you ingest/collect the data and how you want to query it.

We by now at least have some guide for time-series data, which you can find here

> [@Sharding and partitioning guide for time-series data](https://community.cratedb.com/t/sharding-and-partitioning-guide-for-time-series-data/737):
>
> The goal of this guide is to support you with building a sharding and partitioning strategy for your time series data. Let’s start with your time series data which you want to store in a table in CrateDB. You need to consider how to partition your data, how many shards to configure, and how many replicas to use. Partitioning Typically you want to partition your time series data based on a time axis. You can achieve this in CrateDB by using the [date\_trunc](https://crate.io/docs/crate/reference/en/latest/general/builtins/scalar-functions.html#date-trunc-interval-timezone-timestamp) function on a timestamp. An example t…

* * *

For Grafana something like

```sql
CREATE TABLE table_1 (
  ts TIMESTAMP,
  id TEXT,
  val DOUBLE
);

```

```sql
INSERT INTO table_1 (ts,id,val) VALUES (now(),'id1',1.0),(now(),'id2',2.0);

```

would also be fine if e.g. `id` would be selected as metric in Grafana.

That would be 1440 \* 1000 \* 365 = 525 Mio records / year

* * *

**Alternatives** :

As you mentioned, you could use individual columns for every sensor.  
This however would lead to 1000 indexes by default.

```sql
CREATE TABLE table_1 (
  ts TIMESTAMP,
  sensor01 DOUBLE
   ...
   sensor1000 DOUBLE 
);

```

* * *

if the sensor are always read in bulk you could use arrays.  
However this kinda implies, that you always read all the sensors at once.

```sql
CREATE TABLE table_1 (
  ts TIMESTAMP,
  sensors ARRAY(DOUBLE)
);

```

```sql
INSERT INTO table_1 (ts,sensors) VALUES (now(),[1.0,2.0,3.1,...,...])

```

and

```sql
SELECT ts, sensors[1], sensors[123] FROM table_1

```

* * *

another altnernative would be using `OBJECT`s

with dynamic objects, this would be very similar to individual columns

```sql
CREATE TABLE table_1 (
  ts TIMESTAMP,
  sensors OBJECT(DYNAMIC)
);

```

with ignored objects, you probably save some space, but performance is worse for large aggregations

```sql
CREATE TABLE table_1 (
  ts TIMESTAMP,
  sensors OBJECT(IGNORED)
);
```

---

_[View the full topic](https://community.cratedb.com/t/starting-out-with-cratedb/492)._
