NewSQL = NoSQL+ACID

ביז לעצטנס, Odnoklassniki סטאָרד וועגן 50 טב פון דאַטן פּראַסעסט אין פאַקטיש צייט אין SQL סערווירער. פֿאַר אַזאַ אַ באַנד, עס איז כּמעט אוממעגלעך צו צושטעלן שנעל און פאַרלאָזלעך, און אפילו דאַטן צענטער דורכפאַל-טאָלעראַנט אַקסעס ניצן אַ SQL DBMS. טיפּיקאַללי, אין אַזאַ קאַסעס, איינער פון די NoSQL סטאָרידזש איז געניצט, אָבער ניט אַלץ קענען זיין טראַנספערד צו NoSQL: עטלעכע ענטיטיז דאַרפן אַסיד טראַנסאַקטיאָן געראַנטיז.

דאָס האָט אונדז געפֿירט צו די נוצן פון NewSQL סטאָרידזש, דאָס איז, אַ DBMS וואָס גיט שולד טאָלעראַנץ, סקאַלאַביליטי און פאָרשטעלונג פון NoSQL סיסטעמען, אָבער אין דער זעלביקער צייט האַלטן די אַסיד געראַנטיז באַקאַנט מיט קלאַסיש סיסטעמען. עס זענען ווייניק ארבעטן ינדאַסטריאַל סיסטעמען פון דעם נייַ קלאַס, אַזוי מיר ימפּלאַמענאַד אַזאַ אַ סיסטעם זיך און שטעלן עס אין געשעפט אָפּעראַציע.

ווי עס אַרבעט און וואָס געטראפן - לייענען אונטער די שנייַדן.

הייַנט, די כוידעשלעך וילעם פון Odnoklassniki איז מער ווי 70 מיליאָן יינציק וויזאַטערז. מיר מיר זענען אין די שפּיץ פינף גרעסטן געזעלשאַפטלעך נעטוואָרקס אין דער וועלט, און צווישן די צוואַנציק זייטלעך אויף וואָס ניצערס פאַרברענגען די מערסט צייט. די גוט ינפראַסטראַקטשער כאַנדאַלז זייער הויך לאָודז: מער ווי אַ מיליאָן הטטפּ ריקוועס / סעק פּער פראָנט. פּאַרץ פון אַ סערווער פליט פון מער ווי 8000 ברעקלעך זענען ליגן נאָענט צו יעדער אנדערער - אין פיר מאָסקווע דאַטן סענטערס, וואָס אַלאַוז אַ נעץ לייטאַנסי צווישן זיי ווייניקער ווי 1 מיז.

מיר האָבן שוין ניצן Cassandra זינט 2010, סטאַרטינג מיט ווערסיע 0.6. הייַנט עס זענען עטלעכע טוץ קלאַסטערז אין אָפּעראַציע. די פאַסטאַסט קנויל פּראַסעסאַז מער ווי 4 מיליאָן אַפּעריישאַנז פּער סעקונדע, און די גרעסטן סטאָרז 260 טב.

אָבער, דאָס זענען אַלע פּראָסט NoSQL קלאַסטערז געניצט פֿאַר סטאָרידזש שוואַך קאָואָרדאַנייטיד דאַטן. מיר געוואלט צו פאַרבייַטן די הויפּט קאָנסיסטענט סטאָרידזש, Microsoft SQL Server, וואָס איז געניצט זינט די ערשטן פון Odnoklassniki. די סטאָרידזש קאָנסיסטעד פון מער ווי 300 סקל סערווירער סטאַנדאַרד אַדישאַן מאשינען, וואָס קאַנטיינד 50 טב פון דאַטן - געשעפט ענטיטיז. די דאַטן זענען מאַדאַפייד ווי אַ טייל פון אַסיד טראַנזאַקשאַנז און דאַרפן הויך קאָנסיסטענסי.

צו פאַרשפּרייטן דאַטן אַריבער SQL Server נאָודז, מיר געוויינט ביידע ווערטיקאַל און האָריזאָנטאַל צעטיילונג (שאַרדינג). היסטאָריש, מיר געוויינט אַ פּשוט דאַטן שאַרדינג סכעמע: יעדער ענטיטי איז געווען פארבונדן מיט אַ סימען - אַ פֿונקציע פון ​​די ענטיטי שייַן. ענטיטיז מיט די זעלבע סימען זענען געשטעלט אויף דער זעלביקער סקל סערווער. די בעל-דעטאַל שייכות איז ימפּלאַמענאַד אַזוי אַז די טאָקענס פון די הויפּט און קינד רעקאָרדס שטענדיק מאַטשט און זענען ליגן אויף דער זעלביקער סערווער. אין אַ געזעלשאַפטלעך נעץ, כּמעט אַלע רעקאָרדס זענען דזשענערייטאַד אויף ביכאַף פון דער באַניצער - וואָס מיטל אַז אַלע באַניצער דאַטן אין איין פאַנגקשאַנאַל סאַבסיסטאַם זענען סטאָרד אויף איין סערווער. אַז איז, אַ געשעפט טראַנסאַקטיאָן כּמעט שטענדיק ינוואַלווד טישן פֿון איין סקל סערווער, וואָס געמאכט עס מעגלעך צו ענשור דאַטן קאָנסיסטענסי ניצן היגע אַסיד טראַנזאַקשאַנז, אָן די נויט צו נוצן פּאַמעלעך און אַנרילייאַבאַל פונאנדערגעטיילט אַסיד טראַנזאַקשאַנז.

דאַנק צו שאַרדינג און צו פאַרגיכערן SQL:

• מיר טאָן ניט נוצן פרעמד שליסל קאַנסטריינץ, ווייַל ווען שאַרדינג די ענטיטי שייַן קען זיין ליגן אויף אן אנדער סערווער.
• מיר טאָן ניט נוצן סטאָרד פּראָוסידזשערז און טריגערז רעכט צו דער נאָך מאַסע אויף די DBMS קפּו.
• מיר טאָן ניט נוצן JOINs ווייַל פון אַלע די אויבן און אַ פּלאַץ פון טראַפ - לייענען פֿון דיסק.
• אַרויס פון אַ טראַנסאַקטיאָן, מיר נוצן די לייענען ונקאָממיטטעד אפגעזונדערטקייט מדרגה צו רעדוצירן דעדלאַקס.
• מיר דורכפירן בלויז קורץ טראַנזאַקשאַנז (אין דורכשניטלעך קירצער ווי 100 מיז).
• מיר טאָן ניט נוצן מולטי-רודערן דערהייַנטיקן און ויסמעקן רעכט צו דער גרויס נומער פון דעדלאַקס - מיר דערהייַנטיקן בלויז איין רעקאָרד אין אַ צייט.
• מיר שטענדיק דורכפירן פֿראגן בלויז אויף ינדעקסיז - אַ אָנפֿרעג מיט אַ פול טיש יבערקוקן פּלאַן פֿאַר אונדז מיטל אָוווערלאָודינג די דאַטאַבייס און פאַרשאַפן עס צו פאַרלאָזן.

די סטעפּס ערלויבט אונדז צו קוועטשן כּמעט מאַקסימום פאָרשטעלונג פון SQL סערווערס. אָבער, די פּראָבלעמס געווארן מער און מער סך. זאל ס קוק בייַ זיי.

פּראָבלעמס מיט SQL

• זינט מיר געוויינט זיך-געשריבן שאַרדינג, אַדינג נייַ שאַרדז איז מאַניואַלי געטאן דורך אַדמיניסטראַטאָרס. אַלע די צייט, סקאַלאַבלע דאַטן רעפּלאַקאַז זענען נישט סערוויסינג ריקוועס.
• ווי די נומער פון רעקאָרדס אין די טיש וואקסט, די גיכקייַט פון ינסערשאַן און מאָדיפיקאַטיאָן דיקריסאַז ווען אַדינג ינדעקסיז צו אַ יגזיסטינג טיש, די גיכקייַט טראפנס דורך אַ פאַקטאָר און שייַעך-שאַפונג פון ינדעקסיז אַקערז;
• ווייל אַ קליין סומע פון ​​​​Windows פֿאַר SQL Server אין פּראָדוקציע מאכט ינפראַסטראַקטשער פאַרוואַלטונג שווער

אבער דער הויפּט פּראָבלעם איז

שולד טאָלעראַנץ

דער קלאַסיש סקל סערווער האט נעבעך שולד טאָלעראַנץ. זאל ס זאָגן איר האָבן בלויז איין דאַטאַבייס סערווער, און עס פיילז אַמאָל יעדער דריי יאָר. אין דעם צייט, די פּלאַץ איז אַראָפּ פֿאַר 20 מינוט, וואָס איז פּאַסיק. אויב איר האָבן 64 סערווערס, די פּלאַץ איז אַראָפּ אַמאָל יעדער דריי וואָכן. און אויב איר האָבן 200 סערווערס, דער פּלאַץ טוט נישט אַרבעטן יעדער וואָך. דאָס איז אַ פּראָבלעם.

וואָס קענען זיין געטאן צו פֿאַרבעסערן די שולד טאָלעראַנץ פון אַ SQL סערווער? וויקיפעדיע ינווייץ אונדז צו בויען העכסט בנימצא קנויל: ווו אין פאַל פון דורכפאַל פון קיין פון די קאַמפּאָונאַנץ עס איז אַ באַקאַפּ איינער.

דאָס ריקווייערז אַ פליט פון טייַער ויסריכט: פילע דופּליקיישאַנז, אָפּטיש פיברע, שערד סטאָרידזש און די ינקלוזשאַן פון אַ רעזערוו אַרבעט נישט רילייאַבלי: וועגן 10% פון די סוויטשינג ענדיקן מיט די דורכפאַל פון די באַקאַפּ נאָדע ווי אַ באַן הינטער די הויפּט נאָדע.

אָבער דער הויפּט כיסאָרן פון אַזאַ אַ העכסט בנימצא קנויל איז נול אַוויילאַבילאַטי אויב די דאַטן צענטער אין וואָס עס איז ליגן פיילז. Odnoklassniki האט פיר דאַטן סענטערס, און מיר דאַרפֿן צו ענשור די אָפּעראַציע אין פאַל פון אַ גאַנץ דורכפאַל אין איינער פון זיי.

פֿאַר דעם מיר קען נוצן מולטי-מאַסטער רעפּלאַקיישאַן געבויט אין SQL Server. דער לייזונג איז פיל מער טייַער רעכט צו דער פּרייַז פון ווייכווארג און סאַפערז פון באַוווסט פּראָבלעמס מיט רעפּלאַקיישאַן - אַנפּרידיקטאַבאַל טראַנסאַקטיאָן דילייז מיט סינטשראָנאָוס רעפּלאַקיישאַן און דילייז אין אַפּלייינג רעפּלאַקיישאַנז (און, ווי אַ רעזולטאַט, פאַרפאַלן מאָדיפיקאַטיאָנס) מיט ייסינגקראַנאַס רעפּלאַקיישאַן. די ימפּלייד מאַנואַל קאָנפליקט האַכלאָטע מאכט דעם אָפּציע גאָר ינאַפּלאַקאַבאַל צו אונדז.

ד י אל ע פראבלעמע ן האב ן געדארפ ט א ראדיקאלע ר לײזונג , או ן מי ר האב ן ז ײ אנגעהויב ן מי ט דעטאליטעט ן אַנאַליזירן . דאָ מיר דאַרפֿן צו באַקומען באַקאַנט מיט וואָס SQL Server דער הויפּט טוט - טראַנזאַקשאַנז.

פּשוט טראַנסאַקטיאָן

זאל ס באַטראַכטן די סימפּלאַסט טראַנסאַקטיאָן, פֿון די פונט פון מיינונג פון אַ געווענדט SQL פּראָגראַמיסט: אַדינג אַ פאָטאָ צו אַן אלבאם. אַלבומס און פאָוטאַגראַפס זענען סטאָרד אין פאַרשידענע פּלאַטעס. דער אלבאם האט אַ ציבור פאָטאָ טאָמבאַנק. דערנאָך, אַזאַ אַ טראַנסאַקטיאָן איז צעטיילט אין די פאלגענדע סטעפּס:

1. מיר שלאָס דעם אלבאם דורך שליסל.
2. שאַפֿן אַ פּאָזיציע אין די פאָטאָ טיש.
3. אויב די פאָטאָ האט אַ ציבור סטאַטוס, לייגן אַ ציבור פאָטאָ טאָמבאַנק צו דעם אלבאם, דערהייַנטיקן די רעקאָרד און יבערגעבן די טראַנסאַקטיאָן.

