محمد حسین حاجی وندی
محمد حسین حاجی وندی
خواندن ۵ دقیقه·۲ سال پیش

10 اشتباه رایج در استفاده از Apache Cassandra

آپاچی کسندرا (Apache Cassandra) یک سیستم مدیریت پایگاه داده ی NoSQL متن باز است با ویژگی های مهمی از قبیل مقیاس پذیری بالا، سرعت نوشتن زیاد، سازگاری قابل تنظیم (configurable consistency) و خطاپذیر (fault tolerant) که میتواند روی هزاران ماشین معمولی اجرا شود و ده ها پتابایت دیتا را نگهداری کند.من حدود 3 سالی می شود که با پایگاه داده ی کسندرا سر و کار دارم و وقتی این مقاله را خواندم با خودم گفتم که خلاصه ی آن را با شما به اشتراک بگذارم.

لوگو کسندرا به همراه دلایل محبوبیت!
لوگو کسندرا به همراه دلایل محبوبیت!


اشتباه #1: چون کسندرا برای بقیه کار می کند پس برای من هم کار می کند!

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

اشتباه #2: پیاده سازی را از روی مدل داده (data model) شروع کنیم

اینکه پیاده سازی را از روی مدل داده شروع کنیم یک روش عمومی برای پیاده سازی پایگاه داده برای انواع سامانه ها است اما در مورد کسندرا اوضاع کمی متفاوت است و همیشه برای ساخت مدل داده برای کسندرا باید از پرس و جو (query) شروع کنید.

اشتباه #3: بر اساس هر چیزی که توی کسندرا ذخیره کردیم میتونیم جست و جو کنیم.

خیر. این هم یک اشتباه رایج است. درسته که می تونیم برای جدول کسندرا ستون های مختلف تعریف کنیم اما پرس و جو ها باید براساس کلید پارتیشن (partition key) و کلید کلاستر (cluster key) باشند و اگرستونی کلید پارتیشن نباشد و فقط کلید کلاستر نمیتواند به تنهایی به عنوان بخش شرطی پرس و جو استفاده شود و ستونی که کلید پارتیشن یا کلاستر نباشد نمی تواند در بخش شرطی پرس و جو بیاید.

اشتباه #4: اضافه کردن ستون جدید که براساس ترکیبی از ستون های موجود ساخته شده باشد.

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

اشتباه #5: انتخاب سخت افزار اشتباه

با توجه به اینکه کسندرا برای عملیات نوشتن و خواندن سریع بهینه شده است استفاده از دیسک کند باعث کاهش کارایی می شود. همچنین با توجه به اینکه عملیات کامپکشن (Compaction) (تجمیع sstable ها و پاک کردن کلید های تکراری) نیازمند منابع پردازشی و حافظه است استفاده از CPU های ضعیف یا RAM کم باعث کندی کامپکشن می شود. از طرف دیگر تخصیص حجم زیاد RAM باعث افزایش زمان گاربج کالکشن (garbage collection) می شود. بنابراین پیشنهاد می شود که منابع پردازشی بین گره های بیشتر توزیع شده باشد تا اینکه تعداد گره ها کم باشد با CPU و RAM زیاد.

اشتباه #6: عدم توجه به مانیتورینگ و نگهداری سامانه

کسندرا به نداشتن نقطه ی شکست واحد (single point of failure) معروف است یعنی یعنی مثلا اگر فاکتور رونوشت (replication factor) برابر 3 باشد و تعداد گره ها 4 تا باشد با پایین آمدن یک گره مشکلی برای کلاستر کسندرا ایجاد نمی شود و کسندرا با فراهم کردن مکانیزم هایی پس از بالا آمدن گره مذکور داده های مربوط به آن گره را روی آن می نویسد. اما نمی توان بدون داشتن مانیتورینگ و پایش به عملکرد آن اطمینان کرد. مخصوصا هنگام پاک کردن داده باید حواسمان به زیاد شدن زامبی ها باشد(منظور از زامبی داده هایی است که انتظار داشتیم پاک شده باشند اما نشدند!) و حداقل هر 7 روز یکبار عملیات تعمیر (repair) را انجام دهیم! (بعدا در یک پست جداگانه این اتفاق را با شرح جزییات بررسی میکنیم!)

اشتباه #7: استفاده از کسندرا به عنوان صف

اگر نیازمندی شما این است که چندین task با کار معین ولی کوتاه داشته باشید و ردیف ها (row) در پایگاه داده درج شوند و سپس پاک شوند و کسندرا برای شما مناسب نیست چون داده های کسندرا در sstable ذخیره می شود و sstable فایل های تغییر ناپذیر است و پاک کردن از sstable در فرآیند compaction اتفاق می افتد. انجام شدن عملیات کامپکشن هم به CPU و RAM وابسته است و ممکن است زمان طولانی از سیستم بگیرد. پس از کامپکشن هم تضمینی وجود ندارد که ردیف های مورد نظر پاک شده باشد.

اشتباه #8: کسندرا به عنوان موتور جستجو

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

اشتباه #9: استفاده از load balancer خارجی

معماری کسندرا به گونه ای است که بار را بین گره های مختلف تقسیم می کند و استفاده از متوازن کننده ی بار (load balancer) خارجی ریسک وحود نقطه ی شکست واحد را به همراه دارد.

اشتباه #10: استفاده از کسندرا به عنوان filestore

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


جمع بندی

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


امیدوارم که این مطلب به کارتون بیاد و خوشحال می شوم نظرات و پیشنهادات یا اصلاحات کم و کاستی های این مطلب رو بهم زیر همین پست یا به آدرس ایمیلم mhhajivandy@gmail.com اطلاع بدین.

مهندسی دادهnosql
مهندس نرم افزار
شاید از این پست‌ها خوشتان بیاید