[almighty] Cache solution for Almighty core

[Karanbir Singh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is what I am trying to wrap my head around reading this thread.

What exactly are we caching, in many cases - scaling the backend db
for consistency can be an easier win than caching in another db.

For static objects, where we can expire at leisure, we will almost
certainly have a content look-aside cache that wraps the app ( and
will split content at the router / loadbalancer level ). This would be
the (2) Global cache you defined below. It can, if needed, get fairly
smart as well.

regards,


On 08/11/16 10:11, Aslak Knutsen wrote:
> We're talking about 2 different things here:
> 
> 1. Local cache
> 
> The original intent for the Cache in question was to avoid fetching
> the WIT for each WI from the DB, especially for List operations
> where we fetch 100 WIT's per page. And 99 of them are the same
> WIT.
> 
> Moving this to a centralized Cache server makes no sense, as the 
> intended purpose is to avoid network traffic on immutable objects.
> 
> 2. Global cache
> 
> Microservices solutions would normally have a 'Reverse Proxy cache'
> on the 'consumer' side to cache aggregated data from multiple
> services.
> 
> 
> -aslak-
> 
> 
> 
> On Tue, Nov 8, 2016 at 9:41 AM, Thomas Mäder <tmader at redhat.com 
> <mailto:tmader at redhat.com>> wrote:
> 
> Hi Alexey,
> 
> If you're talking about a "cache server" are you talking about a 
> separate process, possibly on a different machine or an in-process 
> service like groupcache?
> 
> How I understand microservices, they DON'T have a shared DB behind 
> them. They have a relatively simple datamodel that is loosely 
> coupled to the other microservices via a well defined API (no 
> peeking at the internals!). Multiple instances of the same service 
> may share a common DB, but not different microservices. As a 
> consequence of this, it doesn't make sense for multiple different 
> services to share the same cache in my opinion. Instead of asking 
> any shared cache service, you might as well ask the original
> service and let that one take care of caching.
> 
> /Thomas
> 
> 
> On 11/08/2016 01:15 AM, Alexey Kazakov wrote:
> 
> Hi all,
> 
> At some point we will probably need some universal cache solution
> which we could use different types of objects in almighty core. I'm
> going to spend some time on researching in this area but there are
> a few questions I would like to discuss with the team. There are
> some solutions like Memcached or Redis which could be used but they
> require to have a server with the cache service (on a dedicated
> container?) where we could keep WIT, WI and any other artefacts
> which we want to access some value by a key. Some solutions like
> Memcached are pure in-memory some like Redis can be persistent but
> my biggest concern for now is what approaches are best for
> microservices world. In monolith world we could have a shared cache
> server. One DB - one cache service. But I'm not sure if it's worth
> having an internal dedicated cache server for each relevant
> microserver. Currently we are kinda building a monolith and a cache
> server could work. But how our cache system should evolve when we
> start splitting/introducing microservices in almighty-core? Is
> there any concept of shared cache between microservices or it's
> always hidden by the microservice implementation and the
> microservice just takes care of synchronization of its internal
> model/DB and uses some internal fully independent cache if needed.
> 
> Any thoughts?
> 


- -- 
Karanbir Singh, Project Lead, The CentOS Project, London, UK
Red Hat Ext. 8274455 | DID: 0044 207 009 4455
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJYIea2AAoJEI3Oi2Mx7xbtcgcH/A19VUpmm23Da+9gq7yRxd6y
OszSGRcpcTWryavPh3DNvwAZ9fAgXA9hV19Hya/fwWevDhbQtPmgqMVWLY3JW8zU
EbQa1dDZ8q96f4LQMnIPoydfD3FXoVQHkcidHLVd7m/2BQ6S1f8RyXLq099+O4rH
srNu63owFJ+nN5utgcqJOqIUnzzfd5eKx5fzDjZ22OxQn3YyBA8t2FC1mZJt81tq
lRQIxrOch7w7Hf7A4rsvyk+Uy/FjBdkzidvGrkSPmlwVcZv7rQ8pMvM2kmEtVJ4k
CXIjfWWD9P/GpLfpzoeW12HPPVOOVKnICXUjMhc8iy6qjsno28shQjZjJm8zf0Q=
=VblP
-----END PGP SIGNATURE-----