دا ډیټابیس اور لګیدلی ...

اجازه راکړئ یو تخنیکي کیسه وکړم.

ډیری کلونه دمخه، ما د همکارۍ ځانګړتیاو سره یو غوښتنلیک جوړ کړی و چې په دې کې جوړ شوی و. دا د کاروونکي دوستانه تجربوي سټیک و چې د لومړني عکس العمل او CouchDB بشپړ ظرفیت څخه یې ګټه پورته کړه. دا د JSON له لارې په ریښتیني وخت کې ډاټا همغږي کوي OT. دا په داخلي توګه د شرکت دننه کارول کیده، مګر په نورو برخو کې د هغې پراخ تطبیق او احتمال روښانه و.

پداسې حال کې چې هڅه کوي دا ټیکنالوژي احتمالي پیرودونکو ته وپلوري، موږ د یو غیر متوقع خنډ سره مخ شو. په ډیمو ویډیو کې، زموږ ټیکنالوژي ښه ښکاري او کار کوي، هیڅ ستونزه نشته. ویډیو په سمه توګه وښودله چې دا څنګه کار کوي او د هیڅ شی تقلید نه کوي. موږ د برنامه کارولو لپاره یو ریښتینی سناریو راوړو او کوډ یې کړ.


په حقیقت کې، دا ستونزه شوه. زموږ ډیمو په سمه توګه هغه ډول کار وکړ چې هر چا خپل غوښتنلیکونه سمول کړي. په ځانګړې توګه، معلومات سمدستي له A څخه B ته لیږدول شوي، حتی که دا لوی میډیا فایلونه وي. د ننوتلو وروسته، هر کارونکي نوي ننوتل ولیدل. د اپلیکیشن په کارولو سره ، مختلف کارونکي کولی شي په ورته پروژو کې په واضح ډول سره کار وکړي ، حتی که چیرې د انټرنیټ اتصال په کلي کې کوم ځای کې مداخله شوې وي. دا په واضح ډول د تاثیراتو وروسته د هر محصول ویډیو کټ کې معنی لري.

که څه هم هرڅوک پوهیدل چې د ریفریش تڼۍ د څه لپاره دی، هیڅوک په ریښتیا نه پوهیږي چې هغه ویب غوښتنلیکونه چې دوی یې له موږ څخه د جوړولو غوښتنه کوله معمولا د دوی د خپلو محدودیتونو تابع وو. او دا چې که دوی نور اړتیا نلري، د کاروونکي تجربه به په بشپړه توګه توپیر ولري. دوی ډیری وختونه ولیدل چې دوی کولی شي د هغو خلکو لپاره د نوټونو په پریښودو سره "چیټ" وکړي چې دوی ورسره خبرې کوي، نو دوی حیران شول چې دا څنګه توپیر لري، د بیلګې په توګه، سلیک. افف!

د ورځني ترکیب ډیزاین

که تاسو د سافټویر پراختیا کې تجربه لرئ، دا باید په یاد ولرئ چې ډیری خلک نشي کولی یوازې د انٹرفیس انځور وګوري او پوه شي چې دا به څه وکړي کله چې ورسره اړیکه ونیسي. د دې یادونه نه کول چې پخپله د برنامه دننه څه پیښیږي. په دې پوه شه کولای شي پیښیږي په لویه کچه د دې پوهیدلو پایله ده چې څه نشي پیښ کیدی او څه باید پیښ نشي. دا اړتیا لري ذهني ماډل نه یوازې دا چې سافټویر څه کوي، بلکې دا هم چې څنګه د هغې انفرادي برخې همغږي کیږي او یو له بل سره اړیکه لري.

د دې یو کلاسیک مثال یو کارن دی چې a ته ګوري spinner.gifحیران یم چې کار به کله بشپړ شي. پراختیا کونکي به پوه شوي وي چې پروسه شاید په ټپه ولاړه وي او دا چې gif به هیڅکله له سکرین څخه ورک نشي. دا حرکت د دندې اجرا کول سموي، مګر د دې حالت پورې اړه نلري. په داسې حاالتو کې، ځینې ټیکنالوژي خوښوي چې سترګې پټې کړي، د کاروونکي ګډوډۍ حد ته حیران دي. په هرصورت، په پام کې ونیسئ چې څومره یې د څرخيدونکي ساعت ته اشاره کوي او وايي چې دا واقعیا سټیشن دی؟

