گلوبلز ڈیٹا کو ذخیرہ کرنے کے لیے خزانہ کی تلوار ہیں۔ درخت حصہ 2

شروع کرنا - حصہ 1 دیکھیں۔

3. گلوبلز استعمال کرتے وقت ڈھانچے کی مختلف حالتیں۔

آرڈر شدہ درخت جیسی ساخت میں مختلف خاص معاملات ہوتے ہیں۔ آئیے گلوبلز کے ساتھ کام کرتے وقت ان پر غور کریں جن کی عملی اہمیت ہے۔

3.1 خصوصی کیس 1. ایک نوڈ بغیر شاخوں کے

گلوبلز کو نہ صرف ایک صف کی طرح استعمال کیا جا سکتا ہے بلکہ باقاعدہ متغیرات کی طرح بھی استعمال کیا جا سکتا ہے۔ مثال کے طور پر، کاؤنٹر کے طور پر:

Set ^counter = 0  ; установка счётчика
Set id=$Increment(^counter) ;  атомарное инкрементирование

اس صورت میں، عالمی، اس کے معنی کے علاوہ، شاخیں بھی ہوسکتی ہیں. ایک دوسرے کو خارج نہیں کرتا۔

3.2 خصوصی کیس 2. ایک چوٹی اور بہت سی شاخیں۔

عام طور پر، یہ ایک کلاسک کلیدی قدر کی بنیاد ہے۔ اور اگر ہم قدروں کی ایک بڑی تعداد کو بطور قدر محفوظ کرتے ہیں، تو ہمیں بنیادی کلید کے ساتھ ایک بہت ہی عام ٹیبل ملے گا۔

گلوبلز پر ٹیبل کو لاگو کرنے کے لیے، ہمیں کالم ویلیوز سے قطاریں بنانا ہوں گی، اور پھر بنیادی کلید کا استعمال کرتے ہوئے انہیں عالمی میں محفوظ کرنا ہوگا۔ پڑھنے کے دوران سٹرنگ کو دوبارہ کالموں میں تقسیم کرنا ممکن بنانے کے لیے، آپ استعمال کر سکتے ہیں:

1. حروف کی حد بندی

   Set ^t(id1) = "col11/col21/col31"
   Set ^t(id2) = "col12/col22/col32"

2. ایک سخت اسکیم جس میں ہر فیلڈ بائٹس کی پہلے سے متعین تعداد پر قبضہ کرتی ہے۔ جیسا کہ رشتہ دار ڈیٹا بیس میں کیا جاتا ہے۔
3. ایک خاص فنکشن $LB (کیشے میں دستیاب ہے)، جو قدروں کی ایک تار بناتا ہے۔

   Set ^t(id1) = $LB("col11", "col21", "col31")
   Set ^t(id2) = $LB("col12", "col22", "col32")

دلچسپ بات یہ ہے کہ رشتہ دار ڈیٹا بیس میں ثانوی اشاریہ جات کی طرح کچھ کرنے کے لیے گلوبلز کو استعمال کرنا مشکل نہیں ہے۔ آئیے اس طرح کے ڈھانچے کو انڈیکس گلوبل کہتے ہیں۔ انڈیکس گلوبل ان فیلڈز کو تیزی سے تلاش کرنے کے لیے ایک معاون درخت ہے جو مرکزی عالمی کی بنیادی کلید کا حصہ نہیں ہیں۔ اسے بھرنے اور استعمال کرنے کے لیے، آپ کو اضافی کوڈ لکھنا ہوگا۔

آئیے پہلے کالم پر انڈیکس گلوبل بنائیں۔

Set ^i("col11", id1) = 1
Set ^i("col12", id2) = 1

اب، پہلے کالم میں معلومات کو تیزی سے تلاش کرنے کے لیے، ہمیں عالمی کو دیکھنا ہوگا۔ ^i اور پہلے کالم کی مطلوبہ قدر کے مطابق بنیادی کلیدیں (id) تلاش کریں۔

ایک قدر داخل کرتے وقت، ہم فوری طور پر مطلوبہ فیلڈز کے لیے قدر اور انڈیکس گلوبلز دونوں بنا سکتے ہیں۔ اور وشوسنییتا کے لیے، آئیے اس سب کو ایک لین دین میں لپیٹ دیں۔