אָדער אין פּסעוודאָקאָדע:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

מיר זען אַז די מערסט פּראָסט געשעפט טראַנסאַקטיאָן סצענאַר איז צו לייענען דאַטן פון די דאַטאַבייס אין דער זכּרון פון די אַפּלאַקיישאַן סערווער, טוישן עפּעס און ראַטעווען די נייַע וואַלועס צוריק צו די דאַטאַבייס. יוזשאַוואַלי אין אַזאַ אַ טראַנסאַקטיאָן מיר דערהייַנטיקן עטלעכע ענטיטיז, עטלעכע טישן.

ווען עקסאַקיוטינג אַ טראַנסאַקטיאָן, קאַנקעראַנט מאָדיפיקאַטיאָן פון די זעלבע דאַטן פון אן אנדער סיסטעם קען פּאַסירן. פֿאַר בייַשפּיל, אַנטיספּאַם קען באַשליסן אַז דער באַניצער איז עפעס סאַספּישאַס און דעריבער אַלע די פאָטאָס פון די באַניצער זאָל ניט מער זיין עפנטלעך, זיי דאַרפֿן צו זיין געשיקט פֿאַר מאַדעריישאַן, וואָס מיטל טשאַנגינג פאָטאָ.סטאַטוס צו עטלעכע אנדערע ווערט און קער אַוועק די קאָראַספּאַנדינג קאָונטערס. דאָך, אויב דעם אָפּעראַציע אַקערז אָן געראַנטיז פון אַטאָמיסיטי פון אַפּלאַקיישאַן און אפגעזונדערטקייט פון קאַמפּיטינג מאָדיפיקאַטיאָנס, ווי אין זויער, דער רעזולטאַט וועט נישט זיין וואָס איז דארף - אָדער די פאָטאָ טאָמבאַנק וועט ווייַזן דעם אומרעכט ווערט, אָדער ניט אַלע פאָטאָס וועט זיין געשיקט פֿאַר מאַדעריישאַן.

א פּלאַץ פון ענלעך קאָד, מאַניפּיאַלייטינג פאַרשידן געשעפט ענטיטיז אין איין טראַנסאַקטיאָן, איז געשריבן איבער די גאנצע עקזיסטענץ פון Odnoklassniki. באַזירט אויף דער דערפאַרונג פון מייגריישאַנז צו NoSQL פֿון עווענטואַל קאָנסיסטענסי מיר וויסן אַז די ביגאַסט אַרויסרופן (און צייט ינוועסמאַנט) קומט פון דעוועלאָפּינג קאָד צו טייַנען דאַטן קאָנסיסטענסי. דעריבער, מיר באַטראַכטן די הויפּט פאָדערונג פֿאַר די נייַע סטאָרידזש צו זיין טנייַ פֿאַר פאַקטיש אַסיד טראַנזאַקשאַנז פֿאַר אַפּלאַקיישאַן לאָגיק.

אנדערע, ניט ווייניקער וויכטיק, באדערפענישן זענען:

• אויב די דאַטן צענטער פיילז, ביידע לייענען און שרייבן צו די נייַע סטאָרידזש מוזן זיין בארעכטיגט.
• מיינטיינינג קראַנט אַנטוויקלונג גיכקייַט. אַז איז, ווען ארבעטן מיט אַ נייַ ריפּאַזאַטאָרי, די סומע פון ​​קאָד זאָל זיין בעערעך דער זעלביקער עס זאָל זיין ניט דאַרפֿן צו לייגן עפּעס צו די ריפּאַזאַטאָרי, אַנטוויקלען אַלגערידאַמז פֿאַר ריזאַלווינג קאָנפליקט, האַלטן צווייטיק ינדעקסיז, אאז"ו ו.
• די גיכקייַט פון די נייַ סטאָרידזש האט צו זיין גאַנץ הויך, ביידע ווען לייענען דאַטן און פּראַסעסינג טראַנזאַקשאַנז, וואָס יפעקטיוולי מענט אַז אַקאַדעמיקלי שטרענג, וניווערסאַל, אָבער פּאַמעלעך סאַלושאַנז, אַזאַ ווי, פֿאַר בייַשפּיל, זענען נישט אָנווענדלעך. צוויי-פאַסע קאַמיץ.
• אָטאַמאַטיק אויף-דעם-פליען סקיילינג.
• ניצן רעגולער ביליק סערווערס, אָן די דאַרפֿן צו קויפן עקזאָטיש ייַזנוואַרג.
• מעגלעכקייט פון סטאָרידזש אַנטוויקלונג דורך פירמע דעוועלאָפּערס. אין אנדערע ווערטער, בילכערקייַט איז געגעבן צו פּראַפּרייאַטערי אָדער אָפֿן מקור סאַלושאַנז, פּרעפעראַבלי אין Java.

באשלוסן, באשלוסן

אַנאַלייזינג מעגלעך סאַלושאַנז, מיר געקומען צו צוויי מעגלעך אַרקאַטעקטשער ברירות:

דער ערשטער איז צו נעמען קיין SQL סערווער און ינסטרומענט די פארלאנגט שולד טאָלעראַנץ, סקיילינג מעקאַניזאַם, פאַילאָווער קנויל, קאָנפליקט האַכלאָטע און פונאנדערגעטיילט, פאַרלאָזלעך און שנעל אַסיד טראַנזאַקשאַנז. מיר רייטאַד דעם אָפּציע ווי זייער ניט-ניטוויאַל און אַרבעט-אינטענסיווע.

די רגע אָפּציע איז צו נעמען אַ פאַרטיק NoSQL סטאָרידזש מיט ימפּלאַמענאַד סקיילינג, אַ פאַילאָווער קנויל, קאָנפליקט האַכלאָטע און ינסטרומענט טראַנזאַקשאַנז און SQL זיך. אין ערשטער בליק, אפילו די אַרבעט פון ימפּלאַמענינג SQL, ניט צו דערמאָנען אַסיד טראַנזאַקשאַנז, קוקט ווי אַ אַרבעט וואָס וועט נעמען יאָרן. אָבער דעמאָלט מיר איינגעזען אַז די SQL שטריך שטעלן מיר נוצן אין פיר איז ווי ווייַט פון ANSI SQL ווי Cassandra CQL ווייַט פון ANSI SQL. גענומען אַן אפילו נעענטער קוק אין CQL, מיר איינגעזען אַז עס איז גאַנץ נאָענט צו וואָס מיר דארף.

