نحوه اتصال به کاساندرا با جاوا (قسمت اول آشنایی با راه اندازها)

در این بخش، نحوه اتصال به کاساندرا با جاوا بررسی خواهد شد. ابتدا به نحوه ی عملکرد دایور ها یا راه انداز کاساندرا پرداخته خواهد شد و در بخش بعدی مطلب یک مثال کاربردی از اتصال زبان برنامه نویسی جاوا به کاساندرا ارائه می شود. در انتهای مطلب هم فایل مثال مذکور که با intellj idea توسعه داده شده است برای استفاده خوانندگان محترم ضمیمه میشود.

درایور های کاساندرا، جهت ارتباط با خوشه پردازشی کاساندرا

راه­ انداز یا درایور، جزئیات و پیچیدگی­ های ارتباطات سطح پایین با پایگاه داده را از بین می­برد و سبب می­شود تا توسعه­ دهنده، تمرکز خود را فقط بر منطق کار اصلی مورد نظر حفظ کند. درایور­های پایگاه ­های داده رابطه­ ای در واقع، واسط­ه ای [1] JDBC را پیاده ­سازی می­کنند و استفاده از آن­ها متداول و بی دردسر است. اما راه­ اندازه پایگاه داده کاساندرا، متفاوت از راه ­انداز پایگاه­ های داده رابطه ­ای هستند و همچنین مفاهیم و ویژگی ­های مهمی را دارا می­ باشند.

 

