Hangi DBMS süper hızlı okumalar ve basit bir veri yapısı için iyidir?

Çalışmasının bir parçası olarak çok sayıda dosya / dizini izlemesi gereken bir ürün geliştiriyorum. Fikir, istatistik bilgilerini bir veritabanında saklamak ve ardından önyüklemede her dosya için saatler oluşturmaktır. Değişen dosyalar, uzak veritabanıyla grup eşitlemesi için sıralanır (veritabanında). Öncelik sırasına göre, 1-10 arasında bir sayı ile senkronize edilecektir.

Veritabanı hakkında bilgi:

• <100.000 istatistik bilgisi girişi
• Tüm veritabanı önyükleme sırasında okundu, sadece dosya yolu gerekli
• Kuyruktaki dosyaların öncelik alanı olacaktır (başka bir şeyin aranması gerekmez)
• Eklemeler yavaş olabilir

Çalışacağını düşündüğüm birkaç veritabanı buldum, ancak hangisinin en iyi olacağından emin değilim:

• Redis - dosya yolunu anahtar olarak, istatistik verilerini değer olarak depola; sıra bir liste olurdu
• MongoDB - Redis'den daha fazla sorgu seçeneği, ancak yine de hızlı

Ben çok fazla ilişkisel mantık oluyor ve toplam veri boyutu çok büyük değil (<100 mb, <30 mb daha yakın) gibi bir NoSQL veritabanı burada en iyi çözüm olacağını düşünüyorum. SQLite'a baktım çünkü yüklenebilir bir uygulamaya gömmek için yeterince basit görünüyor.

Bu, yüksek yüklenen bir sunucu değil son kullanıcılar için dağıtılmış bir uygulama olduğundan, veritabanının birçok eşzamanlı kullanıcıyı desteklemesi gerekmez. Buradaki temel öncelik, modeli en mantıklı olan bir veritabanı bulmaktır.

Peki bu durum için en uygun veritabanı hangisidir?

Ayrıca, böyle bir uygulama için daha anlamlı olabilecek başka veritabanları var mı?

Akla gelen ilk şey, bana tanıdık gelen belirli bir RDBMS'dir. Ancak, bu uygulama için en iyi olmayabilir.

Benim tavsiyem, size tanıdık gelen bir veritabanına gitmektir. Redis veya MongoDB hakkında bilginiz varsa, bunlardan biriyle devam edin. SQLite hakkında daha fazla bilginiz varsa, bunu seçin.

Bu boyutta bir veritabanında, hepsi oldukça hızlı olacak. Daha fazla disk ağırlıklı veritabanları bile bir tür önbellek kullanır, böylece disk hızı çok fazla endişe kaynağı olmaz.

İlişkisel mantıkla ilgili değilseniz, gerçekten hızlı okuma hızı istiyorsanız ve bir RDBMS ile çalışmaya hazırsanız, önyargılı olarak MySQL demeye teşebbüs ederim. Neden ???

MyISAM depolama motoru, daha iyi performans için tablonun fiziksel yapısının artırılmasına olanak tanıyan bir seçeneğe sahiptir. Bu seçenek nedir? ALTER TABLE seçeneği ROW_FORMAT.

Örneğin, MySQL Veritabanı Tasarımı ve Ayarlama kitabı 72,73. Sayfalarda ROW_FORMAT = FIXED kullanılmasını önerir. Bu, tüm VARCHAR alanlarını dahili olarak CHAR'a dönüştürecektir. MyISAM tablosunu büyütür, ancak buna karşı yürütülen SELECT'ler çok daha hızlı olur. Ben şahsen bunu kanıtlayabilirim. Bir zamanlar 1.9GB'lık bir masa vardı. Biçimi ALTER TABLE ile değiştirdim tblname ROW_FORMAT = FIXED. Masa 3,7GB oldu. SELECT'lerin buna karşı hızı, başka bir şey geliştirmeden veya değiştirmeden% 20-25 daha hızlıydı.

Veriler içeren bir MyISAM tablonuz zaten varsa ne olur? MyISAM tablosunda bulunan verilere dayanarak önerilen sütun tanımları için metrikler alabilirsiniz. Hangi metrikler bu metrikleri sunar?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROSEDÜR ANALİZİ () Bu veriler gösterilmez. Her sütunun değerini okuyacak ve sütun tanımlarını önerecektir. Örneğin, değerleri 1-4 olan bir tür sütununuz varsa, bu 4 değerin ENUM'unu kullanarak önerilebilir. Daha sonra aynı miktarda yer kapladıkları için (1 bayt) TINYINT veya CHAR (1) kullanmayı seçebilirsiniz.

Dikkate alınması gereken başka bir şey var: NoSQL DB kullanmayı düşündüğünüzden, MyISAM'ı NoSQL tarzında kullanmayı hiç düşündünüz mü? Bu oldukça mümkün. Bahsettiğim aynı kitabın 175. sayfasında ilişkisel bagaj olmadan bir tablo okumak için HANDLER yapılarının kullanılması önerilmektedir . Aslında, sayfa 175 bu örneği vermektedir:

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

Bu tablo milyonlarca satır içeriyor. Aşağıdaki gereksinimleri içeren bir veri analizi uygulaması oluşturmanız gerektiğini varsayalım:

• Bilgi bloklarını olabildiğince çabuk alması gerekir.
• Kullanıcı girdisine veya diğer faktörlere bağlı olarak, büyük olasılıkla tabloda "atlama" olacaktır.
• Eşzamanlılık veya diğer veri bütünlüğü sorunlarıyla ilgilenmez.
• Çapraz uygulama tablasının kilitlenmesi gerekli değildir.

Bu komutlar tablodan hızlı ve kirli okumalara izin verir:

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

Umarım bu düşünce için yiyecek verir. Lütfen içine bakın.

UYARI

Bu yazıyı yazmamla ilgili çok ironik olan şey, HANDLER'in Percona Server ikili dosyalarında kullanılması ve kullanımının güncel olmadığını düşünmesi hakkında daha önce bir yazı yazmamdı . Bu eski görevden bu yana, HANDLER yapılarını destekleyen bir şey yazacağımı hiç düşünmemiştim. Şimdi düzeltilmiş duruyorum.