Application Features Persistence Alternatives - NoSQL or a RDBMS?

I'm making a system with some features of a social network. And I want to know what your thoughts on the persistence technologies that best apply to certain features.

Let's take three basic features of the system:

• User Stream - All user activity in the application will be recorded, and then displayed on the user profile, it would be something like the Facebook wall. This will be one of the major focus of the application, and it need to have the best performance possible.
• Application and security logs - Here is where the application errors were stored, and other user-related data such as: IP, geo-spatial location, history log, etc. This par开发者_Go百科t would be used as an additional layer of security.
• Statistics of the application, users and ads displayed on it.

What would be the ideal persistence technology for each one of the above characteristics? If some of the answers is a relational database, why would be best to choose a relational database over a NoSQL? And if the answer is a NoSQL, what would be the most recommended NoSQL?

Sorry for many questions, but I'm studying the choices that I can take, and would like to hear from those who already understand the subject so I do not take precipitated decisions.

Note: If you can improve the title of the question, please feel free to do so.

Before going into use cases, NoSQL is there to solve several problems. No matter what answer(s) you get here, think about these questions:

• Do you expect your system to rely on BigData?
• Would it benefit from being Distributed?
• How much Down Time is ok?
• Would you rather support 3 huge boxes in different data centers, or 300 smaller boxes?

Now to your use cases:

• User Stream =>

NoSQL can definitely solve this problem, since there is no 100% consistency requirement here. Having said that, it is funny that you mentioned Facebook, as they rely on huge MySQL farm to solve this problem :)

• Application and security logs =>

NoSQL is great at storing logs, in fact many data structures that some of NoSQL solutions are built on top of are log like structures: Log-Structured Merge-Tree that is/was used in Google BigTabe, Cassandra, and others. Plus logs can grow to be quite huge, hence being able to scale in size is easier with NoSQL

• Statistics of the application =>

You did not provide much details here, but NoSQL can definitely solve displaying stats.

Now to your question of should you go NoSQL. The truth be told:

If most of NoSQL gurus take their masks off, they will all agree that MOST of the problems that developers solve day to day, can and rather be solved with a SQL solution, such as PostgreSQL, MySQL, etc.. with some cool Redis cache layer on top of it. And only a small subset of problems would REALLY benefit from NoSQL.

In case you decide to go with NoSQL, I would recommend an Erlang based solutions (Riak, CouchDB), since a NoSQL, fault tolerant DB should have an extremely strong, flexible and naturally distributed foundation => such as Erlang OTP. Plus simplicity is king. They, of course, have clients for most languages, so you would not need to even know how to spell Erlang if you don't want to.