kgyrtkirk commented on code in PR #16569:
URL: https://github.com/apache/druid/pull/16569#discussion_r1635945757
##########
server/src/main/java/org/apache/druid/client/CacheUtil.java:
##########
@@ -34,6 +34,8 @@
public class CacheUtil
{
+ private static final String RESULT_CACHE_NS = "ResultCacheNS";
Review Comment:
I've changed the resultcache namespace to `RES`
the `toUtf8` stuff is a bit more complicated:
* I wanted to push out the `String/byte[]` conversion from the `NamedKey`
and change the namespace to use `byte[]`;
* however: the `MapCache` directly accesses the
[namespace](https://github.com/apache/druid/blob/fee509df2ebade0d6a17f96ee0637a27acedb45d/server/src/main/java/org/apache/druid/client/cache/MapCache.java#L86)
field of the `NamedKey` class
* since its being used as a key in a `Map` it must provide a valid
`equals` - this could be addressed with a small refactor around there to use
`ByteBuffer`
* the `namespace` also appears as an argument to
[Cache#close](https://github.com/apache/druid/blob/fee509df2ebade0d6a17f96ee0637a27acedb45d/server/src/main/java/org/apache/druid/client/cache/Cache.java#L48)
- so this will kinda force that to change as well
* this could force changes in the segment cache key generation stuff
* ...so this path leads to refactor(s)
* I could store the `byte[]` next to the `String` by passing that as well in
the constructor - but I would rather not do that unless there are measurable
benefits of doing so
* status quo also have some pros: the `toByteArray` is not used in all
cache implementations - so the `toUtf8` might not be even called
I think for now it would be best to just leave this alone; not passing the
full cachekey as the namespace have kinda reduced the key sizes to around half
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
