dragonfly

Sebelum melanjutkan, mohon pertimbangkan untuk memberi kami bintang GitHub ️. Terima kasih!

Bahasa lain: 简体中文 日本語 한국어

Situs web • Dokumen • Panduan Cepat • Perselisihan Komunitas • Forum Capung • Bergabunglah dengan Komunitas Capung

Diskusi GitHub • Masalah GitHub • Berkontribusi • Dragonfly Cloud

Penyimpanan data dalam memori paling efisien di dunia

Dragonfly adalah penyimpanan data dalam memori yang dibuat untuk beban kerja aplikasi modern.

Sepenuhnya kompatibel dengan Redis dan Memcached API, Dragonfly tidak memerlukan perubahan kode untuk diadopsi. Dibandingkan dengan penyimpanan data dalam memori yang lama, Dragonfly memberikan throughput 25X lebih banyak, tingkat cache hit yang lebih tinggi dengan latensi ekor yang lebih rendah, dan dapat berjalan dengan sumber daya hingga 80% lebih sedikit untuk beban kerja berukuran sama.

Isi

• Tolok ukur
• Mulai cepat
• Konfigurasi
• Peta jalan dan status
• Keputusan desain
• Latar belakang
• Bangun dari sumber

Tolok ukur

Pertama-tama kami membandingkan Dragonfly dengan Redis pada instance m5.large yang biasa digunakan untuk menjalankan Redis karena arsitektur single-threadnya. Program benchmark dijalankan dari instance uji beban lain (c5n) di AZ yang sama menggunakan memtier_benchmark -c 20 --test-time 100 -t 4 -d 256 --distinct-client-seed

Dragonfly menunjukkan kinerja yang sebanding:

1. SET ( --ratio 1:0 ):

ulang	DF
QPS: 159K, P99,9: 1,16 md, P99: 0,82 md	QPS:173K, P99,9: 1,26 md, P99: 0,9 md

2. DAPATKAN ( --ratio 0:1 ):

ulang	DF
QPS: 194K, P99,9: 0,8 md, P99: 0,65 md	QPS: 191K, P99,9: 0,95 md, P99: 0,8 md

Tolok ukur di atas menunjukkan bahwa lapisan algoritmik di dalam DF yang memungkinkannya melakukan penskalaan secara vertikal tidak memakan banyak korban saat menjalankan single-threaded.

Namun, jika kita mengambil contoh yang lebih kuat (m5.xlarge), kesenjangan antara DF dan Redis mulai membesar. ( memtier_benchmark -c 20 --test-time 100 -t 6 -d 256 --distinct-client-seed ):

1. SET ( --ratio 1:0 ):

ulang	DF
QPS: 190K, P99,9: 2,45 md, P99: 0,97 md	QPS: 279K , P99,9: 1,95 md, P99: 1,48 md

2. DAPATKAN ( --ratio 0:1 ):

ulang	DF
QPS: 220K, P99,9: 0,98 md, P99: 0,8 md	QPS: 305K, P99,9: 1,03 md, P99: 0,87 md

Kapasitas throughput Dragonfly terus bertambah seiring dengan ukuran instans, sementara Redis single-thread mengalami hambatan pada CPU dan mencapai maksimum lokal dalam hal performa.

Jika kita membandingkan Dragonfly dan Redis pada instance c6gn.16xlarge yang paling berkemampuan jaringan, Dragonfly menunjukkan peningkatan throughput sebesar 25X lipat dibandingkan dengan proses tunggal Redis, yang melampaui 3,8 juta QPS.

Metrik latensi persentil ke-99 Dragonfly pada throughput puncaknya:

op	r6g	c6gn	c7g
mengatur	0,8 ms	1 ms	1 ms
mendapatkan	0,9 ms	0,9 ms	0,8 ms
setex	0,9 ms	1,1 md	1,3 md

Semua tolok ukur dilakukan menggunakan memtier_benchmark (lihat di bawah) dengan jumlah thread yang disetel per server dan jenis instans. memtier dijalankan pada mesin c6gn.16xlarge terpisah. Kami menetapkan waktu kadaluarsa ke 500 untuk benchmark SETEX untuk memastikannya dapat bertahan pada akhir pengujian.

  memtier_benchmark --ratio ... -t < threads > -c 30 -n 200000 --distinct-client-seed -d 256 
     --expiry-range=...