درایورهای رسمی کاساندرا برای زبان ­های برنامه ­نویسی (C/C++، C#، Java، Node.js، PHP، Python و Ruby) ارایه می­شود. همچنین، درایورهای دیگری نیز در جامعه برنامه نویسی بصورت متن باز ارایه شده است. اولین مساله در انتخاب راه­ انداز، زبان برنامه نویسی مورد استفاده است. در این مطلب از راه­ انداز جاوا برای کاساندرا، استفاده می­شود.

مساله دوم، پروتکل ارتباطی است. کتابخانه­ ها و درایورهای قدیمی و سنتی مشتری کاساندرا (مانند Hector، Astynax و غیره که پروژه­ های غیرفعال یا کم فروغی هستند)، با استفاده از پروتکل Thrift با خوشه پردازشی کاساندرا ارتباط برقرار می­کردند. در واقع اولین روش برای ارتباط با خوشه پردازشی کاساندرا، واسط[2] Thrift بود. توسعه دهندگان در نحوه ارتباط با خوشه پردازشی کاساندرا، به دو دسته تقسیم می­شوند:

• توسعه دهندگانی که مدت زیادی از نسخه واسط مبتنی بر Thrift استفاده کرده ­اند و با ارتباط مستقیم با سطرهای ذخیره ­سازی با کاساندرا خو گرفته­ اند.
• توسعه دهندگانی که به­ تازگی با کاساندرا آشنا شده­ اند و در نقشی که Thrift در دنیای نوین کاساندرا بازی می­کند، دچار سردرگمی شده­ اند.

 

Thrift مکانیزم فراخوان رویه راه دور [3] ترکیب شده با تولیدکننده کد است و به­ عنوان پروتکل اصلی ارتباط مشتری با کاساندرا، بود. اتخاذ این استراتژی (Thrift API) با اثرات جانبی منفی همراه می­باشد :

• زبان متداولی برای توصیف مدل­ های داده­ای و پرس­وجوها وجود نداشت. بصورتی که هر مشتری انتزاع متفاوتی را بالای پروتکل Thrift پیاده­ سازی می­کرد.
• تمام درخواست­ها بصورت همگام[4] اجرا می­شوند، زیرا Thrift بصورت توکار از فراخوان­ های غیرهمگام[5] پشتیبانی نمی­کند.
• تمام پرس­وجوها می­بایست در حافظه سرویس ­دهنده و همچنین مشتری، ایجاد شوند. این امر، مشتریان را مجبور می­سازد تا تکنیک­ های صفحه­ بندی پردردسر را در زمان درخواست مجموعه­ های داده­ حجیم پیاده ­سازی کند (برای جلوگیری از زیاده ­روی حافظه در دسترس در سرویس ­دهنده و مشتری).
• بدین خاطر، در نسخه ­های جدید، پروتکل دودویی جدیدی به نام پروتکل بومی CQL، به پروتکل Thrift ترجیح داده میشود، که ویژگی ­های پیشرفته­ تری از قبیل، خط لوله درخواست[6] (شکل 1)، عبارات آماده[7]، نشان­گرها[8]، ارسال اعلان (شکل زیر) و آگاه از خوشه پردازشی را پشتیبانی می­کند. در نسخه­ های جدید، سرویس دهنده­ های Thrift بطور پیش ­فرض غیر فعال هستند.

    

پروتکل بومی [9]– API قدیمی Thrift، ساختار ذخیره­ سازی کاساندرا را مستقیما منعکس می­کرد و کاربران با مدل ذخیره ­سازی داخلی کاساندرا، مستقیما ارتباط برقرار می­کردند. این امر موجب می­شد که توسعه دهنده بیشتر با پیچیدگی­های پیاده ­سازی برنامه درگیر شود درنتیجه سبب کاهش تمرکز وی در بخش منطق کار می­شد. با این­حال، برخی از توسعه­ دهندگان، این امر را می ­پسندیدند زیرا انعطاف­ پذیری و کنترل بیشتری برای آن­ها به ارمغان می­آورد و همچنین می­ توانستند با رویکرد بدون شِمای [10] واقعی با کاساندرا رفتار کنند. در مقابل در پروتکل بومی CQL3، انتزاع سبکی بالای ساختار ذخیره ­سازی داخلی ارایه می­کند که موجب پنهان ­سازی جزئیات پیاده ­سازی ذخیره­ سازی داخلی می­شود و درنتیجه توسعه دهندگان می­توانند (1) فقط برروی منطق اصلی کار متمرکز شوند و (2) از دستورات و نحو یکسانی برای مدل­سازی استفاده کنند (زبان CQL3). همچنین، در پروتکل بومی، ضعف ­های دیگر پروتکل قدیمی Thrift نیز وجود نخواهند داشت. بطور خاص، پروتکل بومی، فرمت پیام‌های تبادلی بین راه انداز و کاساندرا در بستر TCP است و در چهار نسخه با ویژگی‌های مختلف ارایه می‌شود. برای فهمیدن نسخه‌ای که راه انداز در حال استفاده از آن است می‌توان بصورت ذیل عمل کرد:

ProtocolVersion myCurrentVersion = cluster.getConfiguration()

    .getProtocolOptions()

    .getProtocolVersion();

بطور پیش‌فرض، نسخه پروتکل بین راه انداز و کاساندرا زمانی که اولین اتصال برقرار می‌شود، تعیین می‌گردد. همچنین، می‌توان نسخه پروتکل بومی را در زمان نمونه سازی شیء Cluster نیز بطور دستی تعیین کرد (در صورت ناسازگاری بین نسخه پروتکل و  راه انداز/کاساندرا، خطا صادر می‌شود):

Cluster cluster = Cluster.builder()

    .addContactPoint(“127.0.0.1”)

    .withProtocolVersion(ProtocolVersion.V2)

    .build();

 

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

(1) قابل اجرا در یک گره یا تک گره­ ای

(2) قابل اجرا در چندین گره یا توزیع­ شده

توسط کتابخانه نوین و انعطاف­ پذیر راه ­انداز جاوا که توسط Datastax[11] توسعه و پشتیبانی می­شود، می‌توان در برنامه جاوا، با زبان پرس­وجوی کاساندرا (CQL3) و پروتکل دودویی بومی کاساندرا، با خوشه پردازشی کاساندرا ارتباط برقرار کرد. معماری راه­انداز لایه­ بندی می­باشد. در لایه زیرین، هسته راه­ انداز قرار دارد که تمام مسایل مرتبط با اتصال با خوشه پردازشی کاساندرا (برای مثال، استخر اتصال، شناسایی گره جدید و غیره) را برعهده دارد.

 الحاق وابستگی ­ها

برای افزودن وابستگی هسته راه­ انداز، به پروژه maven:

<dependency>

  <groupId>com.datastax.cassandra</groupId>

  <artifactId>cassandra-driver-core</artifactId>

  <version>3.3.0</version>

</dependency>

برای استفاده از ماژول­ های نگاشت شی و extras، می­توان cassandra-driver-mapping و cassandra-driver-extras را نیز به وابستگی­ ها افزود.

[1] interface

[2] API

[3] RPC

[4] synchronous

[5] asynchronous

[6] Request pipelining

[7] Prepared statement

[8] Cursors

[9] Native protocol

[10] schema-less

[11] http://docs.datastax.com/en/developer/java-driver/3.1/

[12] Prepared statements

[13] Asynchronous requests

[14] Batch statements

آدرس کانال تلگرام ما:

t.me/bigdata_channel
برای ورود به کانال بر روی اینجا کلیک کنید.

بازدیدها: 10084