Hikaye gerçek bir kurumsal senaryodan: 1,7 milyar satırlık bir Oracle veri seti, aynı sorgu, uçtan uca ölçüm. Üreticinin kendi BI aracı raporu yaklaşık 4 saatte render etti. Clixer aynı veriyi 2,00 saniyede ekrana getirdi. 14.400 saniyenin 2 saniyeye inmesi 7.200 kat fark demektir ve bu fark bir ayar inceliğinden değil, mimari tercihten gelir.
Klasik BI araçları iki yoldan birini seçer: ya sorguyu genel amaçlı veritabanına gönderip bekler, ya da veriyi belleğe sıkıştırmaya çalışır. İki yol da küçük veride çalışır, büyük veride tıkanır. Analitik sorgular için tasarlanmış kolonar bir motor ise veriyi sütun bazında okur, yalnızca gereken kolonlara dokunur ve önbellek katmanıyla tekrarlanan sorulara anında cevap verir.
Beklemenin görünmeyen bir bütçesi vardır. On saniyelik bir bekleme masum görünür; ama günde elli sorgu yapan bir analiz ekibinde bu, kişi başına günlük sekiz dakikadır. Daha kötüsü davranışsal etkidir: bekleten dashboard açılmayan dashboard olur, ekip Excel'e geri döner ve analitik yatırımı sessizce boşa çıkar.
Ölçek büyüdükçe makas açılır. Veri 100 kat büyüdüğünde bekleme 100 kat artıyorsa mimari yanlıştır. Doğru mimaride küçük veride milisaniye olan fark, milyar satır sınıfında saniyeler ile saatler arasındaki farka dönüşür. Bugün 10 milyon satırla rahat eden bir kurulumun üç yıl sonra nerede olacağını bugünden sormak gerekir.
Bir diğer kritik nokta kaynak sistemin sağlığıdır. Raporlama, operasyonun çalıştığı Oracle'ı yormamalıdır. Doğru desen veriyi analitik motora kopyalamak ve tüm raporlama yükünü orada taşımaktır: ERP'niz siparişleri işlemeye devam eder, kokpitler kendi motorundan beslenir.
Satın alma sürecindeyseniz önerimiz basit: broşürdeki rakama değil, kendi verinizle uçtan uca ölçüme bakın. Demoda kronometreyi siz tutun; sorgu artı render toplam süresini ölçün. Hız, sonradan eklenebilen bir özellik değildir; ilk günden mimariye konulan bir karardır.