it-swarm.asia

Haruskah file biner disimpan dalam database?

Apa tempat terbaik untuk menyimpan file biner yang terkait dengan data di database Anda? Seharusnya kamu:

  1. Simpan di database dengan gumpalan
  2. Simpan di sistem file dengan tautan di basis data
  3. Simpan di sistem file tetapi ganti nama menjadi hash dari konten dan simpan hash pada database
  4. Sesuatu yang tidak pernah saya pikirkan

Keuntungan dari (1) adalah (antara lain) bahwa keaslian transaksi dipertahankan. Biayanya adalah Anda mungkin secara dramatis meningkatkan persyaratan penyimpanan (dan streaming/cadangan terkait)

Tujuan dari (3) adalah untuk mempertahankan atomisitas sampai taraf tertentu - jika Anda dapat memastikan bahwa sistem file yang Anda tulis tidak memungkinkan file untuk diubah atau dihapus, dan selalu memiliki hash yang benar sebagai nama file. Idenya adalah untuk menulis file ke sistem file sebelum mengizinkan memasukkan/memperbarui referensi hash - jika transaksi ini gagal setelah sistem file menulis tetapi sebelum DML database, itu baik-baik saja karena sistem file 'palsu' menjadi repositori dari semua kemungkinan file dan hash - tidak masalah jika ada beberapa file di sana yang tidak diarahkan (dan Anda dapat membersihkannya secara berkala jika Anda berhati-hati)

EDIT:

Sepertinya beberapa RDBMS membahas hal ini dalam cara masing-masing - Saya tertarik untuk mengetahui bagaimana orang lain melakukannya - dan khususnya dalam solusi untuk postgres

  1. Simpan dalam database dengan gumpalan

    Kerugiannya adalah membuat file database Anda cukup besar dan mungkin terlalu besar untuk dicadangkan dengan pengaturan yang ada. Keuntungannya adalah integritas dan atomitas.

  2. Simpan di filesystem dengan tautan di database

    Saya telah menemukan bencana yang sangat mengerikan dalam melakukan ini, dan saya takut orang-orang terus menyarankannya. Beberapa bencana termasuk:

    • Salah satu pengguna istimewa yang akan mengatur ulang file dan sering memutus hubungan antara jalur di DB dan di mana mereka sekarang (tapi entah bagaimana ini menjadi kesalahan saya).
    • Saat berpindah dari satu server ke server lain, kepemilikan beberapa file hilang karena SID untuk akun administrator mesin lama (apa yang dijalankan situs web lama) bukan bagian dari domain dan oleh karena itu file yang disalin memiliki ACL yang dapat tidak diselesaikan sehingga menghadirkan pengguna dengan Prompt nama pengguna/kata sandi/domain.
    • Beberapa jalur akhirnya lebih dari 256 karakter dari C:\ sampai ke .doc dan tidak semua versi NT dapat menangani jalur yang panjang.
  3. Simpan di filesystem tetapi ganti nama menjadi hash dari konten dan simpan hash pada database

    Tempat terakhir saya bekerja melakukan ini berdasarkan penjelasan saya tentang skenario di atas melakukan ini. Mereka berpikir itu adalah kompromi antara ketidakmampuan organisasi untuk mendapatkan pengalaman dengan database besar (apa pun yang lebih besar dari sekitar 40G ditahbiskan menjadi "terlalu besar"), ketidakmampuan perusahaan untuk membeli hard drive besar, dan ketidakmampuan untuk membeli kembali yang lebih modern solusi, dan kebutuhan untuk menjauh dari risiko # 1 & # 3 yang saya identifikasi di atas.

Pendapat saya adalah bahwa menyimpan dalam DB sebagai gumpalan adalah solusi yang lebih baik dan lebih skalabel dalam skenario multi-server, terutama dengan masalah failover dan ketersediaan.

61
Tangurena

Nomor 1 untuk integritas data lengkap. Gunakan opsi lain jika Anda tidak peduli dengan kualitas data. Sesederhana itu.

Kebanyakan RDBMS memiliki optimisasi untuk menyimpan BLOB (misalnya SQL Server filestream)

29
gbn

Jika menggunakan Oracle, lihat dbfs dan File Aman.

File Aman mengatakan semuanya, jaga SEMUA data Anda aman dalam database. Ini diatur dalam lobs. File Aman adalah versi modern dari lobs, yang harus diaktifkan.