קאַסאַנדראַ און קקל

אַזוי, וואָס איז טשיקאַווע וועגן Cassandra, וואָס קייפּאַבילאַטיז עס האט?

פירסטלי, דאָ איר קענען מאַכן טישן וואָס שטיצן פאַרשידן דאַטן טייפּס, איר קענען אויסקלייַבן אָדער דערהייַנטיקן אויף די ערשטיק שליסל.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

צו ענשור רעפּליקע דאַטן קאָנסיסטענסי, Cassandra ניצט קוואָרום צוגאַנג. אין די סימפּלאַסט פאַל, דאָס מיטל אַז ווען דריי רעפּלאַקאַז פון דער זעלביקער רודערן זענען געשטעלט אויף פאַרשידענע נאָודז פון דעם קנויל, די שרייבן איז גערעכנט ווי געראָטן אויב די מערהייַט פון נאָודז (דאָס איז, צוויי פון דריי) באשטעטיקט די הצלחה פון דעם שרייַבן אָפּעראַציע . די רודערן דאַטן זענען געהאלטן קאָנסיסטענט אויב, ווען לייענען, די מערהייַט פון נאָודז זענען פּאָולד און באשטעטיקט זיי. אזוי, מיט דריי רעפּלאַקאַז, גאַנץ און רעגע דאַטן קאָנסיסטענסי איז געראַנטיד אויב איין נאָדע פיילז. דער צוגאַנג ערלויבט אונדז צו ינסטרומענט אַן אפילו מער פאַרלאָזלעך סכעמע: שטענדיק שיקן ריקוועס צו אַלע דריי רעפּלאַקאַז, ווארטן פֿאַר אַ ענטפער פון די צוויי פאַסטאַסט אָנעס. די שפּעט ענטפער פון די דריט רעפּליקע איז אַוועקגענומען אין דעם פאַל. א נאָדע וואָס איז שפּעט אין ריספּאַנדינג קען האָבן ערנסט פּראָבלעמס - בראַקעס, מיסט זאַמלונג אין די JVM, דירעקט זכּרון ריקליים אין די לינוקס קערן, ייַזנוואַרג דורכפאַל, דיסקאַנעקשאַן פון די נעץ. אָבער, דאָס קען נישט ווירקן די אַפּעריישאַנז אָדער דאַטן פון דעם קליענט אין קיין וועג.

דער צוגאַנג ווען מיר קאָנטאַקט דרייַ נאָודז און באַקומען אַ ענטפער פון צוויי איז גערופן ספּעקולאַציע: אַ בקשה פֿאַר עקסטרע רעפּלאַקאַז איז געשיקט אפילו איידער עס "פאַלן אַוועק".

אן אנדער נוץ פון Cassandra איז Batchlog, אַ מעקאַניזאַם וואָס ינשורז אַז אַ פּעקל פון ענדערונגען וואָס איר מאַכן זענען גאָר געווענדט אָדער נישט געווענדט. דאָס אַלאַוז אונדז צו סאָלווע א אין אַסיד - אַטאָמיסיטי אויס פון די קעסטל.

די קלאָוסאַסט זאַך צו טראַנזאַקשאַנז אין קאַסאַנדראַ זענען די אַזוי גערופענע "לייטווייט טראַנזאַקשאַנז". אבער זיי זענען ווייַט פון "פאַקטיש" אַסיד טראַנזאַקשאַנז: אין פאַקט, דאָס איז אַ געלעגנהייט צו טאָן קאַס אויף דאַטן פֿון בלויז איין רעקאָרד, ניצן קאָנסענסוס ניצן די כעוויווייט פּאַקסאָס פּראָטאָקאָל. דעריבער, די גיכקייַט פון אַזאַ טראַנזאַקשאַנז איז נידעריק.

וואָס מיר האָבן פעלנדיק אין קאַסאַנדראַ

אַזוי, מיר האָבן צו ינסטרומענט פאַקטיש אַסיד טראַנזאַקשאַנז אין קאַססאַנדראַ. מיט וואָס מיר קענען לייכט ינסטרומענט צוויי אנדערע באַקוועם פֿעיִקייטן פון קלאַסיש DBMS: קאָנסיסטענט שנעל ינדעקסיז, וואָס וואָלט לאָזן אונדז צו דורכפירן דאַטן סאַלעקשאַנז ניט בלויז דורך די ערשטיק שליסל, און אַ רעגולער גענעראַטאָר פון מאַנאַטאַניק אַוטאָ ינקראַמאַנטינג ידס.

C * איין

אזוי איז געבוירן אַ נייַ DBMS C * איין, קאַנסיסטינג פון דריי טייפּס פון סערווער נאָודז:

• סטאָרידזש - (כּמעט) נאָרמאַל קאַססאַנדראַ סערווערס פאַראַנטוואָרטלעך פֿאַר סטאָרינג דאַטן אויף היגע דיסקס. ווי די מאַסע און באַנד פון דאַטן וואַקסן, זייער קוואַנטיטי קענען זיין לייכט סקיילד צו טענס און הונדערטער.
• טראַנסאַקטיאָן קאָאָרדינאַטאָרס - ענשור די דורכפירונג פון טראַנזאַקשאַנז.
• קלייאַנץ זענען אַפּלאַקיישאַן סערווערס וואָס ינסטרומענט געשעפט אַפּעריישאַנז און אָנהייבן טראַנזאַקשאַנז. עס קענען זיין טויזנטער פון אַזאַ קלייאַנץ.

סערווערס פון אַלע טייפּס זענען טייל פון אַ פּראָסט קנויל, נוצן די ינערלעך Cassandra אָנזאָג פּראָטאָקאָל צו יבערגעבן מיט יעדער אנדערע און יענטע פֿאַר יקסטשיינדזשינג קנויל אינפֿאָרמאַציע. מיט העאַרטבעאַט, סערווערס לערנען וועגן קעגנצייַטיק פייליערז, האַלטן אַ איין דאַטן סטשעמאַ - טישן, זייער סטרוקטור און רעפּלאַקיישאַן; צעטיילונג סכעמע, קנויל טאָפּאָלאָגי, עטק.

