Sinkronisasi Waktu

Topik ini memperkenalkan mekanisme sinkronisasi waktu di Milvus.

Gambaran Umum

Kejadian-kejadian dalam Milvus secara umum dapat dikategorikan ke dalam dua jenis:

• Peristiwa bahasa definisi data (DDL): membuat/menghapus koleksi, membuat/menghapus partisi, dsb.

• Peristiwa bahasa manipulasi data (DML): menyisipkan, mencari, dll.

Setiap kejadian, baik kejadian DDL maupun DML, ditandai dengan stempel waktu yang dapat mengindikasikan kapan kejadian tersebut terjadi.

Misalkan ada dua pengguna yang memulai serangkaian kejadian DML dan DDL di Milvus dengan urutan waktu yang ditunjukkan pada tabel berikut.

Idealnya, pengguna 2 harus dapat melihat:

• Koleksi kosong C0 di t2.

• Data A1 di t7.

• Kedua data A1 dan A2 di t12.

• Hanya data A2 di t17 (karena data A1 telah dihapus dari koleksi sebelum titik ini).

Skenario ideal ini dapat dengan mudah dicapai ketika hanya ada satu simpul tunggal. Namun, Milvus adalah basis data vektor terdistribusi, dan untuk memastikan semua operasi DML dan DDL pada node yang berbeda tetap teratur, Milvus perlu mengatasi dua masalah berikut:

1. Jam waktu berbeda untuk dua pengguna pada contoh di atas jika mereka berada pada node yang berbeda. Sebagai contoh, jika pengguna 2 24 jam di belakang pengguna 1, semua operasi oleh pengguna 1 tidak terlihat oleh pengguna 2 sampai hari berikutnya.

2. Mungkin ada latensi jaringan. Jika pengguna 2 melakukan pencarian pada koleksi C0 di t17, Milvus harus dapat menjamin bahwa semua operasi sebelum t17 berhasil diproses dan diselesaikan. Jika operasi hapus di t15 tertunda karena latensi jaringan, sangat mungkin pengguna 2 masih dapat melihat data yang seharusnya dihapus A1 ketika melakukan pencarian di t17.

Oleh karena itu, Milvus mengadopsi sistem sinkronisasi waktu (timetick) untuk mengatasi masalah ini.

Timestamp oracle (TSO)

Untuk mengatasi masalah pertama yang disebutkan di bagian sebelumnya, Milvus, seperti sistem terdistribusi lainnya, menyediakan layanan timestamp oracle (TSO). Ini berarti bahwa semua kejadian di Milvus harus dialokasikan dengan cap waktu dari TSO dan bukan dari jam lokal.

Layanan TSO disediakan oleh koordinator root di Milvus. Klien dapat mengalokasikan satu atau beberapa stempel waktu dalam satu permintaan alokasi stempel waktu.

Stempel waktu TSO adalah jenis nilai uint64 yang terdiri dari bagian fisik dan bagian logis. Gambar di bawah ini menunjukkan format stempel waktu.

TSO_Timestamp.

Seperti yang diilustrasikan, 46 bit di awal adalah bagian fisik, yaitu waktu UTC dalam milidetik. 18 bit terakhir adalah bagian logis.

Sistem sinkronisasi waktu (timetick)

Bagian ini menggunakan contoh operasi penyisipan data untuk menjelaskan mekanisme sinkronisasi waktu dalam Milvus.

Ketika proxy menerima permintaan penyisipan data dari SDK, proxy membagi pesan-pesan penyisipan ke dalam beberapa aliran pesan (MsgStream) sesuai dengan nilai hash dari kunci utama.

Setiap pesan penyisipan (InsertMsg) diberi stempel waktu sebelum dikirim ke MsgStream.

timesync_proxy_insert_msg

Satu prinsip umum adalah bahwa dalam MsgStream, penanda waktu dariInsertMsgs dari proxy yang sama harus bersifat inkremental. Namun, tidak ada aturan seperti itu untuk InsertMsgs dari proxy yang berbeda.

Gambar berikut ini adalah contoh InsertMsgs dalam MsgStream. Cuplikan ini berisi lima InsertMsgs, tiga di antaranya berasal dari Proxy1 dan sisanya dari Proxy2.

msgstream

Stempel waktu dari tiga InsertMsgs dari Proxy1 bersifat inkremental, begitu juga dengan dua InsertMsgs dari Proxy2. Namun, tidak ada urutan tertentu di antara Proxy1 dan Proxy2 InsertMsgs .

Salah satu skenario yang mungkin terjadi adalah ketika membaca pesan dengan timestamp 110 dari Proxy2, Milvus menemukan bahwa pesan dengan timestamp 80 dari Proxy1 masih berada di dalam MsgStream. Oleh karena itu, Milvus memperkenalkan sistem sinkronisasi waktu, timetick, untuk memastikan bahwa ketika membaca pesan dari MsgStream, semua pesan dengan nilai timestamp yang lebih kecil harus dikonsumsi.

time_synchronization

Seperti yang ditunjukkan pada gambar di atas,

• Setiap proxy secara berkala (setiap 200 ms secara default) melaporkan nilai cap waktu terbesar dari InsertMsg terbaru di MsgStreamke root coord.

• Root coord mengidentifikasi nilai stempel waktu minimum pada Msgstream ini, tidak peduli pada proxy mana InsertMsgs itu berada. Kemudian root coord menyisipkan stempel waktu minimum ini ke dalam Msgstream. Stempel waktu ini juga disebut timetick.

• Ketika komponen konsumen membaca timetick yang disisipkan oleh root coord, mereka memahami bahwa semua pesan sisipan dengan nilai timestamp yang lebih kecil telah dikonsumsi. Oleh karena itu, permintaan yang relevan dapat dieksekusi dengan aman tanpa mengganggu pesanan.

Gambar berikut ini adalah contoh dari Msgstream dengan timetick yang disisipkan.

timetick

MsgStream memproses pesan dalam batch sesuai dengan tanda waktu untuk memastikan bahwa pesan keluaran memenuhi persyaratan cap waktu. Pada contoh di atas, ini akan mengkonsumsi semua catatan kecuali InsertMsgs dari Proxy2 di Timestamp: 120 karena ini adalah setelah TimeTick terbaru.

Apa selanjutnya

• Pelajari tentang konsep stempel waktu.
• Pelajari tentang alur kerja pemrosesan data di Milvus.