dbfs adalah sistem file dalam database. Anda dapat memasangnya seperti sistem file jaringan, pada Linux Host. Ini sangat kuat. Lihat blog Ia juga memiliki banyak opsi untuk menyesuaikan dengan kebutuhan spesifik Anda. Menjadi dba, diberi filesystem (berbasis di database, dipasang di Linux), saya membuat Oracle Database di atasnya tanpa masalah. (database, disimpan dalam ... database). Bukannya ini akan sangat berguna tetapi itu menunjukkan kekuatan.

Lebih banyak keuntungan adalah: ketersediaan, cadangan, pemulihan, semua membaca konsisten dengan data relasional lainnya.

Terkadang ukuran diberikan sebagai alasan untuk tidak menyimpan dokumen dalam database. Data itu mungkin harus dicadangkan dengan cara apa pun sehingga itu bukan alasan yang baik untuk tidak menyimpan dalam database. Terutama dalam situasi di mana dokumen lama dianggap hanya baca, mudah untuk membuat sebagian besar basis data hanya baca. Dalam hal itu, bagian-bagian dari basis data tidak lagi membutuhkan cadangan yang sering tinggi.

Referensi dalam tabel untuk sesuatu di luar basis data tidak aman. Ini dapat dimanipulasi, sulit untuk diperiksa dan dapat dengan mudah hilang. Bagaimana dengan transaksi? Basis data menawarkan solusi untuk semua masalah ini. Dengan Oracle DBFS, Anda dapat memberikan dokumen Anda ke aplikasi non basis data dan mereka bahkan tidak akan tahu mereka mencari-cari di dalam basis data.

Yang terakhir, kejutan besar, kinerja sistem file dbfs seringkali lebih baik daripada sistem file biasa. Ini benar terutama jika file lebih besar dari beberapa blok.

22
ik_zelf

Saya pikir jawaban yang tepat di sini sangat tergantung pada aplikasi Anda, dan seberapa penting dokumen-dokumen itu.

Untuk sistem manajemen dokumen, atau sistem yang dapat memulihkan dokumen yang disimpan sangat penting (sehingga sebagian besar terkait dengan keuangan, SDM, atau CRM), menyimpan dokumen secara sejajar, atau menggunakan teknologi dokumen milik vendor DB favorit Anda sepertinya Right Thing To Do.

Namun, ada banyak aplikasi di mana saya percaya bahwa keputusan yang sebaliknya tepat.

Sistem Helpdesk dan sistem tipe wiki adalah yang saya pikir sangat masuk akal untuk menyimpan data keluar dari database. Saya percaya beberapa, seperti Jira, sebenarnya memberikan opsi untuk memilih apakah Anda ingin menyimpan dokumen inline atau tidak.

Untuk bisnis berukuran sedang, menyimpan dokumen untuk sistem tiket inline dapat berarti perbedaan antara cadangan terkompresi yang diukur dalam megabita, dan yang diukur dalam gigabita.

Saya pribadi lebih suka membawa sistem tiket kembali online dalam beberapa menit dan bergulat dengan dokumen (umumnya kurang penting) selama beberapa jam, daripada meningkatkan "itu rusak dan CTO bernapas di leher saya" RTO dengan harus mengembalikan dan memutar ulang log dari cadangan yang jauh lebih besar.

Ada manfaat lain dari menjaga dokumen tetap terpisah.

  • Anda dapat dengan mudah menjalankan proses terpisah yang katalog dokumen metadata, melakukan pemindaian virus, melakukan pengindeksan kata kunci, dll.
  • Anda dapat memanfaatkan alat untuk membantu dengan pencadangan atau pemulihan - rsync, snapshot penyimpanan, dll. - yang membuat file lebih baik daripada database.
  • Anda benar-benar dapat menggunakan penyimpanan yang mendukung kompresi atau deduplikasi (hal-hal yang admin Anda SAN telah gagal selama bertahun-tahun, alias kutukan administrator database di seluruh dunia)
  • Untuk instalasi di beberapa situs, Anda dapat melengkapi database terpusat dengan sistem file terdistribusi