קאַסטאַמערז

אַנשטאָט נאָרמאַל דריווערס, Fat Client מאָדע איז געניצט. אַזאַ אַ נאָדע טוט נישט קראָם דאַטן, אָבער קענען שפּילן ווי אַ קאָאָרדינאַטאָר פֿאַר די דורכפירונג פון בעטן, דאָס הייסט, דער קליענט זיך אקטן ווי אַ קאָאָרדינאַטאָר פון זיין ריקוועס: עס קווערינג סטאָרידזש רעפּלאַקאַז און ריזאַלווז קאָנפליקט. דאָס איז ניט בלויז מער פאַרלאָזלעך און פאַסטער ווי דער נאָרמאַל שאָפער, וואָס ריקווייערז קאָמוניקאַציע מיט אַ ווייַט קאָאָרדינאַטאָר, אָבער אויך אַלאַוז איר צו קאָנטראָלירן די טראַנסמיסיע פון ​​ריקוועס. אַרויס פון אַ טראַנסאַקטיאָן עפענען אויף דעם קליענט, ריקוועס זענען געשיקט צו ריפּאַזאַטאָריז. אויב דער קליענט האט געעפנט אַ טראַנסאַקטיאָן, אַלע ריקוועס אין די טראַנסאַקטיאָן זענען געשיקט צו די טראַנסאַקטיאָן קאָאָרדינאַטאָר.

C * איין טראַנסאַקטיאָן קאָאָרדינאַטאָר

דער קאָאָרדינאַטאָר איז עפּעס וואָס מיר ימפּלאַמענאַד פֿאַר C * איין פֿון קראַצן. עס איז פאַראַנטוואָרטלעך פֿאַר אָנפירונג טראַנזאַקשאַנז, לאַקס און די סדר אין וואָס טראַנזאַקשאַנז זענען געווענדט.

פֿאַר יעדער סערוויסט טראַנסאַקטיאָן, דער קאָאָרדינאַטאָר דזשענערייץ אַ טימעסטאַמפּ: יעדער סאַבסאַקוואַנט טראַנסאַקטיאָן איז גרעסער ווי די פריערדיקע טראַנסאַקטיאָן. זינט Cassandra ס קאָנפליקט האַכלאָטע סיסטעם איז באזירט אויף טימעסטאַמפּס (פון צוויי קאַנפליקטינג רעקאָרדס, דער איינער מיט די לעצטע טימעסטאַמפּ איז גערעכנט ווי קראַנט), דער קאָנפליקט וועט שטענדיק זיין ריזאַלווד אין טויווע פון ​​די סאַבסאַקוואַנט טראַנסאַקטיאָן. אזוי מיר ימפּלאַמענאַד לאַמפּאָרט וואַך - אַ ביליק וועג צו סאָלווע קאָנפליקט אין אַ פונאנדערגעטיילט סיסטעם.

לאַקס

צו ענשור אפגעזונדערטקייט, מיר באַשלאָסן צו נוצן די סימפּלאַסט אופֿן - פּעסימיסטיש לאַקס באזירט אויף די ערשטיק שליסל פון די רעקאָרד. אין אנדערע ווערטער, אין אַ טראַנסאַקטיאָן, אַ רעקאָרד מוזן ערשטער זיין פארשפארט, נאָר דעמאָלט לייענען, מאַדאַפייד און געראטעוועט. בלויז נאָך אַ מצליח יבערגעבן קענען זיין אַנלאַקט אַ רעקאָרד אַזוי אַז קאַמפּיטינג טראַנזאַקשאַנז קענען נוצן עס.

ימפּלאַמענינג אַזאַ לאַקינג איז פּשוט אין אַ ניט-פוסטריביוטע סוויווע. אין אַ פונאנדערגעטיילט סיסטעם, עס זענען צוויי הויפּט אָפּציעס: אָדער ינסטרומענט פונאנדערגעטיילט לאַקינג אויף דעם קנויל, אָדער פאַרשפּרייטן טראַנזאַקשאַנז אַזוי אַז טראַנזאַקשאַנז מיט די זעלבע רעקאָרד זענען שטענדיק סערווייווד דורך דער זעלביקער קאָאָרדינאַטאָר.

זינט אין אונדזער פאַל די דאַטן זענען שוין פונאנדערגעטיילט צווישן גרופּעס פון היגע טראַנזאַקשאַנז אין סקל, עס איז באַשלאָסן צו באַשטימען היגע טראַנסאַקטיאָן גרופּעס צו קאָאָרדינאַטאָרס: איין קאָאָרדינאַטאָר פּערפאָרמז אַלע טראַנזאַקשאַנז מיט טאָקענס פון 0 צו 9, די רגע - מיט טאָקענס פון 10 צו 19, און אזוי ווייטער. ווי אַ רעזולטאַט, יעדער פון די קאָאָרדינאַטאָר ינסטאַנסיז ווערט דער בעל פון די טראַנסאַקטיאָן גרופּע.

דערנאָך לאַקס קענען זיין ימפּלאַמענאַד אין די פאָרעם פון אַ באַנאַל האַשמאַפּ אין דער זכּרון פון די קאָאָרדינאַטאָר.

קאָאָרדינאַטאָר פייליערז

זינט איין קאָאָרדינאַטאָר אויסשליסלעך סערוועס אַ גרופּע פון ​​טראַנזאַקשאַנז, עס איז זייער וויכטיק צו געשווינד באַשליסן די פאַקט פון זייַן דורכפאַל אַזוי אַז די רגע פּרווון צו ויספירן די טראַנסאַקטיאָן וועט זיין צייט. צו מאַכן דעם שנעל און פאַרלאָזלעך, מיר געוויינט אַ גאָר קאָננעקטעד קוואָרום העאַרבעאַט פּראָטאָקאָל:

יעדער דאַטן צענטער האָסץ לפּחות צוויי קאָאָרדינאַטאָר נאָודז. פּעריאָדיש, שיקט יעדער קאָאָרדינאַטאָר אַ האַרץ-קלאַפּ אָנזאָג צו די אנדערע קאָאָרדינאַטאָרס און ינפאָרמז זיי וועגן זייַן פאַנגקשאַנינג, ווי אויך וואָס האַרץ קלאַפּ אַרטיקלען עס באקומען פון וואָס קאָאָרדינאַטאָרס אין די קנויל לעצטע מאָל.

