App Engine Data Modeling for Comments

Question

I implementing a Comments section for my current application. The Comments section can be thought of as a series of user posts on a given page. I am wondering which design would be most effective in a non-relational database (Google App Engine).

Design 1: Group the comments by a groupId and filter on those results

Comment Entity >> [id, groupId, otherData...]

Queries for all comments pertaining to a page would look like:

Select from Comments filter by groupId

Design 2: Store a single key for all comments within a group and use a Self Expanding List if the number of entries exceeds 5000 entries.

Comment Entity >> [id, SELid]

Queries would simply perform an id/key lookup.

I understand that Indexes can be expensive, but the first design proposal will only index the groupId field and will only require a single write to post a comment (well more writes if you include the index).

The second design will avoid costly indexing but each posted comment will require a read and a write operation. Furthermore, I"m worried about contention issues. These comments should not be experiencing extremely high throughput, but the second design seems to create a bottleneck.

As I am new to non-relational DB's, I would appreciate any input on these proposed designs and their associated tradeoffs.

Answer 1

In case of App Engine and Datastore, the approach you will take depends mainly on the consistency model (strong vs eventual) you require for your entities. In Google Cloud Datastore, there is a concept of an entity group. The entity group (an entity and its descendants) is a unit with strong consistency, transactionality, and locality but also imposes some restrictions (1 write per second).

Considerations

1. Do you require strong consistent results?
2. How often will be comments posted per page?
3. How many comments per page do you expect?
4. Do you have a use case requiring transactional behaviour?

Since neither of your design options uses entity group (page -> posts), I suppose you decided not to go this way.

Design 1

1. Eventual consistent lookup by groupId
2. Easier to maintain (you do not have to deal with 5000 entities limit)

Design 2

1. Strong consistent lookup by entityGroupId
2. Harder to maintain (you HAVE to deal with 5000 entities limit)
3. As mentioned, one entity representing all post for a page can be a bottleneck (can be reduced by means of Memcache)

I would probably go with the first approach even though it can resemble relational data model.