MemoGraph

Alternative Namen

• MemoCache

• nicht: KnowledgeGraph

Konzept

Es gibt Entitäten, die nur einmalig im Cache existieren.

Das sind:

• Thema

• Frage

• Nutzer

• usw.

In process in memory!

Ein wesentliche an der Anforderung ist Geschwindigkeit, insbesondere bei Graphenoperationen. Damit die Operationen schnell sind, soll ein Großteil der Arbeit Prozessgrenzen nicht verlassen, damit es etwa möglich ist, im Millisekunden Daten aus tausenden Knoten zu aggregieren.

Cache-Framework vs Dictionary?

Gegen die Verwendung eines Memory-Cache-Frameworks spricht, dass viele der gebotenen Funktionen - wie Lebenszeitmanagement oder unterschiedliche Storage-Provider - von uns nicht genutzt werden.

Eigener Service?

Soll der MemoGraph/MemoCache als eigener Service herausgelöst werden?

Con:

• Erhöhter Aufwand in der Umsetzung

• Latenz unmittelbar erhöht. Führt zu einer Architektur, die eher verteilt ist.

Pro:

• Ein eigener Service muss seltener neu gestartet werden. (Wie schnell kann das Befüllen des Memory-Graphen erfolgen?)

• Die Architektur könnte so eher auf Skalierung ausgelegt sein.

SQLite als Backend

Utility:

• ?Replikation mit LiteFs: https://fly.io/docs/litefs/

• libsql ist ein SQLite-Fork: https://github.com/tursodatabase/libsql

TOOLS und Bibliotheken

• In process in memory "mediator implementation": https://github.com/jbogard/MediatR

• ChacheManager mit Sync: https://cachemanager.michaco.net/documentation/CacheManagerCacheSynchronization