באקומען ענליכע אינפארמאציע פון ​​אנדערע אלס א טייל פון זייער הארץ-קלאפ מעסעדזשעס, באשליסט יעדער קאארדינאַטאָר פאר זיך וועלכע קנויל נאָודז פונקציאָנירן און וועלכע נישט, גיידיד לויטן קוואָרום פּרינציפּ: אויב נאָדע X האט באקומען אינפארמאציע פון ​​די מערהייט נאָודז אין דעם קנויל וועגן דעם נאָרמאַלן. קאַבאָלע פון ​​אַרטיקלען פון נאָדע י, דעמאָלט Y אַרבעט. און פאַרקערט, ווי באַלד ווי די מערהייט מעלדעט פעלנדיק אָנזאָגן פון נאָדע י, דעמאָלט י האט אפגעזאגט. עס איז טשיקאַווע אַז אויב די קוואָרום ינפאָרמז נאָדע X אַז עס איז ניט מער ריסיווינג אַרטיקלען פון אים, דעמאָלט נאָדע X זיך וועט באַטראַכטן זיך פֿאַר דורכפאַל.

העאַרטביט אַרטיקלען זענען געשיקט מיט הויך אָפטקייַט, וועגן 20 מאל פּער סעקונדע, מיט אַ צייט פון 50 מיז. אין Java, עס איז שווער צו גאַראַנטירן אַפּלאַקיישאַן ענטפער ין 50 מיז רעכט צו דער פאַרגלייַכלעך לענג פון פּאָזאַז געפֿירט דורך די מיסט קאַלעקטער. מיר זענען ביכולת צו דערגרייכן דעם ענטפער צייט מיט די G1 מיסט קאַלעקטער, וואָס אַלאַוז אונדז צו ספּעציפיצירן אַ ציל פֿאַר די געדויער פון GC פּאָזאַז. אָבער, מאל, גאַנץ ראַרעלי, די קאַלעקטער פּאָזאַז יקסיד 50 מיז, וואָס קענען פירן צו אַ פאַלש שולד דיטעקשאַן. צו פאַרמייַדן דעם פון געשעעניש, דער קאָאָרדינאַטאָר קען נישט באַריכט אַ דורכפאַל פון אַ ווייַט נאָדע ווען דער ערשטער כאַרטביט אָנזאָג פון עס פאַרשווינדן, נאָר אויב עטלעכע זענען פאַרשווונדן אין אַ רודערן מיס.

אָבער עס איז נישט גענוג צו געשווינד פֿאַרשטיין וואָס נאָדע האט פארשטאפט פאַנגקשאַנינג. מיר דאַרפֿן צו טאָן עפּעס וועגן דעם.

רעזערוואַציע

דער קלאַסיש סכעמע ינוואַלווז, אין די געשעעניש פון אַ בעל דורכפאַל, סטאַרטינג אַ נייַ וואַלן ניצן איינער פון מאָדערן וניווערסאַל אַלגערידאַמז. אָבער, אַזאַ אַלגערידאַמז האָבן געזונט-באקאנט פּראָבלעמס מיט צייַט קאַנווערדזשאַנס און די לענג פון די וואַלן פּראָצעס זיך. מיר זענען ביכולת צו ויסמיידן אַזאַ נאָך דילייז ניצן אַ קאָאָרדינאַטאָר פאַרבייַט סכעמע אין אַ גאָר פארבונדן נעץ:

זאל ס זאָגן מיר ווילן צו ויספירן אַ טראַנסאַקטיאָן אין גרופּע 50. זאל ס באַשטימען אין שטייַגן די פאַרבייַט סכעמע, וואָס איז, וואָס נאָודז וועט ויספירן טראַנזאַקשאַנז אין גרופּע 50 אין די געשעעניש פון אַ דורכפאַל פון די הויפּט קאָאָרדינאַטאָר. אונדזער ציל איז צו טייַנען סיסטעם פאַנגקשאַנאַליטי אין די געשעעניש פון אַ דאַטן צענטער דורכפאַל. לאָמיר באַשליסן אַז דער ערשטער רעזערוו וועט זיין אַ נאָדע פון ​​אן אנדער דאַטן צענטער, און די רגע רעזערוו וועט זיין אַ נאָדע פון ​​אַ דריט. דער סכעמע איז אויסגעקליבן אַמאָל און טוט נישט טוישן ביז די טאָפּאָלאָגי פון די קנויל ענדערונגען, דאָס איז ביז נייַ נאָודז אַרייַן עס (וואָס כאַפּאַנז זייער ראַרעלי). דער פּראָצעדור פֿאַר סאַלעקטינג אַ נייַ אַקטיוו בעל אויב דער אַלט איינער פיילז וועט שטענדיק זיין ווי גייט: דער ערשטער רעזערוו וועט ווערן דער אַקטיוו בעל, און אויב עס האט אויפגעהערט פאַנגקשאַנינג, די רגע רעזערוו וועט ווערן דער אַקטיוו בעל.

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

אָבער ווי וועט קלייאַנץ פֿאַרשטיין וואָס בעל איז ארבעטן איצט? עס איז אוממעגלעך צו שיקן אינפֿאָרמאַציע צו טויזנטער פון קלייאַנץ אין 50 מיז. א סיטואַציע איז מעגלעך ווען אַ קליענט סענדז אַ בקשה צו עפֿענען אַ טראַנסאַקטיאָן, ניט נאָך געוואוסט אַז דער בעל איז ניט מער פאַנגקשאַנינג, און די בקשה וועט צייט אויס. צו פאַרמייַדן דעם פון געשעעניש, קלייאַנץ ספּעקולאַטיוועלי שיקן אַ בקשה צו עפענען אַ טראַנסאַקטיאָן צו די גרופּע בעל און ביידע פון ​​​​זייַן ריזערווז אין אַמאָל, אָבער בלויז דער איינער וואָס איז דער אַקטיוו בעל אין דעם מאָמענט וועט ריספּאַנד צו דעם בקשה. דער קליענט וועט מאַכן אַלע סאַבסאַקוואַנט קאָמוניקאַציע אין די טראַנסאַקטיאָן בלויז מיט די אַקטיוו בעל.

