Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri

Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri

Komunitas yang Terhormat, Artikel ini akan fokus pada penyimpanan dan pengambilan ratusan juta file kecil secara efisien. Pada tahap ini, solusi akhir diusulkan untuk sistem file yang kompatibel dengan POSIX dengan dukungan penuh untuk kunci, termasuk kunci cluster, dan bahkan tanpa kruk.

Jadi saya menulis server khusus saya sendiri untuk tujuan ini.
Selama pelaksanaan tugas ini, kami berhasil memecahkan masalah utama, dan pada saat yang sama mencapai penghematan ruang disk dan RAM, yang dikonsumsi tanpa ampun oleh sistem file cluster kami. Sebenarnya, jumlah file sebanyak itu berbahaya bagi sistem file cluster mana pun.

Idenya adalah ini:

Dengan kata sederhana, file kecil diunggah melalui server, disimpan langsung ke dalam arsip, dan juga dibaca darinya, dan file besar ditempatkan berdampingan. Skema: 1 folder = 1 arsip, total kami memiliki beberapa juta arsip dengan file kecil, dan bukan beberapa ratus juta file. Dan semua ini diimplementasikan sepenuhnya, tanpa skrip apa pun atau memasukkan file ke dalam arsip tar/zip.

Saya usahakan singkat saja, mohon maaf sebelumnya jika postingannya panjang.

Semuanya dimulai dengan fakta bahwa saya tidak dapat menemukan server yang cocok di dunia yang dapat menyimpan data yang diterima melalui protokol HTTP langsung ke dalam arsip, tanpa kekurangan yang melekat pada arsip konvensional dan penyimpanan objek. Dan alasan pencarian tersebut adalah cluster Asal dari 10 server yang telah berkembang menjadi skala besar, di mana 250,000,000 file kecil telah terakumulasi, dan tren pertumbuhan tidak akan berhenti.

Bagi yang tidak suka membaca artikel, sedikit dokumentasi lebih mudah:

di sini ΠΈ di sini.

Dan buruh pelabuhan pada saat yang sama, sekarang ada opsi hanya dengan nginx di dalamnya untuk berjaga-jaga:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

Selanjutnya:

Jika terdapat banyak file, diperlukan sumber daya yang besar, dan yang terburuk adalah beberapa di antaranya terbuang percuma. Misalnya, saat menggunakan sistem file berkerumun (dalam hal ini, MooseFS), file, berapa pun ukuran sebenarnya, selalu berukuran setidaknya 64 KB. Artinya, untuk file berukuran 3, 10 atau 30 KB, diperlukan 64 KB pada disk. Jika ada seperempat miliar file, kita kehilangan 2 hingga 10 terabyte. Tidak mungkin membuat file baru tanpa batas waktu, karena MooseFS memiliki batasan: tidak lebih dari 1 miliar dengan satu replika untuk setiap file.

Seiring bertambahnya jumlah file, banyak RAM yang dibutuhkan untuk metadata. Pembuangan metadata dalam jumlah besar yang sering juga berkontribusi terhadap keausan drive SSD.

server wZD. Kami membereskan disk.

Server ditulis dalam Go. Pertama-tama, saya perlu mengurangi jumlah file. Bagaimana cara melakukannya? Karena pengarsipan, tetapi dalam hal ini tanpa kompresi, karena file saya hanyalah gambar yang dikompresi. BoltDB datang untuk menyelamatkan, yang masih harus dihilangkan dari kekurangannya, hal ini tercermin dalam dokumentasi.

Secara total, alih-alih seperempat miliar file, dalam kasus saya, hanya tersisa 10 juta arsip Bolt. Jika saya mempunyai kesempatan untuk mengubah struktur file direktori saat ini, maka akan mungkin untuk menguranginya menjadi sekitar 1 juta file.

Semua file kecil dikemas ke dalam arsip Bolt, yang secara otomatis menerima nama direktori di mana mereka berada, dan semua file besar tetap berada di sebelah arsip; tidak ada gunanya mengemasnya, ini dapat disesuaikan. Yang kecil diarsipkan, yang besar tidak diubah. Server bekerja secara transparan dengan keduanya.

Arsitektur dan fitur server wZD.

Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri

Server beroperasi pada sistem operasi Linux, BSD, Solaris dan OSX. Saya hanya menguji arsitektur AMD64 di Linux, tetapi seharusnya berfungsi untuk ARM64, PPC64, MIPS64.

Fitur utama:

  • multithread;
  • Multiserver, memberikan toleransi kesalahan dan penyeimbangan beban;
  • Transparansi maksimal bagi pengguna atau pengembang;
  • Metode HTTP yang didukung: GET, HEAD, PUT dan DELETE;
  • Kontrol perilaku membaca dan menulis melalui header klien;
  • Dukungan untuk host virtual yang fleksibel;
  • Mendukung integritas data CRC saat menulis/membaca;
  • Buffer semi-dinamis untuk konsumsi memori minimal dan penyetelan kinerja jaringan yang optimal;
  • Pemadatan data yang tertunda;
  • Selain itu, pengarsip multi-utas wZA ditawarkan untuk memigrasi file tanpa menghentikan layanan.

