[HOLD] Stop storing actor identity in ate Redis's value

[Haven Xia (HavenXia)]

The key actor:<atespace>:<id> already carries both fields, so storing them in the value duplicates ~20 bytes plus both name lengths per actor.

The only added CPU is a string parse on the list function. GetActor/UpdateActor/DeleteActor just assign the two fields from the function args. list function needs one strings.Split per key — nanoseconds(based on local benchmark by agents), next to the per-object protojson.Unmarshal which is O(microseconds). So not a big addition of latency.

Ram saved: Values can shrink by ~20 bytes + the two name lengths, given both atespace and actor_id are DNS labels so we can save 20+2x1=22 to 20+2x63=146 bytes per object. For 100M actors that's 4~8 GB.

• Tests pass
• Appropriate changes to documentation are included in the PR

[Eitan Yarmush (EItanya)]

One thing I'll say in advance is that this sets the precedent that there's no "schema" for the data in redis which may lead to confusion later on. Is it worth considering having stored data types?

[Tim Hockin (thockin)]

Eitan Yarmush (@EItanya) We do have a schema for stored values - it's the resource proto. It's incomplete (in the sense that what is literally in valkey would not pass validation) but if we replaced valkey with a SQL DB that might be just as true, right?

I was going to make a comment about whether this is at the right layer or not, but I think it is -- the API assumes the storage layer produces fully correct values, regardless of how iut stores them.

[Tim Hockin (thockin)]

If we intersect this with the new API style guide, we will need to replicate this function for every resource, right? I don't see a way to do it generically.

[Tim Hockin (thockin)]

Julian Gutierrez Oschmann (@juli4n) is this optimization worthwhile? Or is it premature?

[Julian Gutierrez Oschmann (juli4n)]

Julian Gutierrez Oschmann (Julian Gutierrez Oschmann (@juli4n)) is this optimization worthwhile? Or is it premature?

Considering all the rework we are doing (right now) in #149 I think it's probably too early (I would also expect patterns to emerge once we add common metadata, where we should be able to reuse some logic across resources).

[Tim Hockin (thockin)]

I initially thought it might be clever, but I think I would like to see the API overhaul land and then consider the impact of this.

Haven Xia (@HavenXia) are you OK to hold on this one for a while?

[Haven Xia (HavenXia)]

I initially thought it might be clever, but I think I would like to see the API overhaul land and then consider the impact of this.

Haven Xia (Haven Xia (@HavenXia)) are you OK to hold on this one for a while?

Yes. I will also check Julian's rework PR.

[Eitan Yarmush (EItanya)]

Eitan Yarmush (Eitan Yarmush (@EItanya)) We do have a schema for stored values - it's the resource proto. It's incomplete (in the sense that what is literally in valkey would not pass validation) but if we replaced valkey with a SQL DB that might be just as true, right?

I was going to make a comment about whether this is at the right layer or not, but I think it is -- the API assumes the storage layer produces fully correct values, regardless of how iut stores them.

Very fair answer, just wanted to point this out. In the past I have gotten tripped up with these sorts of read/write time operations, but they definitely have their place.