Penskalaan & Batasan

storh adalah penyimpanan yang mengutamakan file, bukan mesin kueri relasional. Batas praktisnya, dengan angka acuan dari benchmark (50k catatan, Apple M1 Pro):

• Akses langsung pada praktiknya tidak terbatas jika sistem file mampu menangani jumlah file dan koleksi menggunakan sharding berdasarkan UUID karakter terakhir. Pembacaan langsung memerlukan beberapa mikrodetik; penulisan persisten satu catatan dibatasi fsync hingga beberapa ribu per detik.
• Pemindaian log tersegmentasi, pembacaan cursor, dan pembacaan rentang waktu tetap nyaman hingga sekitar 1M catatan jika ukuran segmen dikonfigurasi sesuai beban kerja. Append massal berjalan pada puluhan ribu catatan per detik; pemulihan ekor terpotong memutar ulang ratusan ribu catatan per detik saat dibuka kembali.
• Operasi antrean menambahkan peristiwa ringkas ke satu log persisten, sehingga enqueue, claim, complete, requeue, dan purge terhindar dari perubahan direktori satu file per pekerjaan. Claim dan complete massal meratakan biaya lock dan fsync untuk seluruh batch.
• Pemindaian kolom per file di DocStore melambat setelah sekitar 10k catatan karena setiap pemindaian yang cocok harus menelusuri file satu per satu. Deklarasikan indeks untuk kolom yang Anda gunakan sebagai filter; kueri kesetaraan berindeks menjawab dalam sekitar satu milidetik, berapa pun ukuran koleksinya.
• storh tidak ditujukan untuk kueri relasional ad hoc, join, pemfilteran berat indeks sekunder, atau pemindaian analitis atas banyak kolom. Dorong koleksi ke mirror SQL saat Anda memerlukan pola baca tersebut; simpan sistem pencatatan utama di database sungguhan jika Anda memerlukan transaksi multi-catatan.

Gunakan DocStore jika pembacaan langsung mendominasi, SegmentedLog jika append dan pembacaan berurutan mendominasi, dan Queue untuk distribusi pekerjaan persisten sederhana. Lihat Memilih mesin untuk perbandingan berdampingan.