کاساندرا که بود و چه کرد؟

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

بریم سراغ آپاچی کاساندرای عزیز دل

آپاچی کاساندرا

کاساندرا (Cassandra) یک پایگاه داده توزیع شده‌ی NoSQL، منبع بازه(open-source) و غیر رابطه‌ایی (non-relational) عه که برای مدیریت حجم زیادی از داده‌ها تو چندین دیتاسنتر و کلود مختلف طراحی شده. به طور کلی پایگاه داده‌های NoSQL برای مدیریت و ذخیره‌سازی داده‌های non-relational طراحی شدن. NoSQL مخفف "Not Only SQL"عه و برعکس SQL از ساختار شمای غیر ثابتی استفاده میکنن و این باعث میشه که واسه سیستم های بزرگ و توزیع شده مناسب باشن چون میتونن به راحتی با روشای مقیاس پذیری افقی (اجازه بدین میگم چیه) گسترش پیدا کنن، با تکثیر دادهاشون تو سرورای مختلف، تاخیر پاسخ دهیشونو به کمترین حد برسونن و به دلیلی این کپی زیادی که از داده ها دارن، با down شدن یه سرور نگران از کار افتادن کل سیستم نباشن. (مقیاس پذیری افقی دیگه چیه؟ تو این برهه زمانی، وقتی یه اپلیکیشن یا وبسایت جدیدی میاد، به سرعت تعداد کاربراش میره بالا. این زمان سیستم باید بتونه اون حجم از بازدید و دیتا رو هندل کنه. این زمان بحث مقیاس پذیریا میاد وسط. تو مقیاس پذیری افقی به جای اینکه توان یه سیستم بره بالا، تعداد سیستم رو میبرن بالا. وقتی تعداد سیستم میره بالا، مهمترین دغدغه همزمانیشونه. یعنی یه کاری کنن که کاربر نفهمه داستان چیه! مجموعه سرورایی که در قالب یه سیستم میان همزمان کار میکنن میشن یه کلاستر ( یا همون خوشه). یه چیزیم که خوبه بدونین اینه که چجوری این ریکوئستا تقسیم میشه؟ چجوری تعادل برقرار میشه؟ این وسط یه سرور داریم، بهش میگن Load Balancer. این عمو میاد میگه هر ریکوئست بره سمت کدوم سرور.)

