Beberapa system penskalaan (Exploring Steem Scalability) yang harus dipelajari sebelum menjadi Witness

elnazry (46)in #steem • 6 years ago

Dalam postingan kali ini kami akan membahas beberapa kekhawatiran yang telah diangkat mengenai peningkatan penggunaan RAM node steemd, serta rencana skala masa depan kami. Sementara tantangan yang terkait penskalaan bukanlah sesuatu yang kita anggap enteng, kami juga berpikir bahwa kekhawatiran telah dikemukakan karena beberapa kesalahahaman tentang cara mengoperasikan node steemd secara tepat/optimal. Kami akan memberikan beberapa panduan mengenai hal inipada penjelasan dibawah ini, dan kami juga akan berbicara tentang beberapa perubahan yang kami miliki untuk menumbuhkan proyeksi masa depan.

Apa itu skalabilitas?

komunitas steem sangat berkembang pesat, begitu juga dengan blockchain steem. Pertumbuhan itu hebat tetapi itu membawa tantangan penskalaan bagi kami. Proyek proyek lain seperti (Bitcoin dan Etherem) telah macet dengan masalah skala mereka selama bertahun tahun tidak mampu mengadopsi perubahan sisignifikan untuk memenuhi tuntutan yang terus meningkat bahwa peningkatan penggunaan telah ditempatkan pada blockchain mereka. Disisi lain steem telah berevolusi dengan cepat dan memenuhi tantangan ini secara langsung, sehingga memungkinkannya untuk memproses lebih banyak transaksi daripada setiap kombinasi blockchain lainnya. Dengan kata lain, mayoritas transaksi blockchain yang terjadi secara global sedang dilakukan pada steem.

Kami telah mampu melakukan ini karena tim kami terdiri dari susunan yang terus berkembang daripada insinyur blockchain yang paling berbakat dan inovatif di planet ini.Itu membuat kami sangat sadar akan tantangan skala didepan kami, dan kami ingin meyakinkan anda bahwa kami cukup siap untuk menghadapinya. Meskipun demikian kami juga ingin mendengar pendapat anda di komentar.

Sejarah singkat scaling

Keputusan paling penting sehubungan dengan penskalaan adalah tempat dimana anda memulai. Pondasi yang lebih terukur, penumpukan yang lebih terukur. Kemampuan menumpuk tumpukan cenderung harus dimiliki, paling baik dalam menghubungkan eksponensial ke titik awal. Sangatlah jarang seorang arsitektur dapat meningkatkan kemampuan kerja untuk mendukung dari 3.000 orang hingga 3.000.000 orang dalam semalam. Dalam hal skalabilitas (Graphene) adalah sebuah komponen penting dalam strategi itu.

Chain base dan AppBase

Upgrade terkait skalabilitas besar pertama adalah penggantian Grafena dengan ChainBase. Berkat beban lebih cepat dan kali keluar, dan peningkatan ketahanan terhadap kerusakan System, ChainBase adalah hal yang penting untuk memungkinkan Steem mendapatkan proses saat volume transaksi.

Peningkatan berikutnya yang hampir selesai adalah AppBase, berkat kerja keras @vandeberg, yang selanjutnya meningkatkan skalabilitas steem secara keseluruhan melalui modularisasi.
AppBase akan memungkinkan banyak komponen dari blockchain steem untuk berjalan secara independen, yang akan memungkinkan steemd untuk mengambil keuntrungan yang lebih baik dari sifat multi threaded komputer, dan bahkan memungkinkan berbagi komponen blockchain untuk dijalankan pada server yang berbeda.

Mengoptimalkan steemd Node: Blog Log + State File

Sehubungan dengan operasi steemd saat ini, sangat penting untuk memahami bahwa Steem membutuhkan dua penyimpanan data :

Blog Log (Blockchain itu sendiri)
State Base (Status terkini objek steem)

