9 milyon fazla veri ve database yavaşlığı

Question

Merhaba 9 milyon dan fazla veri tutan bir mariadb tablomun sütünü var ve buradaki yavaşlık ve veri boyutu bir çok sistemini yavaşlatıyor sizce nasıl bir önlem almalıyız tasviyeler için teşekkür ederim

Etkilenen kısımlar

Veri görüntüleme kısmı
Gerekli veriye  ait ayarlar kısmı
Ana panel kısmı

Ram CPU vs birçok donanım artırıyoruz sürekli şekilde

Özellikle API tarafın hariç bir çok kısım hantal kalıyor

wontew · Answer

WhatsApp ile iletişime geçmek için Tıkla.

3 milyonluk işletme verisi tutuyorum bir sorun yaşamıyorum detay verirseniz yardımcı olurum ücretsiz şekilde

aqu · Answer

büyük veri yönetiminden anlayan hocalarım whatsapp üzerinden benimle de iletişime geçerse çok sevinirim yardım almak istediğim bazı konu ve alanlar var Whatsapp

koksalkesici · Answer

wontew adlı üyeden alıntı:						mesajı görüntüle									WhatsApp ile iletişime geçmek için Tıkla.

3 milyonluk işletme verisi tutuyorum bir sorun yaşamıyorum detay verirseniz yardımcı olurum ücretsiz şekilde 		Hocam kusura bakma detay vermeyi unutmuşum çok AKTİF bır tablo hem veri yazılıp siliniyor (200-500/s ) ortlama işlem gerçekleşiyor ve aynı anda sorgular da oluyor

wontew · Answer

koksalkesici adlı üyeden alıntı:						mesajı görüntüle									Hocam kusura bakma detay vermeyi unutmuşum çok AKTİF bır tablo hem veri yazılıp siliniyor (200-500/s ) ortlama işlem gerçekleşiyor ve aynı anda sorgular da oluyor 		WhatsApp dan yazarsanız yardımcı olurum hocam

ByCaner · Answer

https://youtu.be/lLrzoyU4BPc?si=DzvqPxXz2qD7_Vx9
https://youtu.be/O3PwuzCvAjI?si=jHsn-Iy0_ph6Av43

Hocam bu videolarda discord un nasıl bir çözüm bulduğunu anlatıyorlar. Anlık milyonlarca işlem yapıyorlar

sekidov · Answer

Hocam bu konu yüksek ihtimalle sunucu taraflıdır.
Çünkü verdiğiniz bilgilere bakıldığında donanım taraflı eksklik olduğu kanaatindeyim.

NGEEN · Answer

Ö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.

VBuMaSTeR · Answer

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.

koksalkesici · Answer

VBuMaSTeR adlı üyeden alıntı:						mesajı görüntüle									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. 								NGEEN adlı üyeden alıntı:						mesajı görüntüle									Ö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. 								sekidov adlı üyeden alıntı:						mesajı görüntüle									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

salperen · Answer

Hocam selamlar, bence en iyi çözüm no sql bir database e migrate etmeniz. Şuan çalıştığım yerde couchbase kullanıyoruz ve saatte milyarın üzerinde veri yazıyoruz ve doğru scalelerde bir sıkıntı yaşamıyoruz

dev · Answer

koksalkesici adlı üyeden alıntı:						mesajı görüntüle									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 		Sorgunuza gore index olusturun. aylik +30M yeni kayitin geldigi DB'den duzgun bir indexleme ile benzer sorunu cozmustum.