دا د ریښتیني وخت ارزښت جوهر دی. پدې ورځو کې ، د ریښتیني وخت ډیټابیسونه لاهم خورا لږ کارول کیږي او ډیری خلک دوی ته د شک سره ګوري. ډیری دا ډیټابیسونه د NoSQL سټایل ته خورا ډیر تکیه کوي ، له همدې امله دوی معمولا د مونګو پراساس حلونه کاروي ، کوم چې غوره هیر شوي. په هرصورت، زما لپاره دا پدې مانا ده چې د CouchDB سره کار کولو کې آرامۍ ترلاسه کول، په بیله بیا د جوړښتونو ډیزاین کولو زده کړه چې یوازې د ځینې بیوروکراټ څخه ډیر کولی شي د معلوماتو سره ډک کړي. زه فکر کوم چې زه خپل وخت ښه کاروم.

مګر د دې پوسټ اصلي موضوع هغه څه دي چې زه یې نن ورځ کاروم. د انتخاب له مخې نه، بلکې د بې پروا او ړوند ډول پلي شوي شرکتونو پالیسیو له امله. نو زه به د ګوګل ریښتیني وخت ډیټابیس محصولاتو دوه نږدې اړونده په بشپړ ډول منصفانه او بې طرفه پرتله چمتو کړم.

دواړه په خپلو نومونو کې د اور کلمه لري. یوه خبره مې په زړه پورې یادیږي. زما لپاره دوهم شی د اور بل ډول دی. زه په بیړه نه یم چې د دوی نومونه ووایم، ځکه چې یوځل چې زه یې وکړم، موږ به لومړۍ لویې ستونزې ته ورسیږو: نومونه.

لومړی ورته ویل کیږي د Firebase ریښتیني وخت ډیټابیس، او دوهم - د Firebase کلاوډ Firestore. دا دواړه محصولات دي د Firebase سویټ Google. د دوی APIs په ترتیب سره ویل کیږي firebase.database(…) и firebase.firestore(…).

دا ځکه پیښه شوه د ریښتیني وخت ډیټابیس - دا یوازې اصلي دی د اور وژنې په 2014 کې د ګوګل لخوا د پیرودلو دمخه. بیا ګوګل پریکړه وکړه چې د موازي محصول په توګه رامینځته کړي کاپي Firebase د لوی ډیټا شرکت پراساس، او دا د بادل سره Firestore نومیږي. زه هیله لرم چې تاسو لاهم ګډوډ شوي نه یاست. که تاسو لاهم مغشوش یاست ، اندیښنه مه کوئ ، ما پخپله د مقالې دا برخه لس ځله بیا لیکلې.

ځکه چې تاسو باید اشاره وکړئ د اور وژنې د Firebase پوښتنې کې، او د اور پلورنځي د Firebase په اړه په یوه پوښتنه کې، لږترلږه د دې لپاره چې تاسو څو کاله دمخه د Stack Overflow په اړه پوه شئ.

که چیرې د بدترین سافټویر نومولو تجربې لپاره جایزه وي ، نو دا به یقینا یو له کاندیدانو څخه وي. د دې نومونو تر مینځ د هامینګ واټن دومره کوچنی دی چې دا حتی تجربه لرونکي انجینران مغشوش کوي چې ګوتې یې یو نوم ټایپ کوي پداسې حال کې چې سرونه یې د بل په اړه فکر کوي. دا د ښه نیت پلانونه دي چې په بده توګه ناکامیږي. دوی دا وړاندوینه پوره کړه چې ډیټابیس به اور وي. او زه هیڅ ټوکه نه کوم. هغه څوک چې د دې نومولو سکیم سره راغلی د وینې، خولې او اوښکو لامل شوی.

د پیریک بریا

یو به فکر وکړي چې Firestore دی بدلول Firebase، د دې راتلونکی نسل نسل دی، مګر دا به ګمراه کونکی وي. Firestore تضمین نه دی چې د Firebase لپاره مناسب بدیل وي. داسې ښکاري چې یو څوک له دې څخه په زړه پوري هرڅه پرې کړي ، او ډیری نور یې په بیلابیلو لارو مغشوش کړي.

په هرصورت، په دوو محصولاتو کې یو چټک نظر ممکن تاسو ګډوډ کړي: دوی داسې ښکاري چې ورته ورته کار کوي، اساسا د ورته APIs او حتی د ورته ډیټابیس ناستې کې. توپیرونه فرعي دي او یوازې د پراخو اسنادو د محتاط پرتله کولو مطالعې لخوا څرګند شوي. یا کله چې تاسو د پورټ کوډ هڅه کوئ چې په سمه توګه په Firebase کې کار کوي نو دا د Firestore سره کار کوي. حتی بیا تاسو ومومئ چې د ډیټابیس انٹرفیس ژر تر ژره روښانه کیږي کله چې تاسو په ریښتیني وخت کې د موږک سره د ډریګ او غورځولو هڅه وکړئ. زه تکراروم، زه ټوکې نه کوم.

