If you are only going to store logs, you've strayed into one of the few places were relational databases do not make much sense.
SQL is surely not going to be the ideal medium to perform your work- no joins, not many different tables, etc. Transactions and
UPDATEs probably won't be necessary.
I would choose something that let me run map-reduce jobs easily- it might well be the case that a single-threaded algorithm be all you need, but if it ever becomes too slow for your purposes, being able to throw cores at the problem will come in handy.
If you are going to be searching a lot (i.e. perform calculations on small subsets of data), indexing is going to be another defining factor- having a store which supports indexing which handles your searches well will save plenty of time.
On the other hand, depending on what you do, it might make sense to "summarize" your logs using a non-relational data store, but put in the massaged data in a RDBMS. If there's structured/relational data hidden in your logs, the ability to perform ad-hoc queries using SQL is invaluable- aggregates, window functions, etc. can be made to run pretty quickly in a decent RDBMS, perhaps even more efficiently than with map-reduce and highly-parallel algorithms; definitely, if you know your SQL, implementation is usually much quicker.
For instance, say the logs you are really interested all look like:
[timestamp] add student xxxxx
[timestamp] create class yyyy at [date-time] with professor zzzz
[timestamp] student xxxx books class yyyy
[timestamp] student xxxx cancels class yyyy
then dumping them into
student_booking and performing aggregates on them makes plenty of sense.
(of course, I would contend that you are not parsing logs then...)