Understanding Partition Keys

@Andy_Dent

Partitions isolate related data and reduce the size of a Realm (because there are less objects).

By the description of the project it doesn’t sound like there’s a LOT of data. It also doesn’t sound like the data needs to be isolated… Does it?

I ask because it’s easy to “over-partition” which ends up being a challenge because data is too granular.

Often times with NoSQL (backed) databases, a model design is based on the types of queries you need to run. If you’ve got similar data in multiple partitions, that’s makes queries much more challenging and complex.

Hi Jay, thanks for the feedback.

The code I’m porting is for an app that’s often used in remote worksites with poor and occasional comms, although they get decent wifi to keep them happy back at base. The founder’s expectation is it can grow to tens of thousands of users who would probably be syncing < 20 items with a small group of friends. In most scenarios, the items being synced are in a broadcast by one writer pattern. One person updates appointment or shiftwork descriptions, others just read.

There’s also a chance it could really take off for a gig economy use with people juggling shiftwork.

I’m trying to avoid over-engineering now without building in a gotcha that means the sync falls over and I suddenly have to deal with it failing. I’m very tempted to just ship a version with almost everything in one Realm but am also playing with Flexible Sync as the way to go.

I agree I don’t think I need to worry about the isolation of data for security reasons, it’s just the mechanics of sync have me nervous.

1 Like

BTW I have a pretty good understanding of the Realm dotnet SDK - I wrote a lot of it between 2015-2017.

It’s the new Atlas-backed sync model it’s taken me a while to get my head around.

2 Likes

The model I’ve decided to deploy for now, with likely evolution to FlexibleSync is:

  1. A realm-per-user for all their data. This might be shared with 1-2 other people as a mirroring option (spouse back home). This starts as a local realm only until they sign up for sharing.
  2. A single global SharedItems realm containing a copy of appointments and work shift descriptions. This will migrate over time to be a FlexibleSync partition.
1 Like

Sorry for the belated response. Like the rest of you, I have been waiting for the last two years for fine grain partitions but have managed pretty well with partitions and server side functions instead. Here is my strategy

User Partition: every user has a read/write personal partition. Only allow users to write to this partition.

User Read-Only Partition: to contain data written by the server (not modifiable) that only the user can access.

Public Partition: to contain all public read-only data, only the server can modify this data

Team Partition: to contain read-only data shared by a team

If a user wants to modify data in a public partition or team partition, he/she must make a server function call to do so, or alternatively to respect offline mode first policies write an operation type object in his/her private partition that the server will pop off and execute at some future date when connected again.

I hope this was useful

Richard Krueger

1 Like

Hey All, If you are building a new app I’d certainly recommend that you use Flexible Sync as we are quite close to going GA and it will be the future of sync at MongoDB and Realm.

Also, we are working on field-level permissions/fine-grained permissions right now and will be releasing it shortly for Flexible Sync. These two technologies should make your architecture simpler so that you do not have to call functions/triggers to replicate data between different partitions.

1 Like

Hi Ian, had a meeting yesterday where I expressed my belief that Flexible Sync was just around the corner so thanks for the confirmation.

For our scenario, it’s the prospect of sudden massive growth in the initial sync load that’s made me hesitate with the partition-based strategy. Fine-grained permissions are reassuring but much lower priority than knowing Flexible Sync is GA.

I am working on an internal testbed dotnet sample in Forms which I’d be willing to clean up a bit and make public if there’s interest. It’s based around sharing a small number of items with a small number of people out of potentially much-larger pool, but without formal teams as a grouping mechanism.

Fabulous, this news definitely made my day, my sprint. I spent my last 2 weeks trying to develop for our project how we can use RealmSync. And the result was not really satisfying, but now I believe we can definitely find a reliable approach for our business arch. Thanks Ian <3

I am using realm it’s just great and I have no words but I think documentation should be strong and easy to understand for the newbeis