Saya pikir kombinasi hibrida dari # 2 dan # 3 mungkin pintar. Simpan nama file asli, tetapi hitung dan simpan hash/checksum dokumen, sehingga Anda memiliki beberapa titik referensi yang akan membantu pemulihan jika seseorang memindahkan atau mengganti nama file.

Menyimpan file dengan nama file aslinya berarti bahwa aplikasi dapat benar-benar menariknya langsung dari sistem file dan mengirimkannya melalui kabel, atau dalam dunia klien yang tebal, bahkan mungkin mengarahkan pengguna langsung ke server file.

15
Nathan Jolly

Jangan lakukan itu.

Sebenarnya tidak ada terbalik memiliki file yang disimpan dalam database.

Bukankah sudah terasa aneh dan mencurigakan saat Anda berpikir:

Haruskah saya menyimpan file dalam database atau sistem file ?

Lebih baik lagi, ucapkan dengan lantang.

Ke fakta:

Menggunakan database

" [~ # ~] pro [~ # ~] " ... tetapi tidak cukup :

  • "Atomicity" yang benar tetapi pedang bermata dua. Karena itu menyeret kontra dengannya.
  • Integritas. Sama seperti di atas.

Saya benar-benar tidak ingin menjadi bias, tetapi saya pikir tidak ada lagi yang perlu ditambahkan. Pro tidak terlalu bagus jika Anda memikirkannya.

Jika saya lupa sesuatu komentar di bawah ini, sementara itu baca terus di bawah ini.

CONS:

  • Alat yang salah untuk pekerjaan
  • Sulit dipertahankan
  • Lambat
  • Lupakan menyimpan ratusan MB/gigabytes data PER pengguna .
  • Mencadangkan situs yang tumbuh dengan cepat akan menjadi mimpi buruk.
  • Memulihkan/bergerak juga akan menyedot.

Menggunakan sistem file

PROS:

  • Cara lebih mudah untuk mempertahankannya
  • Cepat
  • Database cadangan tidak ada hubungannya dengan ini
  • Portabilitas lebih tinggi *

