مفاهیم Cassandra

در افسانه‌های یونان، Cassandra دختر شاه پِریام و ملکه هِکوبا از خانواده سلطنتی تروا بود. او به حدی زیبا بود که آپولو قدرت دیدن آینده را به او عطا کرد. اما زمانی که او این لطف عاشقانه را نپذیرفت، آپولو او را نفرین کرد تا هرچه در آینده رخ خواهد داد را به دقت پیش‌بینی کند، اما هیچ کس حرف‌های او را باور نکند. او ویرانی شهرش تروا را دید، اما توان مقابله با این اتفاق را نداشت… نام این پایگاه‌داده توزیع‌شده، از روی همین افسانه انتخاب شده است. مراحل اولیه شکل‌گیری آن در ژانویه ۲۰۰۹ طی شد. از خصوصیات کلیدی این پایگاه‌داده می‌توان به عدم تمرکز، الاستیک بودن، قابلیت تحمل خطا، ثبات قابل تنظیم، بهینه‌سازی و دسترس‌پذیری بالا اشاره کرد. همچنین این پایگاه‌داده از ابتدا به گونه‌ای طراحی شده است که به شدت مقیاس‌پذیر بوده و به‌سادگی روی سرورهای معمولی که در دیتا‌سنترهای مختلف پراکنده شده‌اند، توزیع شود. شرکت‌هایی مانند Digg، فیس‌بوک، Cloudkick، سیسکو، آی‌بی‌ام، Reddit، Rackspace، SimpleGeo، Ooyala و OpenX از این پایگاه‌داده استفاده می‌کنند. پروژه Cassandra در آغاز توسط یک شبکه اجتماعی معروف برای پاسخ‌گویی به نیازهای روزافزون آن شبکه درتعاملات داده‌ای بسیار بزرگ ساخته شد و بعدها، توسعه و نگه‌داری آن به آپاچی محول‌شد. Cassandra یک پایگاه‌داده اپن‌سورس است که بر‌اساس طرح Amazon Dynamo و مدل داده‌ای Bigtable (که از طرف گوگل ارائه شده) طراحی و توسعه داده‌شده است و قابلیت‌های کلیدی مانند توزیع یافتگی، تمرکز زدایی، مقیاس‌پذیری، دسترس‌پذیری بالا، مقاومت در مقابل خطا، ثبات تنظیم‌پذیر و ستون‌گرایی مدل داده‌ای در توسعه آن همواره مورد توجه بوده است.
به یقین، خلاصه‌کردن تمام قابلیت‌های Cassandra در چند کلمه­ ساده، گویای واقعیت‌ها و ایده‌های موجود در پس توسعه چنین پایگاه داده‌ای‌ نیست.

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

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

 

شکل ۱- ساختار ساده یک آرایه

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

2

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

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

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

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

cassandra_column_family

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

مفاهیم بنیادی

همان‌طور که قبلاً نیز گفته شده، کاساندرا بهترین راه حل برای اجرا روی مجموعه‌ای از سرورها است و شاید عملکرد آن روی یک سرور منفرد، چندان رضایت بخش نباشد. بنابراین، ساختار کلی کاساندرا از بیرون، یک کلاستر (و در بعضی مواقع حلقه) نامیده‌می‌شود. عبارت حلقه در این پایگاه‌داده به این دلیل استفاده می‌شود که کاساندرا داده‌ها را در میان نودهای با آرایش حلقوی مدیریت‌می‌کند. واحد سازنده کوچک‌تر از کلاستر، یک نود (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=۳۸۹۴۱۶۶۱۵۷۰۳۱۶۵۱)
=> (column=phone, value=0764-۴۲۲۳۶۵۹, timestamp=۳۸۹۴۱۶۶۱۵۷۰۳۱۶۵۱)
=> (column=name, value=Dariush, timestamp=۳۸۹۴۱۶۶۱۵۷۰۳۱۶۵۱)
=> (column=city, value=Kish, timestamp=۳۸۹۴۱۶۶۱۵۷۰۳۱۶۵۱)
=> (column=address, value= Dariush Sq., timestamp=۳۸۹۴۱۶۶۱۵۷۰۳۱۶۵۱)
Returned ۵ results.

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

برای آشنای با نحوه نصب و را اندازی Cassandra اینجا کلیک کنید.

منبع:http://www.bigdata.ir

سایت اوراکل فارسی راه اندازی شد.برای مشاهده سایت اینجا کلیک نمایید.

محسن صفابخش

محسن صفابخش

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

More Posts - Website

Follow Me:
LinkedInGoogle PlusYouTube

2 thoughts on “مفاهیم Cassandra

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *