NuDSS for irrigated rice merupakan salah satu software DSS yang ditujukan untuk membantu dalam pengambilan keputusan dalam memperkirakan kebutuhan nutrisi yang pasti untuk irigasi persawahan, dapat pula mengambil keputusan untuk memilih pupuk yang berkualitas yang cocok dengan keadaan tanah dan juga kebutuhan nutrisinya, dapat pula memperkirakan keuntungan yang didapatkan dari perkembangan nutrisi dan program untuk manajemen benih yang baik.
Modul-modul yang terintegrasi di dalam NuDSS antara lain; Fertilizer calculator, Fertilizer chooser, Fertilizer splitter, Profit analyzer.
Apa itu NuDSS?
Nutrient Decision System (NuDSS) for irrigated rice merupakan bagian dari Irrigated Rice Research Consortium untuk memberikan suatu penunjang keputusan manajemen nutrisi yang spesifik pada persawahan. NuDSS merupakan software untuk memperkirakan kebutuhan nutrisi untuk target pendapatan yang realistis untuk persawahan, dengan memilih kombinasi pupuk yang berkualitas dan tentu saja dengan harga seminimal mungkin.
Isi dari software ini mengacu pada publikasi sebelumnya pada SSNM (site-spesific nutrient management), termasuk buku pedoman dan petunjuk pemakaian. NuDSS melakukan proses dengan menggabungkan beberapa model menjadi satu paket software yang user-friendly untuk membantu dalam perkembangan strategi pemupukan dengan tujuan agar penggunaan pupuk menjadi lebih efektif. Hasil panen yang tinggi dan bagus, dan menambah keuntungan petani. Software dikembangkan untuk memenuhi kebutuhan akan suatu system pengambil keputusan untuk membantu dalam kalkulasi matematika yang kompleks yang sulit untuk dilakukan secara manual.
NuDSS membantu user untuk :
· Memperkirakan potensi panen padi berdasarkan data climatic
· Menetapkan target panen berdasarkan potensi panen dan panen saat ini yang didapatkan oleh petani
· Memperkirakan kebutuhan pupuk berdasarkan target panen realistic dan suplai nutrisi tanah
· Mengartikan rekomendasi nutrisi kepada komposisi material pupuk yang tepat
· Memilih kombinasi sumber nutrisi pupuk dengan harga seminimal mungkin berdasarkan harga yang ditetapkan untuk produk pupuk
· Memutuskan aplikasi pemisahan pupuk
· Menghitung keuntungan menurut hasil dari harga benih *ladang padi dikurangi semua harga input (gross margin analysis), dan
· Membandingkan dan mengevaluasi harga (harga untuk pupuk, pestisida, pekerja, dll).
Berdasarkan framework dari gambar 1 diatas, terdapat lima output utama (ditandai dengan background abu-abu pada gambar) dan output-output tambahan sebagai berikut :
Estimate recommendation domains and indigenous nutrient supplies. Daerah yang lebih besar dipecah menjadi domain rekomendasi agro-ecological yang lebih kecil lagi. Ukuran domain menentukan jumlah petak nutrient yang akan digunakan untuk mendapatkan rata-rata panen yang valid untuk setiap domain.
Select a yield target. Target panen per musim ditentukan sekitar 10% lebih besar dari yang didapatkan petani saat ini tapi tidak lebih besar dari 75-80% dari potensi panen.
Calculate fertilizer nutrient requirements. Total kebutuhan pupuk dihitung berdasarkan kebutuhan nutrisi pupuk yang diharapkan sekitar 40-50 kg N, 20 kg P2O5, dan 30 kg K2O per ton yang dibutuhkan untuk peningkatan panen. Kebutuhan untuk setiap P dan K disesuaikan dengan menggunakan keseimbangan input-output untuk mencegah penipisan nutrisi tanah.
Select meaningful fertilizer material. Rata-rata pupuk dari elemen nutrisi (kg ha-1) di paparkan dalam sumber nutrisi per local area unit untuk memfasilitasi hasil tani dengan skala yang lebih besar.
Obtain profit estimate. Teknik bertani dibandingkan dengan strategi baru untuk manajemen nutrisi alternative untuk mendapatkan peningkatan keuntungan sebagaimana diharapkan (analisis ex-ante). Strategi pemupukan disesuaikan dengan analisis ekonomi untuk outcome. Simple guidelines and strategies for promotion. Dimana pupuk yang digunakan petani baik, maka akan lebih efektif dan ekonomis untuk berkembang, rekomendasi pupuk melalui partisipasi petani lalu mempromosikan suatu cara baru teknik bertani dengan area yang besar. NuDSS software mengarah pada proses ini.
Halaman Settings menunjukkan informasi umum mengenai profile Negara dan system bercocok tanam, system ukuran, dan bahan nutrisi yang digunakan pada kalkulasi pupuk yang dibutuhkan. Disini kita dapat pula menentukan jenis pupuk atau kombinasi pupuk yang cocok untuk area dimana kita menanam, NuDSS melakukan ini dengan rumus matematika tertentu sehingga hasilnya lebih akurat daripada cara tradisional dimana petani hanya mengira-ngira tidak dengan kalkulasi yang pasti.
Fertilizer Calculator
Data-data yang dibutuhkan untuk menghitung komposisi pupuk N, P dan K (kg N, P2O5, dan K2O per ha) :
Organic sources
Memperkirakan sumber nutrisi organic yang ditambahkan atau diambil ke/dari tanah di awal musim.
Soil nutrient supply
Memperkirakan pasokan nutrisi tanah. Kesuburan tanaman ditentukan oleh kondisi cuaca dan kondisi tumbuh, hal ini digunakan sebagai indicator penentu pasokan pupuk.
Yield potential
Ini adalah teoritis panen yang ditentukan oleh iklim dan varietas. Potensi panen digunakan sebagai acuan untuk menetapkan goal panen dan untuk menganalisa jarak panen antar musim.
Yield goal
Menentukan goal panen yang realistis berdasarkan panen rata-rata, dan kemungkinan penambahan dan pengurangan hasil panen yang mungkin terjadi. Goal panen haruslah tidak lebih besar dari 75-80% dari perkiraan potensi panen untuk menghindari excessive input pupuk dan bertambahnya resiko gagal tanam dan kehilangan profit.
Fertilizer Chooser dapat membantu user untuk mengartikan rekomendasi nutrisi menjadi komposisi material pupuk yang tepat, pilih kombinasi sumber nutrisi pupuk dengan harga seminimal mungkin berdasarkan kuota harga untuk produk-produk pupuk, dan mengevaluasi harga dari program pemupukan yang berbeda.
Fertilizer Splitter
Fertilizer Splitter dapat membantu user untuk memutuskan waktu yang tepat untuk pemberian pupuk dan penghitungan material pupuk yang dibutuhkan untuk diterapkan bersamaan dengan teknik split pupuk untuk mencapai tingkat nutrisi yang direkomendasikan.
Profit Analyzer
Profit analyzer memungkinkan user untuk memperkirakan keuntungan yang didapatkan.
Posted by
iyancoolbgt
Sabtu, 31 Januari 2009
di
20.43
Google File System
Mungkin apabila ada pertanyaan “apakah anda tahu google?” kita pasti dapat memastikan bahwa setiap orang yang mendapatkan pertanyaan itu akan menjawab “ya”.
Benar, google adalah salah satu search engine yang beredar di penjuru dunia maya (internet), kita dapat mencari web, tugas sekolah atau kampus, mencari referensi, bahkan untuk mencari link download video atau musik pun dapat dilakukan oleh google, kita hanya perlu mengetikkan keyword nya saja. Dapat dibayangkan apabila tidak ada web search system seperti google maka pasti akan banyak sekali iklan-iklan website di surat kabar, radio, maupun di televisi. Dan juga web surfing pun akan terasa sulit dilakukan karena jarang ada orang yang hafal betul setiap website untuk setiap keperluannya.
Mungkin terkadang terbesit pertanyaan di benak kita, “bagaimana google melakukan hal ini?” hanya dengan memasukkan keyword yang kita inginkan, google dengan hitungan detik akan mencari ke setiap website yang ada di internet lalu menampilkan website yang kita inginkan. Dari jutaan lebih website di dunia ini bagaimana google dengan mudahnya searching dalam hitungan detik. Ya, google membuat dan menerapkan suatu system penyimpanan dan pencarian file terhadap server yang mereka namakan dengan “Google File System (GFS)”.
Mengapa Google Membuat Google File System (GFS)
ØBanyaknya semi-structured maupun structured data yang terdaftar di google
Data-data tersebut bisa merupakan :
URL
Yang isinya banyak merupakan contents (downloadable file yang disisipkan dalam URL atau website), crawl metadata, links yang merujuk ke URL lainnya, anchors, pagerank dan lainnya.
Per-user Data
Adanya user-user yang menghendaki hasil tampilan result dengan kriteria tertentu, maka perlu dibuatkan User preference settings pada searching system.
ØLarge-Scale
Seperti yang kita tahu bahwa didalam server google, site-site atau file yang sudah terdaftar sudah melampaui jumlah miliaran, belum lagi (bukannya google menyombongkan diri) adanya fakta bahwa google merupakan situs terfavorit jauh dibandingkan situs lainnya, mengakibatkan ratusan bahkan jutaan user mengakses situs google dalam satu waktu per detiknya, sedangkan kecepatan searching tetap harus menjadi prioritas utama. Dan juga 100+ TB satellite image data yang harus di jelajah.
Tujuan dibuatnya Google File System
Google menginginkan proses sinkronisasi server dengan website di-update secara continue untuk setiap ukuran kecil data
Untuk mencapai tujuan ini maka dibutuhkan suatu system yang dapat mengakses ke banyak data secara real time. System ini dibuat untuk banyak pengguna komponen yang memiliki kecepatan rendah, karena pengguna jenis ini rentan sekali terkena fail karena tidak sinkronnya server google dengan pengguna. maka diperlukan system yang dapat memonitor dirinya sendiri dengan konstan dan dapat mendeteksi, mentolerir maupun me-recover dengan cepat component failure yang terdapat pada basis routine.
System dapat menyimpan banyak file berukuran besar. System diharapkan dapat menampung jutaan file berukuran lebih dari 100 MB. File- file yang berukuran giga (GB) harus di-manage oleh system dengan efisien. System juga tidak boleh melupakan file-file berukuran kecil, system juga harus menampung file tersebut. System tidak mengoptimalkan penyimpanan file-file kecil dengan harapan file-file besar dapat ter-manage dengan baik.
Apabila client mengubah atau memodifikasi atau juga meng-update situs-situs mereka, maka biasanya search engine provider akan melakukan overwrite terhadap file situs tersebut di server mereka, hal ini berbeda denga google dengan GFS nya, GFS mendukung system appending file sehingga system hanya menambah informasi terhadap file situs yang telah di-update bukan menulis ulang file tersebut. Hal ini jelas akan mengurangi redundansi kerja.
System juga harus dapat mengantisipasi apabila terdapat lebih dari satu client yang melakukan appending terhadap file yang sama. System diharuskan mempunyai algoritma semantic untuk melakukan sinkronisasi yang tepat agar file tidak terlambat untuk dibaca maupun untuk ditulis.
Interface
GFS menyediakan file system dengan interface yang mudah dipahami oleh user. File disusun secara hirarki pada direktori dan diidentifikasi oleh nama path. File system ini mendukung operasi standar seperti; create, delete, open, close, read, dan write pada file. Selain itu GFS juga mendukung operasi snapshot dan record append. Snapshot membuat salinan dari file atau directory tree dengan biaya rendah. Record append memungkinkan beberapa klien untuk menambahkan data ke file yang sama pada waktu yangbersamaan dimana data yang ditambahkan oleh setiap klien itu dijamin kerahasiaannya.
Berikut merupakan karakteristik GFS:
ØDapat terdistribusi pada multi-level map
ØFault-tolerant, presisi yang tinggi
ØBerskala besar
Ribuan server
Memory data berukuran terabyte
Disk-based data berukuran petabyte
Dapat melakukan jutaan read/write per detik, hal ini mengakibatkan efisiensi pada scanning
Self-Managing
Server dapat ditambah/dikurangi secara dinamik
Server dapat mengantisipasi adanya ketidakseimbangan
GFS mulai di desain dan diimzplementasikan pada awal tahun 2004 dan digunakan untuk perkembangan berbagai proyek, seperti:
ØGoogle print
ØMy search history
ØOrkut
ØCrawling/indexing pipeline
ØGoogle Maps/Google Earth
ØBlogger
ØDan masih banyak yang lainnya
Hingga saat ini GFS telah menangani lebih dari 100 bigtable cells, dan diharapkan dapat menangani sampai lebih dari 200 TB data yang tersebar dilebih dari ribuan mesin. Untuk mencapai hal ini Google merencanakan untuk memperbesar cells pada bigtable.
Arsitektur
Sebuah cluster pada GFS terdiri dari satu master dan banyak chunkserver dan dapat diakses oleh banyak klien. Setiap chunkserver menggunakan mesin Linux yangbertugas untuk memproses server pada level user.
File dibagi-bagi kedalam beberapa chunk yang ukurannya telah ditetapkan. Setiap chunk diidentifikasi oleh 64 bit chunk handle yang dijalankan oleh master setiap sebuah chunk dibuat. Chunkserver menyimpan chunk pada local disk sebagai file Linux dan membaca atau menulis chunk data yang telah dispesifikasi oleh chunk handle dan jangkauan byte-nya. Agar dapat berjalan dengan baik,setiap chunk dibuat salinannya pada banyak chunkserver. Untuk default, system menyimpan tiga salinan, meskipun demikian, user dapat mengatur level salinan untuk region yang berbeda.
Master menjaga semua metadata file system. Termasuk, namespace, informasi access control, mapping dari file ke chunk, dan lokasi chunk. Master juga mengendalikan aktivitas system secara keseluruhan seperti, management chunk, chunk sampah yang sudah tidak terpakai lagi, dan juga migrasi chunk antar chunkserver. Master secara periodik berkomunikasi dengan setiap chunkserver untuk memberikan instruksi dan mengambil data state nya.
Setiap klien memiliki kode yang yang terhubung ke setiap aplikasi yang tertanam pada file system API dan terhubung dengan master dan chunkserver untuk read atau write data. Klien saling berhubungan dengan master untuk operasi metadata, tapi seluruh komunikasi data-bearing langsung menuju chunkserver.
Klien dan chunkserver tidak dapat melakukan cache pada data file. Cache yang dilakukan oleh klien hanya memberikan sedikit keuntungan karena kebanyakan aplikasi merujuk kepada file yang besar atau memiliki working sets yang terlalu besar untuk dilakukan cache terhadapnya.
Single Master
Dengan adanya single master dapat menyederhanakan desain system dan dapat mendukung master untuk membuat pergantian chunk dan keputusan untuk membuat replikasi chunk. Karena master yang digunakan hanya satu maka operasi read/write harus diminimalkan sesedikit mungkin agar system tidak mengalami bottleneck. Oleh karena itu klien dibuat untuk tidak dapat melakukan operasi read/write langsung terhadap master. Klien dapat melakukan berbagai operasi melalui chunkserver yang nantinya akan langsung disampaikan kepada master.
Skema interaksi antara klien chunkserver dan master adalah sebagai berikut.
Pertama, dengan menggunakan chunk size yang telah ditetapkan, klien dapat memberikan nama file dan byte offset yang telah ditetapkan oleh aplikasi kepada chunk dimana index file itu berada.
Lalu, chunk mengirim pesan kepada master yang berisi nama file dan index chunk. Master menjawab dengan menggunakan chunk handle dan lokasi dari replica. Klien mendapatkan informasi ini menggunakan nama file dan index chunk sebagai kunci.
Klien lalu mengirim permintaan kepada salah satu replica, biasanya yang terdekat. Permintaan tersebut menentukan chunk handle dan byte range chunk tersebut. Selama membaca dari chunk yang sama sudah tidak diperlukan lagi interaksi antara klien dengan master sampai informasi tersebut habis atau file terbuka. Faktanya, klien biasanya meminta banyak chunk sekaligus dalam satu permintaan dan master dapat pula memasukkan informasi kepada chunk berdasarkan permintaan tersebut. Informasi tambahan ini mengesampingkan interaksi klien-master.
Untuk lebih jelasnya dapat dilihat pada gambar.
Chunk Size
Chunk size adalah adalah salah satu parameter kunci dari file system ini. Dengan besar 64 MB, lebih besar dari ukuran block pada file system biasa. Setiap replica chunk disimpan sebagai file Linux pada chunkserver dan dapat ditambah apabila diperlukan. Alokasi ruang kosong dapat menghindari pemborosan ruang, dimana ukuran chunk yang sangat besar.
Dengan ukuran chunk yang sangat besar dapat memberikan beberapa keuntungan yang penting, diantaranya:
ØMengurangi interaksi antara klien dengan master
Hal ini sangatlah signifikan karena aplikasi kebanyakan melakukan proses read/write terhadap file besar secara berulang-ulang.
ØKlien dapat melakukan banyak operasi
Karena ukurannya yang besar, hal ini memungkinkan klien untuk melakukan banyak operasi sekaligus pada chunk yang diberikan.
ØMengurangi ukuran metadata pada master
Hal ini memungkinkan kita untuk menyimpan metadata di memory
Metadata
Master menyimpan tiga jenis metadata: file dan namespace chunk, mapping dari file ke chunk, dan lokasi setiap replica chunk. Semua metadata disimpan didalam memori master. Namespace dan mapping file ke chunk juga disimpan melalui operasi log kedalam local disk master dan dibuat replikanya pada remote machine. Dengan menggunakan log file, dapat mendukung kita untuk meng-update state master dengan mudah dan tanpa resiko crash pada master. Master tidak menyimpan informasi lokasi chunk secara terus-menerus. Melainkan, meminta setiap chunkserver akan chunk ketika master startup dan pada saat chunkserver bergabung dengan cluster.
Lease dan Mutation Order
Mutation adalah operasi yang mengubah konten metadata sebuah chunk seperti operasi write atau append. Setiap mutation dilakukan pada semua replika chunk. Lease digunakan untuk menjaga konsistensi perintah mutation. Master memberikan satu chunk lease pada salah satu replika, yang disebut primary. Primary memberikan perintah secara berurutan untuk semua mutation terhadap chunk. Semua replika mengikuti perintah ini ketika menerapkan mutation. Perintah mutation global ditentukan oleh perintah lease yang diberikan master, dan dengan lease yang diperintahkan primary.
Mekanisme lease didesain untuk memperkecil manajemen overhead pada master. Sebuah lease memiliki timeout 60 detik. Bagaimanapun, selama chunk sedang dalam proses mutation, primary dapat meminta dan menerima tambahan waktu dari master setiap saat.
Ilustrasi alur control sebuah operasi write sebagai berikut:
1)Klien meminta master chunkserver yang mana yang memegang lease untuk sebuah chunk dan lokasi dari replikanya. Jika tidak ada yang memiliki lease tersebut, master memberikan lease terhadap replika yang dipilihnya.
2)Master membalas dengan identitas primary dan lokasi replika lainnya. Klien menyimpan data ini untuk mutation selanjutnya. Kontak dengan master diperlukan lagi hanya ketika primary tidak dapat dicapai atau balasan yang tidak lagi menyertakan lease.
3)Klien memasukkan data ke semua replika. Klien dapat melakukannya dengan urutan bebas. Setiap chunkserver akan menyimpan data di dalam internal LRU buffer cache sampai data digunakan. Dengan menggandengkan alur data dari alur control, kita dapat meningkatkan kinerja dengan menjadwalkan alur data yang mahal berdasarkan topologi jaringan tanpa memerhatikan chunkserver yang mana yang sebagi primary.
4)Ketika semua replika telah menerima data, klien mengirimkan operasi write pada primary. Permintaan ini memerintahkan data untuk dimasukkan terlebih dahulu pada seluruh replika. Primary memberikan serial number untuk semua mutation yang diterimanya.
5)Primary meneruskan permintaan write ini ke semua replika sekunder. Setiap replika sekunder menerapkan mutation pada serial number yang sama yang telah ditetapkan oleh primary.
6)Semua replika sekunder membalas primary bahwa mereka telah menyelesaikan operasi.
7)Primary lalu membalas ke klien. Setiap error yang dialami pada setiap replika dilaporkan kepada klien.
Ilustrasi tersebut dapat digambarkan dengan bagan sebagai berikut:
Kesimpulan
Google File System menunjukkan kualitas yang esensial untuk mendukung data processing berskala besar. Desain file system ini dibuat spesifik berdasarkan aplikasi yang Google tawarkan, sehingga akan sedikit sulit untuk diterapkan untuk keperluan lain.
GFS dibuat dengan terlebih dahulu memeriksa file system tradisional dan dibandingkan dengan kebutuhan teknologi dan aplikasi yang dibutuhkan oleh Google.
File system ini menyediakan fault tolerant yang dimonitor secara konstan, mereplikasi data-data krusial, dan system recovery yang cepat dan otomatis. Replikasi chunk mendukung system untuk dapat mentolerir kegagalan chunkserver.
File system ini memberikan keleluasaan untuk melakukan operasi read dan write pada berbagai macam task. Hal ini dimungkinkan karena terpisahnya control file system, yang dapat melalui master, dari transfer data, yang langsung melewati antara chunkserver dan klien. Keikutsertaan master dalam berbagai operasi di minimalisir oleh besarnya ukuran chunk dan oleh lease chunk dengan replika primary dalam mutation data. Hal ini membuat sentralisasi master sulit terkena bottleneck.
GFS telah berhasil memenuhi kebutuhan penyimpanan dan dengan luas digunakan oleh Google sebagai storage platform untuk penelitian dan pengembangan data processing. File system ini merupakan alat yang sangat penting yang dapat membuat kita untuk lebih inovatif dan mengatasi masalah untuk skala web yang luas.
