Her kullanıcının sık sık 10 ila 300 saniye boyunca bir tabloya kayıt aldığı bir modül oluşturuyorum.

Süre dolduğunda bir kayıt silinir. Durum: çok sayıda kullanıcı olacak ve kayıtlar çok sık değişecek - bu uygulamanın bu tablodaki performansını nasıl etkileyecek, çünkü kayıtlar gerçekten sık değişecek ve mysql'in bununla iyi olup olmadığını merak ediyorum? Dizinler gelip gider gibi, bu tablo için veriler 200 kez / saniye gibi değişir. Belki bu tür bir iş için kötü bir çözüm seçiyorum. Herhangi bir öneri ?

Teşekkür ederim!

Dikkate alınması gereken bir şey, MySQL'in ana depolama motorları için tamponları nasıl kullandığıdır: InnoDB ve MyISAM .

Bellekte saklanan şey bu depolama motorları arasında büyük farklılıklar gösterir.

InnoDB hem veri hem de dizin sayfalarını önbelleğe alır. Bunlar, innodb_buffer_pool_size boyutundaki InnoDB Buffer Pool'a yüklenir .

MyISAM yalnızca dizin sayfalarını önbelleğe alır ve key_buffer_size boyutunda olan Anahtar Önbelleğe (Anahtar Arabelleği) yüklenir .

InnoDB Arabellek Havuzu ve MyISAM Anahtar Önbelleğini doğru şekilde boyutlandırmak için diskte kullanılan veri ve dizin boyutlarını almak için information_schema.tables kullanmalısınız .

Ne kadar veriye sahip olduğunuza ve ne kadar zaman ayıracağınıza bağlı olarak, önbellekleri aşağıdaki gibi ısıtabilirsiniz:

Her masa için

• her bir indekse git NDX
• her bir dizin için NDX
  • SEÇ çalıştırmak en az bir kolon indekslenmeyen, Ndx her sütun TABLET tabletten

Bunu yaparak, her verinin ve dizin sayfasının en az bir kez okunacağını garanti edersiniz. Önbellekte oturacaklar. Bu kavram kısmen ve prensip olarak Percona tarafından uygulanmaktadır . Percona bu konsepti mk-slave-prefetch'e dönüştürdü . Bu programın yaptığı

• içinde SQL işleyen köle öncesinde bir slave üzerindeki röle günlüklerini okuyun
• röle günlüğünden bir SQL deyimi alın ve dizin seçimi için bir kılavuz olarak WHERE, GROUP BY ve ORDER BY yan tümcelerini kullanarak bir SELECT'e dönüştürün
• dönüştürülmüş SQL'den gelen SELECT deyimini yürütün

Bu, slave'i SQL'in hızlı bir şekilde işlemesi için slave tarafından ihtiyaç duyulan verilerin% 99,99'una sahip olmaya zorlar. Bu aynı zamanda, köle manuel olarak yük devretmeniz ve önbelleğe BAŞLADIĞINIZ ÜSTÜNCÜ ADI OLARAK SADECE SADECE BİR ÜLKEYE tanıtımınız için hazırlanan köleyi hazırlar.

SONUÇ

Önbellekleri hazır, istekli ve ağır INSERTS, UPDATE'ler ve DELETE'lerin bulunduğu bir ortamda kullanabileceğiniz hiçbir şey yoktur.

Bir şans ver !!!

UYARI

Memcached gibi ürünlerin doğumuyla, bazıları MySQL'in uygun ayarını yapma ihtiyacından uzaklaştı. Ancak, birçok site, geliştiricilerin hızlı bir şekilde memcached ile gördüğü gibi verilerin önbellekleme davranışını kontrol ederek sağlanan veri alımındaki artıştan yararlanmaktadır. Diğer birçok site, sadece depolama motorlarını değiştirerek veya MySQL'i doğru şekilde yapılandırarak aynı performans avantajlarını elde etti. Veritabanından vazgeçmeden ve kesinlikle bir veri havuzu olarak kullanmadan önce veri tabanınızdan en iyi şekilde yararlanın. Durum tespiti takip edin ve MySQL'in sizin için ne yapacağına şaşırabilirsiniz.

