ניתוב שמודע למובילים

בדף הזה מוסבר על ניתוב עם זיהוי Leader ב-Spanner ואיך להשתמש בו. כדי להפחית את זמן האחזור ולשפר את הביצועים במסד הנתונים, Spanner משתמש בניתוב מבוסס-מנהיג כדי לנתב באופן דינמי עסקאות קריאה וכתיבה בהגדרות של מכונות בשני אזורים ובמספר אזורים. התכונה "ניתוב עם מודעות למוביל" מופעלת כברירת מחדל.

ניתוב של Spanner לעסקאות קריאה וכתיבה

‫Spanner משכפל נתונים כדי לספק זמינות נוספת של נתונים ומיקום גיאוגרפי. בהגדרות של מכונות בשני אזורים ובמספר אזורים ב-Spanner, אזור אחד בהגדרה של המכונה בשני אזורים ובמספר אזורים מוגדר כאזור הראשי, והוא מכיל את הרפליקות הראשיות של מסד הנתונים. כשמשתמשים בהגדרת מכונה בשני אזורים או במספר אזורים, והלקוח שולח למסד הנתונים עסקה לקריאה ולכתיבה מאזור שהוא לא ראשי, הכתיבה תמיד מעובדת באזור הראשי ואז נשלחת בחזרה לאזור שהוא לא ראשי. לכן, כדי לבצע עסקאות קריאה-כתיבה מאזור שאינו ראשי, נדרשות כמה נסיעות הלוך ושוב לרפליקה הראשית.

ניתוב עם מודעות ל-Leader הוא מנגנון שמשפר את זמן האחזור של עסקאות קריאה וכתיבה על ידי ניתוב חכם של העסקאות האלה. אם מפעילים ניתוב לפי מיקום ה-Leader, גם אם פעולת הכתיבה לא מגיעה מהאזור הראשי, הבקשות ליצירת סשן מנותבות לאזור הראשי כדי להתאים את ממשק הקצה של Spanner API לאזור הראשי. מנגנון הניתוב הזה משפר את זמן האחזור של עסקאות קריאה-כתיבה, על ידי צמצום מספר הנסיעות הלוך ושוב ברשת שנדרשות בין האזור הלא-ראשי (שבו נמצאת אפליקציית הלקוח) לבין האזור הראשי לשתיים.

צילום מסך של ניתוב ב-Spanner עם ניתוב מבוסס-מנהיג מופעל. איור 1. דוגמה לניתוב ב-Spanner כשהתכונה "ניתוב עם זיהוי של Leader" מופעלת.

אם הניתוב לפי אזור ראשי מושבת, אפליקציית הלקוח מנתבת קודם את הבקשה לשירות קצה קדמי של Spanner API באזור של אפליקציית הלקוח (אזור לא ראשי). לאחר מכן, מהממשק של Spanner API באזור של אפליקציית הלקוח, מתבצעות שלוש נסיעות הלוך ושוב או יותר לשרת של Spanner‏ (SpanServer) באזור הראשי כדי לבצע את פעולת הכתיבה, מה שמגדיל את זמן האחזור. הנסיעות הנוספות האלה נדרשות כדי לתמוך באינדקסים משניים, בבדיקות אילוצים ובקריאת הכתיבות שלכם.

צילום מסך של ניתוב ב-Spanner כשהתכונה "ניתוב עם מודעות ל-Leader" מושבתת. איור 2. דוגמה לניתוב ב-Spanner כשהתכונה "ניתוב לפי ה-Leader" מושבתת.

תרחישים לדוגמה

כתוצאה מהשימוש בניתוב מבוסס-מנהיג, תרחישי השימוש הבאים נהנים מזמן אחזור קצר יותר:

  • עדכון מספר פריטים בו-זמנית: הפעלת ייבוא של Dataflow או הפעלת שינויים ברקע (לדוגמה, DML באצווה) מאזור שאינו ראשי.
  • עמידות באסונות וזמינות גבוהה יותר: פריסת אפליקציות לקוח גם באזורים ראשיים וגם באזורים לא ראשיים כדי לעמוד בהפסקות זמניות בשירות באזורים, תוך כדי התחלת כתיבה מאזורים לא ראשיים.
  • אפליקציה גלובלית: פריסת אפליקציות לקוח באופן גלובלי, עם מיקומים נרחבים של אזורים שבהם מתבצעת שמירת נתונים.