د فایربیس پیرودونکی په دې معنی دی چې دا بدلونونه بفر کوي او په اوتومات ډول تازه معلومات بیا هڅه کوي چې وروستي لیکلو عملیاتو ته لومړیتوب ورکوي. په هرصورت، Firestore د هر کارونکي په هر ثانیه کې د 1 لیکلو عملیاتو محدودیت لري، او دا حد د سرور لخوا پلي کیږي. کله چې د دې سره کار کوئ، دا تاسو پورې اړه لري چې د هغې شاوخوا یوه لاره ومومئ او د تازه نرخ محدودیت پلي کړئ، حتی کله چې تاسو یوازې د خپل غوښتنلیک جوړولو هڅه کوئ. دا دی ، فایرسټور د ریښتیني وخت پیرودونکي پرته د ریښتیني وخت ډیټابیس دی ، کوم چې د API په کارولو سره د یو په توګه ماسک کوي.

دلته موږ د Firestore raison d'être لومړنۍ نښې لیدلو پیل کوو. زه ممکن غلط وي، مګر زه شک لرم چې د ګوګل په مدیریت کې لوړ څوک د پیرود وروسته فایربیس ته ګوري او په ساده ډول یې وویل، "نه، اوه زما خدای، نه. دا د منلو وړ نه ده. یوازې زما تر مشرۍ لاندې نه دی."

هغه د خپلې کوټې څخه راڅرګند شو او اعلان یې وکړ:

"یو لوی JSON سند؟ نه. تاسو به ډاټا په جلا جلا سندونو ویشئ، چې هر یو به یې له 1 میګابایټ څخه زیات نه وي.

داسې بریښي چې دا ډول محدودیت به د کوم کافي هڅول شوي کارونکي بیس سره د لومړۍ پیښې څخه ژوندي پاتې نشي. تاسو پوهیږئ چې دا دی. په کار کې، د بیلګې په توګه، موږ له یو نیم زرو څخه ډیر پریزنټشنونه لرو، او دا په بشپړه توګه نورمال دی.

د دې محدودیت سره، تاسو به مجبور شئ چې دا حقیقت ومني چې په ډیټابیس کې یو "سند" به د کوم شی سره ورته نه وي چې یو کارن یې یو سند بولي.

"د صفونو سرې چې کولی شي په تکراري ډول نور عناصر ولري؟ نه. صفونه به یوازې د ثابت اوږدوالی شیان یا شمیرې ولري، لکه څنګه چې خدای اراده کړې ده."

نو که تاسو تمه درلوده چې GeoJSON ستاسو په فایرسټور کې واچوئ ، نو تاسو به ومومئ چې دا امکان نلري. هیڅ یو اړخیزه د منلو وړ نه ده. زه امید لرم چې تاسو د JSON دننه بیس 64 او/یا JSON خوښ کړئ.

"JSON د HTTP، کمانډ لاین وسیلو یا اډمین پینل له لارې وارد او صادر کړئ؟ نه. تاسو به یوازې د دې وړتیا ولرئ چې د ګوګل کلاوډ ذخیره ته ډیټا صادر او وارد کړئ. دا هغه څه دي چې اوس ورته ویل کیږي، زه فکر کوم. او کله چې زه وایم "تاسو"، زه یوازې هغه کسانو ته خطاب کوم چې د پروژې مالکیت اسناد لري. هرڅوک کولی شي لاړ شي او ټکټونه جوړ کړي."

لکه څنګه چې تاسو لیدلی شئ، د FireBase ډیټا ماډل تشریح کول اسانه دي. دا یو لوی JSON سند لري چې د JSON کیلي د URL لارو سره شریکوي. که تاسو سره لیکئ HTTP PUT в / FireBase په لاندې ډول دی:

{
  "hello": "world"
}

د GET /hello بیرته به راشي "world". اساسا دا په سمه توګه کار کوي لکه څنګه چې تاسو تمه لرئ. د FireBase شیانو راټولول /my-collection/:id د JSON لغت سره برابر {"my-collection": {...}} په ريښه کې، هغه مواد چې په کې شتون لري /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

دا ښه کار کوي که چیرې هر داخل کول د ټکر څخه پاک ID ولري ، کوم چې سیسټم د دې لپاره معیاري حل لري.

