Cassandra مدیریت‌شده، برای نوشتن پرحجم

Cassandra وقتی بهترین نتیجه را می‌دهد که الگوی دسترسی به داده از قبل روشن باشد و حجم نوشتن زیاد باشد. چند نمونه از کارهایی که مدل دادهٔ آن برایشان ساخته شده است:

اگر بیشتر به join، تراکنش چندجدولی یا گزارش‌های موردی نیاز دارید، Cassandra انتخاب درستی نیست و PostgreSQL مدیریت‌شده برای همین کار ساخته شده است. برای تحلیل‌های تجمیعی سنگین روی میلیون‌ها ردیف هم ClickHouse گزینهٔ طبیعی‌تری است.

بزرگ‌ترین تفاوت Cassandra با دیتابیس‌های رابطه‌ای در طراحی جدول است. در PostgreSQL یا MySQL ابتدا موجودیت‌ها را نرمال می‌کنید و بعد هر queryای که لازم شد می‌نویسید. در Cassandra برعکس است: ابتدا فهرست query‌های اپلیکیشن را می‌نویسید و برای هر کدام جدولی می‌سازید که دقیقاً همان query را با یک خواندن پاسخ دهد. تکرار داده در چند جدول اینجا یک الگوی عادی است، نه خطای طراحی.

کلید اصلی دو بخش دارد. partition key تعیین می‌کند هر ردیف کجا ذخیره شود و همهٔ ردیف‌های یک پارتیشن کنار هم نگه داشته می‌شوند. clustering column‌ها ترتیب ردیف‌ها را داخل پارتیشن مشخص می‌کنند؛ مثلاً رویدادهای یک کاربر به ترتیب نزولی زمان. queryای که partition key را مشخص نکند، یا رد می‌شود یا به ALLOW FILTERING نیاز دارد که روی دادهٔ بزرگ کند است.

یک قاعدهٔ عملی: پارتیشن‌ها را محدود نگه دارید. اگر همهٔ رویدادهای یک کاربر پرکار را در یک پارتیشن بریزید، پارتیشن بی‌انتها بزرگ می‌شود؛ افزودن بازهٔ زمانی مثل روز یا ماه به partition key این مشکل را حل می‌کند. Cassandra 5.0 همچنین ایندکس ثانویهٔ SAI را دارد که برای جست‌وجو روی ستون‌های غیرکلیدی انعطاف بیشتری از ایندکس‌های قدیمی می‌دهد.

تنظیماتی را که هنگام نصب اعمال می‌شود شفاف می‌نویسیم تا پیش از برنامه‌ریزی بدانید با چه چیزی کار خواهید کرد. سایر تنظیمات همان مقادیر پیش‌فرض بستهٔ رسمی Cassandra است.

هزینه مثل بقیهٔ سرویس‌های ایران‌کلاد ساعتی است و از کیف پول کسر می‌شود: قیمت سرور پشتیبان به‌اضافهٔ کارمزد مدیریت. اعداد جدول از همان منبعی خوانده می‌شوند که سامانهٔ صورت‌حساب استفاده می‌کند و تعرفهٔ تعریف‌شده برای زمان راه‌اندازی است؛ تا روز باز شدن سفارش ممکن است تغییر کند و مبلغ نهایی همیشه پیش از ساخت در پنل نمایش داده می‌شود.

اولین ساعت هنگام ساخت کسر می‌شود و با حذف نمونه، محاسبه متوقف می‌شود؛ قرارداد ماهانه یا پیش‌پرداخت وجود ندارد. معادل ماهانه بر مبنای ۷۳۰ ساعت حساب شده است. برای مقایسه با سایر سرویس‌ها صفحهٔ قیمت‌گذاری را ببینید یا هزینهٔ کل زیرساخت پروژه را با ماشین‌حساب هزینه تخمین بزنید.

در Cassandra حافظه دو مصرف اصلی دارد: heap مربوط به Java و کش سیستم‌عامل برای فایل‌های SSTable. روی اندازهٔ standard با دو گیگابایت RAM‏، Cassandra اجرا می‌شود و برای توسعه، محیط staging و بارهای سبک تولیدی کافی است، اما فضای زیادی برای کش باقی نمی‌ماند و خواندن‌های تصادفی بیشتر به دیسک می‌رسند.

اگر داده‌تان چند ده گیگابایت است، جدول‌های زیادی دارید یا نرخ نوشتن پیوسته بالاست، plus با چهار گیگابایت RAM و ۸۰ گیگابایت دیسک انتخاب امن‌تری است. Cassandra برای compaction به فضای خالی دیسک نیاز دارد؛ توصیه می‌کنیم حجم داده از حدود نیمی از دیسک بیشتر نشود تا compaction با کمبود فضا روبه‌رو نشود.

تغییر اندازهٔ یک نمونهٔ موجود در فاز نخست پیش‌بینی نشده است. پس اگر بین دو اندازه مردد هستید، بر اساس رشد داده‌ای که در شش ماه آینده انتظار دارید تصمیم بگیرید، نه حجم امروز.

پاسخ به این بستگی دارد که replication و تحمل خرابی نود را از روز اول لازم دارید یا نه. این جدول تفاوت دو مسیر را نشان می‌دهد.

