Menggunakan Basis Data Vektor Milvus untuk Kueri Waktu Nyata

Gambar sampul depan

Artikel ini ditulis oleh Xi Ge dan diterjemahkan oleh Angela Ni.

Pada artikel sebelumnya, kita telah membahas tentang penyisipan data dan persistensi data di Milvus. Dalam artikel ini, kami akan terus menjelaskan bagaimana berbagai komponen dalam Milvus berinteraksi satu sama lain untuk menyelesaikan kueri data real-time.

Beberapa sumber daya yang berguna sebelum memulai tercantum di bawah ini. Kami sarankan untuk membacanya terlebih dahulu untuk lebih memahami topik dalam artikel ini.

• Mendalami arsitektur Milvus
• Model data Milvus
• Peran dan fungsi dari setiap komponen Milvus
• Pemrosesan data di Milvus
• Penyisipan data dan persistensi data di Milvus

Memuat data ke simpul kueri

Sebelum sebuah query dieksekusi, data harus dimuat ke dalam node query terlebih dahulu.

Ada dua jenis data yang dimuat ke node kueri: data streaming dari log broker, dan data historis dari penyimpanan objek (juga disebut penyimpanan persisten di bawah).

Diagram alir

Data coord bertanggung jawab untuk menangani data streaming yang secara terus menerus dimasukkan ke dalam Milvus. Ketika pengguna Milvus memanggil collection.load() untuk memuat sebuah koleksi, query coord akan menanyakan kepada data coord untuk mengetahui segmen mana yang telah disimpan dalam penyimpanan dan checkpoint yang sesuai. Checkpoint adalah tanda yang menandakan bahwa segmen yang disimpan sebelum checkpoint akan dikonsumsi, sementara yang setelah checkpoint tidak.

Kemudian, koordinat kueri mengeluarkan strategi alokasi berdasarkan informasi dari koordinat data: baik berdasarkan segmen atau saluran. Pengalokasi segmen bertanggung jawab untuk mengalokasikan segmen dalam penyimpanan persisten (data batch) ke node kueri yang berbeda. Misalnya, pada gambar di atas, pengalokasi segmen mengalokasikan segmen 1 dan 3 (S1, S3) ke node kueri 1, dan segmen 2 dan 4 (S2, S4) ke node kueri 2. Pengalokasi saluran menetapkan node kueri yang berbeda untuk mengawasi beberapa saluran manipulasi data (DMChannels) di broker log. Misalnya, pada gambar di atas, pengalokasi saluran menetapkan node kueri 1 untuk menonton saluran 1 (Ch1), dan node kueri 2 untuk menonton saluran 2 (Ch2).

Dengan strategi alokasi, setiap node kueri memuat data segmen dan menonton saluran yang sesuai. Pada simpul kueri 1 pada gambar, data historis (data batch), dimuat melalui S1 dan S3 yang dialokasikan dari penyimpanan persisten. Sementara itu, simpul kueri 1 memuat data tambahan (data streaming) dengan berlangganan saluran 1 di broker log.

Manajemen data di simpul kueri

Sebuah simpul kueri perlu mengelola data historis dan data tambahan. Data historis disimpan dalam segmen tertutup sementara data tambahan disimpan dalam segmen yang terus bertambah.

Manajemen data historis

Ada dua pertimbangan utama untuk manajemen data historis: keseimbangan beban dan kegagalan simpul kueri.

Keseimbangan beban

Sebagai contoh, seperti yang ditunjukkan dalam ilustrasi, simpul kueri 4 telah dialokasikan lebih banyak segmen tertutup daripada simpul kueri lainnya. Kemungkinan besar, hal ini akan membuat node kueri 4 menjadi hambatan yang memperlambat seluruh proses kueri. Untuk mengatasi masalah ini, sistem perlu mengalokasikan beberapa segmen di simpul kueri 4 ke simpul kueri lainnya. Ini disebut keseimbangan beban.

Peralihan simpul kueri

Situasi lain yang mungkin terjadi diilustrasikan pada gambar di atas. Salah satu node, node kueri 4, tiba-tiba mati. Dalam kasus ini, beban (segmen yang dialokasikan ke node kueri 4) perlu ditransfer ke node kueri lain yang berfungsi untuk memastikan keakuratan hasil kueri.

Manajemen data tambahan

Node kueri mengawasi DMChannels untuk menerima data tambahan. Flowgraph diperkenalkan dalam proses ini. Pertama-tama menyaring semua pesan penyisipan data. Hal ini untuk memastikan bahwa hanya data dalam partisi tertentu yang dimuat. Setiap koleksi dalam Milvus memiliki saluran yang sesuai, yang digunakan bersama oleh semua partisi dalam koleksi tersebut. Oleh karena itu, flowgraph diperlukan untuk menyaring data yang disisipkan jika pengguna Milvus hanya perlu memuat data pada partisi tertentu. Jika tidak, data di semua partisi dalam koleksi akan dimuat ke simpul kueri.

Setelah disaring, data tambahan dimasukkan ke dalam segmen yang sedang berkembang, dan selanjutnya diteruskan ke node waktu server.

Diagram alir

