🥇گلوبال ها شمشیرهای گنج برای ذخیره داده ها هستند. درختان. قسمت 2

3. انواع ساختارها هنگام استفاده از گلوبال ها

ساختاری مانند درخت سفارش داده شده دارای موارد خاص مختلفی است. بیایید مواردی را در نظر بگیریم که هنگام کار با جهانی ها ارزش عملی دارند.

3.1 مورد خاص 1. یک گره بدون انشعاب

گلوبال ها را می توان نه تنها مانند یک آرایه، بلکه مانند متغیرهای معمولی نیز استفاده کرد. به عنوان مثال، به عنوان یک شمارنده:

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

در این صورت جهانی علاوه بر معنایش می تواند دارای شاخه هایی نیز باشد. یکی دیگری را مستثنی نمی کند.

3.2 مورد خاص 2. یک راس و چندین شاخه

به طور کلی، این یک پایه ارزش کلید کلاسیک است. و اگر چندین مقدار را به عنوان مقدار ذخیره کنیم، یک جدول بسیار معمولی با یک کلید اصلی دریافت خواهیم کرد.

برای پیاده‌سازی جدول روی جهانی‌ها، باید خودمان ردیف‌هایی را از مقادیر ستون تولید کنیم و سپس با استفاده از کلید اصلی آنها را در سراسری ذخیره کنیم. برای ایجاد امکان تقسیم مجدد رشته به ستون ها هنگام خواندن، می توانید از:

کاراکترهای جداکننده

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

یک طرح سفت و سخت که در آن هر فیلد تعداد بایت های از پیش تعیین شده ای را اشغال می کند. همانطور که در پایگاه داده های رابطه ای انجام می شود.
یک تابع ویژه $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

جزئیات نحوه انجام آن در M جداول جهانی, شبیه سازی شاخص های ثانویه.

اگر توابع درج/به‌روزرسانی/حذف ردیف‌ها در COS/M نوشته شده و کامپایل شوند، چنین جداول به سرعت پایگاه‌های داده سنتی (یا حتی سریع‌تر) کار خواهند کرد.من این بیانیه را با آزمایش‌هایی روی INSERT و SELECT انبوه در یک جدول دو ستونی، از جمله استفاده از دستورات TSTART و TCOMMIT (معاملات) بررسی کردم.

من سناریوهای پیچیده تر را با دسترسی همزمان و تراکنش های موازی آزمایش نکرده ام.

بدون استفاده از تراکنش، نرخ درج 778 درج در ثانیه در هر میلیون مقدار بود.
با 300 میلیون مقدار - 422 درج در ثانیه.

هنگام استفاده از تراکنش ها - 572 درج در ثانیه برای 082 میلیون درج. تمام عملیات از کد M کامپایل شده انجام شد.
هارد دیسک ها معمولی هستند نه SSD. RAID5 با Write-back. پردازنده Phenom II 1100T.

برای آزمایش یک پایگاه داده SQL به روشی مشابه، باید یک رویه ذخیره شده بنویسید که درج ها را در یک حلقه انجام دهد. هنگام آزمایش MySQL 5.5 (ذخیره سازی InnoDB)، با استفاده از این روش اعدادی را دریافت کردم که بیش از 11 هزار درج در ثانیه نبود.
بله، پیاده سازی جداول بر روی جهانی ها پیچیده تر از پایگاه داده های رابطه ای به نظر می رسد. بنابراین، پایگاه‌های داده صنعتی در جهانی‌ها برای ساده‌سازی کار با داده‌های جدولی، دسترسی SQL دارند.

به طور کلی، اگر طرح داده ها به طور مکرر تغییر نکند، سرعت درج بسیار مهم نیست و کل پایگاه داده را می توان به راحتی در قالب جداول عادی نشان داد، در این صورت کار با SQL آسان تر است، زیرا سطح بالاتری از انتزاع را فراهم می کند. .

در این مورد خاص می خواستم آن را نشان دهم جهانی ها می توانند به عنوان سازنده برای ایجاد پایگاه های داده دیگر عمل کنند. مانند اسمبلری که می توان زبان های دیگر را در آن نوشت. در اینجا نمونه هایی از نحوه ایجاد آنالوگ در جهانی ها آورده شده است کلید-مقدار، لیست ها، مجموعه ها، جدولی، پایگاه های داده سند محور.

اگر نیاز به ایجاد نوعی پایگاه داده غیر استاندارد با کمترین تلاش دارید، باید به سمت جهانی ها نگاه کنید.

3.3 مورد خاص 3. درخت دو سطحی، هر گره از سطح دوم دارای تعداد ثابتی از شاخه است.

