Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ארגון נתונים לעקביות חזקה

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

רמות עקביות

שאילתות ב-Datastore יכולות להחזיר את התוצאות שלהן באחת משתי רמות עקביות:

שאילתות עם עקביות חזקה מבטיחות את התוצאות העדכניות ביותר, אבל יכול להיות שייקח יותר זמן להשלים אותן או שהן לא נתמכות במקרים מסוימים.
שאילתות Eventually consistent בדרך כלל רצות מהר יותר, אבל לפעמים הן מחזירות תוצאות לא עדכניות.

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

התחייבויות לעקביות

התוצאות של השאילתות מוחזרות עם רמות שונות של הבטחת עקביות, בהתאם לסוג השאילתה:

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

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

מדיניות קריאה של Datastore

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

אפשר להפעיל קריאות עם עקביות סופית באמצעות אפשרויות הקריאה של אובייקט השאילתה:

C#

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore C# API.

כדי לבצע אימות ב-Cloud Datastore, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

Query query = new Query("Task")
{
    Filter = Filter.HasAncestor(_db.CreateKeyFactory("TaskList")
        .CreateKey(keyName))
};
var results = _db.RunQuery(query,
    ReadOptions.Types.ReadConsistency.Eventual);

Go

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore Go API.

ancestor := datastore.NameKey("TaskList", "default", nil)
query := datastore.NewQuery("Task").Ancestor(ancestor).EventualConsistency()

Java

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore Java API.

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            PropertyFilter.hasAncestor(
                datastore.newKeyFactory().setKind("TaskList").newKey("default")))
        .build();
datastore.run(query, ReadOption.eventualConsistency());

Node.js

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore Node.js API.

const ancestorKey = datastore.key(['TaskList', 'default']);
const query = datastore.createQuery('Task').hasAncestor(ancestorKey);

query.run({consistency: 'eventual'});

PHP

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore PHP API.

$query = $datastore->query()
    ->kind('Task')
    ->hasAncestor($datastore->key('TaskList', 'default'));
$result = $datastore->runQuery($query, ['readConsistency' => 'EVENTUAL']);

Python

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore Python API.

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

query = client.query(kind="Task")
query.fetch(eventual=True)

Ruby

מידע על התקנת ספריית הלקוח של Cloud Datastore ושימוש בה מופיע במאמר ספריות הלקוח של Cloud Datastore. מידע נוסף מופיע במאמרי העזרה של Cloud Datastore Ruby API.

# task_list_name = "default"
ancestor_key = datastore.key "TaskList", task_list_name

query = datastore.query("Task")
                 .ancestor(ancestor_key)

tasks = datastore.run query, consistency: :eventual

שיקולים לגבי עסקאות ועקביות

התחייבויות ל-Datastore הן טרנזקציונליות, כלומר הן מתבצעות בהקשר של טרנזקציה וקבוצת השינויים של הטרנזקציה מוחלת במלואה או לא מוחלת בכלל, או לא טרנזקציונליות, כלומר קבוצת השינויים לא מוחלת במלואה או לא מוחלת בכלל.

עסקה אחת יכולה לכלול כל מספר של מוטציות ליצירה, לעדכון או למחיקה. כדי לשמור על עקביות הנתונים, הטרנזקציה מבטיחה שכל השינויים שהיא מכילה יוחלו על Datastore כיחידה אחת, או שאם אחד מהשינויים ייכשל, אף אחד מהם לא יוחל. בנוסף, כל הקריאות עם עקביות חזקה (שאילתות של צאצאים או פעולות lookup) שמתבצעות באותה טרנזקציה מסתמכות על תמונת מצב אחת ועקבית של הנתונים. בשביל שאילתות עם עקביות חזקה, צריך לציין מסנן של ישות אב. שאילתות שמשתתפות בעסקה תמיד עקביות מאוד. בכל טרנזקציה יכולות להיות עד 25 קבוצות ישויות. קריאות עם עקביות סופית לא מוגבלות כך, והן מספיקות במקרים רבים. שימוש בקריאות עם עקביות סופית עשוי לאפשר לכם להפיץ את הנתונים בין מספר גדול יותר של קבוצות ישויות, וכך להשיג קצב העברת נתונים גבוה יותר לכתיבה על ידי ביצוע פעולות Commit במקביל בקבוצות ישויות שונות. עם זאת, כדי לקבוע אם קריאות עם עקביות בסופו של דבר מתאימות לאפליקציה שלכם, אתם צריכים להבין את המאפיינים שלהן:

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

הגדרת מבנה הנתונים לשמירה על עקביות

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

C#

Entity task = new Entity()
{
    Key = _db.CreateKeyFactory("Task").CreateKey("sampleTask"),
    ["category"] = "Personal",
    ["done"] = false,
    ["priority"] = 4,
    ["description"] = "Learn Cloud Datastore"
};