پایگاه داده کاساندرا رو با مجموعه‌ایی از نودها (Nodes) میشه شناخت. این نودها از طریق پروتکلی به اسم Gossip با هم ارتباط برقرار میکنن. پروتکل Gossip یا پروتکل شایعه (پروتکل یک کلاغ چهل کلاغ)، یک پروتکل ارتباطی همتا به همتاست (Peer-to-Peer) که توش گره‌ها به صورت دوره‌ایی، اطلاعات مربوط به وضعیت فعلی خودشون و سایر گره‌هایی که باهاشون در ارتباط هستن رو مبادله میکنن. این باعث میشه که همه گره‌ها از وضع همدیگه مطلع باشن.) ( معماری p2p، یه نوع معماری شبکست که در اون هر گره به عنوان یک همتا (peer) عمل میکنه (همتا به هر کامپیوتر، سرور یا دستگاهی اشاره داره که به صورت یه عضو مستقل تو شبکه عمل میکنه) و همه گره‌ها میتونن به صورت مستقیم و بدون نیاز به یه سرور مرکزی با هم ارتباط برقرار کنن (به این معماریا تو سیستم‌های توزیع شده که توش هیچ گره مرکزی یا مستری وجود نداره میگن Masterless). از اونجایی که همه گره‌ها، همتا هستن پس میتونن وظایف مختلفیم انجام بدن. از اونجایی که تو این شبکه‌ها هیچ وابستگی به یک گره مرکزی وجود نداره اگر یک یا چند گره دچار مشکل بشن، شبکه به کارش ادامه میده.

قدرت بیشتر، گره بیشتر

یه شعار جالبی کاساندرا داره! میگه: " قدرت بیشتر میخوای؟ گره بیشتری اضافه کن" این شعار خیلی تمیز و شسته رفته ماهیت مقیاس پذیری افقی کاساندرا رو بیان میکنه.
دیتابیس‌هایی مثل MySQL و Oracle برای افزایش ظرفیت ذخیره سازی، نیاز دارن CPU و RAM و این چیزا رو ببرن بالا. اینا همشون کلی هزینه داره! تهش بازم کلی محدودیت داریم. اما کاساندرای عزیز دل میگه واسه این کارا گره اضافه کن. خلاص!

تو کاساندرا داده‌ها به صورت خودکار توزیع میشن. حتما میگی چجوری؟ با تکنیک Partition بندی! هر نود یه مجموعه خاصی Token داره و تعیین میکنه چه داده‌هایی در اون نود ذخیره بشه. کاساندرا داده‌ها رو بر اساس Token Rangeتو کلاستر توزیع میکنه. حالا کی میاد این وظیفه رو گردن بگیره که دیتاها رو بین نودا تقسیم کنه؟ Partition Key . این آقا واسه تعیین محل دیتاها خیلی مهمه! وقتی داده‌ایی میاد تو کلاستر اولین گام اینه که یه تابع Hash روی partition Key اعمال بشه. خروجی این تابع هشه که میاد تعیین میکنه کدوم نود این دیتا رو گردن بگیره.

وقتی یه دیتای جدیدی میاد، Coordinator (یا همون نود هماهنگ کننده) وظیفه داره این داده رو به یک partition اختصاص بده. دقت کنید که هر نودی تو کلاستر میتونه Coordinator باشه و الزاما یک نود مشخص نیست! هر گرهی که اون لحظه دیتا رو بگیره میشه Coordinator! برای این داده جدید، Coordinator یه جستجو انجام میده تا نودی که اون دیتا توی محدودشه پیدا کنه. وقتی اون نود پیدا شد، دیتا فرستاده میشه اونجا! اون گره‌ایی که دیتا برای اونه اسمش Replica node عه! یه داده میتونه تو چندین نود کپی بشه. هر چی این کپی ها ( که بهش میگن Replication Factor) بیشتر باشه تحمل خطا میره بالاتر. امکان از دست دادن دیتا خیلی خیلی کم میشه و دسترسی به دیتا تو هر زمانی تقریبا امکان پذیر میشه!

چند تا کپی؟

یه چیزی بالاتر گفتم: Replication Factor!

مفهوم RF در کاساندرا بیان میکنه که چند کپی از داده باید تو دیتابیس باشه. اینکه میگیم کاساندرا distributed عه و روی این مسئله تاکید میکنیم وقتی محسوس میشه که ما چندین Replica داشته باشیم. این به سیستم کمک میکنه که وقتی یه نودی، هارد دیسکی یا امثالهم خراب شد، کل سیستم down نشه! Replication تعیین میکنه که دیتامون از بین نره. وقتی یه request ایی واسه یه دیتایی اومد، حتی اگه یکی از Replica ها down شده باشه، هنوز مابقی هستن! وقتی یه Replica در دسترس نباشه، Coordinator یه hint واسه دیتا نگه میداره. این hint به چه درد میخوره؟ وقتی یه Replica ایی down میشه، قرار نیست کلا بره پی کارش! بالاخره یه روزی بالا میاد! وقتی برگشت، با این hint میشه فهمید چه داده‌ایی باید براش ارسال بشه. جالبه بدونین که این کارا به صورت کاملا اتوماتیک انجام میشه. ( یه چیز جالبیم بگم بهتون! وقتی همه Replicaها در دسترس باشن، نیازی به استفاده از hint نیست! واسه همین هیچ hintایی ذخیره نمیشه! این باعث میشه سیستم بهینه عمل کنه و از منابع به بهترین شکل استفاده بشه.)

کاساندرای ناسازگار

از قضیه‌های مهمی که تو سیستم‌های توزیع شده وجود داره قضیه CAP عه. این تئوری میگه یه سیستم توزیع شده نمیتونه همزمان 3 ویژگی زیر رو با هم داشته باشه:

1. سازگاری (Consistency): وقتی داده‌ایی رو از سیستم میخونید، تمام گره‌های سیستم باید دیتای دقیقا یکسانی را برگردونن.
2. دسترس پذیری (Availability): سیستم همیشه در دسترسه
3. تحمل بخش (Partition Tolerance): سیستم تو هر شرایطی کارشو درست انجام بده حتی اگه بعضی از گره‌ها در دسترس نباشن

تئوری CAP میگه هر سیستم توزیع شده میتونه همزمان 2 تا از این ویژگی‌ها رو داشته باشه. کاساندرا مثالی از یک سیستم توزیع شده‌ی APعه (Availability و Partition Tolerance). این سیستم همیشه در دسترسه و در صورتی که بخشی از شبکه از دست بره باز هم میتونه به کارش ادامه بده اما سازگاری رو به طور کامل تضمین نمیکنه و یه سطح سازگاری محدود داره که بهش Eventual Consistency یا سازگاری نهایی میگن! این یعنی چی؟ یعنی وقتی یه داده جدید میاد و داره نوشته میشه، تا زمانی که این داده جدید به تمام Replicaها پخش نشده ممکنه گره‌ها دیتاهای مختلفی رو نشون بدن. اما کاری که میشه کرد اینه که سطح سازگاری رو برای هر عملیات خوندنی تنظیم کنیم. دو حالت معروف تنظیم سطح تو کاساندرا داریم: ONE و QUORUM.

تو سطح ONE فقط یه Replica به ریکوئست خوندن پاسخ میده. این سطح، سریعترین و پرسرعت ترین حالت ممکنه ولی ممکنه دیتایی که چند لحظه قبل نوشته شده رو برنگردونه!

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

QUORUM = (RF/2)+1

جمع کنیم بریم

خب اگه بخوایم یه جمع بندی کنیم گفتیم که کاساندرا یه پایگاه داده NoSQL توزیع شدست که واسه مدیریت داده‌های حجیم و توزیع شده طراحی شده. میتونه با استفاده از partitioning داده‌ها رو به صورت خودکار بین نودها توزیع کنه و با Replication Factor این اطمینان حاصل میشه که در صورت خرابی یک یا چند نود، سیستم همچنان در دسترس باشه. کاساندرا به عنوان یه سیستم AP هیشه در دسترسه ولی سطح سازگاریش رو به طور کامل تضمین نمیکنه. امیدوارم این پست تونسته باشه بهتون کمک کنه که با کاساندرا بیشتر آشنا بشین. خوشحال میشم که نظراتتونو با من به اشتراک بزارین :)