Timescaledb: [question] Is it compatible with sharding (citus extension)?

[archenroot]

As header says..., When I consider consider horizontal partitioning via citus extension ("sharding"), is this compatible with current timescaledb.

Otherwise good stuff guys!

[mfreed]

Timescale already does 2D partitioning/sharding ("vertically" by time, "horizontally" on an optional partitioning key). While we currently only use this for our single-node version, it will also be employed in the clustered version.

As such, our architecture (and also where we "insert" ourselves into the Postgres engine on the query/insert path) is not really compatible with Citus.

[archenroot]

@mfreed Thanks a lot for your answer. thing is that I design now solution for storing timeseries data, master data, configuration data, document data.

Instead of utilizing mutliple different system I intend to utilize PostgreSQL for all. I will be comparing in next few weeks your TimeScaleDB against MongoDB and maybe one choice from pure timeseries databases.

Now question is, if we pickup timescale who could provide support? I am not looking for kind of TimeScaleDB only support, but PostgreSQL in general but including TimeScaleDB, is some company going to provide enterprise support for this?

Thanks a lot again!

[mfreed]

Your setup makes a lot of sense. In fact, one of the advantages that we see with TimescaleDB is the ability to "simplify your stack": You don't need one RDBMs for master & config data, then a separate NoSQL DB for time-series. Not only are operations/management easier, but you don't need to push the pain/complexity of JOINs between metadata & time-series data into your applications.

We do provide some level of PostgreSQL support to go along with Timescale, but we’d need to better understand your needs first. Send us a quick email at support@ ?

[archenroot]

I will when time comes, really thank you for your answer.

2017-06-12 17:50 GMT+02:00 Mike Freedman [e-mail]:

Your setup makes a lot of sense. In fact, one of the advantages that we
see with TimescaleDB is the ability to "simplify your stack": You don't
need one RDBMs for master & config data, then a separate NoSQL DB for
time-series. Not only are operations/management easier, but you don't need
to push the pain/complexity of JOINs between metadata & time-series data
into your applications.

We do provide some level of PostgreSQL support to go along with Timescale,
but we’d need to better understand your needs first. Send us a quick email
at support@ ?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/timescale/timescaledb/issues/87#issuecomment-307831731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhyKKHlg27wF5GNwrPynlWJvjfRuHDrks5sDV5YgaJpZM4N0DdY
.

[elgalu]

Is this still the case? That TimescaleDB is mutually exclusive with Citus ?

[kgonia]

Hi @mfreed

Timescale is not compatible with Citus means that there is no way to handle both extensions together in one instance or they just don't fit to each other because of different approaches but it's possible to run them together?

Timescale + Citus would be great for spreading work across nodes/shards instead of using second dimension in timescale. If someone has few poor servers in can mean a lot!