Very elegáns. Megírodik valahogy a lekérdezés, majd viszontlátásra, és utána az üzemeltetés nyakán megy az ugrálás, hogy szaraszerver oldják meg. Jellemzően az történik, hogy sosem gondoltak arra, hogy mondjuk 100k-s nagyságrend fölé mehet a rekordszám, a szervert jellemzően roppant spórolva vették, hiszen milyen sokat is költöttek a fejlesztésre ugye, majd jönnek a problémák. Általában az adatok jeletős része archiválható (nem biztos, hogy 10+ év adatsorával kell bohóckodni, elég az utsó 3..., és a régebbieket külön kezelni stb.), a másik az említett index használat (részleges) hiánya és remekbeszabott lekérdezések összehozása. Természetesen a világ összes pénzét el lehet költeni HW-re, nagyon szivesen építek, telepítek, meg adok át ilyesmit, csak nem biztos, hogy ez az adott megrendelőnek tényleg jó..., node ha a fejlesztők ezt igénylik...
Akinek olyan igényei vannak, az lesz szíves az igényekhez rendelni az erőforrásokat, és amikor a szerverbe kell az NVMe SSD, a sok RAM, és sok CPU, akkor nem problémázni.
Ugyanakkor az RBMS-ek lekérdezés optimalizációja körül igen nagy eltérések vannak. Előfordult, hogy ugyanaz PostgreSQL-lel másodpercen belül ment, ami az akkori MySQL-nél bőven sokperces volt. Nyilván az RDBMS csere nem egy hipphopp történet, de a típuson belüli frissítést lehet tesztelni.
Jelen esetben munkaidő adatokról van szó. Vajon mindíg az összes adaton megy a "matek" vagy csak az aktuális hónap 1-től vannak a táblában?
Zárásként még azt tenném hozzá, hogy a fejlesztés egy ideje erős CPU-kon (4GHz+ turbo) és minimum SATA SSD-ken, de már sok esetben NVMe-n megy, mindez lokálisan, minimál késleltetéssel egy SAN-hoz képest. Ezek a konfigok jellemzően sokkal gyorsabbak egyszálon, mint egy értelmesen kifizethető szerver, pláne nagyvállalati. Tessék megnézni a dualsocket CPU-k turbo órajelét, azok jellemzően 3-3,5GHz körül vannak, esetleg elmennek 4GHz-ig, de egy clusterben lévő szervernél nehéz lesz a nettó 1 szálas teljesítményt kicsikarni, mert sok VM fut.