שכפול ברמה גבוהה ב-Tarantool DBMS

שלום, אני יוצר יישומים עבור DBMS טרנטול היא פלטפורמה שפותחה על ידי Mail.ru Group המשלבת DBMS בעל ביצועים גבוהים ושרת יישומים בשפת Lua. המהירות הגבוהה של פתרונות המבוססים על Tarantool מושגת, במיוחד, הודות לתמיכה במצב הזיכרון של ה-DBMS והיכולת לבצע לוגיקה עסקית של יישומים במרחב כתובות יחיד עם נתונים. במקביל, עמידות הנתונים מובטחת באמצעות עסקאות ACID (יומן WAL נשמר על הדיסק). ל-Tarantool יש תמיכה מובנית לשכפול וריסוק. החל מגרסה 2.1, שאילתות בשפת SQL נתמכות. Tarantool הוא קוד פתוח ומורשה תחת רישיון BSD Simplified. יש גם גרסת Enterprise מסחרית.

הרגישו את העוצמה! (...aka תהנה מהביצוע)

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

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

אורז. 1. שכפול בתוך אשכול

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

1. חיסכון בתנועה:

• לא ניתן להעביר את כל הנתונים, אלא רק חלק מהם (לדוגמה, ניתן להעביר רק חלק מהטבלאות, חלק מהעמודות או הרשומות שלהן העומדות בקריטריון מסוים);
• בניגוד לשכפול ברמה נמוכה, המתבצעת באופן רציף במצב אסינכרוני (מיושם בגרסה הנוכחית של Tarantool - 1.10) או סינכרוני (שייושם בגרסאות הבאות של Tarantool), ניתן לבצע שכפול ברמה גבוהה בסשנים (כלומר, האפליקציה מסנכרנת תחילה את הנתונים - נתוני הפעלה של החלפה, לאחר מכן יש הפסקה בשכפול, ולאחר מכן מתרחשת הפגישה הבאה של החלפה וכו');
• אם רשומה השתנתה מספר פעמים, אתה יכול להעביר רק את הגרסה האחרונה שלה (בניגוד לשכפול ברמה נמוכה, שבה כל השינויים שנעשו במאסטר יושמעו ברצף על ההעתקים).

2. אין קשיים ביישום חילופי HTTP, המאפשרים לסנכרן מסדי נתונים מרוחקים.

אורז. 2. שכפול על HTTP

3. מבני מסד הנתונים שביניהם מועברים נתונים אינם חייבים להיות זהים (יתר על כן, במקרה הכללי, ניתן אפילו להשתמש ב-DBMS, שפות תכנות, פלטפורמות וכו').

אורז. 3. שכפול במערכות הטרוגניות

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

אם במצבך היתרונות הנ"ל הם מכריעים (או שהם תנאי הכרחי), אז הגיוני להשתמש בשכפול ברמה גבוהה. בואו נסתכל על מספר דרכים ליישם שכפול נתונים ברמה גבוהה ב-Tarantool DBMS.

מזעור תנועה

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

כיצד למזער את כמות הנתונים המועברים במהלך שכפול ברמה גבוהה? פתרון פשוט יכול להיות בחירת נתונים לפי תאריך ושעה. לשם כך, ניתן להשתמש בשדה תאריך-שעה שכבר קיים בטבלה (אם הוא קיים). לדוגמה, מסמך "הזמנה" עשוי לכלול שדה "זמן ביצוע הזמנה נדרש" - delivery_time. הבעיה בפתרון הזה היא שהערכים בשדה זה לא חייבים להיות ברצף המתאים ליצירת פקודות. אז אנחנו לא יכולים לזכור את ערך השדה המקסימלי delivery_time, משודר במהלך הפעלת ההחלפה הקודמת, ובמהלך הפעלת ההחלפה הבאה בחר את כל הרשומות עם ערך שדה גבוה יותר delivery_time. ייתכן שרשומות עם ערך שדה נמוך יותר נוספו בין הפעלות החלפה delivery_time. כמו כן, הצו יכול היה לעבור שינויים, אשר בכל זאת לא השפיעו על השטח delivery_time. בשני המקרים, השינויים לא יועברו מהמקור ליעד. כדי לפתור בעיות אלו, נצטרך להעביר נתונים "חופפים". הָהֵן. בכל סשן החלפה נעביר את כל הנתונים עם ערך השדה delivery_time, חורג מנקודה כלשהי בעבר (לדוגמה, N שעות מהרגע הנוכחי). עם זאת, ברור שעבור מערכות גדולות גישה זו היא מיותרת ביותר ויכולה לצמצם את החיסכון בתעבורה שאנו שואפים אליו לכלום. בנוסף, ייתכן שלטבלה המועברת אין שדה המשויך לתאריך-שעה.

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

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

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

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

העברת נתונים באמצעות מונה גרסאות שורה

הטמעת השרת/מאסטר חלק

ב-MS SQL Server, יש סוג עמודה מיוחד ליישום גישה זו - rowversion. לכל מסד נתונים יש מונה שעולה באחד בכל פעם שמתווספת/משתנה רשומה בטבלה שיש לה עמודה כמו rowversion. הערך של מונה זה מוקצה אוטומטית לשדה של עמודה זו ברשומה שנוספה/שונתה. ל-Tarantool DBMS אין מנגנון מובנה דומה. עם זאת, ב-Tarantool לא קשה ליישם אותו באופן ידני. בואו נראה איך זה נעשה.

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

לפני ביצוע פעולת מסד נתונים כלשהי ב-Tarantool, עליך להפעיל את הפקודה הבאה:

box.cfg{}

כתוצאה מכך, Tarantool יתחיל לכתוב תמונות מצב של מסד נתונים ויומני עסקאות לספרייה הנוכחית.

בואו ניצור רצף row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

אפשרות if_not_exists מאפשר להפעיל את סקריפט היצירה מספר פעמים: אם האובייקט קיים, Tarantool לא ינסה ליצור אותו שוב. אפשרות זו תשמש בכל פקודות ה-DDL הבאות.

בואו ניצור חלל כדוגמה.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

כאן קבענו את שם החלל (goods), שמות שדות וסוגיהם.

שדות הגדלה אוטומטית ב-Tarantool נוצרים גם באמצעות רצפים. בואו ניצור מפתח ראשי בתוספת אוטומטית לפי שדה id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

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

כדי להשתמש בעמודה row_ver כדי להעביר נתונים שהשתנו, עליך לאגד ערכי רצף לשדות של עמודה זו row_ver. אבל בניגוד למפתח הראשי, ערך שדה העמודה row_ver צריך להגדיל באחד לא רק בעת הוספת רשומות חדשות, אלא גם בעת שינוי רשומות קיימות. אתה יכול להשתמש בטריגרים בשביל זה. ל-Tarantool יש שני סוגים של מפעילי שטח: before_replace и on_replace. טריגרים מופעלים בכל פעם שהנתונים במרחב משתנים (עבור כל tuple המושפע מהשינויים, מופעלת פונקציית טריגר). בניגוד on_replace, before_replace-טריגרים מאפשרים לך לשנות את הנתונים של ה-tuple שעבורו הטריגר מבוצע. בהתאם לכך, הסוג האחרון של טריגרים מתאים לנו.

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

הטריגר הבא מחליף את ערך השדה row_ver tuple מאוחסן לערך הבא של הרצף row_version.

על מנת להיות מסוגל לחלץ נתונים מהחלל goods לפי טור row_ver, בואו ניצור אינדקס:

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

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

בואו נוסיף כמה נתונים למרחב:

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

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

בוא נבדוק את תוצאת ההכנסה:

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

כפי שניתן לראות, השדה הראשון והאחרון ממולאים באופן אוטומטי. כעת יהיה קל לכתוב פונקציה להעלאת עמוד אחר עמוד של שינויים בשטח goods:

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

הפונקציה לוקחת כפרמטר את הערך row_ver, החל ממנו יש צורך לפרוק שינויים, ומחזיר חלק מהנתונים שהשתנו.

דגימת נתונים ב-Tarantool נעשית באמצעות אינדקסים. פוּנקצִיָה get_goods משתמש באיטרטור לפי אינדקס row_ver כדי לקבל נתונים שהשתנו. סוג האיטרטור הוא GT (גדול מ, גדול מ). זה אומר שהאיטרטור יעבור ברצף את ערכי האינדקס החל מהמפתח שעבר (ערך שדה row_ver).

האיטרטור מחזיר tuples. על מנת שניתן יהיה להעביר נתונים באמצעות HTTP לאחר מכן, יש צורך להמיר את ה-tuples למבנה נוח להסדרה לאחר מכן. הדוגמה משתמשת בפונקציה הסטנדרטית לשם כך tomap. במקום להשתמש tomap אתה יכול לכתוב פונקציה משלך. לדוגמה, ייתכן שנרצה לשנות את שם השדה name, אל תעבור את השדה code ולהוסיף שדה comment:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

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

בוא נבצע את הפונקציה get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

בואו ניקח את ערך השדה row_ver מהשורה האחרונה וקרא לפונקציה שוב:

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

שוב פעם:

tarantool> get_goods(8)
---
- []
...

כפי שאתה יכול לראות, בשימוש בדרך זו, הפונקציה מחזירה את כל רשומות החלל עמוד אחר עמוד goods. העמוד האחרון מלווה בבחירה ריקה.

בואו נעשה שינויים בחלל:

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

שינינו את ערך השדה name עבור ערך אחד ונוספו שני ערכים חדשים.

בואו נחזור על קריאת הפונקציה האחרונה:

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

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

נשאיר את הנפקת התוצאות באמצעות HTTP בצורה של JSON מחוץ לתחום המאמר הזה. אתה יכול לקרוא על זה כאן: https://habr.com/ru/company/mailru/blog/272141/

יישום חלק הלקוח/עבד

בואו נסתכל איך נראה היישום של הצד המקבל. בואו ניצור מקום בצד המקבל לאחסון הנתונים שהורדתם:

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

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

בנוסף, אנחנו צריכים מקום לשמירת ערכים row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

עבור כל שטח טעון (שדה space_name) נשמור כאן את הערך האחרון שנטען row_ver (שדה value). העמודה פועלת כמפתח הראשי space_name.

בואו ניצור פונקציה לטעינת נתוני שטח goods באמצעות HTTP. לשם כך, אנו זקוקים לספרייה המיישמת לקוח HTTP. השורה הבאה טוענת את הספרייה ומציגה את לקוח ה-HTTP:

local http_client = require('http.client').new()

אנו זקוקים גם לספרייה עבור דסריאליזציה של json:

local json = require('json')

זה מספיק כדי ליצור פונקציית טעינת נתונים:

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

הפונקציה מבצעת בקשת HTTP לכתובת ה-url ושולחת אותה row_ver כפרמטר ומחזיר את התוצאה המרוסקת של הבקשה.

הפונקציה לשמירת נתונים שהתקבלו נראית כך:

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

מחזור שמירת נתונים בחלל goods ממוקם בעסקה (הפונקציה משמשת לכך box.atomic) כדי להפחית את מספר פעולות הדיסק.

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

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

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

כדי להגן מפני לולאה בשוגג (במקרה של שגיאה בתוכנית), הלולאה while ניתן להחליף על ידי for:

for _ = 1, max_req do ...

כתוצאה מביצוע הפונקציה sync_goods מֶרחָב goods המקלט יכיל את הגרסאות העדכניות ביותר של כל רשומות החלל goods במקור.

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

רצף row_ver יכול לשמש להעברת נתונים ממרחבים אחרים: אין צורך ליצור רצף נפרד לכל מרחב משודר.

בדקנו דרך יעילה לשכפול נתונים ברמה גבוהה ביישומים המשתמשים ב- Tarantool DBMS.

ממצאים

1. Tarantool DBMS הוא מוצר אטרקטיבי ומבטיח ליצירת יישומים בעומס גבוה.
2. לשכפול נתונים ברמה גבוהה יש מספר יתרונות על פני שכפול ברמה נמוכה.
3. שיטת השכפול ברמה הגבוהה הנדונה במאמר מאפשרת למזער את כמות הנתונים המועברים על ידי העברת רק אותן רשומות שהשתנו מאז הפעלת ההחלפה האחרונה.

מקור: www.habr.com