The Canary Historian is a NoSQL time series database. That simply means it is built to specifically store time series data and does not rely on an SQL database to do so.
Every tag you choose to store in the Canary Historian can contain the following data:
Imagine the amount of data that can be produced if you have 5,000 tags sending values every second. What if it was 50,000 tags, or even 500,000?
That’s exactly why Canary chooses not to use SQL, its just too much data for a relational database. The Canary Historian was specifically built and optimized for the writing and reading of this specialty time series data.
You can write more than 1.5 million updates per second to the Historian in a continuous 24 hours a day, 7 days a week operation. That’s a lot of data. Best of all, the database is structured so no matter how many years of data you store, or how many tags you are collecting, you will always maintain that 1.5 million write-per-second performance!
When needed, the Historian can maintain a continuous read speed of more than 2.5 million reads-per-second.
It may seem to some that SQL can achieve similar performance numbers, but at what cost? In fact, as an SQL database grows larger and larger, performance starts to drop. Administrators are forced to either reduce the size of the database or add servers. A lose-lose scenario.
Of course, more servers lead to higher operational costs and more management time. On the other hand, reducing the database size results in cutting storage length or massaging raw data into interpolated data. Neither of these options are ideal.
The most enticing reason a company might choose SQL is simply previous experience or knowing how to use it. Canary actually allows you to make SQL queries against our NoSQL database, eliminating any learning curve.
With Canary, you get all of the performance benefits of a NoSQL time series database and your clients can still make SQL queries. Without a doubt, it is the best solution for you.
Canary’s loss-less compression algorithm ensures your data is never compromised. Each day, all your historic records are validated, compressed, and closed for writing. Your original raw data format is forever stored securely and with the smallest storage footprint possible.
Canary achieves an industry leading compression ratio of better than 3:1, saving you more than 66% in storage.
When you deploy Historian, you organize your tags into DataSets. A DataSet is a collection of sensors, or tags, that you choose to group together. Since you license the Historian only by tag count, you can create as many DataSets as you need.
Within each DataSet, the Historian writes to a Historical DataBase file, or HDB file for short. The HDB contains all the tag names and records the timestamp for every value change as well as its quality score. You can also associate properties to each tag allowing you to store descriptions, engineering units, limits, and more. Typically, a new HDB file is created daily.
We know how important it is that your technology scales with your company. That's why both the the Historian’s technology and Canary’s business model are designed for scalability.
A single Canary Historian server can scale from only 100 tags to more than 2 million without requiring any additional software installations. Simply adjust the tag license to reflect the number of tags you need to store or even opt for an unlimited tag licensing option for ultimate peace-of-mind.
You can install Canary Historians at local sites as well as at corporate locations. Link multiple Historians to automatically move data from the site level to the corporate level in real time or on a schedule. You can also build in redundancy for high availability solutions. Every Data Collector can push data automatically to multiple Historian instances. Additionally, the Canary Mirror Service allows you to schedule DataSet snapshots on an hourly, daily, weekly, or monthly schedule allowing for data duplication to offsite Historians.