په بل عبارت، ډیټابیس 100٪ JSON(*) مطابقت لري او د HTTP سره ښه کار کوي، لکه CouchDB. مګر اساسا تاسو دا د ریښتیني وخت API له لارې کاروئ چې د ویب ساکټونو ، واک ورکولو ، او ګډون خلاصوي. اډمین پینل دواړه وړتیاوې لري ، د ریښتیني وخت ترمیم او JSON واردات / صادراتو ته اجازه ورکوي. که تاسو په خپل کوډ کې ورته کار کوئ ، نو تاسو به حیران شئ چې څومره ځانګړي کوډ به ضایع شي کله چې تاسو پوه شئ چې پیچ او توپیر JSON د دوامداره حالت اداره کولو معمول دندې 90٪ حل کوي.

د Firestore ډیټا ماډل JSON ته ورته دی، مګر په ځینو مهمو لارو کې توپیر لري. ما دمخه په صفونو کې د صفونو نشتوالي یادونه کړې. د فرعي راټولولو ماډل د دوی لپاره د لومړي ټولګي مفکورې وي، د JSON سند څخه جلا چې دوی پکې شامل دي. ځکه چې د دې لپاره د بکس څخه بهر سریال کول شتون نلري، د معلوماتو بیرته ترلاسه کولو او لیکلو لپاره یو ځانګړي کوډ لاره ته اړتیا ده. د خپل ځان راټولولو پروسس کولو لپاره، تاسو اړتیا لرئ خپل سکریپټونه او وسایل ولیکئ. اډمین پینل یوازې تاسو ته اجازه درکوي چې په یو وخت کې په یوه ساحه کې کوچني بدلونونه رامینځته کړئ، او د وارداتو / صادراتو وړتیا نلري.

دوی د ریښتیني وخت NoSQL ډیټابیس اخیستی او دا یې د اتوماتیک یوځای کیدو او جلا غیر JSON کالم سره په ورو غیر SQL کې بدل کړی. د GraftQL په څیر یو څه.

ګرم جاوا

که چیرې فایرسټور باید ډیر د باور وړ او د توزیع وړ وي ، نو بیا حیرانتیا دا ده چې اوسط پراختیا کونکی به د بکس څخه بهر د FireBase غوره کولو په پرتله د لږ باوري حل سره پای ته ورسیږي. د سافټویر ډول چې د ګرم ډیټابیس مدیر ته اړتیا لري د هڅې کچې او وړتیا وړتیا ته اړتیا لري چې په ساده ډول د هغه ځای لپاره غیر واقعیت لري چې محصول یې ښه وي. دا ورته دی چې څنګه HTML5 کینوس د فلش لپاره بدیل ندی که چیرې د پراختیا وسیلې او پلیر شتون نلري. سربیره پردې، Firestore د معلوماتو د پاکوالي او باثباته تایید لپاره په لیوالتیا کې ښکیل دی چې په ساده ډول د اوسط سوداګرۍ کارونکي سره سمون نه لري. کار کول خوښوي: د هغه لپاره هر څه اختیاري دي، ځکه چې تر پای پورې هرڅه یوه مسوده ده.

د FireBase اصلي زیان دا دی چې پیرودونکي د خپل وخت څخه څو کاله وړاندې رامینځته شوي، مخکې لدې چې ډیری ویب پراختیا کونکي د بې ثباتۍ په اړه پوهیدل. د دې له امله، FireBase ګومان کوي ​​چې تاسو به ډاټا بدل کړئ او له همدې امله د کاروونکي لخوا چمتو شوي بې ثباتۍ څخه ګټه نه اخلي. سربیره پردې ، دا په سنیپ شاټونو کې ډیټا بیا نه کاروي چې دا کارونکي ته تیریږي ، کوم چې توپیر خورا ډیر ستونزمن کوي. د لویو اسنادو لپاره، د دې بدلون وړ توپیر پر بنسټ د لیږد میکانیزم په ساده ډول ناکافي دی. هلکانو، موږ لا دمخه لرو WeakMap په جاواسکریپټ کې. دا آرام دی.

که تاسو ډیټا ته مطلوب شکل ورکړئ او ونې خورا لوی نه کړئ ، نو دا ستونزه له مینځه وړل کیدی شي. مګر زه لیواله یم که FireBase به ډیر په زړه پوري وي که چیرې پراختیا کونکو واقعیا یو ښه پیرودونکي API خپور کړي چې د ډیټابیس ډیزاین په اړه د ځینې جدي عملي مشورې سره یوځای بې ثباتي کارولې. پرځای یې، دوی داسې بریښي چې هغه څه حل کړي چې مات شوي ندي، او دا یې خراب کړي.