برای خوشهٔ سه‌نودی، سه سرور ابری با منابع یکسان کافی است تا با replication_factor برابر سه، از دست رفتن یک نود به از دست رفتن داده نینجامد. اگر منابع اختصاصی و جداسازی کامل سخت‌افزار می‌خواهید، کلاستر اختصاصی را هم بررسی کنید.

وقتی سفارش Cassandra باز شود، کل مسیر از پنل انجام می‌شود و به دسترسی سیستم‌عامل نیازی ندارید:

احراز هویت با PasswordAuthenticator از لحظهٔ نصب فعال است و رمز پیش‌فرضی که بستهٔ Cassandra با آن نصب می‌شود، بلافاصله با یک رمز تصادفی ۲۴ کاراکتری جایگزین می‌شود. این رمز در پنل رمزنگاری‌شده نگه‌داری می‌شود و فقط از طریق فایل اطلاعات اتصال در حساب خودتان قابل دریافت است.

چون CassandraAuthorizer فعال است، می‌توانید برای هر اپلیکیشن نقش جدا بسازید: با CREATE ROLE یک نقش با LOGIN و رمز تعریف کنید و با GRANT فقط SELECT و MODIFY را روی keyspace همان اپلیکیشن به آن بدهید. کاربر مدیر را برای کارهای مدیریتی نگه دارید و هرگز در کد اپلیکیشن قرار ندهید.

پورت ۹۰۴۲ برای اتصال از بیرون باز است و TLS روی آن به‌صورت پیش‌فرض فعال نیست؛ پس اطلاعات اتصال را مثل یک رمز عبور نگه دارید و رمز نقش‌ها را طولانی و تصادفی انتخاب کنید. برای ساخت رمز قوی از ابزار ساخت رمز عبور و برای اطمینان از دسترس‌پذیری پورت از شبکهٔ خودتان از بررسی پورت استفاده کنید.

برای پایگاه‌های دادهٔ تحلیلی، از جمله Cassandra، بکاپ خودکار در فاز نخست ارائه نمی‌شود. این را صریح می‌گوییم چون روی تصمیم شما اثر دارد: اگر داده‌ای در این نمونه نگه می‌دارید که بازسازی‌اش ممکن نیست، باید برنامهٔ نسخهٔ پشتیبان خودتان را داشته باشید.

ساده‌ترین روش برای جدول‌های کوچک و متوسط، دستور COPY TO در cqlsh است که محتوای هر جدول را به فایل CSV روی سیستم شما می‌ریزد. ساختار keyspace و جدول‌ها را هم با DESCRIBE KEYSPACE ذخیره کنید تا بازسازی کامل ممکن باشد. برای حجم‌های بزرگ‌تر، ابزار DSBulk همین کار را موازی و سریع‌تر انجام می‌دهد.

خروجی‌ها را جایی جدا از خود نمونه نگه دارید؛ فضای ذخیره‌سازی ابری برای این کار مناسب است. اگر داده از منبع دیگری مثل لاگ اپلیکیشن یا صف رویداد قابل بازسازی است، همان منبع را هم بخشی از برنامهٔ بازیابی بدانید.

اگر امروز Cassandra را روی سرور خودتان یا جای دیگری اجرا می‌کنید، انتقال در دو مرحله انجام می‌شود. اول ساختار: خروجی DESCRIBE KEYSPACE را از مبدأ بگیرید، در تعریف keyspace استراتژی replication را به SimpleStrategy با ضریب ۱ تغییر دهید و آن را روی نمونهٔ جدید اجرا کنید. دوم داده: با COPY TO از مبدأ خروجی بگیرید و با COPY FROM در مقصد بارگذاری کنید، یا برای حجم بالا از DSBulk کمک بگیرید.

اگر مبدأ نسخهٔ ۳ یا ۴ است، پیش از انتقال نوع داده‌ها و قابلیت‌های حذف‌شده را بررسی کنید. انتقال از مسیر CSV به فرمت فایل‌های داخلی Cassandra وابسته نیست و برای همین بین نسخه‌های مختلف مطمئن‌تر است. در طول انتقال، نوشتن روی مبدأ را متوقف کنید یا برنامه‌ای برای همگام‌سازی ردیف‌های تازه داشته باشید.

اگر هنوز بین Cassandra و یک دیتابیس سندمحور مردد هستید، MongoDB مدیریت‌شده همین حالا فعال است و برای داده‌هایی با ساختار متغیر و query‌های انعطاف‌پذیرتر مناسب‌تر است.

نمونهٔ Cassandra تک‌نودی است؛ بنابراین replication بین نودها، تحمل خرابی یک نود و پخش داده بین چند مرکز داده که Cassandra به آن معروف است، در این سرویس وجود ندارد. اگر سرور میزبان برای نگه‌داری یا به‌دلیل خرابی از دسترس خارج شود، دیتابیس هم تا بازگشت آن در دسترس نیست.

به سیستم‌عامل و ابزارهایی مثل nodetool دسترسی ندارید، بکاپ خودکار ارائه نمی‌شود و TLS روی پورت CQL پیش‌فرض فعال نیست. تنها نسخهٔ قابل انتخاب ۵.۰ است و اندازهٔ mini به دلیل نیاز حافظهٔ Java ارائه نمی‌شود. برای ذخیرهٔ موقت و بسیار سریع کلید-مقدار، Redis مدیریت‌شده گزینهٔ سبک‌تری است.