مقدمه ای بر کاساندرا

مقدمه ای بر کاساندرا, پیشرو وب, طراحی سایت در کرج, طراحی وب سایت در کرج, طراحی سایت

کاساندرا، فرزند دختر پادشاه شهر تروا بود که علاوه بر داشتن سیمایی زیبا، قدرت پیش‌بینی آینده را با جزئیاتی بسیار دقیق داشت، به‌طوری که به ندرت کسی حرف‌هایش را باور می‌کرد. او نابودی شهر تروا را پیش‌بینی کرده بود اما توان جلوگیری از آن را نداشت. هکتور، شاهزاده‌ای که توسط آشیل در جنگ تروا کشته شد، برادر کاساندرا بود. در سال ۲۰۰۸ دو کارمند سابق آمازون و مایکروسافت که در یک شبکه اجتماعى بزرگ مشغول به کار بودند، یک پایگاه داده جدید NoSQL را ایجاد کردند که کاساندرا نامیده شد. این پایگاه داده از آن جهت اهمیت دارد که از یک معماری درونی بسیار قوی برای حل معضلاتی بسیار قدیمی سود می برد و به شکل مناسبی پیاده‌سازی شده است. این امر، علاوه بر پیشرو کردن کاساندرا در زمینه پایگاه‌های داده NoSQL، آن را به یکی از نمونه های موفق پروژه‌های اپن‌سورس تبدیل کرده است.
 
کاساندرا شایستگی‌های بسیاری همچون ماندگاری طولانی، مقیاس‌پذیری بسیار بالا و ثبات تنظیم‌پذیر دارد و به همین دلیل، توسعه‌دهندگان بزرگی از طرف شرکت‌های معتبر در توسعه کد آن سهیم هستند. کاساندرا امروزه به پیشتازی بلامنازع در زمینه سرعت عملکرد در پردازش تراکنش‌ها تبدیل شده است و آینده درخشانی برای آن پیش‌بینی می‌شود. نوشتار حاضر مفاهیم کلی مطرح در کاساندرا، روش کار و نحوه برقراری ارتباط با آن از طریق برنامه‌های کاربردی NET. را مرور خواهد کرد.
 
کاساندرا در 100 کلمه
پروژه کاساندرا در آغاز توسط یک شبکه اجتماعی معروف برای پاسخ‌گویی به نیازهای روزافزون آن شبکه درتعاملات داده‌ای بسیار بزرگ ساخته شد و بعدها، توسعه و نگه‌داری آن به آپاچی محول‌شد. کاساندرا یک پایگاه‌داده اپن‌سورس است که بر‌اساس طرح Amazon Dynamo و مدل داده‌ای Bigtable (که از طرف گوگل ارائه شده) طراحی و توسعه داده‌شده است و قابلیت‌های کلیدی مانند توزیع یافتگی، تمرکز زدایی، مقیاس‌پذیری، دسترس‌پذیری بالا، مقاومت در مقابل خطا، ثبات تنظیم‌پذیر و ستون‌گرایی مدل داده‌ای در توسعه آن همواره مورد توجه بوده است.
 
به یقین، خلاصه‌کردن تمام قابلیت‌های کاساندرا در چند کلمه­ ساده، گویای واقعیت‌ها و ایده‌های موجود در پس توسعه چنین پایگاه داده‌ای‌ نیست، اما سعی شده تا در مقاله‌های قبلی به گوشه‌ای از دلایل و مزایای این معماری جدید برای پایگاه‌های داده اشاره شود. به همین دلیل، بیش از این به مزایای عملیاتی و مباحث ساختاری و تئوریک مرتبط با کاساندرا نمی‌پردازیم و به بحث و بررسی درباره مدل داده‌ای آن، چگونگی نصب و راه‌اندازی آن و روش کار با آن به‌عنوان پایگاه داده از طریق برنامه‌های کاربردی خواهیم پرداخت.
 
