4 ms·

The redis cache client in Django is effectively an ORM - but a much lighter one. The cache client is also doing compression and uses msgpack for serialization.

The redis cache client in Django is effectively an ORM - but a much lighter one. The cache client is also doing compression and uses msgpack for serialization. I think the comparison, in the context of a regular Django developer, is apt.

hardwaresofton 7y ago
> The redis cache client in Django is effectively an ORM If you're implying that the redis cache client in Django is comparably stunted, I don't agree. Postgres is a lot more tunable than Redis, and the more complex the underlying machinery the leakier/less powerful the abstraction ORMs can provide without taking on the same complexity. An abstraction layer on top of Redis != an abstraction layer on top of Postgres. Let me put this in context -- you could literally write a custom Postgres access method[0] (see talk on it[1][2][3]) which did nothing but take data and write it to /dev/null, or put it in a bounded space in memory. Of course, you wouldn't want to do that, but there's no way redis is going to be able to compete with that speed -- and from there you can imagine implementing a subset of Redis which is faster than redis can be (while throwing away a lot of course). This is the kind of complexity an ORM has no business replicating most of the time (I don't know which ORMs support the USING in CREATE TABLE yet), but it's part of what could be out there. > The cache client is also doing compression and uses msgpack for serialization. Great for performance but bad for testing -- this skews the results of the analysis, they're not doing the same work. > I think the comparison, in the context of a regular Django developer, is apt. I don't disagree, because this is what I'd expect a regular Django/Rails developer to do and call it a day -- but for those who want more serious analysis, this isn't it. It's a great start (good analysis is hard), but people shouldn't be thinking this is a good analysis with reasonable options explored -- UNLOGGED & TEMP tables are pretty low hanging fruit that isn't even mentioned. Initial settings of the Postgres cluster aren't mentioned/tweaked. This is a pretty naive case and Postgres is near an order of magnitude, while being capable of doing a lot of other things. That's pretty amazing. [0]: https://www.postgresql.org/docs/12/tableam.html https://www.postgresql.org/docs/12/tableam.html [1]: https://www.pgcon.org/2019/schedule/events/1374.en.html https://www.pgcon.org/2019/schedule/events/1374.en.html [2]: https://anarazel.de/talks/2019-05-30-pgcon-pluggable-table-storage/pluggable.pdf https://anarazel.de/talks/2019-05-30-pgcon-pluggable-table-s... [3]: https://www.youtube.com/watch?v=5RCkZl5HNiQ&list=PLuJmmKtsV1dOTmlImlD9U5j1P1rLxS2V8&index=13&t=0s https://www.youtube.com/watch?v=5RCkZl5HNiQ&list=PLuJmmKtsV1...

hardwaresofton 7y ago

> The redis cache client in Django is effectively an ORM If you're implying that the redis cache client in Django is comparably stunted, I don't agree. Postgres is a lot more tunable than Redis, and the more complex the underlying machinery the leakier/less powerful the abstraction ORMs can provide without taking on the same complexity. An abstraction layer on top of Redis != an abstraction layer on top of Postgres. Let me put this in context -- you could literally write a custom Postgres access method[0] (see talk on it[1][2][3]) which did nothing but take data and write it to /dev/null, or put it in a bounded space in memory. Of course, you wouldn't want to do that, but there's no way redis is going to be able to compete with that speed -- and from there you can imagine implementing a subset of Redis which is faster than redis can be (while throwing away a lot of course). This is the kind of complexity an ORM has no business replicating most of the time (I don't know which ORMs support the USING in CREATE TABLE yet), but it's part of what could be out there. > The cache client is also doing compression and uses msgpack for serialization. Great for performance but bad for testing -- this skews the results of the analysis, they're not doing the same work. > I think the comparison, in the context of a regular Django developer, is apt. I don't disagree, because this is what I'd expect a regular Django/Rails developer to do and call it a day -- but for those who want more serious analysis, this isn't it. It's a great start (good analysis is hard), but people shouldn't be thinking this is a good analysis with reasonable options explored -- UNLOGGED & TEMP tables are pretty low hanging fruit that isn't even mentioned. Initial settings of the Postgres cluster aren't mentioned/tweaked. This is a pretty naive case and Postgres is near an order of magnitude, while being capable of doing a lot of other things. That's pretty amazing. [0]: https://www.postgresql.org/docs/12/tableam.html https://www.postgresql.org/docs/12/tableam.html [1]: https://www.pgcon.org/2019/schedule/events/1374.en.html https://www.pgcon.org/2019/schedule/events/1374.en.html [2]: https://anarazel.de/talks/2019-05-30-pgcon-pluggable-table-storage/pluggable.pdf https://anarazel.de/talks/2019-05-30-pgcon-pluggable-table-s... [3]: https://www.youtube.com/watch?v=5RCkZl5HNiQ&list=PLuJmmKtsV1dOTmlImlD9U5j1P1rLxS2V8&index=13&t=0s https://www.youtube.com/watch?v=5RCkZl5HNiQ&list=PLuJmmKtsV1...