[~ # ~] kontra [~ # ~] :

  • Tidak ada *

* Cetak halus

Saat ini kau bertanya pada dirimu sendiri, tunggu sebentar, maksudmu tidak ada kontra ?! Bagaimana bisa?

Kesalahan terbesar di sini adalah orang-orang mencoba mengencangkan sekrup dengan palu.

Alasan utama dan saya akan mengatakan lebih jauh saja alasan ini ditanyakan adalah karena tautan file .

Ini adalah masalah yang tidak ingin diselesaikan oleh database. Bahkan terdengar konyol jika Anda memikirkannya.

"Basis data akan memperbaiki masalah penautan file saya."

Ketika pada kenyataannya, secara logis aplikasi sebenarnya harus bertanggung jawab atas penanganan dan penyajian tautan.

Sebuah solusi:

  1. Buat aplikasi Anda menangani permintaan URL dengan rute khusus.
  2. Simpan rute ini ke basis data Anda.
  3. Secara internal setiap kali rute ini disebut memetakannya ke file yang Anda inginkan.
  4. Jika Anda pernah memindahkan file di tempat lain, ubah saja nilai nama file rute dan rute itu akan selalu menyajikan file yang sama di mana pun file itu disimpan atau direferensikan di seluruh web.

Ini juga akan mengabstraksi jalur asli, membuat aplikasi lebih portabel, dapat dipelihara dan memungkinkan untuk beralih ke semua jenis sistem file tanpa merusak apa pun.

Adapun cara mengimplementasikannya berada di luar cakupan jawaban ini, tetapi Anda dapat melihat contoh umum dalam bahasa web (PHP) yang paling banyak digunakan:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Keduanya sama-sama sangat kuat.

14
Tek

Saya ingin menambahkan pengalaman saya di sini sebagai pengorbanan. Di PostgreSQL, setidaknya, dampak kinerja sangat minim dalam hal server db. Gumpalan besar disimpan dalam file terpisah, bukan di tabel tumpukan utama sehingga memindahkannya dari cara operasi yang dapat menghitung sejumlah besar catatan. Dbs lain dapat melakukan hal serupa.

Keuntungan utama adalah kemampuan untuk menyimpan semua data terkait di satu tempat untuk keperluan atomisitas dan cadangan. Ini sangat mengurangi kemungkinan terjadi kesalahan.

Kerugian utama bukan yang saya lihat dibahas di atas, dan itu penggunaan memori di front-end. Saya tidak tahu persis bagaimana setiap db menangani ini sehingga ini mungkin tergantung pada implementasi tetapi untuk PostgreSQL, data masuk sebagai string ASCII (mungkin hexadecimal, mungkin dengan eskrip inline), ini mungkin keluar. kemudian harus dikonversi kembali ke biner di front end.Banyak kerangka kerja yang saya lihat untuk melakukan ini melibatkan melewati nilai (bukan sebagai referensi) dan kemudian membangun string biner baru berdasarkan itu.Saya menghitung bahwa menggunakan Perl untuk melakukan ini akhirnya menggunakan memori biner berkali-kali untuk menyelesaikannya.

Putusan: Jika file hanya diakses sesekali saya akan menyimpan di db. Jika mereka sering dan berulang kali diakses, setidaknya dengan PostgreSQL, saya pikir biayanya melebihi manfaatnya.

9
Chris Travers

Jangan menyimpan file dalam database.

Setiap orang, tanpa terkecuali, yang dapat menjalankan RDBMS apa pun di pasaran sudah memiliki basis data khusus untuk menyimpan file, dan RDBMS sendiri yang menggunakannya! Database itu adalah sistem file . Sekarang mari kita bicara tentang beberapa kelemahan potensial menyimpan file dalam database, serta beberapa faktor mitigasi spesifik untuk menyimpan file dalam database.

  • Tidak filehandes ke file dalam database. Apa artinya ini?

    • Programmer-talk: Anda TIDAK BISA mencari (fseek), tidak ada kemampuan untuk mengelola sumber daya dengan akses asinkron (asyncio atau epoll), tidak ada sendfile (menghemat salinan dari ruang kernel Anda).

    • Aplikasi praktis: Ingin mengirim video atau gambar ke klien melalui HTTP2/3? Jika ada di database, maka Anda harus terlebih dahulu menanyakannya. Untuk kueri apa pun yang mengembalikan file itu, Anda harus menunggu kueri seluruh untuk menyimpulkan sebelum file itu dapat pindah ke langkah berikutnya. Dalam instalasi produksi dengan rdbms pada server yang berbeda dari server web, Anda akan terlebih dahulu harus mentransfer file seluruhnya dari rdbms ke server web daripada mengalirkannya. Namun, jika lapisan transportasi menyediakan abstraksi sistem file (yang bahkan didukung NFS) Anda dapat mencari setengah jalan melalui file dan segera mulai mengalirkan kembali ke klien tanpa buffering lebih dari file dari yang diperlukan. Ini secara rutin dilakukan oleh server web nginx , Apache , PureFTP, dan ProFTP.

  • Salin ganda pada RDBMS. Dengan fakta bahwa itu ada di database, Anda mungkin akan menulisnya dua kali. Sekali dalam log tulis-depan (WAL), dan kemudian kembali ke tablespace.

  • Tidak ada pembaruan, pernah [~ # ~] mvcc [~ # ~]) berarti tidak ada yang diperbarui, hanya disalin lagi dengan modifikasi , dan kemudian baris lama ditandai sebagai kedaluwarsa (dihapus). Setiap pembaruan ke file, akan membutuhkan penulisan seluruh baris , bukan hanya file seluruh baris. Filesystem dapat menyediakan ini juga, dengan penjurnalan data tetapi Anda jarang membutuhkannya.

  • Membaca-file dan mentransfer untuk memperlambat permintaan Jika file itu sendiri disimpan pada baris yang perlu Anda query, seluruh baris harus tunggu file ditransfer, atau Anda harus mengeluarkan dua pertanyaan terpisah.

  • Penggunaan memori pada klien DB. DB-client (libpq, jdbc, odbc, freetds, dll) atau sejenisnya kemungkinan akan buffer permintaan dalam memori. Ketika buffer dalam memori habis, ia mungkin memulai buffer-disk atau bahkan lebih buruk lagi mungkin jatuh kembali ke kernel untuk di-paged ke disk.

  • Query-throttling banyak database menyediakan kemampuan untuk membunuh dan menuai permintaan ketika mereka mengambil terlalu banyak dalam cara waktu, atau sumber daya. Ingatlah bahwa transfer file tidak akan dalam implementasi apa pun diperinci. Apakah permintaan itu terbunuh setelah 3 detik? Atau apakah perlu 1 detik dan backend menghabiskan 2 detik mentransfer file? Bukan hanya "terperinci", bagaimana Anda akan secara efektif menyatakan berapa banyak waktu yang dibutuhkan sebuah kueri ketika 99,9% kueri mengembalikan 1 KB, dan yang lainnya mengembalikan 1 GB?

  • No-copy-on-write atau de-deduplication XFS dan BTRFS mendukung copy-on-write dan de-duplikasi secara transparan. Ini berarti memiliki gambar yang sama di mana-mana, atau memerlukan salinan kedua dapat secara transparan ditangani oleh sistem file. Namun, jika file tersebut tidak berdiri sendiri, dan baik pada baris atau di toko sistem file kemungkinan tidak dapat memotongnya.

  • Integritas banyak orang di sini berbicara tentang integritas. Menurut Anda apa yang lebih baik dalam mendeteksi korupsi sistem file, aplikasi yang menggunakan filesystem atau utilitas inti filesystem? Simpan file dalam satu baris, atau out-of-line dan korupsi sistem file apa pun akan mengaburkan database. xfs_repair sangat bagus untuk memulihkan ketika Anda memiliki sistem file atau korupsi hard drive, dan jika gagal itu masih akan jauh lebih mudah untuk melakukan forensik data.

  • Migrasi awan jika Anda ingin menyimpan file pada SAN atau cloud Anda akan memiliki lebih banyak lagi kesulitan karena sekarang migrasi penyimpanan adalah migrasi database. Jika file Anda misalnya disimpan di sistem file, Anda dapat dengan mudah memindahkannya ke S3 (dan dengan sesuatu seperti s3fs bisa transparan).

Pengecualian

Menyimpan file dalam database memiliki beberapa kasus penggunaan yang valid,

  • Ketika Anda perlu untuk mengedit file secara transisi. Itu berarti secara harfiah bagian dari transaksi Anda untuk mengedit file. Atau Anda perlu kemampuan untuk memutar kembali pengeditan pada file jika transaksi gagal untuk masalah integritas data dalam relasi (tabel).
  • Ketika Anda perlu untuk memastikan sistem file benar-benar diversi versi dengan data dan Anda tidak dapat menanggung risiko dalam menyinkronkannya.
  • Ketika Anda database benar-benar dapat mem-parsing file dan Anda dapat menanyakannya. Dalam PostgreSQL misalnya, topologi dapat berupa kueri dengan PostGIS. Pada titik ini, sementara itu adalah file, itu juga data untuk kueri dan bukan dump penyimpanan.

Mitigasi

  • Beberapa database memiliki gagasan tentang "sumber daya yang dikelola secara eksternal" di mana database mengelola file secara pribadi pada disk seperti

  • Beberapa database menyimpan objek biner besar out-of-line atau bisa, seperti Oracle SecureFile. Ini memungkinkan Anda untuk memperbarui baris, tanpa menulis ulang file.

  • Beberapa database seperti Oracle melakukan MVC mereka tanpa log WAL dan tidak perlu menggandakan file tersebut.

  • Beberapa database, seperti SQL Server dan Oracle memberikan kemampuan untuk "mengalirkan" data dari file tanpa harus memiliki pegangan file untuk itu. Ini mungkin atau mungkin tidak berjalan pada koneksi yang berbeda dari permintaan databaes. Tetapi kuncinya di sini adalah ketika Anda bisa mengalirkan file (secara teori), saya tidak dapat menemukan bukti produk apa pun yang tidak dibuat oleh penyedia yang menggunakan fitur itu. Misalnya, di mana jembatan NGINX/Apache untuk memungkinkan Anda melakukan ini?

  • Oracle menyediakan deduplikasi, kompresi, dan enkripsi opsional melalui penyimpanan Internal-LOB (seperti SecureFile).

Kesimpulan

Skenario kasus terburuk ketika Anda meletakkan file di database adalah sangat buruk untuk kinerja, dan kompatibilitas dengan tooling. Itu selalu tergantung pada implementasi. Tidak mungkin database lebih baik menjadi sistem file daripada sistem file. Dalam segala hal, ini adalah kompromi dan bahkan ketika Anda mendapatkan fitur mitigasi yang kuat (seperti halnya SecureFile), perkakasnya sangat buruk sehingga benar-benar tidak lebih dari titik pemasaran kecuali seluruh tumpukan Anda dibangun oleh penyedia RDBMS.

Tetap sederhana, dan aturan umum adalah jauhkan file dari DB .

Larutan

Bagaimana seharusnya Anda menyimpan file, atau mengabstraksikan sistem file sedemikian rupa agar berfungsi secara efektif bagi banyak penyewa dan pengguna? Saya sebagian untuk hashing isi file. Ini sangat umum hari ini dan bekerja dengan baik.

9
Evan Carroll

Kembali pada hari itu, Microsoft meningkatkan kemampuan untuk menyimpan gambar (dan tipe data gumpalan serupa) dalam database. Itu adalah fitur baru yang keren dari SQL Server 2000 (saya cukup yakin itu 2000, bukan 7,0) dan banyak orang ikut-ikutan.

Menyimpan BLOBS dalam database memiliki kelebihan dan kekurangan:

Di satu sisi, semua data Anda dan gambar atau dokumen terkait dapat disimpan dan diakses di satu tempat. Pengguna aplikasi tidak memerlukan izin jaringan khusus, karena SQL yang melayani gambar/file/dokumen.

Di sisi lain, basis data Anda dapat tumbuh cukup besar, tergantung pada ukuran dan jumlah BLOBS yang Anda simpan. Ini memengaruhi cadangan, persyaratan penyimpanan, operasi pemulihan yang sensitif terhadap waktu, dll.

SQL Server 2008 memperkenalkan streaming file. Basis data berisi pointer ke file, file berada di server bukan di dalam database, tetapi ketika Anda membuat cadangan database file juga didukung.

Cadangan Anda bisa menjadi cukup besar, tetapi Anda tidak berakhir dengan file/dokumen/blob/gambar yatim.

Preferensi pribadi saya adalah membiarkan database menyimpan pointer/lokasi jaringan, dan membiarkan server file menangani file. Server file lebih baik dioptimalkan untuk tugas-tugas seperti itu.

7
datagod

Pilihan saya tidak untuk keduanya. Simpan data dalam sistem seperti Amazon S3 atau CDN Microsft dan simpan URL itu dalam database.

Dengan cara ini Anda mendapatkan keandalan memiliki data yang selalu dapat diakses tanpa memiliki database berukuran monster yang harus dihadapi.

6
paullb

Meskipun sebagian tergantung pada aplikasi/lingkungan (termasuk orang), saya akan pergi untuk gumpalan.

Menyimpan segala sesuatu di database berarti replikasi berfungsi untuk data file. Anda memerlukan mekanisme terpisah untuk menyinkronkan file FS.

Pada beberapa aplikasi, sistem file seharusnya tidak dimodifikasi. Misalnya, di situs web produksi, saya akan menghindari penggunaan sistem file untuk data yang tidak dapat dibuang (situs hidup di bawah SCM, data dalam database).

Dengan asumsi kami memiliki banyak pengguna/aplikasi dengan izin terpisah, maka setiap penyimpanan sistem file memberikan peluang untuk perbedaan dalam DB dan FS hak akses.

Penyempurnaan yang saya pertimbangkan untuk membuat penyimpanan BLOB adalah untuk memotong data jika itu masuk akal; jika Anda hanya membutuhkan 512 byte dari BLOB 20Mb, akses seperti sektor ini adalah keuntungan nyata, terutama jika Anda berurusan dengan klien jarak jauh (dan sekali lagi, pembaruan parsial menciptakan lalu lintas replikasi yang jauh lebih sedikit).

6
Phil Lello

Untuk postgres:

Ini sebenarnya lurus ke depan. Ada tipe BYTEA yang dapat digunakan untuk menyimpan string biner. Per default, tidak ada utiliti build seperti yang disebutkan untuk MS atau Oracle. Jadi menyimpan banyak file besar dan mengambilnya bisa membosankan. Anda juga perlu melakukan konversi file dalam aplikasi (seperti dengan ByteStream atau serupa, tidak tahu bagaimana cara kerjanya dengan file MS/Oracle spesifik <-> solusi database). Ada juga tipe lo , yang membantu pekerjaan mengelola Gumpalan karena beberapa manajemen internal jenis ini mungkin tidak melacak referensi.

3
DrColossos