מגבלות

אם אפליקציית הלקוח שלכם פרוסה מחוץ לאזור הראשי ואתם כותבים ערכים בלי לקרוא את הנתונים ("כתיבה עיוורת"), יכול להיות שתבחינו ברגרסיה בזמן האחזור אם מופעל ניתוב מבוסס-מנהיג. הסיבה לכך היא שכאשר מפעילים ניתוב עם זיהוי של האזור הראשי, יש שני מסלולים הלוך ושוב בין אזורים (beginTransaction והבקשה commit) בין אפליקציית הלקוח באזור שאינו ראשי לבין ממשק ה-API של Spanner באזור הראשי. לעומת זאת, כשמשביתים את הניתוב לפי מנהיג, פעולות כתיבה ללא קריאה בלבד דורשות רק נסיעה אחת הלוך ושוב בין אזורים בשביל הבקשה של commit (הבקשה של beginTransaction מעובדת בממשק הקצה הקדמי המקומי של Spanner API). לדוגמה, אם טוענים נתונים בכמות גדולה לטבלה חדשה, סביר להניח שהטרנזקציות לא יקראו נתונים מהטבלה. אם אתם מבצעים לעיתים קרובות פעולות כתיבה בלי לקרוא אותן באפליקציה, כדאי לשקול להשבית את הניתוב שמבוסס על המנהיג. מידע נוסף זמין במאמר השבתת ניתוב מבוסס-מנהיג.

שימוש בניתוב שמבוסס על המכשיר המוביל

ניתוב עם מודעות ל-Leader מופעל כברירת מחדל בספריות הלקוח של Spanner.

מומלץ לעבד את בקשות הקריאה והכתיבה כשמופעל ניתוב עם מודעות ל-leader. אתם יכולים להשבית את התכונה כדי להשוות בין הביצועים.

ניתוב עם מודעות ל-Leader וחלוקה למחיצות במיקומים שונים

כשמשתמשים בחלוקה למחיצות במיקומים שונים כדי לחלק את מסד הנתונים לכמה מיקומי נתונים, המערכת של Spanner בודקת את כל הגדרות המכונות שמשמשות את מיקומי מסד הנתונים, כולל מיקום ברירת המחדל, כשהיא מנתבת בקשות. ‫Spanner בוחר ממשק קצה של Cloud Spanner API שנמצא באותו מיקום של אזור המיקום שהכי קרוב ללקוח. הבחירה הזו לא תלויה בשאלה אם מיקום המודעה או הנתונים שלו משמשים בעסקה מסוימת. ‫Spanner מנתב עסקאות קריאה-כתיבה באופן הבא:

  • כשהתכונה "ניתוב לפי מיקום ה-Leader" מופעלת: לכל מיקום יש אזור ראשי משלו (או אזור ראשי שמוגדר כברירת מחדל בהגדרות של שני אזורים או של מספר אזורים). ‫Spanner מנתב עסקאות קריאה-כתיבה לממשק הקצה של Cloud Spanner API באזור הראשי שהכי קרוב ללקוח.
  • כשהניתוב לפי מיקום ה-Leader מושבת: Spanner מנתב עסקאות קריאה-כתיבה לממשק הקצה של Cloud Spanner API באזור השירות הקרוב ביותר בכל המיקומים של מסד הנתונים.

הפעלת ניתוב עם מודעות למוביל

אפשר להשתמש בספריות הלקוח של Spanner כדי להפעיל באופן ידני ניתוב עם זיהוי של ה-Leader.

C++‎

כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג, משתמשים במבנה RouteToLeaderOption:

void RouteToLeaderOption(std::string const& project_id, std::string const& instance_id,
              std::string const& database_id) {
namespace spanner = ::google::cloud::spanner;

// Create a client with RouteToLeaderOption enabled.
auto client = spanner::Client(
  spanner::MakeConnection(
      spanner::Database(project_id, instance_id, database_id)),
  google::cloud::Options{}.set<spanner::RouteToLeaderOption>(
      spanner::true));

C#‎

משתמשים ב-EnableLeaderRouting כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

// Create a client with leader-aware routing enabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = true;

המשך

משתמשים ב-ClientConfig כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

type ClientConfig struct {
    // DisableRouteToLeader specifies if all the requests of type read-write
    // and PDML need to be routed to the leader region.
    // Default: false
    DisableRouteToLeader false
}

Java

משתמשים ב-SpannerOptions.Builder כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

SpannerOptions options = SpannerOptions.newBuilder().enableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";

Node.js

משתמשים ב-SpannerOptions כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

// Instantiates a client with routeToLeaderEnabled enabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: true;
});

PHP

משתמשים ב-routeToLeader כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

// Instantiates a client with leader-aware routing enabled
use Google\Cloud\Spanner\SpannerClient;

$routeToLeader = true;
$spanner = new SpannerClient($routeToLeader);

Python

משתמשים ב-route_to_leader_enabled כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

spanner_client = spanner.Client(
route_to_leader_enabled=true
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)

Ruby

משתמשים ב-self.new כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג:

def self.new(project_id: nil, credentials: nil, scope: nil, timeout: nil,
     endpoint: nil, project: nil, keyfile: nil, emulator_host: nil,
    lib_name: nil, lib_version: nil, enable_leader_aware_routing: true) ->
    Google::Cloud::Spanner::Project

השבתת הניתוב לפי המנהיג

אפשר להשתמש בספריות הלקוח של Spanner כדי להשבית את הניתוב לפי מיקום ה-Leader.

C++‎

כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת, משתמשים במבנה RouteToLeaderOption:

void RouteToLeaderOption(std::string const& project_id, std::string const& instance_id,
              std::string const& database_id) {
namespace spanner = ::google::cloud::spanner;

// Create a client with RouteToLeaderOption disabled.
auto client = spanner::Client(
  spanner::MakeConnection(
      spanner::Database(project_id, instance_id, database_id)),
  google::cloud::Options{}.set<spanner::RouteToLeaderOption>(
      spanner::false));

C#‎

משתמשים ב-EnableLeaderRouting כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

// Create a client with leader-aware routing disabled.
SpannerConnectionStringBuilder builder = new
SpannerConnectionStringBuilder();
Builder.EnableLeaderRouting = false;

המשך

משתמשים ב-ClientConfig כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

type ClientConfig struct {
    // DisableRouteToLeader specifies if all the requests of type read-write
    // and PDML need to be routed to the leader region.
    // Default: false
    DisableRouteToLeader true
}

Java

כדי ליצור חיבור למסד נתונים ב-Spanner כשההגדרה "ניתוב עם זיהוי של Leader" מושבתת, משתמשים ב-SpannerOptions.Builder:

SpannerOptions options = SpannerOptions.newBuilder().disableLeaderAwareRouting.build();
Spanner spanner = options.getService();
String instance = "my-instance";
String database = "my-database";

Node.js

משתמשים ב-SpannerOptions כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

// Instantiates a client with routeToLeaderEnabled disabled
const spanner = new Spanner({
projectId: projectId,
routeToLeaderEnabled: false;
});

PHP

משתמשים ב-routeToLeader כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

// Instantiates a client with leader-aware routing disabled
use Google\Cloud\Spanner\SpannerClient;

$routeToLeader = false;
$spanner = new SpannerClient($routeToLeader);

Python

משתמשים ב-route_to_leader_enabled כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

spanner_client = spanner.Client(
route_to_leader_enabled=false
)
instance = spanner_client.instance(instance_id)
database = instance.database(database_id)

Ruby

משתמשים ב-self.new כדי להגדיר את אפליקציית הלקוח עם ניתוב מבוסס-מנהיג מושבת:

def self.new(project_id: nil, credentials: nil, scope: nil, timeout: nil,
     endpoint: nil, project: nil, keyfile: nil, emulator_host: nil,
    lib_name: nil, lib_version: nil, enable_leader_aware_routing: false) ->
    Google::Cloud::Spanner::Project

המאמרים הבאים