3 ms·

I can't come up with a concrete use case for using multiple keys to access the same data (#8). I'm trying to wrap my head around an example of a single value t

I can't come up with a concrete use case for using multiple keys to access the same data (#8). I'm trying to wrap my head around an example of a single value that would be accessed ~1-million times a second that would be cached and served by Redis, and not cached closer to the consumer (such as a web server).

paxys 5y ago
They don't mean have multiple keys storing the same data, but rather create your data schema in such a way that keys are accessed more uniformly.
- balls187 5y ago
  Can you explain, I'm not seeing how you get that from the anti-pattern.
riverdweller 5y ago
One type of data that can beneficially be exposed under different keys is information pertaining to financial instruments (e.g. instrument reference data or market quotes). Some users may wish to look them up using an ID assigned by Bloomberg (a FIGI). Some other users may instead be familiar with an ID assigned by Reuters (a RIC). Or an ISIN, a CUSIP, or a SEDOL, and so on. In some cases it's simpler to store the data under multiple keys than to build "joins" into the client (given we don't have the luxury of RDBMS SQL logic).
cik 5y ago
Financial data is a great example. Occasionally companies change their ticker symbol. multi-key access for the same data means that using everything existing under the covers the same data can be shared, graphs generated, etc - the very next morning when FOO changes to BAR.
therealdrag0 5y ago
Who says it’s an external consumer asking for the data? Lots of backend services have asynchronous processes or batch jobs that are themselves essentially the consumer.
- balls187 5y ago
  Right. And it's not uncommon for backend services to access internal data via REST endpoints.
  - therealdrag0 5y ago
    But do I want to store data in my microservices? Esp if I've scaled them horizontally. Maybe I have 4 or 8 or 20 instances, I don't want 20 copies of my cache. I want one copy in Redis. I might also want shared evictions/TTLs or other semantics on the data.
    - balls187 5y ago
      > But do I want to store data in my microservices? That is a trade-off, and gets to the meat of my question. If I understand the anti-pattern recommendation, if you have a single data item that needs to be accessed at a very high throughput rate, if you choose to use REDIS, it's best to have n-copies indexed by different keys, in order to properly distribute the data across multiple-shards to have that specific through-put. The tradeoff would be having one-copy of the data (a single key in REDIS) and the complexity of caching it locally, OR have it cached at REDIS, and the complexity of managing having multiple copies of the same data in REDIS with equally distributed keys. My original question--what would be a usecase for choosing the latter.
      - therealdrag0 5y ago
        Oh ya good point. I understand what you’re getting at now.

paxys 5y ago

They don't mean have multiple keys storing the same data, but rather create your data schema in such a way that keys are accessed more uniformly.

balls187 5y ago
Can you explain, I'm not seeing how you get that from the anti-pattern.

riverdweller 5y ago

One type of data that can beneficially be exposed under different keys is information pertaining to financial instruments (e.g. instrument reference data or market quotes). Some users may wish to look them up using an ID assigned by Bloomberg (a FIGI). Some other users may instead be familiar with an ID assigned by Reuters (a RIC). Or an ISIN, a CUSIP, or a SEDOL, and so on. In some cases it's simpler to store the data under multiple keys than to build "joins" into the client (given we don't have the luxury of RDBMS SQL logic).

cik 5y ago

Financial data is a great example. Occasionally companies change their ticker symbol. multi-key access for the same data means that using everything existing under the covers the same data can be shared, graphs generated, etc - the very next morning when FOO changes to BAR.

therealdrag0 5y ago

Who says it’s an external consumer asking for the data? Lots of backend services have asynchronous processes or batch jobs that are themselves essentially the consumer.

balls187 5y ago
Right. And it's not uncommon for backend services to access internal data via REST endpoints.
- therealdrag0 5y ago
  But do I want to store data in my microservices? Esp if I've scaled them horizontally. Maybe I have 4 or 8 or 20 instances, I don't want 20 copies of my cache. I want one copy in Redis. I might also want shared evictions/TTLs or other semantics on the data.
  - balls187 5y ago
    > But do I want to store data in my microservices? That is a trade-off, and gets to the meat of my question. If I understand the anti-pattern recommendation, if you have a single data item that needs to be accessed at a very high throughput rate, if you choose to use REDIS, it's best to have n-copies indexed by different keys, in order to properly distribute the data across multiple-shards to have that specific through-put. The tradeoff would be having one-copy of the data (a single key in REDIS) and the complexity of caching it locally, OR have it cached at REDIS, and the complexity of managing having multiple copies of the same data in REDIS with equally distributed keys. My original question--what would be a usecase for choosing the latter.
    - therealdrag0 5y ago
      Oh ya good point. I understand what you’re getting at now.