Arie Kusuma Atmaja wrote: >> Dengan begitu data tetap >> di satu tempat, dan network traffic dan database load tidak tinggi. >> > > Yang saya pernah lihat malah ada di server pakai NFS segala (jujur saya belum > tau > banyak sampai detil2nya sih, intinya dikasihtau kalau untuk direktori image > bahkan > pakai di-mount dulu (dipisah-pisah) supaya tidak memberatkan kinerja satu > mesin > skrip yg sedang bekerja). Kenapa bisa disebut data tetap di satu tetap > sehingga > load tidak tinggi? Bukankah justru malah jadi lebih tinggi? > > Mungkin yang dimaksud bukan "data di satu tempat", tapi secara struktur direktori, "sepertinya" terlihat di satu tempat.
Mirip dengan symlink di UNIX. Untuk load, saya pikir ini lihat bagaimana si arsitek menata servernya. Kalo dilihat dari deskripsinya, NFS itu digunakan agar gampang menyimpan file hasil upload ke sebuah direktori layaknya write ajah (sama sekali gak ada perubahan di kode Rails app-nyah). Nah, pada saat visitor ingin mendownload file image tersebut, file tsb. bukan di-serve dari Rails app, tapi dari Apache web server yang diinstall di server NFS yang dituju. Di sini, apabila NFS servernya lebih dari 1, maka kinerjanya bisa terbagi lebih "nyaman". "Load tidak tinggi" bisa berarti bahwa si Rails app tidak akan terbebani dengan disk I/O yang sangat berat itu, karena load disk I/O masuknya ke NFS server. >>> * Write tables to cache data for reports that span months and >>> years. It.s much faster than re-generating a year.s worth of reports >>> every time a page is loaded. >>> >> Data yang sudah tua mungkin juga bisa dipindahkan ke archive database. >> > > Ehm, ini dia fitur mantap. Sudah pernah terpikir gak ya tentang desain > business > process-nya, mis. untuk project CMS aja misalkan, untuk data yang tua, mis. > sudah > berusia 2 sampai 3 tahun lalu, itu digenerate otomatis ke HTML biasa (dengan > tetap > mempertahankan kemampuan easy search dan dapat secara akurat seperti halnya > pakai > database biasa). itu satu. yang kedua, file image yang sudah tua juga dapat di > archive. > Soal generate ke HTML bisa dipertimbangkan. Saya belum pernah sih ketemu kasus di mana jumlah records terlalu banyak :D Tapi satu hal yang mungkin bisa di-imagine adalah gimana nyimpen daftar friend untuk situs semacam Friendster? Bayangin, 20 juta user ajah. Untuk relationship matrix membutuhkan 20 juta x 20 juta 400,000,000,000,000 cell! (dengan asumsi opaque). Tapi jika bisa dibikin sparse matrix mungkin lebih space efficient. Tapi kalo mo bikin 2nd degree, 3rd degree... Weleh... (mungkin bagusnya cari filesystem yang sudah support VeryLarge FileSizes dengan dukungan sparse files) Easy search? Kalau pake Ferret atau Lucene, saya pikir jumlah document tidak terlalu mempengaruhi kecepatan, karena yang lebih penting adalah jumlah "word", dengan sistem inverted index tersebut. 1 document atau 1,000 document atau 1,000,000 document, bagi search engine sepertinya tidak terlalu bermasalah, asal jumlah "word" yang terdapat di situ konstan. Lucene is also very flexible. -- Hendy Irawan www.hendyirawan.com