Selama penyisipan data, setiap pesan penyisipan diberi stempel waktu. Pada DMChannel yang ditunjukkan pada gambar di atas, data disisipkan secara berurutan, dari kiri ke kanan. Cap waktu untuk pesan penyisipan pertama adalah 1; yang kedua, 2; dan yang ketiga, 6. Pesan keempat yang ditandai dengan warna merah bukanlah pesan penyisipan, melainkan pesan penanda waktu. Hal ini untuk menandakan bahwa data yang disisipkan dengan timestamp yang lebih kecil dari timetick ini sudah ada di dalam log broker. Dengan kata lain, data yang disisipkan setelah pesan timetick ini harus memiliki timestamp yang nilainya lebih besar dari timetick ini. Sebagai contoh, pada gambar di atas, ketika simpul kueri melihat bahwa timetick saat ini adalah 5, ini berarti semua pesan penyisipan yang nilai timestamp-nya kurang dari 5 dimuat ke simpul kueri.

Node waktu server memberikan nilai tsafe yang diperbarui setiap kali menerima timetick dari node penyisipan. tsafe berarti waktu aman, dan semua data yang disisipkan sebelum titik waktu ini dapat ditanyakan. Sebagai contoh, jika tsafe = 9, data yang disisipkan dengan cap waktu yang lebih kecil dari 9 semuanya dapat ditanyakan.

Kueri waktu nyata di Milvus

Kueri real-time di Milvus diaktifkan oleh pesan kueri. Pesan kueri dimasukkan ke dalam perantara log oleh proksi. Kemudian node kueri mendapatkan pesan kueri dengan melihat saluran kueri di log broker.

Pesan kueri

Pesan kueri

Pesan kueri mencakup informasi penting berikut tentang kueri:

• msgID: ID pesan, ID pesan kueri yang ditetapkan oleh sistem.
• collectionID: ID koleksi yang akan ditanyakan (jika ditentukan oleh pengguna).
• execPlan: Rencana eksekusi terutama digunakan untuk pemfilteran atribut dalam kueri.
• service_ts: Stempel waktu layanan akan diperbarui bersama dengan tsafe yang disebutkan di atas. Stempel waktu layanan menandakan pada titik mana layanan masuk. Semua data yang dimasukkan sebelum service_ts tersedia untuk kueri.
• travel_ts: Stempel waktu perjalanan menentukan rentang waktu di masa lalu. Dan kueri akan dilakukan pada data yang ada pada periode waktu yang ditentukan oleh travel_ts.
• guarantee_ts: Guarantee timestamp menentukan periode waktu setelah kueri perlu dilakukan. Query hanya akan dilakukan ketika service_ts > guarantee_ts.

Kueri waktu nyata

Proses kueri

Ketika pesan kueri diterima, Milvus pertama-tama menilai apakah waktu layanan saat ini, service_ts, lebih besar daripada cap waktu jaminan, guarantee_ts, dalam pesan kueri. Jika ya, permintaan akan dieksekusi. Kueri akan dilakukan secara paralel pada data historis dan data tambahan. Karena mungkin ada tumpang tindih data antara data streaming dan data batch, tindakan yang disebut "pengurangan lokal" diperlukan untuk menyaring hasil kueri yang berlebihan.

Namun, jika waktu layanan saat ini lebih kecil dari stempel waktu jaminan dalam pesan kueri yang baru dimasukkan, pesan kueri akan menjadi pesan yang belum terselesaikan dan menunggu untuk diproses sampai waktu layanan menjadi lebih besar dari stempel waktu jaminan.

Hasil kueri pada akhirnya didorong ke saluran hasil. Proxy memperoleh hasil query dari saluran tersebut. Demikian juga, proxy akan melakukan "pengurangan global" juga karena menerima hasil dari beberapa node kueri dan hasil kueri mungkin berulang.

Untuk memastikan bahwa proxy telah menerima semua hasil kueri sebelum mengembalikannya ke SDK, pesan hasil juga akan menyimpan catatan informasi termasuk segmen tertutup yang dicari, DMChannels yang dicari, dan segmen tertutup global (semua segmen pada semua node kueri). Sistem dapat menyimpulkan bahwa proxy telah menerima semua hasil kueri hanya jika kedua kondisi berikut terpenuhi:

• Gabungan semua segmen tersegel yang dicari yang dicatat dalam semua pesan hasil lebih besar dari segmen tersegel global,
• Semua DMChannels dalam koleksi ditanyakan.

Pada akhirnya, proxy mengembalikan hasil akhir setelah "pengurangan global" ke Milvus SDK.

Tentang Seri Deep Dive

Dengan pengumuman resmi ketersediaan umum Milvus 2.0, kami menyusun seri blog Milvus Deep Dive ini untuk memberikan interpretasi mendalam tentang arsitektur dan kode sumber Milvus. Topik-topik yang dibahas dalam seri blog ini meliputi:

• Gambaran umum arsitektur Milvus
• API dan SDK Python
• Pemrosesan data
• Manajemen data
• Kueri waktu nyata
• Mesin eksekusi skalar
• Sistem QA
• Mesin eksekusi vektor