Kasus Penggunaan MyRocks: Kumpulan Data Besar

Database


MyRocks menggunakan Dataset Besar KasusSalah satu pertanyaan yang paling sering diajukan adalah ketika saya lebih memilih MyRocks daripada InnoDB. Kami telah membahas MyRocks di blog kami:

MyRocks Performance – blog kinerja basis data Percona

Penghematan dengan MyRocks di Cloud – Percona Database Performance Blog

Tapi ada baiknya untuk menyegarkan beberapa bahan.

Kali ini saya akan memilih kumpulan data menarik (dan nyata) yang telah saya bahas sebelumnya: kumpulan data Reddit Comments (lihat Kumpulan Data Besar: Semua Komentar Reddit – Analisis dengan ClickHouse – Blog Kinerja Basis Data Percona). Kumpulan data masih tersedia untuk diunduh dari http://files.pushshift.io/reddit/submissions/ dan mencakup semua komentar terbaru hingga Juni 2022.

Ukuran datasetnya menarik, misalnya komentarnya dari Januari 2022 118 GB Dan ukuran total kumpulan data adalah Januari hingga Juni 2022 729 GB.

Hal yang menarik dari dataset ini adalah bahwa ia disediakan dalam format JSON, dan sekarang MySQL menyediakan kemampuan yang luas untuk bekerja secara langsung dengan file JSON.

Sebagai contoh, kita dapat langsung memuat dataset sebagai berikut:

mysqlsh [email protected]/rs -- util importJson /storage/vadim/reddit/RS_2022-01 --table=stor --tableColumn=doc

Dalam tabel yang dibuat sebagai:

CREATE TABLE stor (
doc json DEFAULT NULL,
id int BUKAN NULL AUTO_INCREMENT,
kunci utama (id)
)

Sekarang kita dapat membandingkan waktu muat di MyRocks dan InnoDB untuk file yang sama.

Perlu dicatat bahwa saya menggunakan penyimpanan NVMe cepat untuk database MySQL, yang berguna untuk InnoDB (karena InnoDB berkinerja lebih baik pada penyimpanan cepat, lihat Menyimpan Dengan MyRocks di Cloud – Percona Database Performance Blog).

Jadi unggah enam file di MyRocks Mesin penyimpanan:

Memproses 124,26 GB pada 32091070 dokumen dalam 1 jam 45 menit dan 4,8562 detik (5,09 ribu dokumen per detik)
Memproses 116,83 GB pada 29843162 dokumen dalam 1 jam 40 menit 45,0204 detik (4,94 ribu dokumen per detik)
Memproses 128,81 GB pada 32677372 dokumen dalam 1 jam 54 menit 16,1496 detik (4,77 ribu dokumen per detik)
Memproses 130,34 GB pada 33002461 dokumen dalam 1 jam 56 menit dan 43,0586 detik (4,71 ribu dokumen per detik)
Memproses 142,88 GB dalam 34838318 dokumen dalam 2 jam 1 menit dan 22,7340 detik (4,78 ribu dokumen per detik)
Memproses 139,09 GB pada 34395243 dokumen dalam 2 jam 4 menit 49,8066 detik (4,59 ribu dokumen per detik)

Dan ukuran akhirnya ada di MyRocks 238 gram. MyRocks menggunakan kombinasi kompresi LZ4 + Zstandard untuk mencapai ukuran ini (lebih kecil dari dataset asli).

Demikian juga untuk InnoDB Mesin penyimpanan:

Memproses 124,26 GB pada 32091070 dokumen dalam 2 jam 17 menit 33,0404 detik (3,89 ribu dokumen per detik)
Memproses 116,83 GB pada 29843162 dokumen dalam 2 jam 8 menit 6,3595 detik (3,88 ribu dokumen per detik)
Memproses 128,81 GB pada 32677372 dokumen dalam 2 jam 28 menit dan 8,5292 detik (3,68 ribu dokumen per detik)
Memproses 130,34 GB pada 33002461 dokumen dalam 2 jam 31 menit 25,8357 detik (3,63 ribu dokumen per detik)
Memproses 142,88 GB dalam 34838318 dokumen dalam 2 jam 44 menit 56,9327 detik (3,52 ribu dokumen per detik)
Memproses 139,09 GB dalam 34395243 dokumen dalam 2 jam 39 menit 53,3889 detik (3,59 ribu dokumen per detik)

Ukuran terakhir ada di InnoDB 991G.

Catatan: InnoDB tidak menggunakan kompresi dalam pengujian ini. Meskipun mesin InnoDB memiliki kemampuan kompresi, itu bukan sesuatu yang biasanya kami sarankan untuk digunakan karena berbagai masalah.

Rata-rata penyisipan MyRock di seluruh papan adalah 4,81 ribu dokumen per detik dan InnoDB adalah 3,7 ribu dokumen per detik, jadi ada peningkatan 24% dalam kecepatan pemuatan saat membandingkan MyRocks dengan InnoDB.

Sekarang mari kita bandingkan beberapa kueri agregasi dengan keuntungan untuk menunjukkan bagaimana kita dapat menangani dokumen JSON di MySQL.

