Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.
Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.
Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.
Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).
Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.
Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.
184 Odpovědí
44389 Zhlédnutí