مدل داده‌ای
تا چند سال پیش، تقریباً تمام توسعه‌دهندگان برنامه‌هایی که به گونه‌ای با داده‌ها و پایگاه‌های داده‌ سروکار داشتند، تنها مدل داده‌ای که برای طراحی در اختیار داشتند، مدل سنتی جدول، ستون و سطری بود که میراث حکمرانی چندین و چند ساله مدل پایگاه‌های داده رابطه‌ای‌بوده است. هم‌اکنون نیز بسیاری می‌پندارند همچنان تنها مدل قابل استفاده برای پیاده‌سازی پایگاه داده، همین مدل سنتی داده‌ای است. اما دنیا دیگر تغییر کرده و بر‌اساس چالش‌های موجود بر سر راه مدل سنتی، مدل‌های جدیدی معرفی شده‌اند که در بسیاری از زمینه‌ها و در مواجهه با بسیاری از چالش‌ها، شایستگی‌های بسیاری دارند. برای آموختن کاساندرا، بهتر است برای چند لحظه، تمام آنچه را که درباره پایگاه‌های داده‌ می‌دانید، به فراموشی بسپارید. بسیاری از مفاهیم موجود در مدل داده کاساندرا مانند فضای نام یا keyspace، برای توسعه‌دهندگان قدیمی پایگاه داده، مفاهیمی جدید و ناآشنا بوده و بسیاری دیگر، مانند ستون یا column معانی متفاوتی با مشابه‌های قدیمی خود دارند. همچنین، با این‌که کاساندرا بر‌اساس مفاهیم بنیادی داینامو و Bigtable ساخته شده است، اما مدل داده‌ای و مفاهیم مرتبط منحصر به فردی برای خود دارد.
 
برای آشنایی با مدل داده‌ای کاساندرا، بهتر است از مفاهیم ساده و ابتدایی برای ذخیره‌سازی داده‌ها شروع کنیم. ساده‌ترین حالت ذخیره‌سازی داده‌ای را که با استفاده از یک آرایه یا لیست قابل پیاده‌سازی است، در نظر بگیرید. شکل ۱ نمایی از این مدل را ارائه می‌کند. در این حالت، برای فهمیدن این‌که هر عنصر ذخیره کننده چیست، باید اسناد و دانشی درباره آن به‌صورت خارجی نگه‌داری شود. همچنین، برای این‌که اندازه­ یک شکل کل مجموعه داده‌ای حفظ شود، باید مقادیر خالی را با مقادیری مشخص (همانند null) پر کرد. یک آرایه، به‌طور ساده ساختار داده‌ای سودمندی است، اما از لحاظ معنایی، قوی نیست (شکل‌‌۱).
 

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

شکل ۲- اضافه کردن بعد دوم به آرایه، آن را با مفهوم‌تر ‌می‌کند.

 
با این حال، با این ساختار تنها می‌توانیم به یک مفهوم (مثلاً یک شخص) اشاره‌کنیم و راهی برای ذخیره‌سازی داده‌های چندگانه (مثلاً اشخاص مختلف) در یک ساختار منفرد را در اختیار نخواهیم داشت. به بیان دیگر، ما به ستون‌هایی احتیاج داریم که در آن‌ها نیاز نباشد تا نام آن‌ها همواره تکرار شود و همچنین، به مفهومی نیاز داریم تا بتوانیم گروهی از ستون‌ها را در یک قالب مفهومی دسته‌بندی‌کنیم. راه‌حل ساده برای اضافه‌کردن مقادیر چندگانه به ستون‌ها، سطرها هستند که می‌توانند یک شناسه انحصاری به نام کلید سطر یا Row Key را نیز در اختیار داشته باشند. کاساندرا، مفهومی به‌نام Column Family را معرفی‌کرده که برای تقسیم‌بندی گروهی از ستون‌های مرتبط با یکدیگر در‌نظر گرفته‌شده است و مثالی از آن یک Column Family برای مشخصات اشخاص است. در اصل، مفهوم Column Family در کاساندرا به نوعی شبیه به مفهوم جدول در مدل سنتی رابطه‌ای است.
 
