ตอบสนองการเขียนสถานะก่อนการติดตามและอ่านบรรทัดนำด้วยกุญแจของมันเอง

Shipped

6 พฤศจิกายน 2569 เวลา 18:31 UTC

Author

Kamo

Commit

5b273d8

ผลลัพธ์การกดโทรศัพท์จากชั้น โปรไฟล์กับ JFR บนเซิร์ฟเวอร์ความปลอดภัย (lab org, 40 ครั้ง) / เขียนระยะใช้เวลา 160-360 ms, ค่าเฉลี่ย ~ 220 ms ประมาณ 90 ms ของมันเป็นหลัง-คอมมิทติดตาม ไม่มีใครรอ: ตัวติดตามรายชื่อผู้ติดต่อ (แสดงสถานะอ่าน + 2-3 upserts, ทุกตัวมี YugabyteDB ของตัวเอง) บริการที่ประกาศการคอมมิทใหม่ ตัวประมวลผล LeadStatusFollowUps ตอนนี้ตอบกลับเมื่อสถานะได้ถูกคอมมิชต์แล้วและทำงานสองอย่างบนมัน; ถ้าไม่มีมัน มันก็จะทำงานเหมือนเดิม สมมติฐาน ตัววางแผนของ YugabyteDB ใช้การค้นหาแบบพบเจอ: "org_id =? AND <key>" ไปยังดัชนีขององค์กร วัดจาก ใหญ่ที่สุด org (อธิบายวิเคราะห์, อ่านได้เท่านั้น): - ประวัติการนำโดยนำ: 17.9 วินาที -> 35 มิลลิวินาที การอ่านแต่ละนำไปตาม lead_uid, org ตรวจสอบโดยกุญแจ - DialLedger อ่านข้อความแรก: 7.15 วินาที -> ~ 1.5 มิลลิวินาที (เฉพาะ UID, org ตรวจสอบใน Java) - **************** โดย uid เท่านั้น, org ตรวจสอบใน Java (การเข้าถึงการบันทึก, แท็ก) - / leads grid with named leads (Selected tab, stream leads): org check written org_ id + 0= ?, 7.06 วินาที -> 4.6มิลวินาที; ตัวกรองเดียวกัน ไม่มีอินเดกซ์ที่สามารถใช้ได้ ดังนั้นจึงใช้ pk