Bu kötü bir çözüm olsaydı birçok şeye bağlı olurdu. Bu verinin kalıcı olması gerekiyor mu? Aksi takdirde, bu verileri bellekte tutan bir çözüm daha iyi çalışır.

"Çok sayıda kullanıcı" gerçekten kimseye yardım etmiyor. "Çok" birkaç yüzlerce anlamına gelirse MySQL büyük olasılıkla iyi olacaktır. (Veritabanınızın başka ne işleyeceğine bağlı olsa da, birkaç bin büyük olasılıkla da çalışmalıdır.)

Sonuçta, bu kayıtları birkaç saniye ila dakika sonra kalmak veya silmek için yazarsanız, o kadar önemli değil. Silme işlemi bir işlemden iki işlem yapar. Ve MySQL, çok büyük miktarda kayıt oluşturma ve silme işini kesinlikle yapabilir. Bu kayıtları silmek üzere tekrar bulmak için basit bir dizin kullandığınızdan emin olun.

Ancak gerçek sayılar ve veritabanı sunucunuzun kullandığı donanım hakkında bazı bilgiler olmadan, bu çok hassas bir şekilde cevaplanamaz.

En iyi şey, çok fazla gerçek işlem yapmadan alacağınızı düşündüğünüz yük miktarını simüle eden küçük bir uygulama yazmak olacaktır, sadece sunucuya çok fazla kayıt bırakın, silin, aynı hızda bazı sorgular çalıştırın programınızın geri kalanı oluşturur. Sunucunuza bir göz atın ve herhangi bir şekilde etkilenip etkilenmediğini görün.

Emin değilim, ancak MySQL için bir tabloyu tamamen bellekte önbelleğe almasına izin verecek seçenekler vardır. Ancak gerçekten çok fazla sayıda kullanıcı ve kayıttan bahsediyorsanız, özel gereksinimleriniz için önbelleği optimize etmek için birkaç parametreyi değiştirebilirsiniz.

İşte çılgın bir fikir. Varsayımları ve her zaman tavsiye edilmeyen uygulamaları içerir (bir anahtarın güncellenmesi gibi) - Bunu önermek için çok sayıda olumsuzluk alacağım ama işte burada ...

Çok yüksek satır ve yüksek silme sayısına sahip olduğunuzu varsayarsak, tablonuzda 2 bölüm oluşturarak silme performansını artırabilirsiniz. Bölümler, anahtarın ilk basamağına göre farklılık gösterir. Misal:

Anahtar değeri 1123234441 etkin satırlar ve anahtar değeri içindir: 9123234441 etkin olmayan satırlar içindir (bu örnekteki ilk basamak aşağıdaki gibi kullanılır: 1 = etkin, 9 = etkin değil).

Kullanıcı bir satırı sildiğinde, satırı fiziksel olarak silmezsiniz, anahtarı güncellersiniz (Ouch!), Bu otomatik olarak satırı etkin olmayan satırlar bölümüne taşır.

Tabii ki, sadece aktif bölümden veri okumak için seçimlerinizi kısıtlamanız gerekir. Şimdi havalı kısım, inaktif satırlar bölümünü düşürmenin son derece hızlı olmasıdır.

Daha önce söylediğim gibi, sadece 1 tablonuz varsa bu işe yarar. Bunu test etmedim, bu yüzden sadece teorik bir yaklaşım ama bölüm düşme hızını deneyimledim ve inanılmaz derecede hızlı.

Seçimlerinizi geliştirmek için, uygun dizine ekleme özelliğini kullanın ve ekleri geliştirmek için satır boyutunu ve dizin sayısını en aza indirin (bu ifade çok geneldir ...)

Referans için bakınız: http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html Umarım bu yardımcı olur.