TSTART
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^i("col11", id1) = 1
TCOMMIT

ایم پر کیسے کرنا ہے اس کی تفصیلات عالمی سطح پر میزیں, ثانوی اشاریہ جات کی نقالی.

اس طرح کی میزیں روایتی ڈیٹا بیس کی طرح تیزی سے کام کریں گی (یا اس سے بھی تیز) اگر قطاروں کو داخل کرنے/اپ ڈیٹ کرنے/حذف کرنے کے افعال COS/M میں لکھے جائیں اور مرتب کیے جائیں۔میں نے اس بیان کو ایک دو کالم ٹیبل میں بلک INSERT اور SELECT پر ٹیسٹ کے ساتھ چیک کیا، بشمول TSTART اور TCOMMIT کمانڈز (لین دین) کا استعمال۔

میں نے سمورتی رسائی اور متوازی لین دین کے ساتھ زیادہ پیچیدہ منظرناموں کا تجربہ نہیں کیا ہے۔

لین دین کا استعمال کیے بغیر، اندراج کی شرح 778 انسرٹس/سیکنڈ فی ملین ویلیو تھی۔
300 ملین اقدار کے ساتھ - 422 داخلات/سیکنڈ۔

لین دین استعمال کرتے وقت - 572M داخلوں کے لیے 082 انسرٹس/سیکنڈ۔ تمام کارروائیاں مرتب کردہ M کوڈ سے کی گئیں۔
ہارڈ ڈرائیوز باقاعدہ ہیں، SSD نہیں۔ رائٹ بیک کے ساتھ RAID5۔ فینوم II 1100T پروسیسر۔

اسی طرح سے ایس کیو ایل ڈیٹا بیس کی جانچ کرنے کے لیے، آپ کو ایک ذخیرہ شدہ طریقہ کار لکھنا ہوگا جو ایک لوپ میں اندراجات انجام دے گا۔ MySQL 5.5 (InnoDB سٹوریج) کی جانچ کرتے وقت، اس طریقہ کو استعمال کرتے ہوئے میں نے فی سیکنڈ 11K داخلوں سے زیادہ نمبر حاصل نہیں کیے تھے۔
جی ہاں، گلوبلز پر جدولوں کا نفاذ متعلقہ ڈیٹا بیس کی نسبت زیادہ پیچیدہ لگتا ہے۔ لہذا، گلوبلز پر صنعتی ڈیٹا بیس کو ٹیبلر ڈیٹا کے ساتھ کام کو آسان بنانے کے لیے SQL تک رسائی حاصل ہے۔

عام طور پر، اگر ڈیٹا سکیما بار بار تبدیل نہیں ہوتا ہے، اندراج کی رفتار اہم نہیں ہے اور پورے ڈیٹا بیس کو آسانی سے عام میزوں کی شکل میں پیش کیا جا سکتا ہے، تو ایس کیو ایل کے ساتھ کام کرنا آسان ہے، کیونکہ یہ تجرید کی اعلی سطح فراہم کرتا ہے۔ .

اس خاص معاملے میں میں اسے دکھانا چاہتا تھا۔ گلوبلز دوسرے ڈیٹا بیس بنانے کے لیے کنسٹرکٹر کے طور پر کام کر سکتے ہیں۔. اسمبلر کی طرح جس میں دوسری زبانیں لکھی جا سکتی ہیں۔ یہاں مثالیں ہیں کہ آپ گلوبلز پر ینالاگ کیسے بنا سکتے ہیں۔ کلیدی قدر، فہرستیں، سیٹ، ٹیبلر، دستاویز پر مبنی ڈیٹا بیس۔

اگر آپ کو کم سے کم کوشش کے ساتھ کسی قسم کا غیر معیاری ڈیٹا بیس بنانے کی ضرورت ہے، تو آپ کو گلوبلز کی طرف دیکھنا چاہیے۔

3.3 خصوصی کیس 3. دو سطحی درخت، دوسرے درجے کے ہر نوڈ میں شاخوں کی ایک مقررہ تعداد ہوتی ہے

آپ نے شاید اس کا اندازہ لگایا ہے: یہ گلوبلز پر جدولوں کا متبادل نفاذ ہے۔ آئیے اس نفاذ کا پچھلے سے موازنہ کریں۔

