Hey Jerry,
Your question is certainly apropriate and good that you are considering optimizing your storage and query times. That said, VTScada's database is not like SQL.
First, VTScada typically uses way less disk space than a similar app using SQL. Also, if you want to reduce storage size in VTScada, typically, it is best spend your time looking at the deadbands. You likely don't need data saved at the precision of the instrument and changing this slightly can create an enormous savings in both the historian filesize as well as the RPC traffic between servers.
If you have a single server with a smaller disk size, you can also consider created a filtered tag list for that server which will cause that application on that server to only load a filtered section of the tags. Typically this would be only those in the area apropriate for that localized server (ie: a local VTScada instance in a single liftstation which is part of a much larger system. Note that Subordinate tags are also a good method in this example).
Regarding querying data, VTScada's query times are typically a magnitude of order faster than a SQL database so this is not a concern with most customers.
TLDR:
We typically recommend you use an SSD, pay attention to your deadbands, and enjoy a high performance historian, using less disk space than you are expecting, and containing many years worth of data.
Hey Jerry,
Your question is certainly apropriate and good that you are considering optimizing your storage and query times. That said, VTScada's database is not like SQL.
First, VTScada typically uses way less disk space than a similar app using SQL. Also, if you want to reduce storage size in VTScada, typically, it is best spend your time looking at the deadbands. You likely don't need data saved at the precision of the instrument and changing this slightly can create an enormous savings in both the historian filesize as well as the RPC traffic between servers.
If you have a single server with a smaller disk size, you can also consider created a filtered tag list for that server which will cause that application on that server to only load a filtered section of the tags. Typically this would be only those in the area apropriate for that localized server (ie: a local VTScada instance in a single liftstation which is part of a much larger system. Note that Subordinate tags are also a good method in this example).
Regarding querying data, VTScada's query times are typically a magnitude of order faster than a SQL database so this is not a concern with most customers.
**TLDR:
We typically recommend you use an SSD, pay attention to your deadbands, and enjoy a high performance historian, using less disk space than you are expecting, and containing many years worth of data.**
Trihedral Engineering Ltd.