احتمالاً حدس زده اید: این یک پیاده سازی جایگزین جداول در جهانی ها است. بیایید این پیاده سازی را با اجرای قبلی مقایسه کنیم.

جداول روی درخت دو سطحی در مقابل روی درخت تک سطحی

منفی
مزایا

برای درج کندتر است، زیرا باید تعداد گره ها را برابر با تعداد ستون ها تنظیم کنید.
مصرف فضای دیسک بیشتر از آنجایی که شاخص های سراسری (که به عنوان شاخص های آرایه فهمیده می شوند) با نام ستون ها فضای دیسک را اشغال می کنند و برای هر ردیف تکرار می شوند.

دسترسی سریع تر به مقادیر ستون های جداگانه، زیرا نیازی به تجزیه رشته نیست. طبق آزمایشات من، در 11,5 ستون 2٪ سریعتر و در تعداد بیشتری از ستون ها بیشتر است.
تغییر طرح داده آسان تر است
کد واضح تر

نتیجه گیری: برای هرکس نیست. از آنجایی که سرعت یکی از کلیدی‌ترین مزایای جهانی‌ها است، استفاده از این پیاده‌سازی سود چندانی ندارد، زیرا به احتمال زیاد سریع‌تر از جداول در پایگاه‌های داده رابطه‌ای عمل نمی‌کند.

3.4 مورد کلی. درختان و درختان سفارش داده شده

هر ساختار داده ای که می تواند به عنوان یک درخت نمایش داده شود کاملاً با جهانی ها مطابقت دارد.

3.4.1 اشیاء با موضوعات فرعی

این منطقه استفاده سنتی از جهانی ها است. در زمینه پزشکی تعداد زیادی از بیماری ها، داروها، علائم و روش های درمانی وجود دارد. ایجاد جدولی با یک میلیون فیلد برای هر بیمار غیرمنطقی است. علاوه بر این، 99 درصد از فیلدها خالی خواهند بود.

یک پایگاه داده SQL از جداول را تصور کنید: "بیمار" ~ 100 فیلد، "پزشکی" - 000 فیلد، "درمان" - 100 فیلد، "عوارض" - 000 فیلد و غیره. و غیره یا می توانید پایگاه داده ای از هزاران جدول ایجاد کنید که هر کدام برای نوع خاصی از بیمار است (و می توانند همپوشانی داشته باشند!)، درمان ها، داروها و هزاران جدول دیگر برای ارتباط بین این جداول.

گلوبال ها برای پزشکی ایده آل هستند، زیرا به شما این امکان را می دهند که برای هر بیمار شرح دقیقی از تاریخچه پزشکی، درمان های مختلف و عملکرد داروها، به شکل درخت، بدون هدر دادن فضای اضافی دیسک بر روی ستون های خالی ایجاد کنید. در یک مورد رابطه ای باشد.

با استفاده از جهانی ها، ایجاد یک پایگاه داده با داده های مربوط به افراد راحت است، زمانی که جمع آوری و سیستماتیک کردن حداکثر اطلاعات مختلف در مورد مشتری مهم است. این مورد در پزشکی، بانکداری، بازاریابی، بایگانی و سایر زمینه ها مورد تقاضا است