Go

type Task struct {
	Category        string
	Done            bool
	Priority        float64
	Description     string `datastore:",noindex"`
	PercentComplete float64
	Created         time.Time
}
task := &Task{
	Category:        "Personal",
	Done:            false,
	Priority:        4,
	Description:     "Learn Cloud Datastore",
	PercentComplete: 10.0,
	Created:         time.Now(),
}

Java

Key taskKey = datastore.newKeyFactory().setKind("Task").newKey("sampleTask");
Entity task =
    Entity.newBuilder(taskKey)
        .set("category", "Personal")
        .set("done", false)
        .set("priority", 4)
        .set("description", "Learn Cloud Datastore")
        .build();

Node.js

const task = {
  category: 'Personal',
  done: false,
  priority: 4,
  description: 'Learn Cloud Datastore',
};

PHP

$task = $datastore->entity('Task', [
    'category' => 'Personal',
    'done' => false,
    'priority' => 4,
    'description' => 'Learn Cloud Datastore'
]);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

task = datastore.Entity(client.key("Task"))
task.update(
    {
        "category": "Personal",
        "done": False,
        "priority": 4,
        "description": "Learn Cloud Datastore",
    }
)

Ruby

task = datastore.entity "Task" do |t|
  t["category"] = "Personal"
  t["done"] = false
  t["priority"] = 4
  t["description"] = "Learn Cloud Datastore"
end

לאחר מכן, המערכת שולחת שאילתה לגבי סוג הישות Task כדי למצוא את המשימות שעדיין לא בוצעו עם עדיפות של 4 ומעלה, וממיינת אותן בסדר יורד לפי עדיפות:

C#

Query query = new Query("Task")
{
    Filter = Filter.And(Filter.Equal("done", false),
        Filter.GreaterThanOrEqual("priority", 4)),
    Order = { { "priority", PropertyOrder.Types.Direction.Descending } }
};

Go

query := datastore.NewQuery("Task").
	FilterField("Done", "=", false).
	FilterField("Priority", ">=", 4).
	Order("-Priority")

Java

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            CompositeFilter.and(
                PropertyFilter.eq("done", false), PropertyFilter.ge("priority", 4)))
        .setOrderBy(OrderBy.desc("priority"))
        .build();

Node.js

const query = datastore
  .createQuery('Task')
  .filter(
    and([
      new PropertyFilter('done', '=', false),
      new PropertyFilter('priority', '>=', 4),
    ]),
  )
  .order('priority', {
    descending: true,
  });

PHP

$query = $datastore->query()
    ->kind('Task')
    ->filter('done', '=', false)
    ->filter('priority', '>=', 4)
    ->order('priority', Query::ORDER_DESCENDING);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

query = client.query(kind="Task")
query.add_filter(filter=datastore.query.PropertyFilter("done", "=", False))
query.add_filter(filter=datastore.query.PropertyFilter("priority", ">=", 4))
query.order = ["-priority"]

Ruby

query = datastore.query("Task")
                 .where("done", "=", false)
                 .where("priority", ">=", 4)
                 .order("priority", :desc)

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

כדי להשיג מודל עקביות חזק, כדאי ליצור את הישויות עם נתיב אב. נתיב האב מזהה את ישות הבסיס המשותפת שבה מקובצות הישויות שנוצרו. בדוגמה הזו נעשה שימוש בנתיב של ישות אב מסוג TaskList בשם default:

C#

Key taskListKey = _db.CreateKeyFactory("TaskList").CreateKey(TestUtil.RandomName());
Key taskKey = new KeyFactory(taskListKey, "Task").CreateKey("sampleTask");
Entity task = new Entity()
{
    Key = taskKey,
    ["category"] = "Personal",
    ["done"] = false,
    ["priority"] = 4,
    ["description"] = "Learn Cloud Datastore"
};

Go

parentKey := datastore.NameKey("TaskList", "default", nil)
key := datastore.IncompleteKey("Task", parentKey)

task := Task{
	Category:    "Personal",
	Done:        false,
	Priority:    4,
	Description: "Learn Cloud Datastore",
}

// A complete key is assigned to the entity when it is Put.
var err error
key, err = client.Put(ctx, key, &task)

Java

Key taskKey =
    datastore
        .newKeyFactory()
        .addAncestors(PathElement.of("TaskList", "default"))
        .setKind("Task")
        .newKey("sampleTask");
Entity task =
    Entity.newBuilder(taskKey)
        .set("category", "Personal")
        .set("done", false)
        .set("priority", 4)
        .set("description", "Learn Cloud Datastore")
        .build();

Node.js

const taskKey = datastore.key([
  'TaskList',
  'default',
  'Task',
  'sampleTask',
]);

