Could you clarify your questions a bit?
Please tell us how would you measure the database size of a PI System and where you saw the System Sizing Recommendations.
I think that the size of osisoft pi, can be checked in 2x2 dimension; number of tags vs number of days of history ;
even if number of days can be dependent of disk size.
It would be really hard to know how many days of history a PI Server has, and it does depend too, is it the same to have 1 tag with 100 values per second to have 100 tags with 1 value per second? Your question is really way to broad to be answered lightly.
Regarding the 5/10 million point comment, do you remember where you saw that? or could you clarify the question a bit more?
I think this is the type of questions that's really hard to answer because of the number of factors to consider (hardware you are running on, network latency between the various nodes involved, types of tags, scanning frequency, efficiency of the data sources, number of users/applications retrieving data, etc.). Essentially, one needs to take the answer with a (huge) grain of salt.
I guess the question really is: why do you need to know that?
- Is it just plain curiosity? i.e. you simply want to know what the biggest system out there is, out of curiosity...
- You need to calculate the required hardware/network specs for a big system you actually envision?
If it's the latter (i.e. you have an actual implementation to perform), I think there are other, better resources than vCampus to handle that: your best bet is to contact our regular Technical Support such that this gets channeled to the people who can sort this out. If this is in the context of an Enterprise Agreement (EA), my suggestion would be to contact the appropriate Enterprise Project Manager (EPM) and involve OSIsoft's Center of Excellence (CoE).
If this may satisfy your curiosity (in case that is the reason you asked), the PI Server team successfully demonstrated a 20+ million PI Server at one of our past Users Conference. Again, this is to take with a grain of salt... it all depends on so many factors, related to your environment. That covers the "number of PI Points" dimension. As far as the "length of the history" dimension, I know of a couple customers with 20+ years of history in their systems - and this does by no means represent any sort of limit.
Filipe CamposI'm not quite sure I understand what you mean by "delete the 5/10 million tag"... are you referring to an article or a document you found on our website? If so, which one is this?
Hardware System Sizing Recommendations for 2010 delete the 5/10 million tag ! Why ?
I know of a couple customers with 20+ years of history in their systems - and this does by no means represent any sort of limit.
Longest query I have run against PI is approximately 15 years (longer than I have worked with PI )...apparently some of the data came from something called PI on VMS
The 20+ million PI Server that we showed at the Monterey UC a couple years ago was a futuristic prototype meant to inspire, not a production system. In retrospect, it was probably a mistake to demo such a system, as it continues to be used as a reference point out of context in numerous circumstances.
The PI Server is just one aspect -- granted, a very key one -- of PI System scalability but this is by no means the only thing that needs to be considered. What about the interfaces, middle layers, and clients?
OSIsoft's AMI and data center initiatives are definitely pushing the envelope in terms of scalability, and we are already making internal changes to the PI Server (and also the AF Server and other places) to help accomodate larger tag / element counts.
A more practical upper bound for tags is probably a couple million points. To put that in perspective, the vast majority of our Managed PI sites from enterprise customers -- which is a reasonable proxy for our customer base at large -- have less than 25-50K points.
In terms of duration of archive history, there really are not any designed architectural limits, and you can split up archive history into multiple archive files to meet basic management / performance criteria. Of course, the more dense a given tag, and the greater the time range for archive queries, the longer it will take to read back / process all the data. Thus, the default data access timeouts for clients and cache limits may be insufficient for really big systems.
Scalability is an ongoing effort, and it is not isolated to the PI Server. OSIsoft is committed to meeting the scalability needs of our customers.
thank you all for the feedback;
Omar thank you by the email, i think you touch the problem.
that 10/5 million tags i see in Hardware_Recommendations_June2008xls.xls
in new file of 2010 Hardware System Sizing Recommendations - Feb 2010.xls , that maximum size disapear.
the files are in download area.
The Hardware and PI System Sizing Recommendations Spreadsheet is being phased out. A new online Hardware Sizing Tool has replaced it. At this time the tool only gives sizing recommendations for PI Data Archive and PI AF Server.