It always depends. :) But here's one factor to consider:
From a R.A.S. perspective (descibed here: http://bit.ly/1fS01MU) a
one-topology approach
*may* negatively impact operational agility when those metrics can be
calculated independently
of one another. In such cases, merging them into one topology creates an
unnatural dependency
where, the moment code for any one metric needs to be updated (for
whatever reason),
calculation of remaining metrics must stop since the common topology
must be stopped,
modified, and tested.
So *S*erviceability characteristics of that topology will suffer, and
*A*vailability numbers
for metrics that didn't require modification will unnecessarily suffer, too.
You may also want to consider the ability/inability to tweak
per-topology run-time
properties (e.g. memory allocation, schedulers, etc.).
Perhaps a few 'bundled' topologies where it makes sense, versus
many-to-one or
many-to-many approach.
Besides R.A.S. there are other reasons pro and con.
On 03/27/2014 01:47 PM, Software Dev wrote:
How are many of you typically using storm? Use cases usually work best ;)
Say you have one source for a stream of user activity (page views,
product searches, purchases, etc). Now lets say you wanted to
calculate some running metrics for each of these activities. Is it
best to have one major topology where you would send each metric type
to their respective bolts or would you create many topologies, one for
each activity?
Thanks