Dalam mode pipeline --pipeline=30 , Dragonfly mencapai 10 juta QPS untuk operasi SET dan 15 juta QPS untuk operasi GET.

Capung vs. Memcached

Kami membandingkan Dragonfly dengan Memcached pada instans c6gn.16xlarge di AWS.

Dengan latensi yang sebanding, throughput Dragonfly mengungguli throughput Memcached dalam beban kerja tulis dan baca. Dragonfly menunjukkan latensi yang lebih baik dalam beban kerja tulis karena pertentangan pada jalur tulis di Memcached.

TETAPKAN tolok ukur

pelayan	QPS (ribuan qps)	latensi 99%	99,9%
Capung	? 3844	? 0,9 ms	? 2,4 ms
Memcache	806	1,6 mdtk	3,2 ms

DAPATKAN patokan

pelayan	QPS (ribuan qps)	latensi 99%	99,9%
Capung	? 3717	1 ms	2,4 ms
Memcache	2100	? 0,34 md	? 0,6 ms

Memcached menunjukkan latensi yang lebih rendah untuk benchmark baca, namun juga throughput yang lebih rendah.

Efisiensi memori

Untuk menguji efisiensi memori, kami mengisi Dragonfly dan Redis dengan ~5 GB data menggunakan perintah debug populate 5000000 key 1024 , mengirimkan lalu lintas pembaruan dengan memtier , dan memulai snapshotting dengan perintah bgsave .

Gambar ini menunjukkan bagaimana setiap server berperilaku dalam hal efisiensi memori.

Dragonfly 30% lebih hemat memori dibandingkan Redis dalam kondisi idle dan tidak menunjukkan peningkatan nyata dalam penggunaan memori selama fase snapshot. Pada puncaknya, penggunaan memori Redis meningkat hingga hampir 3X lipat dibandingkan Dragonfly.

Dragonfly menyelesaikan snapshot lebih cepat, dalam beberapa detik.

Untuk informasi lebih lanjut tentang efisiensi memori di Dragonfly, lihat dokumen Dashtable kami.

Konfigurasi

Dragonfly mendukung argumen umum Redis jika memungkinkan. Misalnya, Anda dapat menjalankan: dragonfly --requirepass=foo --bind localhost .

Dragonfly saat ini mendukung argumen khusus Redis berikut:

• port : Port koneksi Redis ( default: 6379 ).
• bind : Gunakan localhost untuk hanya mengizinkan koneksi localhost atau alamat IP publik untuk mengizinkan koneksi ke alamat IP tersebut (yaitu dari luar juga). Gunakan 0.0.0.0 untuk mengizinkan semua IPv4.
• requirepass : Kata sandi untuk otentikasi AUTH ( default: "" ).
• maxmemory : Batas memori maksimum (dalam byte yang dapat dibaca manusia) yang digunakan oleh database ( default: 0 ). Nilai maxmemory 0 berarti program akan secara otomatis menentukan penggunaan memori maksimumnya.
• dir : Dragonfly Docker menggunakan folder /data untuk snapshotting secara default, CLI menggunakan "" . Anda dapat menggunakan opsi -v Docker untuk memetakannya ke folder host Anda.
• dbfilename : Nama file untuk menyimpan dan memuat database ( default: dump ).

Ada juga beberapa argumen khusus Dragonfly:

• memcached_port : Port untuk mengaktifkan API yang kompatibel dengan Memcached ( default: disabled ).

• keys_output_limit : Jumlah maksimum kunci yang dikembalikan dalam perintah keys ( default: 8192 ). Perhatikan bahwa keys adalah perintah yang berbahaya. Kami memotong hasilnya untuk menghindari ledakan penggunaan memori saat mengambil terlalu banyak kunci.

• dbnum : Jumlah maksimum database yang didukung untuk select .

• cache_mode : Lihat bagian desain cache baru di bawah.

• hz : Frekuensi evaluasi kedaluwarsa kunci ( default: 100 ). Frekuensi yang lebih rendah menggunakan lebih sedikit CPU saat idle sehingga mengorbankan tingkat penggusuran yang lebih lambat.

• snapshot_cron : Ekspresi jadwal Cron untuk snapshot cadangan otomatis menggunakan sintaks cron standar dengan rincian menit ( default: "" ). Berikut adalah beberapa contoh ekspresi jadwal cron di bawah, dan silakan membaca lebih lanjut tentang argumen ini di dokumentasi kami.

  Ekspresi Jadwal Cron	Keterangan
  * * * * *	Setiap menit
  */5 * * * *	Setiap menit ke 5
  5 */2 * * *	Pada menit ke 5 lewat setiap jam ke 2
  0 0 * * *	Pukul 00.00 (tengah malam) setiap hari
  0 6 * * 1-5	Pukul 06.00 (fajar) dari Senin sampai Jumat

