A Table\/Index AM API-ban v\u00e9grehajtand\u00f3 v\u00e1ltoztat\u00e1sokat az OrioleDB kiterjeszt\u00e9s szemsz\u00f6g\u00e9b\u0151l vizsg\u00e1lj\u00e1k, amelyet a PostgreSQL be\u00e9p\u00edtett t\u00e1rol\u00e1si mechanizmus\u00e1nak ismert hi\u00e1nyoss\u00e1gainak kik\u00fcsz\u00f6b\u00f6l\u00e9s\u00e9re fejlesztettek ki. A probl\u00e9ma az, hogy az OrioleDB teljes integr\u00e1ci\u00f3j\u00e1hoz a PostgreSQL k\u00f3dj\u00e1ban m\u00f3dos\u00edt\u00e1sokat kell v\u00e9gezni, ami bonyol\u00edtja a projekt bevezet\u00e9s\u00e9t, \u00e9s hangs\u00falyozza a jelenlegi Table AM API korszer\u0171s\u00edt\u00e9s\u00e9nek sz\u00fcks\u00e9gess\u00e9g\u00e9t. <\/p>\n
A Table AM API nem k\u00e9nyszer\u00edt k\u00f6zvetlen\u00fcl MVCC megval\u00f3s\u00edt\u00e1si m\u00f3dot. M\u00e9gis, a Table AM \u00e9s Index AM API az al\u00e1bbi feltev\u00e9st teszi: minden TID (Tuple\/row Identifier) vagy minden index \u00e1ltal index\u00e1lva van, vagy egy\u00e1ltal\u00e1n nem index\u00e1lva. M\u00e9g ha az Index AM t\u00f6bb hivatkoz\u00e1st is tartalmaz egy TID-re (p\u00e9ld\u00e1ul GIN), akkor az \u00f6sszes hivatkoz\u00e1snak ugyanarra az index\u00e1lt \u00e9rt\u00e9kre kell vonatkoznia.
![\"Az](\"\/wp-content\/uploads\/2025\/04\/a2082618f49d887e6987a73c65091c59.png\")
<\/center> <\/p>\nEzt az elvet kritiz\u00e1lt\u00e1k a write amplification n\u00f6veked\u00e9se miatt \u2014 ha egy indexelt attrib\u00fatum friss\u00fcl, akkor a t\u00e1bl\u00e1zat minden index\u00e9t friss\u00edteni kell. Ahhoz, hogy teljes m\u00e9rt\u00e9kben kihaszn\u00e1lhassuk az UNDO napl\u00f3 el\u0151nyeit, vagy m\u00e1s t\u00e1rol\u00e1si m\u00f3dszert kell kialak\u00edtani write amplification n\u00e9lk\u00fcl (p\u00e9ld\u00e1ul a WARM m\u00f3dszert), ezt a feltev\u00e9st meg kell bontani.
![\"Az](\"\/wp-content\/uploads\/2025\/04\/da5adbec63e0b4c139733c5775b317b9.png\")
<\/center> <\/p>\nAz UNDO-ra alapozott Table AM, amely nem s\u00e9rti ezt a felt\u00e9telez\u00e9st, hasonl\u00edt a megl\u00e9v\u0151 HOT (Heap-Only Tuples) m\u00f3dszerhez, kiv\u00e9ve, hogy a r\u00e9gi sorverzi\u00f3k az UNDO napl\u00f3ban t\u00e1rol\u00f3dnak, \u00e9s nem kell, hogy ugyanabban az oldalon legyenek. Az \u00edr\u00f3k v\u00e9lem\u00e9nye szerint azonban ez az el\u0151ny nem elegend\u0151 ahhoz, hogy indokolja a k\u00fcl\u00f6n Table AM l\u00e9tez\u00e9s\u00e9t. <\/p>\n
A megl\u00e9v\u0151 API gyakorlati korl\u00e1tai: <\/p>\n
- \n
- A t\u00e1bl\u00e1zat sor\u00e1nak friss\u00edt\u00e9sekor az indexek az '\u00f6sszes vagy semmi' elve szerint friss\u00fclnek.\n
- Az API Index AM nem ny\u00fajt lehet\u0151s\u00e9get bizonyos tuple-\u00f6k pontszer\u0171 t\u00f6rl\u00e9s\u00e9re. Jelenleg t\u00f6megesen lehet t\u00f6r\u00f6lni a tuple-\u00f6ket az indexekb\u0151l az ambulkdelete \u00e9s az amvacuumcleanup m\u00f3dszerek seg\u00edts\u00e9g\u00e9vel. A pontszer\u0171 t\u00f6rl\u00e9s megval\u00f3s\u00edt\u00e1sa ezen az API-n kereszt\u00fcl alacsony hat\u00e9konys\u00e1ghoz vezetne, mivel a jelenlegi implement\u00e1ci\u00f3k t\u00f6bbs\u00e9ge az eg\u00e9sz indexet \u00e1t kell, hogy szkennelje. Ezenk\u00edv\u00fcl az API nem teszi lehet\u0151v\u00e9, hogy megadjuk, mely tuple-\u00f6ket kell t\u00f6r\u00f6lni, amelyek ugyanarra TID-re hivatkoznak. Csak az \u00f6sszeset t\u00f6r\u00f6lheti.\n
- Jelenleg az indexek a t\u00e1bl\u00e1zat soraira blokk sz\u00e1m (32 bit) \u00e9s eltol\u00e1si sz\u00e1m (16 bit) alapj\u00e1n hivatkoznak. Csak 11 bit eltol\u00e1si sz\u00e1mot lehet biztons\u00e1gosan \u00e1tadni a t\u00e1bl\u00e1zat TID-j\u00e9b\u0151l az indexhozz\u00e1f\u00e9r\u00e9si m\u00f3dszerekhez. Ezenk\u00edv\u00fcl a MVCC alternat\u00edv megval\u00f3s\u00edt\u00e1soknak sz\u00fcks\u00e9g\u00fck lehet arra, hogy plusz hasznos terhel\u00e9st (payload) t\u00e1roljanak a TID mellett. P\u00e9ld\u00e1ul az OrioleDB-nek egy vagy t\u00f6bb bitre van sz\u00fcks\u00e9ge az 'delete-marking' indexek vagy a l\u00e1that\u00f3s\u00e1g teljes inform\u00e1ci\u00f3j\u00e1nak megval\u00f3s\u00edt\u00e1s\u00e1hoz. <\/ul>\n
K\u00e9t m\u00f3dot javasoltak a korl\u00e1tok gyakorlati t\u00fall\u00e9p\u00e9s\u00e9re: <\/p>\n
- \n
1. megk\u00f6zel\u00edt\u00e9s: Az API Index AM lehet\u0151s\u00e9geket biztos\u00edt az alternat\u00edv MVCC megval\u00f3s\u00edt\u00e1s\u00e1ra. <\/p>\n
M\u00edg a Table AM tov\u00e1bbra is felel\u0151s az \u00f6sszes MVCC komponens\u00e9rt, az Index AM biztos\u00edtja a sz\u00fcks\u00e9ges lehet\u0151s\u00e9geket a MVCC alternat\u00edv megval\u00f3s\u00edt\u00e1s\u00e1hoz, nevezetesen: a felhaszn\u00e1l\u00f3i hasznos terhel\u00e9s (payload) TID-vel val\u00f3 t\u00e1rol\u00e1sa, a pontszer\u0171 t\u00f6rl\u00e9s m\u00f3dszere, \u00e9s ak\u00e1r a pontszer\u0171 friss\u00edt\u00e9s m\u00f3dszere (ha a TID-t nem lehet megv\u00e1ltoztatni az indexben, a felhaszn\u00e1l\u00f3i hasznos terhel\u00e9s v\u00e1ltoztathat\u00f3). Ezen k\u00edv\u00fcl, mivel enged\u00e9lyezni kell, hogy t\u00f6bb index tuple egyazon TID-hez hivatkozhasson, az indexszkennel\u00e9s sor\u00e1n alkalmazott API m\u00f3dszereket is friss\u00edteni kell. <\/p>\n
2. megk\u00f6zel\u00edt\u00e9s: MVCC-t t\u00e1mogat\u00f3 indexek. <\/p>\n
Alternat\u00edv megold\u00e1s lenne, ha enged\u00e9lyezn\u00e9nk az MVCC-t t\u00e1mogat\u00f3 indexeket. Vagyis az 'executor' (vagy esetleg a Table AM) egyszer\u0171en h\u00edvja az insert() \u00e9s delete() m\u00f3dszereket az Index AM-ben, m\u00edg az Index AM MVCC-vel \u00f6sszhangban biztos\u00edtja a szkennel\u00e9s lehet\u0151s\u00e9g\u00e9t. Ez jelent\u0151sen egyszer\u0171s\u00edten\u00e9 az indexek haszn\u00e1lat\u00e1val t\u00f6rt\u00e9n\u0151 szkennel\u00e9st (index-only). M\u00e9g a teljes Table AM is k\u00f6zbens\u0151 r\u00e9tegg\u00e9 v\u00e1lhatna, amely az indexben t\u00e1rolja az adatokat. <\/p>\n
Az al\u00e1bbi diagramon l\u00e1that\u00f3 egy p\u00e9lda. A 2-es index \u00e9rt\u00e9ke a 11-es tranzakci\u00f3 \u00e1ltal friss\u00fcl az «A» \u00e9rt\u00e9kr\u0151l az «B» \u00e9rt\u00e9kre. Ez\u00e9rt az «A» \u00e9rt\u00e9ket xmax == 11-k\u00e9nt jel\u00f6lj\u00fck, m\u00edg a «B» \u00e9rt\u00e9ket xmin == 11-k\u00e9nt. \u00cdgy a 2-es indexet szkennelve csak a MVCC szerint l\u00e1that\u00f3 tuple-okat kaphatunk, heap ellen\u0151rz\u00e9sek n\u00e9lk\u00fcl. A 2-es index szem\u00e9tgy\u0171jt\u00e9se szint\u00e9n elv\u00e9gezhet\u0151 heap haszn\u00e1lata n\u00e9lk\u00fcl.
![\"Az](\"\/wp-content\/uploads\/2025\/04\/9103127cc51f83c824c6cdc22135b470.png\")
<\/center> <\/p>\nA fent eml\u00edtett \u00faj\u00edt\u00e1sok implement\u00e1l\u00e1s\u00e1n\u00e1l az indexel\u00e9si met\u00f3dusok API-j\u00e1ban val\u00f3sz\u00edn\u0171tlen, hogy egyszerre siker\u00fclne az \u00f6sszes indexet m\u00f3dos\u00edtani az \u00faj funkci\u00f3k t\u00e1mogat\u00e1s\u00e1ra. Realist\u00e1bb lenne, ha t\u00f6bb megval\u00f3s\u00edt\u00e1s is enged\u00e9lyezve lenne egy indexel\u00e9si met\u00f3dus sz\u00e1m\u00e1ra. P\u00e9ld\u00e1ul a hagyom\u00e1nyos B-fa mellett a kiterjeszt\u00e9s megval\u00f3s\u00edthat egy alternat\u00edv B-f\u00e1t, amely t\u00e1mogatja az MVCC-t az indexen bel\u00fcl, \u00e9s kezeli az \u00f6nk\u00e9nyes hossz\u00fas\u00e1g\u00fa rekordazonos\u00edt\u00f3kat.
![\"Az](\"\/wp-content\/uploads\/2025\/04\/57e1c15ecdd08f7b8095f464b59523b9.png\")
<\/center> <\/p>\n