3 قانون اساسی برای انتخاب شاخص ها

چند قانون اساسی وجود دارد که باید هنگام انتخاب فهرست برای پایگاه داده به خاطر داشت. یک شاخص خوب باید این سه ویژگی را داشته باشد:

1. سودمندی: سرعت اجرای برخی پرس و جوها (یا اعمال یک محدودیت)
2. خوشه بندی: سوابقی را که احتمالاً با هم در نزدیکی یکدیگر قابل دسترسی هستند نگهداری کنید
3. پراکندگی: رکوردهایی را که بعید به نظر می رسد با هم دسترسی داشته باشند، از هم دور نگه دارید

مفید بودن

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

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

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

خوشه بندی

قانون دوم، خوشه بندی، کمی ظریف تر است. هنگامی که یک برنامه نیاز دارد چندین رکورد را همزمان بارگیری کند (مثلاً به دلیل JOIN یا استفاده از عملگر IN)، اگر آن رکوردها نزدیک یکدیگر باشند، برای عملکرد بهتر است.

در ابتدا، این توصیه برای به حداقل رساندن تعداد جستجوهایی که باید روی هاردهای در حال چرخش انجام شود، ارائه شد. در یک پایگاه داده توزیع شده مانند CockroachDB، همان دستورالعمل برای به حداقل رساندن تعداد عملیات شبکه برای دسترسی از راه دور به داده ها عمل می کند. به عنوان مثال، در یک فید خبری شبکه اجتماعی، اکثر بازدیدهای صفحه فقط به داده های روز جاری نیاز دارند. سازماندهی داده ها بر اساس زمان ممکن است بهترین خوشه بندی داده ها و کارایی حافظه پنهان را ارائه دهد (یا شاید نه، همانطور که در زیر خواهیم دید).

CockroachDB چند برنامه افزودنی SQL را ارائه می دهد که می تواند خوشه بندی داده ها را بیشتر بهبود بخشد، از جمله ذخیره سازی فهرست ها.

پراکندگی

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

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

گزینه هایی برای انتخاب شناسه های منحصر به فرد

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

سکانس

ساده ترین (اما اغلب کمترین عملکرد) برای تولید شناسه های منحصر به فرد ، شروع با 1 و شمارش است. این همان چیزی است که شما از ویژگی دنباله در CockroachDB و PostgreSQL یا کلمه کلیدی Auto_increment در MySQL دریافت می کنید. این شناسه هایی را تولید می کند که تقریباً با سفارش درج مطابقت دارد ، و بسیاری از کاربران این واقعیت را دوست دارند که شناسه های تولید شده عدد صحیح کوچک هستند (از طرف دیگر ، شناسه های پی در پی می توانند جزئیات تعداد کاربر/عکس و غیره را ارائه دهند).

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

توجه: توالی ها غیر تعاملی هستند

چرا IDS فقط با سفارش درج مطابقت دارد؟(این در اکثر بانکهای اطلاعاتی ، نه فقط CockroachDB) صادق است) زیرا وقتی یک معامله رکورد را وارد می کند ، هنگام رسیدن به بیانیه درج ، شناسه می شود ، اما این سابقه تا زمان انجام معامله برای سایر خوانندگان قابل مشاهده نیست. این بدان معناست که می توان به نظر می رسد که سوابق به نظر می رسد خارج از نظم است ، مانند این:

1. معامله درج یک رکورد است که به شناسه 1 اختصاص داده شده است
2. معامله B سابقه ای را درج می کند که به شناسه 2 اختصاص داده شده است
3. معامله B مرتکب می شود
4. معامله C از جدول خوانده می شود و رکورد 2 را می بیند
5. معامله A مرتکب می شود
6. معامله C از جدول خوانده می شود و سوابق 1 و 2 را می بیند

اگر برنامه شما به شناسه نیاز دارد تا به طور دقیق با ترتیب درج مطابقت داشته باشد ، می توانید کاری مانند Insert int in int int int into tbl (id ،…) مقادیر ((حداکثر (شناسه) +1 را از TBL) ،…) انجام دهید. با این حال ، این هزینه عملکرد بسیار بالایی دارد زیرا باعث می شود همه معاملات درج منتظر نوبت خود باشند تا شناسه بعدی را وارد کنند ، بنابراین فقط در صورت نیاز به درخواست شما نیاز به سفارش دقیق شناسه انجام دهید.

