Comments (3)
I see nothing wrong with querying multiple actors. It's just a read operation. I would consider actor types just as you have proposed.
from actordb.
Using these actor choices seems less elegant than classic monolithic SQL queries to me. Perhaps I'm missing something?
For example, retrieving the contents of all unread items in the RSS reader. With classic SQL, it would be approximately, SELECT body FROM items JOIN item_statuses WHERE user_id=user_id AND is_read=false
. Very straight-forward.
With ActorDB using one actor type stores feeds and another actor type stores each user's per-feed-item read/unread status, I'd need one query to select all unread item IDs from the user(user_id)
actor, then a second query to grab the contents of all those items by ID from feed(feed_id)
. Maybe with IN
? Or pack it all into one query with an ActorDB loop and variables?
Using either multiple queries and an IN
holding possibly thousands of IDs, or using a query with a loop, both seem less elegant than the classic SQL solution. Are either of these the recommended ActorDB approach?
Or maybe a better approach is for each feed
actor to contain a table with the read status of all items for all users?
With each actor being a complete database, I'm very unclear on where classic SQL design and queries stop end and ActorDB-specific operations and design begin.
from actordb.
I'd need one query to select all unread item IDs from the user(user_id) actor, then a second query to grab the contents of all those items by ID from feed(feed_id)
Yes this is how I would do it. User actor stores positions of last read items for every feed, then you go to the feeds themselves to check if there is anything new.
Using either multiple queries and an IN holding possibly thousands of IDs, or using a query with a loop, both seem less elegant than the classic SQL solution
Yes but what you described has to happen either way. You are either joining yourself or within the database. A single server database is fine with doing it as it has all that data readily available. A distributed system must join across servers for this to work.
With ActorDB it is very clear what has to happen. This way you can design your system with this in mind. When you are displaying the feeds to the user, they can be loaded asynchronously. You do not have to read everything at once. You are not doing joins across large tables, you are making simple read queries.
I suggest not worrying as much about what is "elegant" but what is scalable and reasonable. A lot of the time people consider one solution more elegant then the other, simply because they shifted the complexity to some other system. It's elegant to them, because they don't have to deal with the messy details.
With each actor being a complete database, I'm very unclear on where classic SQL design and queries stop end and ActorDB-specific operations and design begin.
Usually the correct design is avoiding multi actor write transactions. In this case if you have a feed, your crawler updates feeds actors, your client side code updates user actors. This keeps your write and read load distributed across your cluster.
from actordb.
Related Issues (20)
- Unable to open req pipe MacOS 10.13.6 HOT 2
- Error: {error,{error,<<"unknown_actor_type: type1">>}} HOT 3
- How to execute actorDB's load test? HOT 1
- SQLight drop in replacement build for C/C++ HOT 1
- LMDB still grows after delete then insert HOT 3
- actordb crash: exception exit: badmatch, sqlite_error, "SQL logic error or missing database" HOT 1
- Timeout error when executing init.example.sql on OSX HOT 2
- Connecting using MySQL CLI on OS X fails with error HOT 5
- PRAGMA LIST not updating after PRAGMA COPY HOT 1
- How to send multiple parameterised queries through the thrift interface? HOT 9
- Using mysql driver HOT 2
- Execute query timeout by using actordb_console
- Same name columns in query result are swallowed and column order can't be specified HOT 1
- Queuing of queries (basic question) HOT 3
- sqlcipher HOT 1
- Sqlite upgarde
- Running protractor test using docker-compose but getting error HOT 3
- Are clusters immutable?
- vm.args needs to have a -name parameter. -sname is not supported.
- Storage for FastAPI service
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from actordb.