دو سطحی درخت پر میزیں بمقابلہ۔ ایک سطح کے درخت پر۔

Cons
پیشہ

1. اندراج کے لیے آہستہ، کیونکہ آپ کو نوڈس کی تعداد کالموں کی تعداد کے برابر سیٹ کرنے کی ضرورت ہے۔
2. زیادہ ڈسک کی جگہ کی کھپت. چونکہ کالم کے ناموں کے ساتھ عالمی اشاریہ جات (سرنی اشاریہ کے طور پر سمجھے جاتے ہیں) ڈسک کی جگہ لیتے ہیں اور ہر قطار کے لیے ڈپلیکیٹ ہوتے ہیں۔

1. انفرادی کالموں کی قدروں تک تیز رسائی، کیونکہ سٹرنگ کو پارس کرنے کی ضرورت نہیں ہے۔ میرے ٹیسٹوں کے مطابق، یہ 11,5 کالموں پر 2% تیز اور کالموں کی ایک بڑی تعداد پر زیادہ ہے۔
2. ڈیٹا اسکیما کو تبدیل کرنا آسان ہے۔
3. مزید واضح کوڈ

: اختتام سب کے لیے نہیں. چونکہ رفتار گلوبلز کے سب سے اہم فوائد میں سے ایک ہے، اس لیے اس عمل کو استعمال کرنے کا کوئی فائدہ نہیں ہے، کیونکہ یہ ممکنہ طور پر متعلقہ ڈیٹا بیس میں ٹیبلز سے زیادہ تیز کارکردگی کا مظاہرہ نہیں کرے گی۔

3.4 عمومی معاملہ۔ درخت اور آرڈر شدہ درخت

کوئی بھی ڈیٹا ڈھانچہ جسے درخت کے طور پر پیش کیا جا سکتا ہے وہ گلوبلز کے ساتھ بالکل فٹ بیٹھتا ہے۔

3.4.1 ذیلی اشیاء کے ساتھ آبجیکٹ

یہ گلوبلز کے روایتی استعمال کا علاقہ ہے۔ طبی میدان میں بیماریوں، ادویات، علامات اور علاج کے طریقوں کی ایک بڑی تعداد ہے۔ ہر مریض کے لیے دس لاکھ فیلڈز کے ساتھ ٹیبل بنانا غیر معقول ہے۔ مزید یہ کہ 99% فیلڈز خالی ہوں گی۔

جدولوں کے SQL ڈیٹا بیس کا تصور کریں: "مریض" ~ 100 فیلڈز، "میڈیسن" - 000 فیلڈز، "تھراپی" - 100 فیلڈز، "پیچیدگیاں" - 000 فیلڈز وغیرہ۔ اور اسی طرح. یا آپ کئی ہزار میزوں کا ڈیٹا بیس بنا سکتے ہیں، ہر ایک ایک مخصوص قسم کے مریض کے لیے (اور وہ اوور لیپ کر سکتے ہیں!)، علاج، ادویات، اور ان میزوں کے درمیان کنکشن کے لیے مزید ہزاروں میزیں۔

گلوبلز ادویات کے لیے مثالی ہیں، کیونکہ وہ آپ کو ہر مریض کے لیے اس کی طبی تاریخ، مختلف علاج، اور دوائیوں کے اعمال کی درست وضاحت، ایک درخت کی شکل میں، خالی کالموں پر اضافی ڈسک کی جگہ ضائع کیے بغیر، تخلیق کرنے کی اجازت دیتے ہیں۔ ایک رشتہ دار کیس میں معاملہ ہو.

گلوبلز کا استعمال کرتے ہوئے لوگوں کے بارے میں ڈیٹا کے ساتھ ڈیٹا بیس بنانا آسان ہے۔، جب کلائنٹ کے بارے میں زیادہ سے زیادہ مختلف معلومات کو جمع کرنا اور منظم کرنا ضروری ہے۔ طب، بینکنگ، مارکیٹنگ، آرکائیونگ اور دیگر شعبوں میں اس کی مانگ ہے۔