با استفاده از تغییر ضبط داده (CDC) می تواند به جلوگیری از نیاز به سفارش دقیق شناسه در بسیاری از برنامه ها کمک کند و به شما امکان می دهد از استراتژی های شناسه با کارایی بالاتر استفاده کنید.

تناقضات زمانی

Timestamps تقریباً سفارش داده شده و تقریباً منحصر به فرد است (و با افزودن بیت های تصادفی یا استفاده از محدودیت های منحصر به فرد در پایگاه داده می توان برخورد را انجام داد). آنها مقیاس پذیر تر از توالی هستند زیرا برای حفظ پیشخوان دنباله به یک تنگنا تک کلید احتیاج ندارند ، بنابراین آنها مناسب برای پایگاه داده های توزیع شده هستند.

CockroachDB از Timestamps به علاوه بیت های تصادفی به عنوان پیش فرض برای نوع ستون سریال و عملکرد منحصر به فرد_روید () استفاده می کند. هنگامی که خوشه بندی مرتبه درج مهمتر از پراکندگی برای برنامه شما است ، شناسه های مبتنی بر Timestamp را توصیه می کنیم.

تصادفی بودن

سومین گزینه اصلی برای تولید شناسه استفاده از اعداد تصادفی بزرگ ، معمولاً از طریق نوع UUID 128 بیتی است. همانطور که ممکن است انتظار داشته باشید ، شناسه های تصادفی پراکندگی را به حداکثر می رسانند اما هیچ خوشه ای نمی دهند. شناسه های تصادفی معمولاً بهترین عملکرد درج خام را در CockroachDB به وجود می آورند زیرا به آنها اجازه می دهد تا تمام گره های موجود در خوشه به طور کامل مورد استفاده قرار گیرند ، اگرچه عدم وجود خوشه بندی می تواند به عملکرد برخی از سؤالات آسیب برساند.

یک رویکرد جایگزین: کلیدهای شاخص هش دار

حتی اگر Timestamps از بدترین تنگناهای شناسه های پی در پی جلوگیری کند ، اما هنوز هم تمایل به ایجاد تنگنا دارند زیرا همه درج ها در حدود زمان فعلی اتفاق می افتد ، بنابراین فقط تعداد کمی از گره ها قادر به شرکت در رسیدگی به این نوشتن ها هستند. اگر به توان نوشتن بیشتری نسبت به شناسه های Timestamp نیاز دارید اما خوشه بندی بیشتری نسبت به UUID های تصادفی دارید ، CockroachDB دارای یک ویژگی منحصر به فرد به نام شاخص های هش دار است که دقیقاً برای آن الزامات طراحی شده است.

شاخص های هشک چگونه کار می کنند

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

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

نحوه ایجاد یک نمایه هش-شارد شده

برای ایجاد یک نمایه هش-شارد شده، متغیر جلسه experimental_enable_hash_sharded_indexes را روی on قرار دهید. سپس، عبارت اختیاری USING HASH WITH BUCKET_COUNT = n_buckets را به یک عبارت CREATE INDEX، به یک تعریف INDEX در یک عبارت CREATE TABLE، یا به یک عبارت ALTER PRIMARY KEY اضافه کنید. وقتی از این بند استفاده می شود، CockroachDB n_buckets ستون های محاسبه شده ایجاد می کند، ایندکس را به قطعات n_buckets تقسیم می کند، و سپس هر تکه شاخص را با یکی از هش های ستون محاسبه شده به عنوان پیشوند، در ذخیره سازی مقدار کلید زیرین ذخیره می کند.

برای تغییر اندازه سطل یک فهرست کلید اصلی هش شارد موجود، از عبارت ALTER PRIMARY KEY با عبارت USING HASH WITH BUCKET_COUNT = n_buckets استفاده کنید که اندازه سطل جدید و ستون های کلید اصلی موجود را مشخص می کند.