.
البته در SQL می‌توانید درخت را تنها با چند جدول تقلید کنید (EAV, 1,2,3,4,5,6,7,8,9,10، اما این به طور قابل توجهی پیچیده تر است و کندتر خواهد بود. در اصل، شما باید یک جهانی بنویسید که روی جداول کار کند و تمام کارها را با جداول زیر یک لایه انتزاعی پنهان کنید. تقلید فناوری سطح پایین (جهانی) با استفاده از فناوری سطح بالاتر (SQL) اشتباه است. نامناسب

بر کسی پوشیده نیست که تغییر طرح داده در جداول غول پیکر (ALTER TABLE) می تواند زمان زیادی را ببرد. برای مثال MySQL با کپی کامل اطلاعات از جدول قدیمی به جدول جدید (موتورهای MyISAM، InnoDB تست شده) ALTER TABLE ADD|DROP COLUMN را تغییر می دهد. که می تواند یک پایگاه داده کار با میلیاردها رکورد را برای روزها، اگر نه هفته ها، قطع کند.

تغییر ساختار داده در صورت استفاده از جهانی ها هیچ هزینه ای برای ما ندارد. در هر زمان می توانیم هر ویژگی جدیدی را که نیاز داریم به هر شی، در هر سطحی از سلسله مراتب اضافه کنیم. تغییرات مرتبط با تغییر نام شاخه ها را می توان در پس زمینه در یک پایگاه داده در حال اجرا اجرا کرد.

بنابراین، هنگامی که صحبت از ذخیره اشیاء با تعداد زیادی از ویژگی های اختیاری می شود، جهانی ها یک انتخاب عالی هستند.

علاوه بر این، اجازه دهید به شما یادآوری کنم که دسترسی به هر یک از ویژگی ها فوری است، زیرا در سراسری همه مسیرها B-trees هستند.

پایگاه های داده جهانی، به طور کلی، نوعی پایگاه داده سند محور با قابلیت ذخیره اطلاعات سلسله مراتبی هستند. بنابراین پایگاه های اسناد مدارک می توانند در زمینه ذخیره مدارک پزشکی با جهانی ها رقابت کنند. اما هنوز کاملاً یکسان نیستبیایید MongoDB را برای مقایسه در نظر بگیریم. در این حوزه به دلایل زیر به جهانیان می بازد:

اندازه سند واحد ذخیره سازی متنی با فرمت JSON (به طور دقیق تر BSON) با حداکثر حجم حدود 16 مگابایت است. این محدودیت به طور خاص ایجاد شده است تا اگر یک سند بزرگ JSON در آن ذخیره شود و سپس توسط فیلدها قابل دسترسی باشد، پایگاه داده JSON در حین تجزیه کند نمی شود. این سند باید حاوی تمام اطلاعات مربوط به بیمار باشد. همه ما می دانیم که سوابق بیماران چقدر می تواند ضخیم باشد. حداکثر اندازه کارت 16 مگابایت بلافاصله به بیمارانی که کارت بیماری آنها شامل فایل های MRI، اسکن اشعه ایکس و سایر مطالعات است پایان می دهد. در یکی از شاخه های جهانی می توانید گیگابایت و ترابایت اطلاعات داشته باشید. در اصل ما می توانیم به این موضوع پایان دهیم، اما من ادامه می دهم.
زمان هوشیاری/تغییر/حذف ویژگی های جدید در نمودار بیمار. چنین پایگاه داده ای باید کل نقشه را در حافظه بخواند (این مقدار زیادی است!)، BSON را تجزیه کند، یک گره جدید را اضافه/تغییر/حذف کند، فهرست ها را به روز کند، آن را در BSON بسته بندی کند و در دیسک ذخیره کند. یک جهانی فقط باید به یک ویژگی خاص دسترسی داشته باشد و آن را دستکاری کند.
دسترسی سریع به املاک فردی با ویژگی‌های زیاد در یک سند و ساختار چند سطحی آن، دسترسی به ویژگی‌های فردی سریع‌تر خواهد بود، زیرا هر مسیر در سراسری یک درخت B است. در 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، آرایه‌های انجمنی، می‌توانید راه‌های مختلفی برای نمایش در جهانی‌ها ارائه دهید. در این مورد، ترتیب زیربرچسب ها را در تگ یادداشت منعکس نکردیم. در سطح جهانی ^ 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. در چه مواردی استفاده از گلوبال ها سودمندتر است؟

ستون اول مواردی را نشان می دهد که با استفاده از جهانی ها افزایش سرعت قابل توجهی خواهید داشت، و ستون دوم زمانی که طراحی یا مدل داده ساده می شود.

سرعت
سهولت پردازش/ارائه داده ها

درج [با مرتب‌سازی خودکار در هر سطح]، [نمایه‌سازی با کلید اصلی]
حذف درختان فرعی
اشیایی با ویژگی های تو در تو زیاد که نیاز به دسترسی فردی دارند
ساختار سلسله مراتبی با قابلیت دور زدن شاخه های فرزند از هر شاخه، حتی از شاخه های موجود
عمق-اول پیمایش زیر درختان

اشیاء/موجودات با تعداد زیادی ویژگی/موجود اختیاری [و/یا تودرتو]
داده های بدون طرحواره زمانی که خواص جدید اغلب ظاهر می شوند و قدیمی ها ناپدید می شوند.
شما باید یک پایگاه داده سفارشی ایجاد کنید.
پایه های مسیر و درخت های تصمیم. وقتی راحت است که مسیرها را به صورت درخت نشان دهیم.
حذف ساختارهای سلسله مراتبی بدون استفاده از بازگشت

توسعه گلوبال ها شمشیرهای گنج برای ذخیره داده ها هستند. آرایه های پراکنده قسمت 3".

سلب مسئولیت: این مقاله و نظرات من در مورد آن نظر من است و هیچ ارتباطی با موضع رسمی InterSystems Corporation ندارد.

منبع: www.habr.com

جهانی ها شمشیرهای گنج برای ذخیره داده ها هستند. درختان. قسمت 2