Temukan subkategori teratas (berdasarkan jumlah komentar) yang tidak ditandai sebagai “Hanya Dewasa” (Saya tidak mengambil risiko menambahkan “Dewasa” ke output …):

SELECT doc->"$.subreddit",count(*) cnt FROM stor WHERE JSON_VALUE(doc, "$.over_18" RETURNING UNSIGNED) IS NOT TRUE GROUP BY 1 ORDER BY cnt DESC LIMIT 100;

Jalur keluaran pertama:

+-------------------------+--------+
| doc->"$.subreddit" | cnt |
+-------------------------+--------+
| "AskReddit" | 329683 |
| "teenagers" | 131401 |
| "memes" | 102118 |
| "AutoNewspaper" | 82080 |
| "relationship_advice" | 66883 |
| "UltraAlgo" | 64958 |
| "antiwork" | 54697 |
| "NoStupidQuestions" | 52531 |
| "NFTsMarketplace" | 48647 |
| "CryptoCurrency" | 46817 |

dan waktu pelaksanaan:

MyRocks: 100 baris dalam satu set (6 menit 20,31 detik)
InnoDB: 100 baris dalam satu set (8 menit 10,29 detik)

Bagian MyRocks yang tidak begitu bagus

Pengungkapan penuh: Saya juga akan menunjukkan bagian di mana MyRocks berkinerja lebih buruk daripada InnoDB. Untuk tujuan ini, saya menggunakan pertanyaan yang memunculkan pendapat penulis.

Untuk melakukan ini, kita perlu membuat indeks dengan “penulis”, dan karena ini semua disimpan dalam dokumen JSON, kita perlu membuat kolom “penulis” virtual:

ALTER TABLE stor ADD COLUMN author VARCHAR(255) GENERATED ALWAYS AS ( doc->"$.author" );

dan untuk InnoDB Ini praktis operasi instan:

Kueri disetujui, 0 baris terpengaruh (1 menit 22,61 detik)

Sedangkan untuk MyRocks ini membutuhkan waktu:

Kueri disetujui, 61934232 baris terpengaruh (45 menit 46,61 detik)

Perbedaannya adalah bahwa MyRocks belum mendukung operasi DDL “INSTAN”, sementara InnoDB mendukung. Namun, kami melihat bahwa justru operasi “INSTANT” menyebabkan bug utama dan ketidakcocokan di InnoDB dalam versi 8.0.29 dan 8.0.30 (lihat Percona XtraBackup 8.0.29 dan Kolom TAMBAH/DROP INSTAN – Kinerja Basis Data Percona (lihat Blog) Lebih hati-hati sebelum menggunakan operasi “INSTANT” di InnoDB.

Dan sekarang kita dapat membuat indeks pada kolom virtual:

MyRocks:

ALTER TABLE stor ADD KEY (author);

Kueri OK, 0 baris terpengaruh (14 menit 37,34 detik)

InnoDB:

ALTER TABLE stor ADD KEY (author);

Kueri OK, 0 baris terpengaruh (40 menit 4,39 detik)

MyRocks membutuhkan waktu lebih sedikit untuk membuat profil baru di pilar. Untuk menunjukkan di mana MyRocks lebih buruk, saya akan menggunakan benchmark MySQL yang buruk, perintah BENCHMARK, seperti ini:

SELECT BENCHMARK(50000000,(with t1 as (with q as (select FLOOR(1 + RAND()*(7685162 -1 + 1)) c1) select * from authors,q where id=q.c1) select count(*) cnt from stor,t1 where stor.author=t1.author limit 100));

Pada dasarnya, saya menjalankan kueri 50 juta kali yang menarik komentar dari penulis acak.

Ke InnoDB Waktu berjalan (lebih sedikit lebih baik, tiga upaya berbeda):

1 baris di set (2 menit 14,66 detik)
1 baris di set (1 menit 53,10 detik)
1 baris di set (1 menit 40,18 detik)

Ke MyRocks:

1 baris di set (6 menit 38,60 detik)
1 baris di set (5 menit 42,83 detik)
1 baris di set (6 menit 4,76 detik)

Sebagai gambaran, ini menghasilkan 442 ribu kueri per detik untuk InnoDB dan 137 ribu kueri per detik untuk MyRocks (struktur data yang dioptimalkan untuk kompresi dan penulisan ikut berperan di sini). Kami perlu menyoroti hasil ini tanpa koneksi jaringan. Dalam kondisi normal, latensi jaringan bertambah dan perbedaan antara kedua mesin menjadi jauh lebih kecil.

Hasil

MyRocks merupakan kasus yang baik untuk kumpulan data besar (dalam pengujian kami, kami memuat kumpulan data TB), menawarkan tingkat penyisipan yang baik dan ukuran terkompresi kecil dari produk akhir.

Sebagai bug kompresi dan mesin yang dioptimalkan untuk penulisan, MyRocks tertinggal di belakang InnoDB dalam pencarian “pencarian daftar” yang cepat, yang menurut saya dapat diterima, tetapi Anda harus mengevaluasi ini untuk penggunaan Anda sendiri.

Lampiran:

Spesifikasi dan pengaturan perangkat keras:

2022-MyRocks-reddit/benchmarkspec.md Aslinya · Percona-Lab-results/2022-MyRocks-reddit (github.com)





Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.