.
یقینا، ایس کیو ایل میں آپ صرف چند ٹیبلز کے ساتھ ایک درخت کی تقلید بھی کر سکتے ہیں (ای اے وی, 1,2,3,4,5,6,7,8,9,10)، تاہم یہ نمایاں طور پر زیادہ پیچیدہ ہے اور آہستہ ہوگا۔ بنیادی طور پر، آپ کو ایک گلوبل لکھنا پڑے گا جو میزوں پر کام کرتا ہے اور تمام کام کو ٹیبل کے ساتھ ایک تجریدی پرت کے نیچے چھپانا ہوگا۔ اعلی درجے کی ٹیکنالوجی (SQL) کا استعمال کرتے ہوئے نچلی سطح کی ٹیکنالوجی (گلوبلز) کی تقلید کرنا غلط ہے۔ نامناسب۔

یہ کوئی راز نہیں ہے کہ جائنٹ ٹیبلز (ALTER TABLE) پر ڈیٹا اسکیما کو تبدیل کرنے میں کافی وقت لگ سکتا ہے۔ مثال کے طور پر، MySQL پرانے ٹیبل سے نئی ٹیبل میں معلومات کو مکمل طور پر کاپی کر کے ٹیبل ایڈڈ | ڈراپ کالم کو تبدیل کرتا ہے (مائی آئی ایس اے ایم، اننو ڈی بی انجنوں کا تجربہ کیا گیا)۔ جو اربوں ریکارڈ کے ساتھ کام کرنے والے ڈیٹا بیس کو ہفتوں نہیں تو دنوں کے لیے لٹکا سکتا ہے۔

اگر ہم گلوبلز استعمال کرتے ہیں تو ڈیٹا کے ڈھانچے کو تبدیل کرنے سے ہمیں کچھ نہیں ہوتا۔ کسی بھی وقت ہم درجہ بندی کی کسی بھی سطح پر، کسی بھی شے میں کسی بھی نئی خصوصیات کو شامل کر سکتے ہیں۔ شاخوں کے نام تبدیل کرنے سے وابستہ تبدیلیاں چلتے ہوئے ڈیٹا بیس پر پس منظر میں چلائی جا سکتی ہیں۔


لہذا، جب بہت زیادہ تعداد میں اختیاری خصوصیات کے ساتھ اشیاء کو ذخیرہ کرنے کی بات آتی ہے، تو گلوبل ایک بہترین انتخاب ہیں۔

مزید برآں، میں آپ کو یاد دلاتا ہوں کہ کسی بھی پراپرٹی تک رسائی فوری ہے، کیونکہ عالمی سطح پر تمام راستے B-trees ہیں۔

عالمی ڈیٹا بیس، عام طور پر، ایک قسم کا دستاویز پر مبنی ڈیٹا بیس ہے جس میں درجہ بندی کی معلومات کو ذخیرہ کرنے کی صلاحیت ہے۔ لہذا، دستاویز پر مبنی ڈیٹا بیس طبی ریکارڈ کو ذخیرہ کرنے کے میدان میں عالمی سطح پر مقابلہ کر سکتے ہیں۔ لیکن یہ اب بھی بالکل ایک جیسا نہیں ہے۔آئیے مقابلے کے لیے MongoDB لیتے ہیں۔ اس ڈومین میں یہ مندرجہ ذیل وجوہات کی بنا پر عالمیوں سے ہار جاتا ہے:

