QuestDB official documentation

Ignition
1

Is there any official documentation on QuestDB such as setting up a connection when installed on localhost. I realize it’s time series and non-relational. Does it have a web interface or did they leave it out since it is embedded? It is unclear to me what username, password, and drivers to use but I have found that postgress works on other forum topics.

2

Crickets. Installed ignition-8.3.0-rc1 and testing the Core Historian which looks like Quest DB under the hood. Still not much documentation on purging stale tags or any kind of database management interface.

3

There isn't. There's a comment on one of the topics about enabling the PostgreSQL-like external port, but everything about this is an internal implementation detail. It is not intended to be managed externally. Ergo, not documented.

1 Like
4

Thanks for the response. Is there any mechanism to delete stale/obsolete tags? When history gets enabled/disabled on a particular tag will it re-combine with the old history or is it lost? I’m really familiar with the table structure when using sql historian. I’m just trying to relate it to that, like the ‘retired’ field for a particular tag ID. I don’t see how anybody could decide to use this without this basic information.

5

I don't know all the details, but I think as part of 8.3 in general, I think they were making improvements across all historian providers to handle tag renaming, etc so that history tables aren't required to be manually modified for things like this anymore.

1 Like
6

I'm not quite sure where this messaging got lost, but the purpose of the new "core" historian is precisely to be a "black box" where you don't have to think about it. It's not "another RDBMS to manage", its "a turn key embedded historian solution", precisely for the people who don't want to think about it.

Among the reasons not to think about it - just because it's questDB today doesn't mean it will be in the future. By choosing to let us control the level of abstraction, you're also choosing to allow us to take over the pain of migrating to some other historian provider if we ever choose to in the future, or make any other optimizations. The second you start intervening in the internal table structure yourself, all bets are off.

3 Likes
7

Yeah but we had a case where somebody was accidentally storing tags with all null values, for a long time because nobody noticed. It has storage implications. There was also a glitch because they had the settings to store on change, so the historian did not respect the deadband and was storing them as fast as possible, but that’s another subject. I had to delete millions of tags from each monthly file.

8

QuestDB, the product, does not support deleting values. There is no way to purge stale tags.

9

Like the idea of having that level of abstraction, only question would be is there then a standard way to “query“ historical records outside of the platform?(without the use of the Web Dev module).

10

Same question as leonard.smit for me now. It seems like the most common answer is to install historian of your choice and use splitter which is unfortunate.

11

Yes, with the WebDev module.

No, use the WebDev module. (Or write your own 3rd party module with the SDK.)

12

I believe [1] that we're planning to add some automatic routes to the historian module to expose the data as a fairly standard HTTP service (so you wouldn't need Webdev unless you needed something more customizable).

But:

  1. I have no idea if that's actually still the plan (not my area of the product)
  2. I have no idea when that would happen if it is still happening.

  1. don't take this as a guarantee of anything ↩︎

1 Like
13

Thanks for the feedback, is there currently any SDK example to query the new historian module from the SDK? Any documentation for 8.3?