DBMS mana yang bagus untuk pembacaan super cepat dan struktur data sederhana?

Saya mengembangkan produk yang, sebagai bagian dari operasinya, harus melacak sejumlah besar file / direktori. Idenya adalah untuk menyimpan informasi stat dalam database kemudian, saat boot, buat jam tangan untuk setiap file. File yang berubah akan diantrekan (dalam database) untuk sinkronisasi grup ke database jauh. Mereka akan disinkronkan dalam urutan prioritas, angka antara 1-10.

Informasi tentang basis data:

• <100.000 entri info stat
• Seluruh basis data dibaca saat boot, hanya path file yang diperlukan
• File yang antri akan memiliki bidang prioritas (tidak ada lagi yang perlu dicari oleh)
• Penyisipan bisa lambat

Saya telah menemukan beberapa database yang saya pikir akan berfungsi, tetapi saya tidak yakin mana yang terbaik:

• Redis - menyimpan path file sebagai kunci, data stat sebagai nilai; antrian akan menjadi daftar
• MongoDB - lebih banyak opsi permintaan daripada Redis, tetapi masih cepat

Saya berpikir database NoSQL akan menjadi solusi terbaik di sini, karena tidak ada terlalu banyak logika relasional yang terjadi, dan ukuran total data tidak terlalu besar (sekitar <100 mb, lebih dekat dengan <30 mb). Saya memang melihat SQLite karena tampaknya cukup sederhana untuk menanamkan dalam aplikasi yang dapat diinstal.

Karena ini adalah aplikasi terdistribusi untuk pengguna akhir dan bukan server beban tinggi, database tidak harus mendukung banyak pengguna secara bersamaan. Prioritas utama di sini adalah untuk menemukan database yang modelnya paling masuk akal.

Jadi pertanyaannya, basis data mana yang paling sesuai untuk situasi ini?

Juga, apakah ada database lain yang lebih masuk akal untuk aplikasi seperti ini?

Hal pertama yang terlintas dalam pikiran saya adalah RDBMS tertentu yang saya kenal. Saya menyadari, bagaimanapun, bahwa itu mungkin bukan yang terbaik untuk aplikasi ini.

Jadi, saran saya adalah untuk pergi dengan database yang Anda kenal. Jika Anda terbiasa dengan Redis atau MongoDB, maka gunakan salah satunya. Jika Anda lebih terbiasa dengan SQLite, maka pilih itu.

Pada database sebesar ini, semuanya akan cukup cepat. Bahkan database yang lebih berat disk akan menggunakan semacam caching sehingga kecepatan disk tidak terlalu menjadi perhatian.

Jika Anda tidak terlalu peduli dengan logika relasional, ingin kecepatan baca yang sangat cepat, dan Anda bersedia bekerja dengan RDBMS, saya akan berani mengatakan MySQL. Kenapa ???

Mesin penyimpanan MyISAM memiliki opsi yang dapat memungkinkan struktur fisik tabel diperbesar untuk kinerja yang lebih baik. Pilihan apa itu? Opsi ALTER TABLE ROW_FORMAT.

Misalnya, buku yang direkomendasikan oleh Desain dan Tuning Basis Data MySQL menggunakan ROW_FORMAT = TETAP pada halaman 72,73. Ini akan secara internal mengonversi semua bidang VARCHAR ke CHAR. Ini akan membuat tabel MyISAM lebih besar, tetapi mengeksekusi SELECTs terhadapnya akan jauh lebih cepat. Saya pribadi bisa membuktikan hal ini. Saya pernah punya meja yang 1.9GB. Saya mengubah format dengan ALTER TABLE tblname ROW_FORMAT = TETAP. Tabel berakhir 3.7GB. Kecepatan SELECT terhadap itu adalah 20-25% lebih cepat tanpa memperbaiki atau mengubah apa pun.

Bagaimana jika Anda sudah memiliki tabel MyISAM yang diisi dengan data? Anda bisa mendapatkan metrik untuk definisi kolom yang disarankan berdasarkan data yang ada di tabel MyISAM. Kueri apa yang menyajikan metrik itu?

SELECT * FROM tblname PROCEDURE ANALYSE();

PROSEDUR ANALISIS () Ini tidak akan menampilkan data. Ini akan membaca nilai setiap kolom dan merekomendasikan definisi kolom. Contoh, jika Anda memiliki kolom tipe yang nilainya 1-4, itu akan lebih baik menggunakan ENUM dari 4 nilai tersebut. Anda kemudian dapat memilih untuk menggunakan TINYINT atau CHAR (1) karena mereka mengambil jumlah ruang yang sama (1 byte).

Berikut adalah hal lain yang perlu dipertimbangkan: Karena Anda berpikir tentang menggunakan DB NoSQL, apakah Anda pernah berpikir untuk menggunakan MyISAM dengan cara NoSQL? Ini sangat mungkin. Halaman 175 dari buku yang sama yang saya sebutkan menyarankan menggunakan struktur HANDLER untuk membaca tabel tanpa bagasi relasional . Faktanya, halaman 175 memberikan contoh ini:

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;

Tabel ini berisi jutaan baris. Misalkan Anda perlu membuat aplikasi analisis data yang memiliki persyaratan berikut:

• Perlu mengambil blok informasi secepat mungkin.
• Berdasarkan input pengguna atau faktor lain, kemungkinan akan "melompat-lompat" di tabel.
• Itu tidak berkaitan dengan konkurensi atau masalah integritas data lainnya.
• Penguncian tabel lintas-aplikasi tidak diperlukan.

Perintah-perintah ini memungkinkan pembacaan cepat dan kotor dari tabel:

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;

Saya harap ini memberi makanan untuk dipikirkan. Silakan melihatnya.

CAVEAT

Apa yang sangat ironis tentang saya menulis posting khusus ini adalah bahwa saya menulis posting sebelumnya tentang HANDLER yang digunakan dalam biner Percona Server dan berpikir bahwa menggunakannya adalah ketinggalan zaman . Sejak posting yang lebih tua itu, saya tidak pernah berpikir saya akan pernah menulis sesuatu untuk mendukung struktur HANDLER. Saya sekarang berdiri dikoreksi.