1. دستاویز کا سائز۔ اسٹوریج یونٹ JSON فارمیٹ میں متن ہے (زیادہ واضح طور پر BSON) جس کا حجم تقریباً 16MB ہے۔ یہ پابندی خاص طور پر اس لیے لگائی گئی تھی تاکہ JSON ڈیٹابیس کو پارس کرنے کے دوران سست نہ ہو اگر JSON کی ایک بڑی دستاویز کو اس میں اسٹور کیا جائے اور پھر فیلڈز کے ذریعے اس تک رسائی حاصل کی جائے۔ اس دستاویز میں مریض کے بارے میں تمام معلومات ہونی چاہئیں۔ ہم سب جانتے ہیں کہ مریض کا ریکارڈ کتنا موٹا ہو سکتا ہے۔ کارڈ کا زیادہ سے زیادہ سائز 16MB فوری طور پر ایسے مریضوں کو ختم کر دیتا ہے جن کے مرض کارڈ میں ایم آر آئی فائلیں، ایکس رے اسکین اور دیگر مطالعات شامل ہیں۔ عالمی کی ایک شاخ میں آپ کے پاس گیگا بائٹس اور ٹیرا بائٹس معلومات ہو سکتی ہیں۔ اصولی طور پر، ہم اسے ختم کر سکتے ہیں، لیکن میں جاری رکھوں گا.
2. مریض کے چارٹ میں نئی ​​خصوصیات کے شعور/تبدیلی/حذف کا وقت۔ اس طرح کے ڈیٹا بیس کو پورے نقشے کو میموری میں پڑھنا چاہیے (یہ ایک بڑی رقم ہے!)، BSON کو پارس کرنا، نیا نوڈ شامل کرنا/تبدیل کرنا/ڈیلیٹ کرنا، اشاریہ جات کو اپ ڈیٹ کرنا، اسے BSON میں پیک کرنا، اور اسے ڈسک میں محفوظ کرنا چاہیے۔ ایک عالمی کو صرف ایک مخصوص پراپرٹی تک رسائی حاصل کرنے اور اس میں ہیرا پھیری کرنے کی ضرورت ہے۔
3. انفرادی خصوصیات تک فوری رسائی۔ دستاویز میں بہت ساری خصوصیات اور اس کے کثیر سطحی ڈھانچے کے ساتھ، انفرادی خصوصیات تک رسائی اس حقیقت کی وجہ سے تیز تر ہو جائے گی کہ عالمی سطح پر ہر راستہ ایک B-tree ہے۔ BSON میں، آپ کو مطلوبہ پراپرٹی تلاش کرنے کے لیے دستاویز کو لکیری طور پر پارس کرنا ہوگا۔

3.3.2 ایسوسی ایٹیو صفیں۔

ایسوسی ایٹیو ارے (یہاں تک کہ نیسٹڈ اریوں کے ساتھ بھی) عالمی سطح پر بالکل فٹ ہوتے ہیں۔ مثال کے طور پر، PHP سے ایسی صف پہلی تصویر 3.3.1 میں دکھائی جائے گی۔

$a = array(
  "name" => "Vince Medvedev",
  "city" => "Moscow",
  "threatments" => array(
    "surgeries" => array("apedicectomy", "biopsy"),
    "radiation" => array("gamma", "x-rays"),
    "physiotherapy" => array("knee", "shoulder")
  )
);

3.3.3 درجہ بندی کی دستاویزات: XML, JSON

عالمی سطح پر بھی آسانی سے ذخیرہ کیا جاتا ہے۔ سٹوریج کے لئے مختلف طریقوں سے باہر رکھا جا سکتا ہے.

XML
XML کو گلوبلز میں تحلیل کرنے کا سب سے آسان طریقہ یہ ہے کہ نوڈس میں ٹیگ کی خصوصیات کو اسٹور کیا جائے۔ اور اگر ٹیگ انتسابات تک فوری رسائی کی ضرورت ہے، تو ہم انہیں الگ الگ شاخوں میں منتقل کر سکتے ہیں۔

<note id=5>
<to>Вася</to>
<from>Света</from>
<heading>Напоминание</heading>
<body>Позвони мне завтра!</body>
</note>

COS پر یہ کوڈ کے مطابق ہوگا:

Set ^xml("note")="id=5"
Set ^xml("note","to")="Саша"
Set ^xml("note","from")="Света"
Set ^xml("note","heading")="Напоминание"
Set ^xml("note","body")="Позвони мне завтра!"

نوٹ: XML، JSON، associative arrays کے لیے، آپ عالمی سطح پر ڈسپلے کرنے کے بہت سے مختلف طریقے تلاش کر سکتے ہیں۔ اس صورت میں، ہم نے نوٹ ٹیگ میں ذیلی ٹیگز کی ترتیب کو ظاہر نہیں کیا۔ عالمی سطح پر ^xml ذیلی ٹیگز حروف تہجی کی ترتیب میں دکھائے جائیں گے۔ آرڈر کی سختی سے عکاسی کرنے کے لیے، آپ استعمال کر سکتے ہیں، مثال کے طور پر، درج ذیل ڈسپلے:

JSON
سیکشن 3.3.1 کی پہلی تصویر اس JSON دستاویز کا عکس دکھاتی ہے:

var document = {
  "name": "Vince Medvedev",
  "city": "Moscow",
  "threatments": {
    "surgeries": ["apedicectomy", "biopsy"],
    "radiation": ["gamma", "x-rays"],
    "physiotherapy": ["knee", "shoulder"]
  },
};

3.3.4 درجہ بندی کے رشتوں سے جڑے ایک جیسے ڈھانچے

مثالیں: سیلز دفاتر کا ڈھانچہ، MLM ڈھانچے میں لوگوں کا مقام، شطرنج میں کھلنے کا ڈیٹا بیس۔

ڈیبیو ڈیٹا بیس۔ آپ اسٹروک فورس کے تخمینہ کو عالمی نوڈ کی انڈیکس ویلیو کے طور پر استعمال کر سکتے ہیں۔ اس کے بعد، مضبوط ترین اقدام کا انتخاب کرنے کے لیے، سب سے زیادہ وزن والی شاخ کا انتخاب کرنا کافی ہوگا۔ عالمی سطح پر تمام شاخوں کو حرکت کی طاقت کے مطابق ترتیب دیا جائے گا۔

سیلز دفاتر کا ڈھانچہ، MLM میں لوگوں کی ساخت۔ نوڈس کچھ کیشنگ اقدار کو ذخیرہ کرسکتے ہیں جو پورے ذیلی درخت کی خصوصیات کو ظاہر کرتی ہیں۔ مثال کے طور پر، دیے گئے ذیلی درخت کی فروخت کا حجم۔ کسی بھی لمحے ہمیں کسی بھی شاخ کی کامیابیوں کی عکاسی کرنے والا اعداد و شمار مل سکتے ہیں۔

4. کن صورتوں میں گلوبلز کا استعمال سب سے زیادہ فائدہ مند ہے؟

پہلا کالم ایسے کیسز کو پیش کرتا ہے جہاں آپ کو گلوبلز کا استعمال کرتے ہوئے تیز رفتاری کا خاص فائدہ ملے گا، اور دوسرا جب ڈیزائن یا ڈیٹا ماڈل کو آسان بنایا جائے گا۔

رفتار
ڈیٹا پروسیسنگ/پریزنٹیشن میں آسانی

1. اندراج [ہر سطح پر خودکار چھانٹ کے ساتھ]، [ماسٹر کلید کے ذریعے انڈیکسنگ]
2. ذیلی درختوں کو ہٹانا
3. بہت ساری گھریلو خصوصیات کے ساتھ آبجیکٹ جن کے لیے انفرادی رسائی کی ضرورت ہوتی ہے۔
4. درجہ بندی کا ڈھانچہ کسی بھی شاخ سے بچوں کی شاخوں کو نظرانداز کرنے کی صلاحیت کے ساتھ، یہاں تک کہ غیر موجود بھی
5. ذیلی درختوں کی گہرائی کا پہلا راستہ

1. بڑی تعداد میں اختیاری [اور/یا نیسٹڈ] پراپرٹیز/اینٹی کے ساتھ آبجیکٹ/اینٹیٹیز
2. سکیما سے کم ڈیٹا۔ جب نئی خصوصیات اکثر ظاہر ہوسکتی ہیں اور پرانی غائب ہوجاتی ہیں۔
3. آپ کو اپنی مرضی کے مطابق ڈیٹا بیس بنانے کی ضرورت ہے۔
4. راستے کے اڈے اور فیصلے کے درخت۔ جب درخت کے طور پر راستوں کی نمائندگی کرنا آسان ہو۔
5. تکرار کا استعمال کیے بغیر درجہ بندی کے ڈھانچے کو ہٹانا

تسلسل "عالمی لوگ ڈیٹا کو ذخیرہ کرنے کے لیے خزانہ کی تلوار ہیں۔ ویرل صفیں حصہ 3".

اعلانِ لاتعلقی: یہ مضمون اور اس پر میرے تبصرے میری رائے ہیں اور ان کا انٹر سسٹم کارپوریشن کی سرکاری پوزیشن سے کوئی تعلق نہیں ہے۔

ماخذ: www.habr.com