Kedua hal tersebut sangat penting untuk memferifikasi intyegritas blok baru dan mengindek ulang State Base jika diperlukan, Sate Base sama halnya seperti saldo akun, posting, dan vote, yang didukung oleh disk, tetapi diakses melalui tehnik yang disebut file memori yang di petakan . Tehnik ini diperkenalkan pada bulan Desember 2016 dengan judul ChainBase.

Semuanya RAM

Banyak operator node menyarankan bahwa server harus memiliki RAM yang memadai untuk menyimpat seluruh status file steem, karena fakta tentang kinerja steem akan turun ketika system operasi mulai "pagging" memori steem, sebagai tehnik managemen memori umum. Kami ingin menjelaskan bahwa tidak diperlukan tehnik ini untuk menjalankan node steemd. Ini hanya sebatas tehnik yang valid untuk meningkatkan kinerja indek yang kembali pada node dan servis panggilan API saja, dalam sebagian kasus besar (Termasuk witness, seed, dan exchange nodes), itu sebenarnya sudah cukup untuk menyimpan file memori bersama SSD atau MVMe drive, bukan didalam RAM.

Persyaratan RAM untuk Witness dan Seed Node

Ketika menjalankan node steemd dengan server witness. Steemit merekomendasikan kapasitas RAM sebesar 16 GB, meskipu dengan RAM 8 GB sudah memadai untuk penggunaa steemd reindex.
Jika file memori bersama disimpan /dev/shm/, maka ram tambahan akan diperlukan untuk menyimpan seluruh File state, tetapi ini bukanlah konfigurasi yang disarankan. Untuk menghindari kebutuhan ram tambahan , file memori bersama dapat disimpan langsung pada SSD atau NVMe drive.

Server dengan RAM 8-16 GBakan lambat dengan reindex, tetapi akan berfungsi dengan baik sebagai Node seed/ Witness setelah up to date dengan block terbaru, maka dari itu untuk pekerjaan yang optimal sangat disarankan dengan memakai kapasitas RAM sebesar 32 GB, itu bukanlah syarat untuk menjadi saksi, tapi itu hanyalah beroperasi secara benar.

Ukuran memori bersama

Konfigurasi default untuk node steemd menyimpan file memori bersama dalam data/blockchain direktori. Selama lokasi ini berada dalam drive yang sangat cepat (SSD/NVMe} dengan ruuang yang cukup, maka pengaturan default akan berfungsi.

Rekomendasi yang harus dimiliki saat ini sebesar 150 GB penyimpanan SSD, yang mencakup blog_log sebesar 90 GB dan yang mencakup shared_memory . bin sebanyak 33 GB, jumlah ini akan meningkat seiring waktu.Apabila setiap file memory telah meningkat melampaui ukuran yang telah dikonfigurasikan dalam config file, maka itu harus memperbaharui konfigurasi ke ukuran yang lebih besar dan harus memulai lagi node. Akan ada perubahan yang akan dimasukkan dalam rilis berikutnya (steem19.4) yang secara otomatis akan meningkatkan batas yang sesuai kebutuhan, tanpa harus me-restart node. Ini akan dapat dikonfigurasikan dan dimatikan sepenuhnya jika anda ingin menyimpan file /dev/ehm. anda.

"Full Node" Requirements (syarat)

Node yang menjalankan plugin tambahan API (terutama riwayat akun) akan membutuhkan lebih banyak RAM untuk mendukung file status yang lebih besar, secara teknis dapat berjalan pada server 64 GB, tetapi akan sangat lambat untuk reindex, dan akan lambat juga dalam menangani panggilan API karena algoritma paging system operasi tidak menangani file yang telah dipetakan oleh memory dengan sangat baik.Node dengan RAM 64-256 GB dan Drive SSD/NVMe akan memadai untuk beberapa kasus, tergantung penggunaan pada bebannya.

Meningkatkan kinerja tinggi pada penggunaan Node