با کنار هم قراردادن مباحث بالا، ساختار داده‌ای کلی کاساندرا از این قرار خواهد بود: ستون‌ها که جفت‌های Name/Value هستند و Column Family‌ها که حاوی سطرهایی هستند که مجموعه‌های ستونی مشابه، اما نه دقیقاً یکسان با تعداد ستون‌های موجود در سیستم، هستند. نکته مهم دیگری که در کاساندرا مطرح است آن است که بر‌خلاف پایگاه‌های داده‌ سنتی که در آن‌ها نام ستون‌ها باید تنها یک متغیر رشته‌ای باشد، نام ستون‌ها و مقادیر ذخیره‌شده در سطرهای مرتبط می‌توانند علاوه بر نوع رشته‌ای، مقادیر Integer، UUID یا هر نوع آرایه بایتی دیگری نیز باشند. این قابلیت، امکان ذخیره‌سازی داده‌های ارزشمند در کلیدها (خود ستون‌ها) را علاوه بر مقادیر آن‌ها (سطرها) فراهم می‌سازد که کاربردهای پیشرفته‌ای ، به خصوص در زمینه ایندکس‌کردن دارد.
 

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

 
با استفاده از مدل داده‌ای کاساندرا دیگر نیاز نیست تا برای ذخیره هر مدخل جدید داده‌ای، تمام مقادیر مرتبط با ستون‌ها را دانسته یااز null برای پر‌کردن مقادیر ناآشنای آن‌ها استفاده کنیم. در کاساندرا به سادگی می‌توانیم مقادیری را که نمی‌خواهیم، ذخیره نکنیم و در زمینه سرعت عملکرد، فضای ذخیره‌سازی و قابلیت انعطاف پایگاه داده به نتایج مثبتی برسیم. با این اوصاف، مدل داده‌ای منطبق با آنچه در کاساندرا استفاده می‌شود را می‌توان همانند شکل‌۳ در نظر گرفت(شکل‌۳).
 

شکل ۳- نمایی ساده از مدل داده‌ای کاساندرا

 
برای آشنایی بیشتر با مفهوم مطرح در شکل ۳‌، محتوای چنین پایگاه داده‌ای را می‌توان با روش JSON با مثالی به‌صورت زیر نیز بیان کرد:
 

Editors: ColumnFamily1 - نام جدول
Erfan Nazari: RowKey - کلید سطر
Email: Nazari@shabakeh-mag.com ColumnName:Value - مقدار ستون
Interests: open-source ColumnName:Value - مقدار ستون
Parham Izadpanah: RowKey - کلید سطر
Email: izadpanah@shabakeh-mag.com ColumnName:Value - مقدار ستون
Directors: ColumnFamily2 - نام جدول
Parham Izadpanah: RowKey - کلید سطر
Tel: +982166905080 ColumnName:Value - مقدار ستون

 
همان‌طور که در بالا نیز می‌بینید، سطرها الزاماً حاوی مقادیر برای ستون‌های مشابه‌نیستند و در Column Family‌های دیگر، می‌توان مجموعه ستون‌های دیگری را برای داده‌های مشابه داشت. با این حال، واحدهای دیگری نیز برای گروه‌بندی ساختار پایگاه داده وجود دارند که با نام Super Column شناخته می‌شوند. این اَبَر‌ستون‌ها، مجموعه‌ای از ستون‌های مرتبط را در یک Column Family شامل می‌شوند که می‌توان از آن‌ها به نقشه­ نقشه‌ها تعبیر کرد. شکل ۴ نمایی از مدل داده‌ای کامل کاساندرا را نشان می‌دهد (شکل‌۴). به یاد داشته باشید که ستون‌ها در کاساندرا در اصل یک بعد دیگر با نام timestamp نیز دارند که ذخیره‌کننده آخرین به روزرسانی‌داده‌های درون ستون است. این برچسب زمانی، مقداری خودکار و یک متادیتا نیست، بلکه مقداری است که باید توسط کلاینت فراهم شود و قابلیت پرس و‌جو نیز ندارد، بلکه برای جلوگیری از اختلاط داده‌ها مورد استفاده قرار‌می‌گیرد. توجه کنید، سطرها برچسب زمانی ندارند، بلکه تنها ستون‌های منفرد برچسب زمانی را ذخیره می‌کنند.
 

