PostgreSQL ရှိ ကြီးမားသော အတွဲများပေါ်တွင် တစ်ပြားတစ်ချပ် သိမ်းဆည်းပါ။

ကြီးကြီးမားမား ဒေတာစီးကြောင်းများကို မှတ်တမ်းတင်ခြင်းဆိုင်ရာ ခေါင်းစဉ်ဖြင့် ဆက်လက်ဖော်ပြသည်။ Partitioning အကြောင်း ယခင်ဆောင်းပါးဤတွင်သင်လုပ်နိုင်သောနည်းလမ်းများကိုကြည့်ရှုပါမည်။ သိမ်းဆည်းထားသည့် "ရုပ်ပိုင်းဆိုင်ရာ" အရွယ်အစားကို လျှော့ချပါ။ PostgreSQL တွင်၎င်းတို့၏ဆာဗာစွမ်းဆောင်ရည်အပေါ်သက်ရောက်မှု။

အကြောင်းပြောပါမယ်။ TOAST ဆက်တင်များနှင့် ဒေတာ ချိန်ညှိမှု. “ပျမ်းမျှအားဖြင့်၊” ဤနည်းလမ်းများသည် အရင်းအမြစ်များစွာကို သိမ်းဆည်းမည်မဟုတ်သော်လည်း အက်ပ်ကုဒ်ကို လုံးဝမပြုပြင်ဘဲနေပါ။

မည်သို့ပင်ဆိုစေကာမူ ၎င်း၏သဘောသဘာဝအရ စောင့်ကြည့်မှုတိုင်းနီးပါးကို သိမ်းဆည်းထားသောကြောင့် ယင်းနှင့်ပတ်သက်၍ ကျွန်ုပ်တို့၏အတွေ့အကြုံသည် အလွန်အကျိုးဖြစ်ထွန်းပါသည်။ အများအားဖြင့် append-only မှတ်တမ်းတင်ထားသောဒေတာ၏စည်းကမ်းချက်များ၌။ အကယ်၍ သင်သည် ဒေတာဘေ့စ်ကို အစား disk သို့ စာရေးနည်းကို သင်မည်ကဲ့သို့ သင်ပေးနိုင်သည်ကို အံ့သြနေပါက၊ 200MB / s နဲ့ ထက်ဝက် - ကျေးဇူးပြု၍ ကြောင်အောက်မှာ။

အချက်အလက်ကြီးတွေရဲ့ လျှို့ဝှက်ချက်လေးတွေ

အလုပ်ကိုယ်ရေးအကျဉ်းအားဖြင့် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသူတို့သည် လှေခါးမှ သူ့ထံ မှန်မှန် ပျံသန်းသွားကြသည်။ စာသားအထုပ်များ.

ထိုကတည်းက VLSI ရှုပ်ထွေးသည်။ကျွန်ုပ်တို့ စောင့်ကြည့်နေသည့် ဒေတာဘေ့စ်သည် ရှုပ်ထွေးသော ဒေတာဖွဲ့စည်းပုံများပါရှိသော အစိတ်အပိုင်းပေါင်းစုံ ထုတ်ကုန်တစ်ခုဖြစ်ပြီး၊ ထို့နောက် မေးမြန်းမှုများ အမြင့်ဆုံးစွမ်းဆောင်ရည်အတွက် ဤကဲ့သို့အတော်လေးထွက် ရှုပ်ထွေးသော အယ်လ်ဂိုရီသမ် ယုတ္တိဗေဒဖြင့် “အများအပြား အတွဲ”. ထို့ကြောင့် တောင်းဆိုချက်တစ်ခုစီ၏ စံနမူနာတစ်ခုစီ၏ ပမာဏ သို့မဟုတ် ကျွန်ုပ်တို့ထံ ရောက်ရှိလာသော မှတ်တမ်းရှိ ရလဒ်ဆိုင်ရာ အကောင်အထည်ဖော်မှု အစီအစဉ်သည် "ပျမ်းမျှအားဖြင့်" ပမာဏမှာ အလွန်ကြီးမားပါသည်။

