Why does Orleans use BLOBs for storing/persisting grains? Instead of using relational model? And the potential problems that might cause...

[v8ify]

It is my understanding that while storing a grain in the database, Orleans will serialize the entire object in binary, XML or json format first and then store it in its entirety.

So if I have a Student grain with fields like roll_no, name, age, etc, I cannot store it like a relational way with Student as a table and roll_no, name, etc as its columns. And I also can't have Professor table which has a One-To-Many relationship with Student table using foreign keys.

Is my understanding correct? If so, then I want to know the reasoning behind it? And won't it cause problems for querying data? Moreover relational way of storing data is a proven way, why change it?

The last question I have is this: Suppose I have a newspaper website. With each news article as my grain. Since the grain is stored as a BLOB, I cannot use free-text-search or other functionality that the database provides. Is that true?

One more thing, suppose I build my application using Orleans and it has fairly large number of grain classes. Suppose after some time I decide that I don't want to use Orleans anymore. I want to migrate my app to Java/Spring or Python/Django. If I don't use Orleans, I can just use any back-end framework I want since my database is in the relational form and is generally portable.

But with Orleans, will my database too closely tied to the framework, so that it becomes impossible to switch frameworks in the future?

I am a total noob to the whole actor frameworks so forgive me if any of these questions sound stupid.

[dodyg]

You keep RDMBS as your primary data storage.

I consider a grain like a persistent live object that survive multiple restarts. You can use grain to access database as usual without any problem.

• You can choose to cache the data you get from your RDBMS in grain so the subsequent requests don't need to hit your database.
• You can use grain to store temporary data that you will at some point calculate and manipulate and store in your RDBMS.
• A grain can act a VIEW to your data. You can do multiple queries to your db and built up a comprehensive object of your data and have other grain access that.
• You can mark a grain as stateless and it will not keep any data.

For example, a shopping cart. You might not care to store every single item in the shopping cart in your RDBMS. Just store them in your grain until it turns into a order. Then you hit your database after that. Then if you have a tax module. You can have the tax module calculate the tax from the information stored in the shopping cart grain without hitting your RDBMS.

[rallets]

Hi @Prajwal-Jadhav , Orleans and the actor model are meant to solve - between many others - the problem of scaling. So a relational db will bring some performance limitations, as you need to keep in shape all the PK, FK, constraints, etc. This has a huge impact on the throughput of the system. On the same topic, you can check why no-sql dbs are useful. As everything, they solve problems and introduce others. Said that, Orleans and the actor model require you think in a different way, because they solve another class of problems. As example using a rdbms for storage, and with thousands of nodes reading/saving state you will not be able to use 100% of the potential throughput (as the db will be the bottleneck). So Orleans is very useful if you need to implement data intensive applications that haven't a big degree of relation between data (between actors), as games, IoT, etc. An ERP/RM is not a "natural" fit for an Actor model. Someone likes Orleans for the way to model the data (as it solves a lot of problems like concurrency and caching), and use them in applications that are not a perfect-fit, but IMHO that requires good experience and knowledge to be able to solve the limitations you mentioned, like storing the data in a no-sql db and using the db engine to query the data (that is outside the Orleans/Actor "pure" way of thinking). The topic is huge, but I hope I could help to get you in the right direction.

[ghost]

Thanks for contacting us. We believe that the question you've raised has been answered. If you still feel a need to continue the discussion, feel free to reopen the issue and add your comments.