[almighty] Cache solution for Almighty core

[Alexey Kazakov]

Thanks for sharing your thoughts everyone. So, at this point any global 
cache seems to be very premature. We could introduce some local caches 
when it makes sense (like caching immutable WITs) right now and work on 
a global cache when/if we need it.


On 11/08/2016 06:52 AM, Karanbir Singh wrote:
> -----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-----
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public