Pengalaman Nyata:

Saya telah mengembangkan dan menguji server dan pengarsip pada data langsung untuk waktu yang cukup lama, sekarang berhasil beroperasi pada cluster yang mencakup 250,000,000 file kecil (gambar) yang terletak di 15,000,000 direktori pada drive SATA terpisah. Sekelompok 10 server adalah server Asal yang dipasang di belakang jaringan CDN. Untuk melayaninya digunakan 2 server Nginx + 2 server wZD.

Bagi mereka yang memutuskan untuk menggunakan server ini, sebaiknya rencanakan struktur direktori, jika memungkinkan, sebelum digunakan. Izinkan saya segera membuat reservasi bahwa server tidak dimaksudkan untuk menjejalkan semuanya ke dalam arsip 1 Bolt.

Pengujian kinerja:

Semakin kecil ukuran file zip, semakin cepat operasi GET dan PUT dilakukan pada file tersebut. Mari kita bandingkan total waktu penulisan klien HTTP dengan file biasa dan arsip Bolt, serta pembacaan. Bekerja dengan file berukuran 32 KB, 256 KB, 1024 KB, 4096 KB dan 32768 KB dibandingkan.

Saat bekerja dengan arsip Bolt, integritas data setiap file diperiksa (CRC digunakan), sebelum perekaman dan juga setelah perekaman, pembacaan dan penghitungan ulang dilakukan dengan cepat, hal ini tentu saja menimbulkan penundaan, tetapi yang utama adalah keamanan data.

Saya melakukan pengujian kinerja pada drive SSD, karena pengujian pada drive SATA tidak menunjukkan perbedaan yang jelas.

Grafik berdasarkan hasil pengujian:

Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri
Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri

Seperti yang Anda lihat, untuk file kecil, perbedaan waktu baca dan tulis antara file yang diarsipkan dan yang tidak diarsipkan adalah kecil.

Kami mendapatkan gambaran yang sangat berbeda saat menguji membaca dan menulis file berukuran 32 MB:

Menyimpan ratusan juta file kecil secara efisien. Solusi yang Dihosting Sendiri

Perbedaan waktu antara membaca file berkisar antara 5-25 ms. Dengan perekaman, keadaan menjadi lebih buruk, perbedaannya sekitar 150 ms. Namun dalam hal ini tidak perlu mengunggah file berukuran besar; tidak ada gunanya melakukan hal tersebut; file tersebut dapat disimpan secara terpisah dari arsip.

*Secara teknis, Anda dapat menggunakan server ini untuk tugas-tugas yang memerlukan NoSQL.

Metode dasar bekerja dengan server wZD:

Memuat file biasa:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

Mengunggah file ke arsip Bolt (jika parameter server fmaxsize, yang menentukan ukuran maksimum file yang dapat dimasukkan ke dalam arsip, tidak terlampaui; jika terlampaui, file akan diunggah seperti biasa di sebelah arsip):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

Mengunduh file (jika ada file dengan nama yang sama di disk dan di arsip, maka saat mengunduh, prioritas diberikan secara default ke file yang tidak diarsipkan):

curl -o test.jpg http://localhost/test/test.jpg

Mengunduh file dari arsip Bolt (dipaksa):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

Deskripsi metode lain ada di dokumentasi.

Dokumentasi wZD
Dokumentasi wZA

Server saat ini hanya mendukung protokol HTTP; belum berfungsi dengan HTTPS. Metode POST juga tidak didukung (belum diputuskan perlu atau tidak).

Siapa pun yang menggali kode sumber akan menemukan butterscotch di sana, tidak semua orang menyukainya, tetapi saya tidak mengikat kode utama ke fungsi kerangka web, kecuali untuk pengendali interupsi, jadi di masa depan saya dapat dengan cepat menulis ulang untuk hampir semua mesin.

Melakukan:

  • Pengembangan replikator dan distributor + geo Anda sendiri untuk kemungkinan digunakan dalam sistem besar tanpa sistem file cluster (Semuanya untuk orang dewasa)
  • Kemungkinan pemulihan metadata sepenuhnya jika hilang sepenuhnya (jika menggunakan distributor)
  • Protokol asli untuk kemampuan menggunakan koneksi jaringan persisten dan driver untuk berbagai bahasa pemrograman
  • Kemungkinan tingkat lanjut untuk menggunakan komponen NoSQL
  • Kompresi berbagai jenis (gzip, zstd, snappy) untuk file atau nilai di dalam arsip Bolt dan untuk file biasa
  • Enkripsi berbagai jenis untuk file atau nilai di dalam arsip Bolt dan untuk file biasa
  • Konversi video sisi server tertunda, termasuk pada GPU

Saya punya segalanya, semoga server ini bermanfaat bagi seseorang, lisensi BSD-3, hak cipta ganda, karena jika tidak ada perusahaan tempat saya bekerja, server tidak akan ditulis. Saya satu-satunya pengembang. Saya akan berterima kasih atas segala bug dan permintaan fitur yang Anda temukan.

Sumber: www.habr.com

Tambah komentar