Vlákno názorů k článku Nekonečný list pomocí RecyclerView a Microstream (Android) od anonym - Mam dotaz k Microstreamu. Zkusil jsem si ulozeni...

Mam dotaz k Microstreamu. Zkusil jsem si ulozeni 1M entit do mapy a pri kazde dalsi transakci (ulozeni mapy v rootu) se zrejme uklada cela mapa, protoze pri vetsi velikosti kolekce se zapis zpomaluje. Takze u velikosti mapy x10_000 to jiz celkem trva a velikost uloziste pak neni umerne poctu entit v kolekci.

Pokud pridavam prvky po jednom (tedy ne v davce), mel bych pridani zakoncit transakci. A zde se mi jevi, ze pokud na pozadi dochazi k ukladani cele kolekce a ne pouze rozdilu od minule verze, pak to je nelinearne tim vetsi problem, cim vetsi je ta kolekce.

Mam dotaz: Jaka je doporucena cesta k ukladani velkych kolekci? Existuje nejaky dobry zpusob, jak v Microstream spravovat (zakladni: list, set, map) kolekce s velikosti x1M?

Napadlo me akorat vest odkazy ne z objektu kolekce na jeji polozky, ale v opacnem smeru a nasledne vyhodnocovat formou dotazu. Tim ale problem nezmizi.

Zkusil jsem si ulozit take com.google.com­mon.collect.Im­mutableMap a net.openhft.co­llect.map.hash­.HashIntObjMap, ale s tim mela DB problem a bylo by mi nejspis treba proniknout hloubeji do custom value handleru.

Dobrý den,
na ukládání těchto rozsáhlých kolekcí není Microstream ta nejlepší volba. Každá technologie je silná v něčem a síla Microstream je v ukládání rozsáhlejších datových struktur v Javě. Objektového grafu. Ten uložit pomocí stávajících relačních databází není zcela triviální, kdežte s Microstream ano.

S pomocí Lazy můžete vždy držet v paměti třeba aktuální část, se kterou momentálně pracujete, zbytek nechat na disku a načíst pouze v případě potřeby.

V androidu, kde na mobilním zařízení nepředpokládám ukládání milionů dat a ta databáze tam slouží více méně jako lokální persistentní cache, to bude fungovat dobře.

Ohledně google collections, ty jsou v backlogu, tu druhou kolekci vidím poprvé. Pro custom type handler existuje ukázkový projekt:
https://github.com/microstream-one/examples/blob/master/customTypeHandler/src/main/java/one/microstream/sampler/customtypehandler/CustomBufferedImageHandler.java
https://manual.docs.microstream.one/data-store/customizing/custom-type-handler a dokumentace, která má poněkud potenciál na vylepšení.

Nez jsem se zeptal, tak jsem si ty handlery zbezne prosel. Proto to povazuji za mozny zpusob, ktery ale neresi "rozkrajeni" vetsi kolekce na mensi celky, ktere by slo spravovat separatne.

V jednom drivejsim prispevku (MicroStream used as a search server) jste odpovidal, ze by se search dal implementovat pres Microstream. Odvozoval jsem od toho, ze jiz s velkymi kolekcemi je nejaka zkusenost. Napriklad, ze bude existovat vhodnejsi implementace pro transparentni pouziti, vhodnejsi pro uziti s Microstream.

> V androidu, kde na mobilním zařízení nepředpokládám ukládání milionů dat...
Tam to bude OK, ale hodila by se serverova technologie, kde jsou instance objektu prolinkovany do jednoho velkeho spojiteho grafu, ktery je omezeny pouze velikosti pameti.

> na ukládání těchto rozsáhlých kolekcí není Microstream ta nejlepší volba.
Skoda, ze je to uzavrena technologie. Myslim, ze by se to dalo resit.

Kazdopadne dekuji za odpoved a budu se tesit na dalsi clanek.

Teď Vám už lépe rozumím. Rozsekání řešitelné je už nyní, na to existuje přímo podpora.

Pokud si uděláte object, kde budete mít List<Lazy<List<T>>> tak můžete tu kolekci rozsekat na části a ty načítat podle potřeby z paměti. Můžete tam použít například Map<someKey, Lazy<List<T>>> a načíst si přímo tu část, kterou budete potřebovat a s tou pracovat. Pak nebudete omezen velikostí paměti a ty data si načtete podle potřeby a ty můžete následně ihned uvolnit.
Lazy můžete použít kdekoliv a s tím by se asi váš problém dal řešit.

Pochopil jsem to správně?