Vector instead of Linked List
Whatever you do, don't use a doubly linked list for this. It has a lot of allocation and space overhead. The data is read and appended sequentially, there is no random access or random removal of items, so a vector-like data structure would be much more suitable to store data. But even that is overkill for the raw data, as you'll see below.
Data flows through Listeners, then disappears
To do linear pattern matching you don't have to store the data at all, and you'll only have to traverse it once. The idea is to have several matchers listening for their patterns as the data hums along. These store only the data needed to detect a pattern. Any items that cannot be part of a pattern anymore will be forgotten.
I'll describe one way of achieving that. I must warn you that the task you want to perform is not trivial to do efficiently. Judging from your proposal of using a linked list, it may take some time to wrap your head around the principles involved.
Continuously register Matchers listening to the data
Let's start by adding some entities to listen for your patterns in the data. Register a matcher factory for every combination you want to recognize. Typically each pattern would be in its own matcher class, parametrized by the resolution it is looking for.
Now start reading in the data, and feed each item to each matcher factory as you read it. Then have that factory instantiate/reuse a matcher for every place that could be the starting point of a pattern. For example, a matcher with a 7 day resolution could be instantiated each time the first data point for the new week comes in.
Matchers update internal state until they reject/accept a pattern
The ticker items are also fed to each active matcher. Each matcher should track its own internal matching state. For example, a matcher with a 7 day resolution may be accumulating ticker values to calculate the 7 day average. After each 7 days pass, it stores the average in the next position of an array, starting a new average accumulation for subsequent incoming ticker items. This continues until it has seen enough weeks to either reject the or confirm the presence of the pattern. To get some ideas on how to do this, look into 'Finite State Machines'.
Efficiency gains by eliminating duplicate calculations
Of course, if there are multiple matchers that need the data on a 7-day resolution it is not efficient to have each one calculate it on its own. You may build a hierarchy of matchers so intermediate patterns only have to be calculated once. Look into ring buffers for ideas on how to maintain rolling averages (or other aggregate functions)
Related: Parser Generators
So-called 'Parser Generators' do a similar thing automatically for formal grammars. The generated parsers employ a finite state machine to detect hundreds of patterns with about the same effort it would take to recognize just one, and in just one pass of the source data. I imagine such tools may also exist for continuous time-series data, or you could transform their ideas to apply them to your problem.
Hope this helps!
As @Cosmin-Prund said, there's no trivial or good pre-existing way to do this. My off-the-top-of-my-head suggestion would be to use a search engine like Lucene to tokenize and store the feed title. Use a stemming tokenizer, so that you can match words even if they're in different forms (such as wins vs winning). Then, when you process a new feed, you can search for the title as keywords, and see what you get back. You'll have to play with it some to find out how to tune the results to do what you want (try dropping the two most common tokens?), but it ought to be in the right ballpark of what you're looking for.
Best Answer
I am currently undertaking a similar (although more generic) project with my lab. As such, I want to warn you that this feature is a rabbit hole that can get very complicated very quickly. The first thing you need to do is think about your users and your goals and decide what's "good enough" or you will spend a lot of time developing a feature that, in the grand scheme of your site, might not be that important.
Basically you want some sort of information retrieval system. Think a mini-Google but not nearly as complex. First you need to decide how you will define similarity between articles (a metric). This will be handled in your preprocessing. Generally your actually comparison will be the same no matter what your metric (typically cossine similarity).
Defining a Metric
First, you need to decide what makes articles similar. There are two main approaches: looking for similarities in article topics or looking for similarities in article text. Topics will give better results but text is easier to implement.
Similarity by Topic
As mentioned several times, the easiest way to implement this system is allowing specify topics through author-specified tags. You would then search for articles with large overlaps in tags. If the tags are numerous and fine grained enough then this should give the best results.
The disadvantage is that you need to put a lot of thought into what the tags are to ensure you have coverage, clarity, and a lack of redundancy. If you take the Stack Exchange approach of letting users create their own tags then you can increase coverage but you need to moderate the tags to maintain the clarity/lack of redundancy. However, the greatest drawback of this approach is that you are trusting users to appropriately tag their posts. SE gets around this problem by letting other users edit and make suggestions for the tags.
You can get even better results if you tag topics at the sentence or paragraph level. It gives a better representation of which topics are more important in an article but it's more work. As the tagging scope gets smaller, the complexity of this task becomes exponentially more difficult.
What about an automated solution to take the work load off the users? Automatic Topic Identification is something that has been studied a lot. I'm not an expert at it but I suggest you read a few papers and decide if you feel these solutions are mature enough to give reliable results. My concern with this approach is that since you admit your domain is niche you might have a hard time finding an out-of-the-box solution and will need to implement the topic identifier yourself. At that point you might as well just do text-based similarity because it will be much easier and out-of-the-box solutions exist.
Similarity by Text
In this approach instead of comparing topic tags, you compare the actual words in the article. The advantage is that the preprocessing is much easier to accomplish. The disadvantage is that it assumes that similar text means a similar topic, which is not always the case.
Making it Work
In general, whichever metric you choose you will end up with a vector representing your articles. Maybe the vector is of word frequencies or of topic tags. You now need to compare the vectors for your articles to see which are similar.
The Stanford Natural Language Processing Course offered on coursera.com is a good introduction to Information Retrieval (specifically the Week 7 lectures). Keep in mind that the solutions presented in those lectures are relatively basic, but it's a good start.
I would heavily suggest trying to find an out-of-the-box implementation here. Failing that, using a toolkit like Apache Lucene will greatly simplify your development.
Now you need to test out a bunch of term weighting algorithms and see which one gives the best results for your data. TREC is a competition to find better and better weighting algorithms. Check the proceedings on their website to find discussions of newer, more accurate weighting algorithms.