Struggling with nosql/Parse data model design

Question

I'm used to SQL and relational design, so I'm a bit stumped on my current project. Here's how it goes:

There are things called "Bubbles" which operate basically the same as a Google Circle. They're user-defined and can have any PFUsers in them as "members".

There are then "Posts". Each post has a visibility setting that is an array of PFUsers (or bubbles).

How the app works is a user makes his/her bubbles and then can browse a feed/post to bubbles. The reason this gets tricky is this: When the app launches and I want to query the posts for a particular user, I first need to find their bubbles that belong to them (easy enough), then I need to get the users in those bubbles, then I need to query the posts of those users, then I need to make sure I'm in the visibility of those posts. I tried making a cloud code function, but it failed to populate the posts part of the dictionary because of asynchronous calls messing up the index of the for loop.

Anyway, I'm currently pulling out my hair trying to figure out the best nosql way to do this. Any help, Parsers?

Answer 1

Kind of a big question there. I can't create a model for you, but I can give you some hints on how you need to think.

First, as you seem to have found out already, you need to stop thinking in relational design terms for this task. For all who are schooled in SQL databases first (most of us, still), this is a long stretch. Many of the NoSQL ways strike a bad note in our relational minds.

Second, you need to focus on data extraction. With the model you no doubt formed in your mind (and perhaps even implemented), the queries needed to extract the desired data quickly become very complex. And since your clients are probably mostly (only?) mobile devices, you need to reduce both the number of queries and calculation overhead to a minimum.

Third, if you have faith that your app could hit the charts and become wildly popular (assuming you're not designing an enterprise app), you need to design for scalability. Not necessarily implementing it perfectly so, but at least design for it so that you can build on your initial design by improving it rather than rebuild it entirely if the app becomes popular (and thereby risking total disaster if your efforts are unable to keep up with the growing user base).

As a typical example; if you need a list of posts created by a list of users, you don't first go and get the users and then query for posts by those users. You prepare your schema so that this list of posts (and other result lists commonly requested) are ALREADY prepared as part of your schema. This could be a table (parse class) for feeds. One record for each user, and the record contains a pre-prepared array of the feed. Which would need to be updated every time a user that I follow writes a new post. And so would the records for all other users who follow the author of the post! There, I just struck a bad note in your relational mind, didn't I? :-)

Now, for implementation specifics, I recommend you take a look at NoSQL schema design examples. I found "Twissandra" (a Twitter clone implemented in Apache Cassandra) to be a very good primer on how to design for NoSQL. Especially since Twitter is a use case we can easily relate to. Even though Parse is backed by MongoDB, not Cassandra, most of the principles carry over: http://www.rackspace.com/blog/cassandra-by-example/

Also, comparing page 6 and 7 in this presentation provides a good visual for how different such schema designs can be between SQL and NoSQL: https://speakerdeck.com/mongodb/mongodb-dc-2012-schema-design-by-example

I recommend you try (re)designing your schema after reading those (and maybe other) articles, and then ask more specific questions relating to your implementation here on SO if needed.