PI Notifications create several tags per notification. Actually 7 Tags get created per Notification.
So if you indeed want to have 10,000 Notifications - you would end up with 70,000 additional tags. Instead of having 10,000 Notifications, you might want to group the conditions to achieve less Notifications.
I'll check with the developers to see what OSIsoft's suggestion is.
Issue I seem to have now is when a client requires some kind of Notification/Alerting for either PI or other (via AF) data then there is quite an overhead they need to be aware of with Notifications, especially with some licence restrictions. Rationalising Notifications is always one option but you will always have 7:1 ratio of PI tags to Notifications.
Are there plans to move Notifications to SQL Server instead of PI tags?
Whilst we are still waiting to hear back from the Notifications team about their "Best practices" and the likelyhood of SQL-based notifications, I can comment on some of your questions.
When I first heard that notifications uses 7 points per notification, I was quite sceptical. I have since "seen the light". These 7 tags are used to store the history of the notification. If something is important enough to alert on, it is just as vital to store the history of this alert. Being able to track the history of a faulting pump or a process constantly in excursion is just as benefitial as sending Bob the Instument tech out to the plant every day to hit it with a big wrench. Furthermore, being able to track when Bob is being slack and it needs to be escalated to the site manager will be vital when Bob demands his next Raise (sorry Bob!).
These tags should not be collecting a lot of data, nor should the data rates be high (barely measureable). I don't think you will need to move them off to another server but, with any advice we give, it should be considered on a case-by-case basis!
You mentioned rationalising notifications. I believe that this is more than an option, but actually a vital part of the notification creation process. Unlike other notification and alerting tools (such as RtAlerts), there is often no need to create one notification per "condition". For example, If I have one tank and I want to notify the engineer if the level is too high, input or output pumps break or it's maintenance schedule expires, I should only really need to create one notification, not 4 or 5. Rolling up notifications to a root element in your hierachy and using various conditions is much more appropriate.
An example I like to use is monitoring a Windows server (using IT monitor, AF and notifications). Whilst you could create a notification for CPU Usage, Memory USage, HDD Capacity, one for each vital service on the machine, it is excessive. one notification for the entire server (or even group of servers) is much more appropriate. Should you be alerting the engineer 15 times for the one issue? Would you ever send out 10 different engineers to fix the one server (it would be a pretty cramped server room) or just the one? The notification content will contain the trigger, so the engineer will know what to look into.
We'll let you know when we get word back from the Notifications Team (they may even post directly)
Sam made a very good point with his IT Monitor example - rationalizing the notifications is vital and will not restrict the fidelity of the result.
For each notification, we need to create seven tags to store the history of the notification. So 10K notifications will require 70K tags on the PI server acting as the historian of the notification. The data rate for these history tags are not going to high unless that expect the notifications have high incidents rate. Whether you want to create separate PI server to host the notification history tags really depends on your resources.
On the other hand the amount of notifications raises some concerns from our developers. They did some preliminary benchmarks on the upcoming release 1.1 that did show an evaluation performance of 1000-5000 notifications per second. So for a suggestion on architecture we would need more information: How complicate is the condition, do you want to run the notification on the PI Server, is AF on the same machine, what input data rate do you expect, etc.? Anyhow, the general suggestion from the developer is to wait for v1.1 of PI Notifications before deploying 10k notifications (In general we expect a performance improvement for multiple trigger tags and natural scheduling close to ten times compared to v1.0).
I assume you are referring to SQL as you consider the amount of tags crucial. With the traditional view of the PI System as a data historian with a license based on tags you always get the question - does this additional information justify spending some more money for some more tags. Fortunately we in vCampus are not dealing with that kind of stuff, we look for the best technical solution; and allow me to say that for anything that could create events reasonable fast and often - like the notifications - I do not see any better place to store that than PI
btw, handling large amounts of events that need a post-processing - you might want to take a look at Microsoft's CEP: http://vcampus.osisoft.com/blogs/msosi/archive/2009/05/20/complex-event-processing-cep.aspx