by brittonrt on 10/31/12, 4:41 PM with 5 comments
An example would be fetching the 10 most recent submissions by a specific user, sorted by "rating" number which is also associated with a piece of content, as well as all content which has been related to each returned piece of content.
IE Bob requests the 5 most popular data points he's published and all the associated images/links/etc.
I am currently using MongoDB, and have had no issues, but after doing some research, I'm considering switching to an amorphous Postgres implementation where there are only 2 tables, a data table and a relationships table, with Memcached keeping some of the higher level requests precached for quick fetching. This should keep my schema from the application's perspective highly flexible.
I know it's apples and oranges, but would anyone be willing to offer maybe some of their own experiences with similar setups that might help me determine if this is a good decision? My main reason for looking into migrating away from MongoDB is write speed and data volatility. I don't want to ever lose data if possible, and I understand that Mongo has table level locking when writing (is this true still?)
If anyone has any advice on the performance/reliability implications of either or both options, or if anyone thinks there's an even better 3rd option I haven't considered, I would be very interested to hear!
Thanks so much!
by lmm on 10/31/12, 5:08 PM
If you're worried about performance, benchmark it (or find someone who has). On the reliability side there are plenty of NoSQL options with better reputations than MongoDB. My first thought is neo4j, but I don't really know enough about your particular problem.
by dotborg on 10/31/12, 8:28 PM
if it's less than 1mil and they are not updated frequently, you should go for postgres and have some fun with SQL,
more data and increased concurrency means problems also in postgres, a lot of optimizing, materializing views and other fun problems to solve.