Daha uygulamanızın başındasınız derken, daha başlamamışsınız ihtiyacınıza uygunsa redis öneriyorlar kodlarınızı değiştirmek zorunda kalmayacaksınız noktasını vurgulamak istemiştim, sonradan ihtiyacım aslında buymuş diyip kodları değiştirmek de vardı.

Sorunuza gelecek olursak, eğer milyonlarca kayıttan söz ediyorsak onu genelde bir çok uygulama şu şekilde çözüyor, ihtiyaç kadarı cache'leniyor. Mesela tablomuzda 2 milyon kayıt var ancak kaç tanesine dönüp bakacağız, işlemler tablosu dediniz mesela, bu işlemleri kullanıcı işlemleri varsayalım, işte şu kaydı açtı, şu içeriği güncelledi gibi, bunları açıp bakan kişi 2 milyon kayıt varsa bunu en alta kadar bir anda inip bakamaz zaten, çok kayıtlı tabloları 20,30, 50, 100,200'er olarak listele opsiyonu koyuluyor bir çok yerde, biz de istersek uygulamamıza bir servis bağlarız, islemler tablosunun son 100 kaydını cachele yaparız, ya da kullanıcı isteği olduğunda yaparız bunu. Örnek olarak, 20'şer olarak listeliyoruz diyelim kaydı, kullanıcı işlemler sayfasına girdiğinde ilk 60 kaydı listeler ve cache'leriz, 20li olarak listelediğimizden ilk 3 sayfamız cache'lenmiş olur, kullanıcı 2. sayfaya tıkladığında cache'den gelecek kayıtlar, 3. sayfada da sonraki 60 kaydı çağırırız mesela, 3. sayfaya ilk cache'lediğimiz 60 kaydın son 20 kayıt cache'den gelir yine hızlı bir şekilde, o kayıtlar incelenirken sonraki 60 kayıt hazır olmuş olur.

Genelde cache kısmı uygulama yazıldıktan sonraya bırakıyorum ben, çünkü daha belli oluyor, uygulamayı kullanırken hızı neler arttırıyor onu görüyorum, verdiğim örnekdeki gibi mesela uygulama kullanılırlığını neler arttıracak onlara odaklanıp, hangi bölüm sunucumun belleğini, işlemcisini, veritabanını ne kadar yoruyor, nerelerde cache'leme yaparsam daha hızlı çalışır, hangi tabloları direk veritabanından index'leme yaparsam verimli olur vs gibi.



Bu arada, verdiğim örnekdeki saydırma işlemi yerine veritabanlarındaki Triggers (Tedikleyiciler) özelliğini ya da son id numarasına baz alabilirsin, böylelikle tüm satırları saydırmana gerek kalmaz.