شکل ۴- شکل کامل مدل داده‌ای کاساندرا

 
مفاهیم بنیادی
همان‌طور که قبلاً نیز گفته شده، کاساندرا بهترین راه حل برای اجرا روی مجموعه‌ای از سرورها است و شاید عملکرد آن روی یک سرور منفرد، چندان رضایت بخش نباشد. بنابراین، ساختار کلی کاساندرا از بیرون، یک کلاستر (و در بعضی مواقع حلقه) نامیده‌می‌شود. عبارت حلقه در این پایگاه‌داده به این دلیل استفاده می‌شود که کاساندرا داده‌ها را در میان نودهای با آرایش حلقوی مدیریت‌می‌کند. واحد سازنده کوچک‌تر از کلاستر، یک نود (Node) یا به زبان ساده‌تر یک نسخه از کاساندرا روی یک ماشین منفرد است که وظیفه نگه‌داری از قسمتی از داده‌ها را بر‌عهده دارد. در صورتی که هر نود از کار بیافتد، نودهای جایگزینی برای پاسخ‌دهی به پرس‌و‌جوها وجود‌ خواهند داشت. تعداد نودهای جایگزین موجود برای هر قسمت از داده‌ها را فاکتور جایگزینی می‌نامند.
  
هر کلاستر، نگه‌دارنده‌ (یک یا چند) مفهوم کلی و انتزاعی با نام Keyspace است که بزرگ‌ترین مفهوم داده‌ای در کاساندرا به شمار می‌آید و معادل مفهوم Database در مدل RDBMS است. هر فضای کلیدی خصوصیات مختلفی (مانند فاکتور جایگزینی، راهبرد جایگزینی، Column Family‌ها و…) دارد که چگونگی رفتار آن را در کل کلاستر تعیین می‌کنند. مفهوم بعدی، Column Family‌ها هستند که نگه‌دارنده مجموعه مرتبی از سطرهای داده‌ای است و هر کدام از آن‌ها، حاوی مجموعه مرتبی از ستون‌های داده‌ای هستند. مفهوم Column Family را می‌توان به نوعی معادل جدول‌ها در مدل رابطه‌ای به شمار آورد، اما توجه کنید که با جدول‌ها بسیار متفاوت هستند. با توجه به مفهوم کلید سطر و مفهوم ستون که در بخش قبل نیز مطرح شدند، به ساختار ۴ بعدی معمول در کاساندرا خواهیم رسید که نقشی اساسی را در دسترسی به داده‌ها ایفا می‌کند:
 
[Keyspace][ColumnFamily][Key][Column]
 
برای روشن شدن مطلب، می‌توانیم یک مثال برای ذخیره داده‌ها در کاساندرا مطرح کنیم. برای این منظور، یک Column Family با نام Hotel برای ذخیره‌سازی داده‌های چند هتل، مطابق نوشتار JSON ارائه شده در زیر را در نظر می‌گیریم:
 

Hotel {
key: THE_043 { name: Espinas, phone: 021-66352565,
address: Keshavarz Blvd., city: Tehran, state: Tehran}
key: THC_011 { name: Evin, phone: 021-22668562,
address: Chamran Highway, city: Tehran, state: Tehran}
key: HRD_021 { name: Dariush, phone: 0764-4223659,
address: Dariush Sq. , city: Kish, state: Hormozgan}
key: GIH_042 { name: Height, phone: 0131-5262266,
address: Namak Abrood, city: Chaloos, state: Gilan}
}

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

=> (column=state, value=Hormozgan, timestamp=3894166157031651)
=> (column=phone, value=0764-4223659, timestamp=3894166157031651)
=> (column=name, value=Dariush, timestamp=3894166157031651)
=> (column=city, value=Kish, timestamp=3894166157031651)
=> (column=address, value= Dariush Sq., timestamp=3894166157031651)
Returned 5 results.

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

لینک منبع