Menyimpan dan membuat cadangan 10 juta file di Linux


25

Saya menjalankan situs web tempat sekitar 10 juta file (sampul buku) disimpan dalam 3 tingkat subdirektori, mulai dari [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Ini mengarah ke sekitar 2400 file per direktori, yang sangat cepat ketika kita perlu mengambil satu file. Ini juga merupakan praktik yang disarankan oleh banyak pertanyaan .

Namun, ketika saya perlu membuat cadangan file-file ini, dibutuhkan beberapa hari hanya untuk menelusuri direktori 4k yang menyimpan file 10m.

Jadi saya bertanya-tanya apakah saya bisa menyimpan file-file ini dalam wadah (atau dalam wadah 4k), yang masing-masing akan bertindak persis seperti sistem file (semacam wadah ext3 / 4 yang dipasang?). Saya kira ini akan hampir seefisien mengakses langsung file di sistem file, dan ini akan memiliki keuntungan besar disalin ke server lain dengan sangat efisien.

Adakah saran tentang bagaimana melakukan yang terbaik? Atau alternatif yang layak (noSQL, ...)?


Sistem file apa yang Anda gunakan saat ini?
cmcginty

NetApp dengan lickly menjadi pilihan jika Anda bisa menawar harga
Ian Ringrose

Saya menggunakan ext4 di bawah CentOS 5.6
Benjamin

1
Penasaran mengapa perlu "berhari-hari hanya untuk menelusuri direktori 4k yang menyimpan file 10m", yang sepertinya terlalu lambat. Dengan asumsi 150 byte per pathname, nama file 10m menghasilkan 1,5 GB data, jadi itu bisa menjadi memori / CPU yang tersedia (termasuk mengurutkan hasilnya). Juga, periksa apakah mengaktifkan / menonaktifkan dir_index membantu: lonesysadmin.net/2007/08/17/… plus berbagai tips di serverfault.com/questions/183821/…
RichVel

Catatan 5 tahun kemudian: Saya telah memigrasi semuanya ke Amazon S3, yang sangat cocok untuk menyimpan sejumlah besar file. Ditambah lagi, saya tidak perlu lagi memecah file menjadi 3 tingkat sub-direktori, karena untuk S3 tidak ada bedanya (path adalah path, apakah itu berisi garis miring atau tidak ada bedanya). Dan saya bisa tidur lebih nyenyak, mengetahui bahwa data saya direplikasi dengan aman di beberapa lokasi.
Benjamin

Jawaban:


11

Opsi untuk mengakses dan mencadangkan jutaan file dengan cepat

Pinjam dari orang dengan masalah yang sama

Ini terdengar seperti masalah yang lebih mudah yang dihadapi server berita USENET dan caching proxy web: ratusan juta file kecil yang diakses secara acak. Anda mungkin ingin mengambil petunjuk dari mereka (kecuali mereka biasanya tidak harus mengambil cadangan).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Jelas sifat siklus dari sistem file berita siklik tidak relevan bagi Anda, tetapi konsep tingkat rendah memiliki banyak file / perangkat disk dengan gambar yang dikemas dan indeks cepat dari informasi yang disediakan pengguna untuk mencari informasi lokasi sangat tepat.

Sistem file khusus

Tentu saja, ini hanya konsep yang mirip dengan apa yang orang bicarakan dengan membuat sistem file dalam file dan memasangnya di loopback kecuali Anda bisa menulis kode sistem file Anda sendiri. Tentu saja, karena Anda mengatakan sistem Anda telah dibaca sebagian besar, Anda sebenarnya bisa mendedikasikan partisi disk (atau partisi lvm untuk fleksibilitas dalam ukuran) untuk tujuan yang satu ini. Saat Anda ingin mencadangkan, pasang sistem file read-only dan kemudian buat salinan bit partisi.

LVM

Saya menyebutkan LVM di atas bermanfaat untuk memungkinkan ukuran dinamis suatu partisi sehingga Anda tidak perlu membuat cadangan banyak ruang kosong. Tapi, tentu saja, LVM memiliki fitur lain yang mungkin sangat bisa diterapkan. Khususnya fungsionalitas "snapshot" yang memungkinkan Anda membekukan sistem file pada suatu saat. Kecelakaan rm -rfapa pun atau apa pun tidak akan mengganggu snapshot. Bergantung pada apa yang Anda coba lakukan, itu mungkin cukup untuk kebutuhan cadangan Anda.

RAID-1

Saya yakin Anda sudah akrab dengan RAID dan mungkin sudah menggunakannya untuk keandalan, tetapi RAID-1 dapat digunakan untuk cadangan juga, setidaknya jika Anda menggunakan perangkat lunak RAID (Anda dapat menggunakannya dengan perangkat keras RAID, tetapi itu sebenarnya memberi Anda keandalan yang lebih rendah karena mungkin memerlukan model / pengontrol revisi yang sama untuk membaca). Konsepnya adalah Anda membuat grup RAID-1 dengan satu disk lebih banyak daripada yang sebenarnya perlu Anda hubungkan untuk kebutuhan keandalan normal Anda (mis. Disk ketiga jika Anda menggunakan perangkat lunak RAID-1 dengan dua disk, atau mungkin disk besar dan perangkat keras- RAID5 dengan disk yang lebih kecil dengan perangkat lunak RAID-1 di atas perangkat keras RAID-5). Ketika tiba saatnya untuk mengambil cadangan, instal disk, minta mdadm untuk menambahkan disk ke grup raid, tunggu sampai menunjukkan kelengkapan, secara opsional minta scrub verifikasi, dan kemudian hapus disk. Tentu saja,


Jawaban yang sangat lengkap, yang merangkum solusi yang baik. Saya pikir saya akan menjaga struktur filesystem saya yang ada, dan menggunakan snapshot LVM, yang tampaknya sempurna untuk use case saya.
Benjamin

9

Anda bisa memasang sistem file virtual menggunakan manajer loopback tetapi sementara ini akan mempercepat proses cadangan Anda, itu mungkin mempengaruhi operasi normal.

Alternatif lain adalah membuat cadangan seluruh perangkat menggunakan dd. Sebagai contoh dd if=/dev/my_device of=/path/to/backup.dd,.


+1 Mencadangkan perangkat itu sendiri adalah ide yang bagus.
asm

3
Anda harus, jika Anda menggunakan pendekatan ini, uji pemulihan (well, Anda harus selalu melakukan itu), karena jika input Anda adalah disk seperti / dev / sdd, dd akan menyimpan partisi dan ukuran partisi. Jika Anda mengembalikannya ke disk yang lebih kecil, Anda akan mendapatkan kesalahan, dan jika Anda mengembalikannya ke disk yang lebih besar, itu akan muncul terpotong. Ini akan bekerja paling baik, jika Anda mengembalikan data ke contoh lain dari jenis disk yang sama. Mengembalikan partisi saja (/ dev / sdd1) tidak akan terlalu merepotkan.
pengguna tidak dikenal

1
Perhatikan bahwa jika perangkat menggunakan LVM, pencadangan juga dapat dilakukan tanpa melepas disk menggunakan snapshot LVM.
bdonlan

Saya kedua pendekatan cadangan snapshot LVM. Saya menggunakan LVM di masa lalu untuk replikasi DR langsung. Menggunakan dd dalam kombinasi dengan snapshot membuatnya mudah untuk melakukan pencadangan tingkat blok cepat.
slashdot

Aku mencoba ddlebih ncdan ini melakukan pekerjaan yang baik! Namun saya mungkin memiliki data yang tidak konsisten / rusak, sebagai lawan menggunakan snapshot LVM bukannya partisi hidup.
Benjamin

8

Seperti yang mungkin Anda ketahui, masalah Anda adalah lokalitas. Pencarian disk biasanya membutuhkan waktu 10 ms atau lebih. Jadi hanya memanggil "stat" (atau buka ()) pada 10 juta file yang ditempatkan secara acak membutuhkan 10 juta pencarian, atau sekitar 100000 detik, atau 30 jam.

Jadi, Anda harus meletakkan file ke wadah yang lebih besar, sehingga nomor yang relevan adalah bandwidth drive Anda (50-100 MB / detik untuk satu disk, biasanya) daripada waktu pencarian Anda. Juga, Anda bisa melempar RAID, yang memungkinkan Anda meningkatkan bandwidth (tetapi tidak mengurangi waktu pencarian).

Saya mungkin tidak memberi tahu Anda apa pun yang belum Anda ketahui, tetapi poin saya adalah bahwa gagasan "wadah" Anda pasti akan menyelesaikan masalah, dan hampir semua wadah akan melakukannya. Mount loopback kemungkinan akan berfungsi sebaik apa pun.


Yup, lokalitas sangat penting. Lihatlah pola penggunaan Anda. Sebagian besar masalah cenderung mengikuti Prinsip Pareto (80% proses mencapai 20% data), jadi jika Anda bisa mencari tahu file mana yang perlu di-cache dalam RAM, atau cukup letakkan di partisi terpisah dengan tata letak direktori yang berbeda, jadi dibutuhkan pencarian atau pencarian direktori yang lebih sedikit, mungkin akan banyak membantu. Menyebarkan file-file yang sering diakses pada spindle disk yang berbeda sehingga pencarian dapat dilakukan secara paralel juga dapat membantu. +1 untuk @nemo untuk memunculkan referensi lokal.
Marcin

5

Ada beberapa opsi. Yang paling sederhana, dan harus bekerja dengan semua sistem file Linux, adalah ddmenyalin seluruh partisi ( /dev/sdb3atau /dev/mapper/Data-ImageVol) ke satu gambar dan mengarsipkan gambar itu. Dalam kasus mengembalikan file tunggal, loopback me-mount gambar ( mount -o loop /usr/path/to/file /mountpoint) dan menyalin file yang Anda butuhkan. Untuk pemulihan partisi penuh, Anda dapat membalikkan arah ddperintah awal , tetapi Anda benar-benar membutuhkan partisi dengan ukuran yang sama.

Menilai dari kasus penggunaan Anda, saya menduga setiap file-restore adalah peristiwa yang sangat jarang, jika pernah terjadi sama sekali. Inilah sebabnya mengapa cadangan berbasis gambar sangat masuk akal di sini. Jika Anda perlu membuat pemulihan individu lebih sering, menggunakan snapshot LVM bertahap akan jauh lebih nyaman; tetapi Anda masih perlu melakukan backup berbasis gambar untuk bencana kritis "kami kehilangan segalanya". Pemulihan berbasis gambar cenderung jauh lebih cepat daripada pemulihan berbasis tar hanya karena pemulihan hanya blok, itu tidak menimbulkan cukup banyak operasi metadata dengan setiap fopen / fclose, dan juga bisa menjadi operasi disk yang sangat berurutan untuk peningkatan kecepatan lebih lanjut.

Bergantian, seperti video Google @casey menunjuk ke menyebutkan sekitar setengah jalan, XFS adalah sistem file yang bagus (jika kompleks). Salah satu utilitas yang lebih baik dengan XFS adalah xfsdumputilitas, yang akan membuang seluruh sistem file ke satu file, dan umumnya melakukannya lebih cepat daripada yang tarbisa. Ini adalah utilitas khusus sistem file, sehingga dapat memanfaatkan fs internal dengan cara yang tidak bisa dilakukan tar.


Banyak jawaban bagus di sana! XFS tampaknya menarik, tetapi saya khawatir ini sedikit di luar jangkauan saya.
Benjamin


2

Mungkin jawaban yang sederhana, tetapi pikiran pertama saya adalah menggunakan sesuatu seperti GridFS yang dibangun dari MongoDB . Banyak driver bahasa utama yang mendukungnya, jadi Anda harus bisa menukarnya dengan bagian membaca file dari kode Anda. Juga, Anda bisa membuat direktori Anda yang ada jalur untuk file-file ini.

Satu masalah yang mungkin Anda miliki adalah bahwa Mongo cenderung melambat cukup cepat jika mencari dari disk sepanjang waktu. Dengan 10 juta file, saya berharap sebagian besar data Anda akan di disk. Potongan file dalam GridFS adalah 4MB, seingat saya, jadi jika file Anda lebih besar dari itu, Anda akan melakukan beberapa operasi mahal untuk mendapatkan satu file. Kuncinya, saya pikir, akan shard file Anda berdasarkan pada struktur direktori Anda sudah rapi sehingga Anda bisa memiliki beberapa contoh Mongo berjalan pada beberapa kotak untuk meringankan beban. Namun, saya juga tidak tahu apa persyaratan kinerja Anda sehingga saya mungkin terlalu memikirkannya.

Apa manfaat dari semua ini? Performa yang cukup dekat dengan disk membaca jika dilakukan dengan benar. Selain itu, Mongo hadir dengan beberapa cara bawaan yang bagus untuk mencadangkan seluruh petak data dalam instance DB dengan cepat, dan bahkan dengan database yang masih berjalan.


Pasti akan melihat GridFS yang saya tidak tahu, tapi saya pikir saya akan akhirnya menjaga semua berbasis filesystem untuk menurunkan jumlah pekerjaan, karena semuanya sudah berfungsi!
Benjamin

1

Jika Anda senang dengan model alat untuk penyimpanan data Anda, mungkin Anda bisa mempertimbangkan NexentaStor . Ini menjalankan ZFS pada OpenSolaris di bawah tenda tetapi semua administrasi adalah melalui GUI web.

Ada beberapa fitur yang akan membantu masalah Anda.

  • Versi Enterprise mendukung bentuk replikasi jarak jauh berdasarkan snapshot yang tidak memerlukan pemindaian melalui seluruh sistem file.

  • Jika Anda tidak keberatan tangan Anda kotor, ZFS memiliki perintah ZFS diff yang sangat berguna yang secara efisien memberi tahu Anda file mana yang telah ditambahkan, dimodifikasi, atau dihapus sejak snapshot terakhir, tanpa perlu memindai seluruh sistem file. Anda dapat memasukkan ini ke dalam sistem cadangan Anda untuk sangat mengurangi waktu yang diperlukan untuk melakukan cadangan tambahan.


Terima kasih, akan melihatnya. Mungkin itu akan menambah sedikit kerumitan pada proyek saya!
Benjamin

1

Anda dapat menggunakan standar dump utilitas Untuk membuat cadangan sistem file EXT4 dengan banyak file. Utilitas ini pertama-tama memeriksa blok mana yang digunakan pada sistem file dan kemudian mencadangkannya dalam urutan disk, menghilangkan sebagian besar upaya.

Ada restoreutilitas yang sesuai untuk memulihkan cadangan yang dibuat oleh dump.

Ini mendukung cadangan tambahan menggunakan level - level 1 file cadangan yang dimodifikasi dari cadangan level 0 (penuh) terakhir, level 2 - dimodifikasi dari cadangan level 1 dan seterusnya.


0

Untuk cadangan tambahan, satu opsi adalah memiliki pohon bayangan kedua untuk sampul baru. Artinya, Anda akan memiliki pohon utama yang digunakan untuk semua operasi baca. Anda juga akan memiliki newfiles/012345.....jpgdirektori; sampul yang baru ditambahkan membuat hardlink di sini juga di pohon utama. Saat melakukan pencadangan, Anda dapat mencadangkan pohon utama sesekali, namun mencadangkan (jauh lebih kecil)newfiles lebih teratur.

Perhatikan bahwa untuk menjaga newfilespohon tetap kecil, sebelum melakukan cadangan baru dari pohon utama, Anda dapat mengosongkan pohon file baru:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Setelah Anda melakukan ini, tentu saja, Anda berkomitmen untuk menghasilkan cadangan baru dari pohon utama.


Pendekatan yang menarik, terima kasih sudah berbagi. Tapi saya khawatir itu akan melibatkan banyak perubahan dalam aplikasi, dan akan sulit untuk menjaga aplikasi dan kebutuhan penyimpanan dalam dua lapisan terpisah.
Benjamin

0

Menambahkan sedikit konkurensi biasanya membantu.

Saya memiliki masalah yang sama dari Anda; dalam kasus saya, saya harus membuat cadangan sekitar 30 juta file, kebanyakan dari mereka file HTML, PHP atau JPEG. Bagi saya, BackupPC + rsync over ssh berfungsi OK; cadangan penuh membutuhkan waktu sekitar satu hari, tetapi penambahan biasanya akan selesai dalam beberapa jam.

Caranya adalah dengan menambahkan setiap direktori level utama (0, 1, 2 ... a, b, c ...) sebagai target baru untuk menyalin di BackupPC dan membiarkannya melakukan backup secara paralel, sehingga secara bersamaan membuat cadangan direktori a / , b / , c / * dan seterusnya. Tergantung pada subsistem disk Anda, apa pun antara beberapa proses hingga sekitar 10 proses mungkin merupakan cara tercepat untuk membuat cadangan.

Snapshots LVM dan cadangan tingkat blok juga merupakan pilihan, tetapi dengan BackuPC dan cadangan tingkat file Anda masih dapat memulihkan file atau direktori individual jika diperlukan.


Saya terkejut bahwa membackup direktori root secara bersamaan menyelesaikan masalah untuk Anda, saya berharap itu menjadi lebih lambat. Apakah semua direktori pada disk yang sama? Apakah Anda menggunakan SSD?
Benjamin

File data disimpan di SAN.
Janne Pikkarainen

Oke, masuk akal sekarang, Anda memperoleh efisiensi dari mengakses beberapa file secara bersamaan, karena folder Anda yang berbeda kemungkinan besar secara fisik terletak pada drive yang berbeda di SAN, atau setidaknya direplikasi pada beberapa drive, yang memungkinkan akses bersamaan. Saya hanya berdasarkan pada RAID-1, jadi saya kira di atas dua akses bersamaan, kecepatan saya sangat mungkin turun.
Benjamin

0

Benjamin,

Saya pikir masalah Anda dapat diatasi dengan jumlah file per level direktori!

Apakah waktu akses berubah oleh faktor signifikan jika Anda menyimpan 20.000 file dalam direktori?

Juga apakah Anda menyimpan metadata sistem file pada drive akses cepat yang terpisah? (Seperti SSD).


0

Saya akan merekomendasikan database relasional yang baik sebagai gantinya.

Saya akan menggunakan PostgreSQL dengan, katakanlah, 256 tabel partisi (cover_00, cover_01, ..., cover_ff) dengan data gambar sebagai byteakolom (biner) dengan penyimpanan eksternal, dengan pengidentifikasi file sebagai kunci utama. Mengambil gambar akan cepat (berkat indeks pada kunci utama), integritas data akan dijamin (database yang sesuai dengan ACID), cadangan akan berada dalam urutan disk, jadi tidak terlalu banyak mencari.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.