4 ms·
> When speed matters, you have to get the compute and the data as close as possible. And when scaling matters, you often need to do the opposite. And scaling
by gnaritas 15y ago
> When speed matters, you have to get the compute and the data as close as possible.
And when scaling matters, you often need to do the opposite. And scaling is often more important than speed.
- gaius 15y agoErmm, that's nonsense. You can move the compute into the database (stored procedures) or you can move the data to the compute (caching - and deal with cache invalidation yourself). There is no situation ever in which you would deliberately seek to make them as far apart as possible.
- babebridou 15y agoNot necessarily nonsense: figuratively, you can (and should in many cases!) be putting as much of the data as possible, as far away as possible from your code with divide and conquer to work on only a fraction of it. But anyway, that's what indexes are for in RDBMS, so you still have a point, even figuratively :)
- gnaritas 15y ago> You can move the compute into the database Yes, often doesn't scale because the database is an extremely limited resource that generally doesn't scale horizontally. > or you can move the data to the compute Which is what I said, which allows you to scale computation horizontally. > There is no situation ever You just named one, however I see where you're misinterpreting me or I you; when I said do the opposite, I meant move the computing away from the database.