• primary_port_http_enabled : Memungkinkan mengakses konsol HTTP pada port TCP utama jika true ( default: true ).

• admin_port : Untuk mengaktifkan akses admin ke konsol pada port yang ditetapkan ( default: disabled ). Mendukung protokol HTTP dan RESP.

• admin_bind : Untuk mengikat koneksi TCP konsol admin ke alamat tertentu ( default: any ). Mendukung protokol HTTP dan RESP.

• admin_nopass : Untuk mengaktifkan akses admin terbuka ke konsol pada port yang ditetapkan, tanpa memerlukan token autentikasi ( default: false ). Mendukung protokol HTTP dan RESP.

• cluster_mode : Mode cluster didukung ( default: "" ). Saat ini hanya mendukung emulated .

• cluster_announce_ip : IP yang diumumkan oleh perintah cluster kepada klien.

• announce_port : Port yang diumumkan oleh perintah cluster ke klien, dan ke master replikasi.

Contoh skrip awal dengan opsi populer:

./dragonfly-x86_64 --logtostderr --requirepass=youshallnotpass --cache_mode=true -dbnum 1 --bind localhost --port 6379 --maxmemory=12gb --keys_output_limit=12288 --dbfilename dump.rdb

Argumen juga dapat diberikan melalui:

• --flagfile <filename> : File harus mencantumkan satu tanda per baris, dengan tanda sama dengan, bukan spasi untuk tanda nilai kunci. Tidak diperlukan tanda kutip untuk nilai bendera.
• Mengatur variabel lingkungan. Tetapkan DFLY_x , di mana x adalah nama sebenarnya dari bendera, peka huruf besar-kecil.

Untuk opsi lainnya seperti manajemen log atau dukungan TLS, jalankan dragonfly --help .

Peta jalan dan status

Dragonfly saat ini mendukung ~185 perintah Redis dan semua perintah Memcached selain cas . Hampir setara dengan Redis 5 API, pencapaian Dragonfly berikutnya adalah menstabilkan fungsionalitas dasar dan mengimplementasikan API replikasi. Jika ada perintah yang Anda perlukan namun belum diterapkan, silakan buka terbitan.

Untuk replikasi asli Dragonfly, kami merancang format log terdistribusi yang akan mendukung kecepatan lebih tinggi.

Mengikuti fitur replikasi, kami akan terus menambahkan perintah yang hilang untuk API Redis versi 3-6.

Silakan lihat Referensi Perintah kami untuk perintah saat ini yang didukung oleh Dragonfly.

Keputusan desain

Desain cache baru

Dragonfly memiliki algoritma caching tunggal, terpadu, adaptif yang sederhana dan hemat memori.

Anda dapat mengaktifkan mode caching dengan meneruskan tanda --cache_mode=true . Setelah mode ini aktif, Dragonfly akan mengeluarkan item yang paling kecil kemungkinannya untuk ditemukan di masa mendatang, tetapi hanya jika item tersebut mendekati batas maxmemory .

Batas waktu kedaluwarsa dengan akurasi relatif

Rentang kedaluwarsa dibatasi hingga ~8 tahun.

Batas waktu kedaluwarsa dengan presisi milidetik (PEXPIRE, PSETEX, dll.) dibulatkan ke detik terdekat untuk tenggat waktu lebih besar dari 2^28ms , yang memiliki kesalahan kurang dari 0,001% dan dapat diterima untuk rentang yang besar. Jika ini tidak sesuai untuk kasus penggunaan Anda, hubungi atau buka terbitan yang menjelaskan kasus Anda.

Untuk perbedaan lebih detail antara tenggat waktu kedaluwarsa Dragonfly dan implementasi Redis, lihat di sini.

Konsol HTTP asli dan metrik yang kompatibel dengan Prometheus

Secara default, Dragonfly mengizinkan akses HTTP melalui port TCP utamanya (6379). Benar, Anda dapat terhubung ke Dragonfly melalui protokol Redis dan melalui protokol HTTP — server mengenali protokol tersebut secara otomatis selama inisiasi koneksi. Silakan dan coba dengan browser Anda. Akses HTTP saat ini tidak memiliki banyak informasi tetapi akan mencakup informasi debugging dan manajemen yang berguna di masa depan.

