Doğru bir indexleme yapılırsa 9m veri bir şey değil. Select sorgularınızı hangi kolon veya kolonlara göre where şartı ile çekiyorsanız ona göre indexleme yapmak gerekir.
Öncelikle bu veri büyük veri falan değil. Büyük verinin yanından bile geçmiyor. Sıcak sayılabilecek küçük bir veri kütlesi.
Verinin tasarımı burada büyük öneme sahip. Bu veri seti içinde yapılan her bir select sorgusu sütunların tiplerinden ve index'li olup olmamasından çok etkilenir (bunlar yapıldıysa partitioning'de unutulmamalı). Arama yapılıyorsa ve kriterler çok fazla ise Elasticsearch kullanmanızı önerebilirim.
Aynı zamanda eğer sonuçların değişimi anlık olarak sorun yaratmıyorsa cachelemenizi de şiddetle öneririm. Sonuçta vertiabanı üzerinde yapılan her sorgu bir maliyet doğuracaktır. Sorguları iyileştirmek kadar azaltmakta önemli bir şey.
Son olarak istediğiniz kadar kaynak arttırın ortada bir darboğaz varsa ve bu dar boğaz veritabanı ise ne yazık ki pek işe yaramaz. Emin olmamakla beraber (bu özellik MySQL'de var) master-slave replikasyonunu deneyebilirsiniz. Read için ayrı sunucu, create ve update için ayrı sunucu oluşturup master altında çalışmalarını sağlayabilirsiniz (teorik olarak mariadb'de de çalışmalı).
Bunlar hala çözüm değilse NoSQL veritabanlarını kullanmak için bir plan yapmalısınız.
Hocam bu konu yüksek ihtimalle sunucu taraflıdır.
Çünkü verdiğiniz bilgilere bakıldığında donanım taraflı eksklik olduğu kanaatindeyim.
Merhaba Hocalarım yapıda 6 âdet 4 slave 2 master şeklinde indexleme gerekli kısımlarda abartı şeklinde değil ortalama 9 milyon veri 15+ GB fazla yer kaplıyor donanım tarafında sıkıntımız yok anlık yükseltme ve benzeri işletmeler yapabiliyoruz