زه د Firestore د جوړولو تر شا ټول منطق نه پوهیږم. د هغه انګیزو په اړه قیاس کول چې د تور بکس دننه رامینځته کیږي هم د ساتیرۍ برخه ده. د دوه خورا ورته خو د نه پرتله کیدونکي ډیټابیسونو دا ترکیب خورا نادر دی. دا لکه یو چا فکر کاوه: "Firebase یوازې یو فعالیت دی چې موږ یې په ګوګل کلاوډ کې تقلید کولی شو"، مګر تراوسه یې د ریښتیني نړۍ اړتیاو پیژندلو یا ګټور حلونو رامینځته کولو مفهوم ندی موندلی چې دا ټولې اړتیاوې پوره کوي. " پریږدئ چې پراختیا کونکي د دې په اړه فکر وکړي. یوازې UI ښکلی کړئ ... ایا تاسو کولی شئ نور اور اضافه کړئ؟"

زه د ډیټا جوړښتونو په اړه یو څو شیان پوهیږم. زه حتما د "په یوه لوی JSON ونې کې هرڅه" مفهوم د ډیټابیس څخه د لوی کچې جوړښت هر ډول احساس خلاصولو لپاره د یوې هڅې په توګه ګورم. د سافټویر تمه کول په ساده ډول د هر ډول مشکوک ډیټا جوړښت فرکټل سره مقابله کول په ساده ډول لیونی دی. زه حتی دا تصور هم نه کوم چې څومره بد شیان کیدی شي، ما د کوډ سختې پلټنې ترسره کړې او ما هغه شیان ولیدل چې تاسو خلکو هیڅکله خوب نه و لیدلی. مګر زه دا هم پوهیږم چې ښه جوړښتونه څنګه ښکاري، څنګه یې وکاروئ и ولې دا باید ترسره شي. زه د داسې نړۍ تصور کولی شم چیرې چې فایرسټور به منطقي ښکاري او هغه خلک چې دا یې رامینځته کړي فکر کوي چې دوی ښه کار کړی. مګر موږ په دې نړۍ کې ژوند نه کوو.

د FireBase د پوښتنې ملاتړ د هر معیار له مخې ضعیف دی او په عملي توګه شتون نلري. دا یقینا پرمختګ یا لږترلږه بیاکتنې ته اړتیا لري. مګر Firestore ډیر ښه ندی ځکه چې دا په ساده SQL کې موندل شوي ورته یو اړخیز شاخصونو پورې محدود دی. که تاسو پوښتنو ته اړتیا لرئ چې خلک په ګډوډ ډیټا کې پرمخ ځي، تاسو د بشپړ متن لټون، څو رینج فلټرونو، او د دودیز کارونکي لخوا ټاکل شوي ترتیب ته اړتیا لرئ. د نږدې تفتیش سره ، د ساده SQL دندې پخپله خورا محدود دي. سربیره پردې، یوازې د SQL پوښتنې چې خلک کولی شي په تولید کې پرمخ بوځي ګړندي پوښتنې دي. تاسو به د فکري ډیټا جوړښتونو سره د دودیز لیست کولو حل ته اړتیا ولرئ. د هر څه لپاره، لږترلږه باید د نقشې زیاتوالی یا ورته ورته وي.

که تاسو د دې په اړه د معلوماتو لپاره د ګوګل ډاکس لټون کوئ، نو تاسو به هیله مند یاست چې د BigTable او BigQuery په څیر د یو څه لوري ته اشاره وکړئ. په هرصورت، دا ټول حلونه د ډیری ډیری کارپوریټ پلور پلور جرګون سره دي چې تاسو به ژر تر ژره بیرته وګرځئ او د بل څه په لټه کې شئ.

وروستی شی چې تاسو یې د ریښتیني وخت ډیټابیس سره غواړئ هغه څه دي چې د مدیریت د معاشونو په کچه د خلکو لخوا رامینځته شوي.

(*) دا یوه ټوکه ده، داسې هیڅ نشته 100٪ JSON مطابقت لري.

د اعلاناتو حقونه

لټون کول لپاره د VDS د ډیبګ کولو پروژو لپاره، د پراختیا او کوربه کولو لپاره سرور؟ تاسو یقینا زموږ پیرودونکی یاست 🙂 د مختلف ترتیبونو سرورونو لپاره ورځني نرخونه ، د DDoS ضد او وینډوز جوازونه دمخه په نرخ کې شامل دي.

سرچینه: www.habr.com