const task = {
  key: taskKey,
  data: {
    category: 'Personal',
    done: false,
    priority: 4,
    description: 'Learn Cloud Datastore',
  },
};

PHP

$parentKey = $datastore->key('TaskList', 'default');
$key = $datastore->key('Task')->ancestorKey($parentKey);
$task = $datastore->entity(
    $key,
    [
        'Category' => 'Personal',
        'Done' => false,
        'Priority' => 4,
        'Description' => 'Learn Cloud Datastore'
    ]
);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

key_with_parent = client.key("TaskList", "default", "Task", "sampleTask")

task = datastore.Entity(key=key_with_parent)

task.update(
    {
        "category": "Personal",
        "done": False,
        "priority": 4,
        "description": "Learn Cloud Datastore",
    }
)

Ruby

# task_list_name = "default"
# task_name = "sampleTask"
task_key = datastore.key [["TaskList", task_list_name], ["Task", task_name]]

task = datastore.entity task_key do |t|
  t["category"] = "Personal"
  t["done"] = false
  t["priority"] = 4
  t["description"] = "Learn Cloud Datastore"
end

לאחר מכן תוכלו לבצע שאילתא לגבי ישות אב עם עקביות חזקה בתוך קבוצת הישויות שזוהתה על ידי ישות שורש משותפת:

C#

Query query = new Query("Task")
{
    Filter = Filter.HasAncestor(_db.CreateKeyFactory("TaskList")
        .CreateKey(keyName))
};

Go

ancestor := datastore.NameKey("TaskList", "default", nil)
query := datastore.NewQuery("Task").Ancestor(ancestor)

Java

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            PropertyFilter.hasAncestor(
                datastore.newKeyFactory().setKind("TaskList").newKey("default")))
        .build();

Node.js

const ancestorKey = datastore.key(['TaskList', 'default']);

const query = datastore.createQuery('Task').hasAncestor(ancestorKey);

PHP

$ancestorKey = $datastore->key('TaskList', 'default');
$query = $datastore->query()
    ->kind('Task')
    ->hasAncestor($ancestorKey);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

# Query filters are omitted in this example as any ancestor queries with a
# non-key filter require a composite index.
ancestor = client.key("TaskList", "default")
query = client.query(kind="Task", ancestor=ancestor)

Ruby

# task_list_name = "default"
ancestor_key = datastore.key "TaskList", task_list_name

query = datastore.query("Task")
                 .ancestor(ancestor_key)

הגישה הזו מאפשרת מודל עקביות חזק על ידי כתיבה לקבוצת ישויות אחת לכל רשימת משימות, אבל היא גם מגבילה את השינויים ברשימת המשימות ללא יותר מכתיבה אחת לשנייה (המגבלה הנתמכת לקבוצות ישויות). אם סביר להניח שהאפליקציה שלכם תיתקל בשימוש אינטנסיבי יותר בפעולות כתיבה, יכול להיות שתצטרכו לשקול שימוש באמצעים אחרים. לדוגמה, אם האפליקציה שלכם היא ספר אורחים שמאפשר למשתמשים לפרסם הודעות בלוח הודעות ציבורי, אתם יכולים להציב פוסטים מהזמן האחרון ב-memcache עם תפוגה ולהציג שילוב של פוסטים מהזמן האחרון מ-memcache ומ-Datastore, או שאתם יכולים לשמור אותם במטמון בקובץ Cookie, להציב מצב מסוים בכתובת ה-URL או משהו אחר לגמרי. המטרה היא למצוא פתרון אחסון במטמון שיספק את הנתונים של המשתמש הנוכחי במהלך התקופה שבה המשתמש מפרסם באפליקציה שלכם. חשוב לזכור: אם מבצעים lookup, שאילתא לגבי ישות אב (בהנחה שמדיניות קריאה לא מוגדרת כמודל עקביות הדרגתי) או כל פעולה בתוך טרנזקציה, תמיד יוצגו הנתונים שנכתבו לאחרונה.

דוגמאות נוספות לשימוש בעסקאות זמינות כאן.

הגבלות על עסקאות של קבוצות ישויות

ארגון הנתונים בקבוצות של ישויות יכול להגביל את סוגי העסקאות שאפשר לבצע:

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

מידע נוסף על עדכון ישויות ואינדקסים מופיע במאמר בידוד טרנזקציות.

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

רמות עקביות

התחייבויות לעקביות

מדיניות קריאה של Datastore

C#

Go

Java

Node.js

PHP

Python

Ruby

שיקולים לגבי עסקאות ועקביות

הגדרת מבנה הנתונים לשמירה על עקביות

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

הגבלות על עסקאות של קבוצות ישויות

ארגון נתונים לעקביות חזקה