Untuk cara terbaik dalam menggunakan Node saat ini adalah memiliki RAM yang cukup untuk menyimpan seluruh database. Teknik yang kami gunakan untuk menurunkan persyaratan memory pada "simpul lengkap"termasuk riwayat akun, adalah membagi Node API menjadi dua server. Satu server hanya menjalankan riwayat akun, dan server satu lagi menjalankan sisanya. Kemungkinan kedua server tersebut akan memakai kapasitas RAM kurang dari 256 GB, kami sangat menyarankan untuk untuk menjalankan riwayat akun pada Node khususjika anda menginginkan riwayat lengkap dari semua akun.

Mengoptimalkan use case dari "Full Node" adalah prioritas utama kami, jika anda memelukan riwayat dari akun tertentu, atau hanya peduli pada operasi tertentu, Hardware anda mungkin akan berkurang secara signifikan.

Rencana skala masa depan

Saat ini kami sedang mengerjakan beberapa proyek yang akan mengurangi persyaratan memory, dengan cara memindahkan sebagian besar logika API kedalam plugin non-konsensusseperti HiveMine dan SBDS. Ini akan memungkinkan banyak fungsi untuk menjalankan penyimpananSSD, daripada di RAM - yang akan menurunkan biaya operasi. Dengan membongkar data ke HiveMine /SBDS/RocksDB, kita harus mengurangi persyaratan penuh untuk Node yang merupakan tujuan penting bagi kita.

RocksDB

Selain plugin non-konsensus, kami telah memulai penelitian tentang penggunaan penyimpanan data alternatif dan pindah dari Chainbase. Salahsatu penyimpanan data yang menjanjikan adalah RocksDB.

RocksDB adalah penyimpanan data cepat on-diskdengan lapisan caching lanjutan, yang selanjutnya dapat meminimalkan latensi saat membaca/menulis ke disk atau dari diskkarena dioptimalkan untuk penyimpanan cepat, latensi rendah.

Telah digunakan juga dalam system produksi perusahaan skala web seperti Facebook, Yahoo, *Linkedln, dengan peningkatan kinerja berkat kemampuannya untuk mengeksploitasi beberapa core CPU dan penyimpanan SSD sebagai beban kerja input/output. Daya tahan SSD yang lebih lama dan lebih banyak kapasitas IO yang tersedia untuk menangani queries.

Modularisasi lebih lanjut

Kami juga bekerja untuk memodularisasi blockchain diluar bahkan apa yang semula direncanakan untuk implementasi AppBase awal, misalnya, dengan memiliki layanan terpisah yang dapat dijalankan pada server yang berbeda. Ini akan memungkinkan proses untuk lebih tersebar di banyak server kecil, meningkatkan fleksibilitas dan mengurangi biaya.

Kesimpulan

Karena proyek blockchain menjadi lebih umum, skalabilitas seiring waktu juga akan menjadi banyak perhatian. Menjadi blockchain skalabel bukan hanya mampu membuat satu kali perbaikan untuk memenuhi sumber daya saat ini. Ini juga tentang siap menghadapi tantangan masa depan atau tidak.

Steem telah terbukti menjadi blockchain publik tercepat dan paling sering ditransaksikan,dan skalabilitas akan terus menjadi fokus utama kami. Kami tau bahwa tantangan penskalaan tidak akan pernah sepenuhnya hilang, itulah sebabnya kami terus berinovasi untuk memastikan pertumbuhan yang datang kedepan, kami telah siap.

Note :

Postingan ini telah saya rubah kedalam bahasa Indonesia. Saya mendapatkan kesempatan ini dari seorang konten direktor Steemit yaitu @andrarchy, untuk melihat postingan original maka anda dapat menuju Link Exploring Steem Scalability

Jangan lupa untuk berbagi pikiran dan wawasan anda pad komentar.

Salam hangat saya @elnazry kepada seluruh stemians dunia.