Hi,
I'd really like to understand with having low Ignition History, why people like to use Canary with Ignition.
I mean for normal applications with less than 50K tag changes per second.
Hi,
I'd really like to understand with having low Ignition History, why people like to use Canary with Ignition.
I mean for normal applications with less than 50K tag changes per second.
I haven't used Canary, although we've started adding it to some quotes where customers are asking for a more robust historian, or have special requirements like immutable data storage.
We have a lot of customers who are used to OSI Pi or need more features than what Ignition's historian provides, either due to dashboards at a corporate level, Excel add-ins, or regulatory requirements where the data has to be encrypted/immutable.
Was researching a canary error and saw this... felt the overwhelming need to comment...
As someone who works on servers that use both... and even used Canary labs as an operator for years... I really dislike what Canary Labs has become...
Their pricing is absolutely outrageous for the service you get. I have two critical servers down right now, and their top engineers are telling me the only way to proceed is to purchase a new support license, quarantine, and install the latest version of their software on to the server (lengthy process with air gapped servers), and I still to date have not been provided with an explanation as to root cause. The downtime is awful & there is nothing I can do to fix it except abide by their demands or switch to open source (which I'm doing now for all our servers).
As far as the idea that Canary is any more robust than a free & open source solution like MariaDB, take a guess which ones I spend more time trying to repair... That's why I found this thread...
The beauty in open source is that you have the power to solve your own problems (or cause them)... Oh yeah, it's also totally free and the whole community is ripe with support.
For immutability, you might be able to get away with just configuring read only access to your server, & or lock down your historian HMI interface through the project security zones.
At rest encryption is also be supported for my girl Maria, but we don't have a compliance standard that requires it yet so I'm still learning about it's use:
Take it from someone who spends a lot of time working with both... Choose a solution where you are allowed to fix your own application, I have yet to receive a product request I can't build in ignition for this data, and if you really want a truly isolated tool for your data totally independent of the gateway check out Grafana.
I think/hope the new PowerHistorian coming out with 8.3 checks a lot of the boxes that Canary did for those not needing anything as advanced as Canary. I also really want to compare the new PowerHistorian storage size to TimescaleDB running on PostgreSQL as I'm seeing significantly smaller sizes of blocks once they're compressed in Timescale.
@michael.flagler I'd be very curious to see your results, would you please share them with us all here when you are able?
To further clarify, I was a big fan of Canary, used it for years operating, just not a big fan of the price tag & I'm still looking at a support ticket with them that has no end in sight months later. Just isn't worth thousands of dollars & my customer isn't happy about it... MariaDB has been a good substitute for the past few weeks, would it be worth switching to Postgre for the smaller block sizes?
Been reading a lot about it online but I'd be curious to get the community's opinion about the benefits of a switch.
I was using MariaDB as my go to for Historian and on this latest project I tried using the RocksDB extension to try to improve compression. In house it seemed to work fine, but once I got it on a live system with live data after a few weeks (still in commissionig phase) the database kept locking and spiking CPU making it unusable. So I did a quick install test of Timescale on top of Postgres since I had heard good things about it and so far no issues and it has been fast. You're able to pull stats and the compressed data on average has been about 8% of the size of the uncompressed data. I would need to compare storage space with MariaDB and even native Postgres to see how they compare since I can't assume Timescale uncompressed is the same storage size.