ကျွန်ုပ်တို့ "ကြမ်း" ဒေတာကို ရေးသားသည့် ဇယားတစ်ခု၏ ဖွဲ့စည်းပုံကို ကြည့်ကြပါစို့ - ဆိုလိုသည်မှာ ဤနေရာတွင် မှတ်တမ်းထည့်သွင်းမှုမှ မူရင်းစာသားဖြစ်ပါသည်။

CREATE TABLE rawdata_orig(
  pack -- PK
    uuid NOT NULL
, recno -- PK
    smallint NOT NULL
, dt -- ключ секции
    date
, data -- самое главное
    text
, PRIMARY KEY(pack, recno)
);

ပုံမှန်လက္ခဏာတစ်ခု (အပိုင်းခွဲပြီးပြီ၊ ဒါကြောင့် ဒါက အပိုင်းပုံစံပုံစံတစ်ခုပါ)၊ အရေးကြီးဆုံးအရာက စာသားပါ။ တခါတရံ တော်တော် တောက်ပြောင်တယ်။

PG တစ်ခုရှိ မှတ်တမ်းတစ်ခု၏ "ရုပ်ပိုင်းဆိုင်ရာ" အရွယ်အစားသည် ဒေတာစာမျက်နှာတစ်ခုထက်ပို၍ မသိမ်းပိုက်နိုင်သော်လည်း "ယုတ္တိဗေဒ" အရွယ်အစားသည် လုံးဝကွဲပြားသည့်ကိစ္စဖြစ်ကြောင်း သတိရပါ။ အကွက်တစ်ခုသို့ ထုထည်တန်ဖိုး (varchar/text/bytea) ကိုရေးရန်၊ အသုံးပြုပါ။ TOAST နည်းပညာ:

PostgreSQL သည် ပုံသေစာမျက်နှာအရွယ်အစား (ပုံမှန်အားဖြင့် 8 KB) ကိုအသုံးပြုပြီး tuple များကို စာမျက်နှာများစွာကို ချဲ့ထွင်ရန် ခွင့်မပြုပါ။ ထို့ကြောင့်၊ အလွန်ကြီးမားသော အကွက်တန်ဖိုးများကို တိုက်ရိုက်သိမ်းဆည်းရန် မဖြစ်နိုင်ပါ။ ဤကန့်သတ်ချက်ကို ကျော်လွှားရန်အတွက် ကြီးမားသောအကွက်တန်ဖိုးများကို ဖိသိပ်ထားပြီး/သို့မဟုတ် ရုပ်ပိုင်းဆိုင်ရာလိုင်းများစွာကို ပိုင်းခြားထားသည်။ ၎င်းသည် အသုံးပြုသူမှ သတိမပြုမိဘဲ ဆာဗာကုဒ်အများစုအပေါ် သက်ရောက်မှုအနည်းငယ်သာရှိသည်။ ဒီနည်းကို TOAST လို့ ခေါ်တယ်...

တကယ်တော့၊ "ဖြစ်နိုင်ချေကြီးမားသော" အကွက်များပါသောဇယားတိုင်းအတွက်အလိုအလျောက် "slicing" ဖြင့်တွဲထားသောဇယားကိုဖန်တီးထားသည်။ 2KB အပိုင်းများတွင် "ကြီးမားသော" မှတ်တမ်းတစ်ခုစီ၊

TOAST(
  chunk_id
    integer
, chunk_seq
    integer
, chunk_data
    bytea
, PRIMARY KEY(chunk_id, chunk_seq)
);

ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် “ကြီးမားသော” တန်ဖိုးဖြင့် စာကြောင်းတစ်ခုကို ရေးရပါက၊ dataဒါမှ အစစ်အမှန် မှတ်တမ်းတင်မှု ဖြစ်ပေါ်လာမှာပါ။ ပင်မစားပွဲနှင့် ၎င်း၏ PK အတွက်သာမက TOAST နှင့် ၎င်း၏ PK တို့လည်းဖြစ်သည်။.

TOAST သြဇာကို လျှော့ချခြင်း။

ဒါပေမယ့် ကျွန်တော်တို့ရဲ့ မှတ်တမ်း အများစုဟာ ကြီးကြီးမားမားတော့ မဟုတ်သေးပါဘူး။ 8KB နှင့် ကိုက်ညီရမည်။ - ဒီအတွက် ပိုက်ဆံဘယ်လိုစုရမလဲ..

ဤနေရာတွင် အရည်အချင်းသည် ကျွန်ုပ်တို့၏အကူအညီသို့ ရောက်ရှိလာပါသည်။ STORAGE ဇယားကော်လံမှာ

• တိုးချဲ့ compression နှင့် သီးခြား storage နှစ်မျိုးလုံးကို ခွင့်ပြုသည်။ ဒီ စံရွေးချယ်မှု TOAST အများစုနှင့် ကိုက်ညီသော ဒေတာအမျိုးအစားများအတွက်။ အတန်းက အရမ်းကြီးနေသေးရင် စားပွဲအပြင်ဘက်မှာ ချုံ့ဖို့ အရင်ကြိုးစားတယ်။
• လကျ ဖိသိပ်မှုကို ခွင့်ပြုသော်လည်း သီးခြားသိုလှောင်မှု မပြုပါ။ (တကယ်တော့၊ သီးခြားသိုလှောင်မှုကို ထိုကော်လံများအတွက် ဆက်လက်လုပ်ဆောင်နေမည်ဖြစ်သော်လည်း၊ နောက်ဆုံးအားကိုးရာအဖြစ်စာမျက်နှာပေါ်တွင် အံဝင်ခွင်ကျဖြစ်အောင် ကြိုးကိုကျုံ့ရန် အခြားနည်းလမ်းမရှိသောအခါ၊

တကယ်တော့ ဒါက စာသားအတွက် လိုအပ်တာ အတိအကျပါပဲ၊ တတ်နိုင်သမျှဖိပြီး လုံးဝမကိုက်ညီပါက TOAST တွင်ထည့်ပါ။. ၎င်းကို command တစ်ခုတည်းဖြင့် တိုက်ရိုက်လုပ်ဆောင်နိုင်သည်-

ALTER TABLE rawdata_orig ALTER COLUMN data SET STORAGE MAIN;

အကျိုးသက်ရောက်မှုကို ဘယ်လိုသုံးသပ်မလဲ။

ဒေတာစီးဆင်းမှုသည် နေ့တိုင်းပြောင်းလဲနေသောကြောင့် ကျွန်ုပ်တို့သည် ပကတိနံပါတ်များကို နှိုင်းယှဉ်၍မရသော်လည်း နှိုင်းယှဥ်သဘောတူပါသည်။ သေးငယ်သောမျှဝေမှု ငါတို့ အဲဒါကို TOAST မှာ ရေးခဲ့တယ် - အများကြီး ပိုကောင်းတယ်။ သို့သော် ဤနေရာတွင် အန္တရာယ်တစ်ခု ရှိသည် - တစ်ခုချင်းစီ၏ မှတ်တမ်းတစ်ခုစီ၏ "ရုပ်ပိုင်းဆိုင်ရာ" ပမာဏ ကြီးမားလေ၊ ကျွန်ုပ်တို့သည် ဒေတာစာမျက်နှာများကို ပိုမိုဖုံးအုပ်ထားရသောကြောင့် အညွှန်းကိန်း "ပိုကျယ်လေ" ဖြစ်လာသည်။

အပိုင်း မပြောင်းလဲမီ:

heap  = 37GB (39%)
TOAST = 54GB (57%)
PK    =  4GB ( 4%)

အပိုင်း အပြောင်းအလဲများပြီးနောက်:

heap  = 37GB (67%)
TOAST = 16GB (29%)
PK    =  2GB ( 4%)

တကယ်တော့ ကျွန်တော်တို TOAST ကို မကြာခဏ 2 ကြိမ်လျှော့စပြီးရေးတယ်။ဒစ်ကိုသာမက CPU ကိုပါ ပြန်ဖွင့်ပေးသော၊

ကျွန်ုပ်တို့သည် “စာဖတ်ခြင်း” ဒစ်ကို “စာရေးခြင်း” သာမဟုတ်ဘဲ သေးငယ်လာကြောင်း မှတ်သားထားရမည်ဖြစ်ပြီး၊ ဇယားတစ်ခုထဲသို့ မှတ်တမ်းတစ်ခုထည့်သွင်းသည့်အခါ၊ ၎င်း၏အညွှန်းတစ်ခုစီ၏သစ်ပင်၏တစ်စိတ်တစ်ပိုင်းကိုလည်း “ဖတ်ရှု” ရန် လိုအပ်သည်။ သူတို့အတွက် အနာဂတ် အနေအထား။

PostgreSQL 11 တွင် ကောင်းမွန်စွာနေထိုင်နိုင်သူ

PG11 သို့ အပ်ဒိတ်လုပ်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် "ချိန်ညှိခြင်း" TOAST ကို ဆက်လက်လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့ပြီး ဤဗားရှင်းမှ ကန့်သတ်ချက်များ စတင်သည်ကို သတိပြုမိပါသည်။ toast_tuple_target:

TOAST_TUPLE_THRESHOLD bytes (များသောအားဖြင့် 2 KB) ထက်ကြီးသော အတန်းတန်ဖိုးသည် TOAST_TUPLE_THRESHOLD bytes ထက်ကြီးသောအခါမှသာ TOAST လုပ်ဆောင်ခြင်းကုဒ်သည် မီးလောင်ပါသည်။ TOAST ကုဒ်သည် အတန်းတန်ဖိုး TOAST_TUPLE_TARGET bytes ထက် နည်းသွားသည်အထိ ဇယားကွက်မှ အကွက်တန်ဖိုးများကို ချုံ့ပြီး/သို့မဟုတ် ရွှေ့ပေးမည် (သို့) အရွယ်အစားကို လျှော့၍မရပါ။

ကျွန်ုပ်တို့ရှိလေ့ရှိသောဒေတာသည် "အလွန်တိုသည်" သို့မဟုတ် "အလွန်ရှည်သည်" ဟုဆုံးဖြတ်ခဲ့သည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ဖြစ်နိုင်ခြေအနည်းဆုံးတန်ဖိုးတွင် မိမိကိုယ်ကိုကန့်သတ်ရန် ဆုံးဖြတ်ခဲ့သည်-

ALTER TABLE rawplan_orig SET (toast_tuple_target = 128);

ပြင်ဆင်သတ်မှတ်ပြီးနောက် ဆက်တင်အသစ်များသည် disk loading ကို မည်သို့အကျိုးသက်ရောက်သည်ကို ကြည့်ကြပါစို့။

မဆိုးပါဘူး! ပျမ်းမျှ disk သို့ တန်းစီခြင်း လျော့နည်းသွားသည်။ ခန့်မှန်းခြေအားဖြင့် 1.5 ကြိမ်ဖြစ်ပြီး disk "အလုပ်များ" သည် 20 ရာခိုင်နှုန်းဖြစ်သည်။ ဒါပေမယ့် ဒါက CPU ကို တစ်နည်းနည်းနဲ့ သက်ရောက်မှုရှိနိုင်လား။

အနည်းဆုံးတော့ ပိုဆိုးမလာဘူး။ သို့ပေမယ့်၊ ထိုကဲ့သို့သော volumes များပင်လျှင် ပျမ်းမျှ CPU load ကို ပိုမြင့်အောင် မမြှင့်တင်နိုင်ပါက ဆုံးဖြတ်ရန် ခက်ခဲပါသည်။ 5%.

ဝေါဟာရများ၏ နေရာများကို ပြောင်းလဲခြင်းဖြင့် ပေါင်းလဒ်... ပြောင်းလဲပါသည်။

သင်သိသည့်အတိုင်း တစ်ပြားတစ်ချပ်သည် ရူဘယ်တစ်ပြားကို သက်သာစေပြီး ကျွန်ုပ်တို့၏ သိုလှောင်မှုပမာဏနှင့် ပတ်သက်ပါသည်။ 10TB/လ အနည်းငယ် optimization သည်ပင် ကောင်းသောအမြတ်အစွန်းကို ပေးနိုင်သည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဒေတာ၏ ရုပ်ပိုင်းဆိုင်ရာဖွဲ့စည်းပုံအား အာရုံစိုက်ခဲ့သည် - မည်မျှတိကျသည်။ မှတ်တမ်းအတွင်း၌ "တန်းစီထားသော" အကွက်များ ဇယားတစ်ခုစီ။

အကြောင်းကတော့ ဒေတာ ချိန်ညှိမှု ဒါက ရှေ့တည့်တည့်ပဲ။ ရလဒ်အသံအတိုးအကျယ်ကိုအကျိုးသက်ရောက်သည်။:

ဗိသုကာများစွာသည် စက်စကားလုံးနယ်နိမိတ်များပေါ်တွင် ဒေတာချိန်ညှိမှုကို ပေးသည်။ ဥပမာအားဖြင့်၊ 32-bit x86 စနစ်တွင်၊ ကိန်းပြည့်များ (ကိန်းပြည့်အမျိုးအစား၊ 4 bytes) သည် 4-byte စာလုံးဘောင်ပေါ်တွင် ချိန်ညှိမည်ဖြစ်ပြီး၊ တိကျသော floating point နံပါတ်များ (double precision floating point, 8 bytes) ကို နှစ်ဆတိုးပေးမည်ဖြစ်သည်။ 64-bit စနစ်တွင်၊ နှစ်ဆတန်ဖိုးများကို 8-byte စကားလုံးနယ်နိမိတ်များနှင့် ချိန်ညှိမည်ဖြစ်သည်။ ဒါက လိုက်ဖက်မှုမရှိတဲ့ အကြောင်းရင်းတစ်ခုပါပဲ။

ချိန်ညှိမှုကြောင့်၊ ဇယားအတန်း၏အရွယ်အစားသည် အကွက်များ၏ အစီအစဥ်ပေါ်တွင် မူတည်သည်။ အများအားဖြင့် ဤအကျိုးသက်ရောက်မှုသည် သိသာထင်ရှားခြင်းမရှိသော်လည်း အချို့ကိစ္စများတွင် ၎င်းသည် အရွယ်အစားသိသိသာသာတိုးလာနိုင်သည်။ ဥပမာအားဖြင့်၊ သင်သည် char(1) နှင့် ကိန်းပြည့်အကွက်များကို ရောနှောပါက၊ ပုံမှန်အားဖြင့် ၎င်းတို့ကြားတွင် 3 bytes ဆုံးရှုံးသွားမည်ဖြစ်သည်။

Synthetic မော်ဒယ်များဖြင့် စကြပါစို့။

SELECT pg_column_size(ROW(
  '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
, '2019-01-01'::date
));
-- 48 байт

SELECT pg_column_size(ROW(
  '2019-01-01'::date
, '0000-0000-0000-0000-0000-0000-0000-0000'::uuid
, 0::smallint
));
-- 46 байт

ပထမကိစ္စတွင် အပိုဘိုက်နှစ်စုံဘယ်ကလာသနည်း။ ရိုးရှင်းပါတယ်- 2-byte နယ်နိမိတ်တွင် 4-byte သေးငယ်သောint ကို ချိန်ညှိထားသည်။ နောက်အကွက်ရှေ့မှာ၊ နောက်ဆုံးတစ်ခုဖြစ်တဲ့အခါ၊ ဘယ်အရာမှ ညှိစရာမလိုပါဘူး။

သီအိုရီအရ၊ အားလုံးအဆင်ပြေပြီး နယ်ပယ်များကို သင်နှစ်သက်သလို ပြန်စီနိုင်ပါသည်။ 10-15GB ရှိသောနေ့စဥ်အပိုင်းဖြစ်သော ဇယားတစ်ခု၏ ဥပမာကို အသုံးပြု၍ တကယ့်ဒေတာပေါ်တွင် စစ်ဆေးကြည့်ကြပါစို့။

ကနဦးဖွဲ့စည်းပုံ-

CREATE TABLE public.plan_20190220
(
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  dt date,
  CONSTRAINT plan_20190220_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190220_dt_check CHECK (dt = '2019-02-20'::date)
)
INHERITS (public.plan)

ကော်လံအမှာစာပြောင်းပြီးနောက် အပိုင်း - အတိအကျ တူညီသောနယ်ပယ်၊ အစီအစဥ်မတူပါ။:

CREATE TABLE public.plan_20190221
(
-- Унаследована from table plan:  dt date NOT NULL,
-- Унаследована from table plan:  ts timestamp with time zone,
-- Унаследована from table plan:  pack uuid NOT NULL,
-- Унаследована from table plan:  recno smallint NOT NULL,
-- Унаследована from table plan:  host uuid,
-- Унаследована from table plan:  apn uuid,
-- Унаследована from table plan:  ptr uuid,
-- Унаследована from table plan:  bufint bigint,
-- Унаследована from table plan:  bufmem bigint,
-- Унаследована from table plan:  bufdsk bigint,
-- Унаследована from table plan:  exectime numeric(32,3),
-- Унаследована from table plan:  duration numeric(32,3),
  CONSTRAINT plan_20190221_pkey PRIMARY KEY (pack, recno),
  CONSTRAINT chck_ptr CHECK (ptr IS NOT NULL),
  CONSTRAINT plan_20190221_dt_check CHECK (dt = '2019-02-21'::date)
)
INHERITS (public.plan)

အပိုင်း၏ စုစုပေါင်းထုထည်ကို "အချက်အလက်" အရေအတွက်ဖြင့် ဆုံးဖြတ်ပြီး ပြင်ပလုပ်ငန်းစဉ်များပေါ်တွင်သာ မူတည်ပါသည်၊ ထို့ကြောင့် အစု၏အရွယ်အစားကို ခွဲကြည့်ကြပါစို့။pg_relation_size၎င်းတွင်ရှိသော မှတ်တမ်းအရေအတွက်အားဖြင့် ) ဆိုလိုသည်မှာ ကျွန်ုပ်တို့ရရှိသည်။ အမှန်တကယ် သိမ်းဆည်းထားသော မှတ်တမ်း၏ ပျမ်းမျှအရွယ်အစား:

အနှုတ် 6% အသံအတိုးအကျယ်မိုက်တယ်!

ဒါပေမယ့် အရာရာတိုင်းဟာ နှင်းဆီပန်းမလှပါဘူး၊ အညွှန်းများတွင် ကျွန်ုပ်တို့သည် အကွက်များ၏ အစီအစဥ်ကို ပြောင်းလဲ၍မရပါ။ထို့ကြောင့် "ယေဘုယျအားဖြင့်" (pg_total_relation_size) ...

...ဒီမှာလည်း ရှိနေတုန်းပဲ။ 1.5% သက်သာသည်ကုဒ်တစ်ကြောင်းတည်းကို မပြောင်းဘဲ။ ဟုတ်ကဲ့ဟုတ်ကဲ့!

အကွက်များစီစဉ်ခြင်းအတွက် အထက်ဖော်ပြပါရွေးချယ်မှုသည် အသင့်လျော်ဆုံးဖြစ်သည်ဟူသောအချက်မဟုတ်ကြောင်း ကျွန်ုပ်သတိပြုမိပါသည်။ အလှအပဆိုင်ရာ အကြောင်းပြချက်များဖြင့် နယ်ပယ်အချို့ကို “မကိုက်” ချင်သောကြောင့် - ဥပမာ စုံတွဲတစ်တွဲ၊ (pack, recno)ဤဇယားအတွက် PK ဖြစ်သည် ။

ယေဘုယျအားဖြင့်၊ နယ်ပယ်များ၏ "အနည်းဆုံး" အစီအစဉ်ကို ဆုံးဖြတ်ခြင်းသည် မျှမျှတတရိုးရှင်းသော "ရိုင်းစိုင်းသောစွမ်းအား" အလုပ်ဖြစ်သည်။ ထို့ကြောင့်၊ သင်သည် ကျွန်ုပ်တို့၏ဒေတာထက် ပိုကောင်းသောရလဒ်များကို ရနိုင်သည် - စမ်းသုံးကြည့်ပါ။

source: www.habr.com