באַקקופּ הארן שטעלן באקומען ריקוועס פֿאַר טראַנזאַקשאַנז וואָס זענען נישט זייערער אין די ריי פון אַנבאָרן טראַנזאַקשאַנז, ווו זיי זענען סטאָרד פֿאַר עטלעכע מאָל. אויב דער אַקטיוו בעל דיעס, דער נייַ בעל פּראַסעסאַז ריקוועס צו עפענען טראַנזאַקשאַנז פון זיין ריי און ריספּאַנדז צו דעם קליענט. אויב דער קליענט האט שוין געעפנט אַ טראַנסאַקטיאָן מיט די אַלט בעל, די רגע ענטפער איז איגנאָרירט (און, דאָך, אַזאַ אַ טראַנסאַקטיאָן וועט נישט פאַרענדיקן און וועט זיין ריפּיטיד דורך דער קליענט).

ווי די טראַנסאַקטיאָן אַרבעט

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

ווען אַ קליענט וויל צו טוישן דאַטן אין אַ טראַנסאַקטיאָן, עס סענדז אַ בקשה צו די קאָאָרדינאַטאָר צו מאָדיפיצירן די ענטיטי, און דער קאָאָרדינאַטאָר שטעלן די נייַע דאַטן אין די טראַנסאַקטיאָן סטאַטוס טיש אין זכּרון. דאָס קאַמפּליץ די רעקאָרדינג - קיין רעקאָרדינג איז געמאכט צו די סטאָרידזש.

ווען אַ קליענט ריקוועס זיין אייגענע געביטן דאַטן ווי אַ טייל פון אַן אַקטיוו טראַנסאַקטיאָן, דער קאָאָרדינאַטאָר אַקערז ווי גייט:

• אויב די שייַן איז שוין אין די טראַנסאַקטיאָן, די דאַטן זענען גענומען פון זכּרון;
• אויב עס איז קיין שייַן אין זכּרון, די פעלנדיק דאַטן זענען לייענען פֿון די סטאָרידזש נאָודז, קאַמביינד מיט די שוין אין זכּרון, און דער רעזולטאַט איז געגעבן צו דער קליענט.

אזוי, דער קליענט קענען לייענען זיין אייגענע ענדערונגען, אָבער אנדערע קלייאַנץ טאָן ניט זען די ענדערונגען, ווייַל זיי זענען סטאָרד בלויז אין דער זכּרון פון די קאָאָרדינאַטאָר, זיי זענען נישט נאָך אין די קאַססאַנדראַ נאָודז.

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

און צו צוריקקריגן, דער קאָאָרדינאַטאָר נאָר דאַרף צו באַפרייַען די זיקאָרן פאַרנומען דורך די טראַנסאַקטיאָן שטאַט.

ווי אַ רעזולטאַט פון די ימפּרווומאַנץ אויבן, מיר ימפּלאַמענאַד די אַסיד פּרינסאַפּאַלז:

• אַטאָמיסיטי. דאָס איז אַ גאַראַנטירן אַז קיין טראַנסאַקטיאָן וועט זיין טייל רעקאָרדעד אין די סיסטעם אָדער אַלע פון ​​זייַן סאַב-אָפּעראַטיאָנס וועט זיין געענדיקט, אָדער גאָרניט וועט זיין געענדיקט. מיר אַדכיר צו דעם פּרינציפּ דורך לאָגד פּעקל אין Cassandra.
• קאָנסיסטענסי. יעדער געראָטן טראַנסאַקטיאָן, דורך דעפֿיניציע, רעקאָרדירט ​​בלויז גילטיק רעזולטאַטן. אויב, נאָך עפן אַ טראַנסאַקטיאָן און דורכפירן טייל פון די אַפּעריישאַנז, עס איז דיסקאַווערד אַז דער רעזולטאַט איז פאַרקריפּלט, אַ ראָולבאַק איז דורכגעקאָכט.
• איזאלאציע. ווען אַ טראַנסאַקטיאָן איז עקסאַקיוטאַד, קאַנקעראַנט טראַנזאַקשאַנז זאָל נישט ווירקן זייַן אַוטקאַם. קאַמפּיטינג טראַנזאַקשאַנז זענען אפגעזונדערט מיט פּעסימיסטיש לאַקס אויף די קאָאָרדינאַטאָר. פֿאַר לייענען אַרויס אַ טראַנסאַקטיאָן, די אפגעזונדערטקייט פּרינציפּ איז באמערקט אויף די לייענען קאַמיטאַד מדרגה.
• פעסטקייַט. רעגאַרדלעסס פון פּראָבלעמס אין נידעריקער לעוועלס - סיסטעם בלאַקאַוט, ייַזנוואַרג דורכפאַל - ענדערונגען געמאכט דורך אַ הצלחה געענדיקט טראַנסאַקטיאָן זאָל בלייַבן אפגעהיט ווען אַפּעריישאַנז נעמענ זיכ ווידער.

לייענען דורך ינדעקסיז

לאָמיר נעמען אַ פּשוטן טיש:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

עס האט אַ שייַן (ערשטיק שליסל), באַזיצער און מאָדיפיקאַטיאָן דאַטע. איר דאַרפֿן צו מאַכן אַ זייער פּשוט בקשה - סעלעקטירן דאַטן אויף די באַזיצער מיט די ענדערונג טאָג "פֿאַר די לעצטע טאָג".

SELECT *
WHERE owner=?
AND modified>?

אין סדר אַז אַזאַ אַ אָנפֿרעג צו זיין פּראַסעסט געשווינד, אין אַ קלאַסיש SQL DBMS איר דאַרפֿן צו בויען אַן אינדעקס דורך שפאלטן (באַזיצער, מאַדאַפייד). מיר קענען טאָן דאָס גאַנץ לייכט, ווייַל מיר איצט האָבן זויער געראַנטיז!

ינדעקסיז אין C * איין

עס איז אַ מקור טיש מיט פאָוטאַגראַפס אין וואָס די רעקאָרד שייַן איז די ערשטיק שליסל.

פֿאַר אַן אינדעקס, C * One קריייץ אַ נייַע טיש וואָס איז אַ קאָפּיע פון ​​​​דער אָריגינעל. דער שליסל איז די זעלבע ווי דער אינדעקס אויסדרוק, און עס אויך כולל די ערשטיק שליסל פון די רעקאָרד פון די מקור טיש:

