Q:

How to store frequently modified lists in database in a natural way so that they are just ready to read? 

For a social network site, I need to store frequently modified lists for each entity(& millions of such entities) which are:

frequently appended to   
frequently read       
sometimes reduced 
lists are keyed by primary key

I'm already storing some other type of data in an RDBMS.  I know that I could store those lists in an RDBMS as a many to many relationship like this way: Create a table listItems with two columns listId & listItem & to generate any particular list, just do a SELECT query for all records WHERE listId = x. But storing lists this way in an RDBMS is not very ideal when high scalability is concerned.  Instead I would like to store prepared lists in a natural way, so that retrieval performance is maximized.  Because I need to fetch around hundred of such lists for a user, whenever I user does login & view a page. 
So how do I solve this ?  What kind of database should be used for this data, probably the one that provide adding variable no of columns to keyed by a primary key, the ones like Cassandra ? 

A:

I used the same method that is, to store a 2 column row for every record, which I turned to a txt file with the formatted html which then we changed to json and finally to mongodb. 
But since you have got frequent operations, I suggest cassandra, hbase and googles big table implementations like accumulo cloudata and hypertable. 
Cloudata may be the right one for you. 

A:

As you pointed out the solution must be performant and scaleable: I'd suggest you to use Redis with it's LIST data structure and O(1) inserts and O(N) fetches (N - elements to fetch, considering you're fetching last ones from lists) and scale it horizontally with some hashing algorithm.  I don't know what amount of data you are going to store and how many machines are available, but definitely it will be the best choice performance-wise, since nothing beats memory access speed. 
If the amount of data is huge and you can't keep it all in RAM then Cassandra can do the job - storing lists ordered by time is a nice fit for it even better with partition strategy as Zanson mentioned above. 
One more thought: you said read performance must be max, and once user logs in you will need to fetch hundred of lists for this user.  Why not to prepare a single list for each user?  That way there will be more writes but the read will be optimized since you will need to fetch only latest entries from one list.  I'm not sure if that fits your task, just a thought. :)