Buka URL :6379/metrics untuk melihat metrik yang kompatibel dengan Prometheus.

Metrik yang diekspor Prometheus kompatibel dengan dasbor Grafana, lihat di sini.

Penting! Konsol HTTP dimaksudkan untuk diakses dalam jaringan yang aman. Jika Anda mengekspos port TCP Dragonfly secara eksternal, kami menyarankan Anda untuk menonaktifkan konsol dengan --http_admin_console=false atau --nohttp_admin_console .

Latar belakang

Dragonfly dimulai sebagai eksperimen untuk melihat tampilan penyimpanan data dalam memori jika dirancang pada tahun 2022. Berdasarkan pembelajaran dari pengalaman kami sebagai pengguna penyimpanan memori dan insinyur yang bekerja di perusahaan cloud, kami tahu bahwa kami perlu melestarikan dua properti utama untuk Dragonfly: Jaminan atomisitas untuk semua operasi dan latensi sub-milidetik yang rendah pada throughput yang sangat tinggi.

Tantangan pertama kami adalah bagaimana memanfaatkan sepenuhnya sumber daya CPU, memori, dan I/O menggunakan server yang saat ini tersedia di cloud publik. Untuk mengatasi hal ini, kami menggunakan arsitektur shared-nothing, yang memungkinkan kami mempartisi keyspace penyimpanan memori antar thread sehingga setiap thread dapat mengelola potongan data kamusnya sendiri. Kami menyebut irisan ini "pecahan". Pustaka yang mendukung manajemen thread dan I/O untuk arsitektur shared-nothing bersumber terbuka di sini.

Untuk memberikan jaminan atomisitas pada operasi multi-kunci, kami menggunakan kemajuan dari penelitian akademis terbaru. Kami memilih makalah "VLL: desain ulang manajer kunci untuk sistem basis data memori utama" untuk mengembangkan kerangka transaksional untuk Dragonfly. Pilihan arsitektur shared-nothing dan VLL memungkinkan kami menyusun operasi multi-kunci atom tanpa menggunakan mutex atau spinlock. Ini merupakan tonggak penting bagi PoC kami dan kinerjanya menonjol dibandingkan solusi komersial dan sumber terbuka lainnya.

Tantangan kedua kami adalah merekayasa struktur data yang lebih efisien untuk toko baru. Untuk mencapai tujuan ini, kami mendasarkan struktur tabel hash inti kami pada kertas "Dash: Hashing yang Dapat Diskalakan pada Memori Persisten". Makalah itu sendiri berpusat di sekitar domain memori persisten dan tidak terkait langsung dengan penyimpanan memori utama, namun masih paling dapat diterapkan pada masalah kita. Desain tabel hash yang disarankan dalam makalah ini memungkinkan kami mempertahankan dua properti khusus yang ada dalam kamus Redis: Kemampuan hashing tambahan selama pertumbuhan penyimpanan data, kemampuan untuk menjelajahi kamus saat terjadi perubahan menggunakan operasi pemindaian tanpa status. Selain kedua properti tersebut, Dash lebih efisien dalam penggunaan CPU dan memori. Dengan memanfaatkan desain Dash, kami dapat berinovasi lebih jauh dengan fitur-fitur berikut:

• Kedaluwarsa catatan yang efisien untuk catatan TTL.
• Algoritme penggusuran cache baru yang mencapai tingkat hit lebih tinggi dibandingkan strategi cache lainnya seperti LRU dan LFU dengan overhead memori nol .
• Algoritme pengambilan gambar tanpa garpu yang baru.

Setelah kami membangun fondasi untuk Dragonfly dan kami puas dengan kinerjanya, kami melanjutkan untuk mengimplementasikan fungsi Redis dan Memcached. Hingga saat ini kami telah mengimplementasikan ~185 perintah Redis (kira-kira setara dengan Redis 5.0 API) dan 13 perintah Memcached.

Dan akhirnya,
Misi kami adalah membangun penyimpanan data dalam memori yang dirancang dengan baik, sangat cepat, dan hemat biaya untuk beban kerja cloud yang memanfaatkan kemajuan perangkat keras terkini. Kami bermaksud untuk mengatasi permasalahan solusi saat ini sambil mempertahankan API dan proposisi produknya.