איצט די אָנפֿרעג פֿאַר "באַזיצער פֿאַר די לעצטע טאָג" קענען זיין רירייט ווי אַ אויסקלייַבן פון אן אנדער טיש:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

די קאָנסיסטענסי פון די דאַטן אין די מקור טיש פאָטאָס און די אינדעקס טיש i1 איז אויטאָמאַטיש מיינטיינד דורך די קאָאָרדינאַטאָר. באַזירט אויף די דאַטן סטשעמאַ אַליין, ווען אַ ענדערונג איז באקומען, דער קאָאָרדינאַטאָר דזשענערייץ און סטאָרז אַ ענדערונג ניט בלויז אין די הויפּט טיש, אָבער אויך אין קאפיעס. קיין נאָך אַקשאַנז זענען דורכגעקאָכט אויף די אינדעקס טיש, לאָגס זענען נישט לייענען און קיין לאַקס זענען געניצט. אַז איז, אַדינג ינדעקסיז קאַנסומז כּמעט קיין רעסורסן און האט כמעט קיין ווירקונג אויף די גיכקייַט פון אַפּלייינג מאָדיפיקאַטיאָנס.

מיט ACID, מיר זענען ביכולת צו ינסטרומענט סקל-ווי ינדעקסיז. זיי זענען קאָנסיסטענט, סקאַלאַבלע, שנעל, קאַמפּאָוזאַבאַל און געבויט אין די CQL אָנפֿרעג שפּראַך. קיין ענדערונגען צו די אַפּלאַקיישאַן קאָד זענען פארלאנגט צו שטיצן ינדעקסיז. אַלץ איז ווי פּשוט ווי אין SQL. און רובֿ ימפּאָרטאַנטלי, ינדעקסיז טאָן ניט ווירקן די דורכפירונג גיכקייַט פון מאָדיפיקאַטיאָנס צו דער אָריגינעל טראַנסאַקטיאָן טיש.

וואס איז געשען

מיר דעוועלאָפּעד C * One מיט דריי יאָר צוריק און לאָנטשט עס אין געשעפט אָפּעראַציע.

וואָס האָבן מיר באַקומען אין די סוף? לאָמיר אָפּשאַצן דעם מיט דעם ביישפּיל פון די פאָטאָ פּראַסעסינג און סטאָרידזש סאַבסיסטאַם, איינער פון די מערסט וויכטיק טייפּס פון דאַטן אין אַ געזעלשאַפטלעך נעץ. מיר רעדן נישט וועגן די קערפּער פון די פאָטאָגראַפיע אַליין, נאָר וועגן אַלע מינים פון מעטאַ אינפֿאָרמאַציע. איצט Odnoklassniki האט וועגן 20 ביליאָן אַזאַ רעקאָרדס, די סיסטעם פּראַסעסאַז 80 טויזנט לייענען ריקוועס פּער סעקונדע, אַרויף צו 8 טויזנט אַסיד טראַנזאַקשאַנז פּער סעקונדע פֿאַרבונדן מיט דאַטן מאָדיפיקאַטיאָן.

ווען מיר געוויינט SQL מיט רעפּלאַקיישאַן פאַקטאָר = 1 (אָבער אין RAID 10), די פאָטאָ מעטאַ-אינפֿאָרמאַציע איז געווען סטאָרד אויף אַ העכסט בנימצא קנויל פון 32 מאשינען מיט Microsoft SQL Server (פּלוס 11 באַקאַפּס). 10 סערווערס זענען אויך אַלאַקייטיד פֿאַר סטאָרינג באַקאַפּס. א גאַנץ פון 50 טייַער קאַרס. אין דער זעלביקער צייט, די סיסטעם אַפּערייטאַד מיט רייטאַד מאַסע, אָן רעזערוו.

נאָך מיגרייטינג צו די נייַע סיסטעם, מיר באקומען רעפּלאַקיישאַן פאַקטאָר = 3 - אַ קאָפּיע אין יעדער דאַטן צענטער. די סיסטעם באשטייט פון 63 קאַססאַנדראַ סטאָרידזש נאָודז און 6 קאָאָרדינאַטאָר מאשינען, פֿאַר אַ גאַנץ פון 69 סערווערס. אבער די מאשינען זענען פיל טשיפּער, זייער גאַנץ פּרייַז איז וועגן 30% פון די קאָס פון אַ סקל סיסטעם. אין דער זעלביקער צייַט, די מאַסע איז געהאלטן בייַ 30%.

מיט די הקדמה פון C * One, לייטאַנסי אויך דיקריסט: אין SQL, אַ שרייַבן אָפּעראַציע גענומען וועגן 4,5 מיז. אין C * One - וועגן 1,6 מיז. די טראַנסאַקטיאָן געדויער איז אין דורכשניטלעך ווייניקער ווי 40 מיז, די יבערגעבן איז געענדיקט אין 2 מיז, די לייענען און שרייַבן געדויער איז אין דורכשניטלעך 2 מיז. 99 פּראָצענטיל - בלויז 3-3,1 מיז, די נומער פון טיימאַוץ איז דיקריסט מיט 100 מאל - אַלע רעכט צו דער וויידספּרעד נוצן פון ספּעקולאַציע.

איצט, רובֿ פון די SQL סערווירער נאָודז האָבן שוין דיקאַמישאַנד נייַע פּראָדוקטן זענען דעוועלאָפּעד בלויז מיט C * One. מיר צוגעפאסט C * One צו אַרבעטן אין אונדזער וואָלקן איין-וואָלקן, וואָס געמאכט עס מעגלעך צו פאַרגיכערן די דיפּלוימאַנט פון נייַ קלאַסטערז, פאַרפּאָשעטערן קאַנפיגיעריישאַן און אָטאַמייט אָפּעראַציע. אָן די מקור קאָד, דאָס וואָלט זיין פיל מער שווער און קאַמבערסאַם.

איצט מיר אַרבעטן אויף טראַנספערינג אונדזער אנדערע סטאָרידזש פאַסילאַטיז צו די וואָלקן - אָבער דאָס איז אַ גאָר אַנדערש געשיכטע.

מקור: www.habr.com