اپاچی اگنائٹ زیرو تعیناتی: واقعی صفر؟

ہم ریٹیل نیٹ ورک کے ٹیکنالوجی ڈویلپمنٹ ڈیپارٹمنٹ ہیں۔ ایک دن، انتظامیہ نے MSSQL کے ساتھ مل کر Apache Ignite کا استعمال کرتے ہوئے بڑے پیمانے پر حسابات کو تیز کرنے کا کام مقرر کیا، اور جاوا کوڈ کی خوبصورت عکاسیوں اور مثالوں کے ساتھ ایک ویب سائٹ دکھائی۔ مجھے فوری طور پر سائٹ پسند آئی زیرو تعیناتی۔، جس کی تفصیل معجزات کا وعدہ کرتی ہے: آپ کو گرڈ میں ہر نوڈ پر اپنے جاوا یا اسکالا کوڈ کو دستی طور پر تعینات کرنے کی ضرورت نہیں ہے اور ہر بار جب یہ تبدیل ہوتا ہے تو اسے دوبارہ تعینات کرنا پڑتا ہے۔ جیسے جیسے کام آگے بڑھا، پتہ چلا کہ زیرو تعیناتی کے مخصوص استعمال ہیں، جن کی خصوصیات میں شیئر کرنا چاہتا ہوں۔ کٹ کے نیچے خیالات اور عمل درآمد کی تفصیلات ہیں۔

1. مسئلہ کا بیان

مسئلہ کا خلاصہ درج ذیل ہے۔ سیلز پوائنٹ سیلز پوائنٹ ڈائرکٹری اور ایک Sku (اسٹاک کیپنگ یونٹ) پروڈکٹ ڈائرکٹری ہے۔ پوائنٹ آف سیل میں "Small" اور "large" کی قدروں کے ساتھ "Store type" وصف ہے۔ ایک درجہ بندی (پوائنٹ آف سیل کی مصنوعات کی فہرست) ہر پوائنٹ آف سیل سے منسلک ہوتی ہے (DBMS سے بھری ہوئی) اور معلومات فراہم کی جاتی ہیں کہ مخصوص تاریخ سے مخصوص مصنوعات
درجہ بندی سے خارج یا درجہ بندی میں شامل کیا گیا۔

اس کے لیے ضروری ہے کہ فروخت کے پوائنٹس کے ایک تقسیم شدہ کیش کو منظم کریں اور اس میں منسلک مصنوعات کے بارے میں معلومات کو ایک ماہ پہلے سے محفوظ کریں۔ جنگی نظام کے ساتھ مطابقت کے لیے Ignite کلائنٹ نوڈ کو ڈیٹا لوڈ کرنے، فارم کی مجموعی تعداد (اسٹور کی قسم، پروڈکٹ کوڈ، دن، نمبر_of_sales_points) کا حساب لگانے اور اسے DBMS پر واپس اپ لوڈ کرنے کی ضرورت ہوتی ہے۔

2. ادب کا مطالعہ

مجھے ابھی تک کوئی تجربہ نہیں ہے، اس لیے میں چولہے سے ناچنا شروع کر رہا ہوں۔ یعنی اشاعتوں کے جائزے سے۔

آرٹیکل 2016 Apache Ignite کا تعارف: پہلا قدم Apache Ignite پروجیکٹ کی دستاویزات کا ایک لنک اور ساتھ ہی اس دستاویزات کی مبہمیت کے لیے ایک ملامت بھی شامل ہے۔ میں نے اسے ایک دو بار دوبارہ پڑھا، وضاحت نہیں آتی۔ میں سرکاری ٹیوٹوریل کا حوالہ دیتا ہوں۔ شروع ہوا چاہتا ہےکون سا
امید مندانہ طور پر وعدہ کرتا ہے کہ "آپ ایک لمحے میں تیار ہو جائیں گے اور بھاگ جائیں گے!" میں ماحول کی متغیر ترتیبات کا پتہ لگا رہا ہوں، دو Apache Ignite Essentials ویڈیوز دیکھ رہا ہوں، لیکن وہ میرے مخصوص کام کے لیے زیادہ کارآمد نہیں تھے۔ میں نے پہلی ایپلیکیشن کی تعمیر کرتے ہوئے معیاری فائل "example-ignite.xml" کے ساتھ کمانڈ لائن سے Ignite کو کامیابی کے ساتھ لانچ کیا کمپیوٹ ایپلی کیشن Maven کا استعمال کرتے ہوئے. ایپلیکیشن کام کرتی ہے اور زیرو تعیناتی کا استعمال کرتی ہے، کیا خوبصورتی ہے!

میں نے مزید پڑھا، اور وہاں مثال فوری طور پر affinityKey کا استعمال کرتی ہے (اس سے پہلے ایس کیو ایل کے استفسار کے ذریعے بنائی گئی تھی)، اور یہاں تک کہ پراسرار BinaryObject کا استعمال کرتی ہے:

IgniteCache<BinaryObject, BinaryObject> people 
        = ignite.cache("Person").withKeepBinary(); 

میں نے اسے پڑھا۔ تھوڑا سا: بائنری فارمیٹ - عکاسی جیسی کوئی چیز، نام سے کسی چیز کے فیلڈز تک رسائی۔ آبجیکٹ کو مکمل طور پر ڈی سیریلائز کیے بغیر کسی فیلڈ کی ویلیو پڑھ سکتے ہیں (میموری کو بچانا)۔ لیکن بائنری آبجیکٹ کو شخص کی بجائے کیوں استعمال کیا جاتا ہے، چونکہ زیرو تعیناتی ہے؟ کیوں IgniteCache IgniteCache میں منتقل کیا گیا۔ ? یہ ابھی تک واضح نہیں ہے۔

میں اپنے کیس کے مطابق کمپیوٹ ایپلیکیشن کو دوبارہ بنا رہا ہوں۔ MSSQL میں پوائنٹس آف سیل کی ڈائرکٹری کی بنیادی کلید کو [id] [int] NOT NULL کے طور پر بیان کیا گیا ہے، میں تشبیہ کے ذریعہ ایک کیش بناتا ہوں

IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")

ایکس ایم ایل تشکیل میں میں اشارہ کرتا ہوں کہ کیشے تقسیم ہے۔

<bean class="org.apache.ignite.configuration.CacheConfiguration">
    <property name="name" value="spCache"/>
    <property name="cacheMode" value="PARTITIONED"/>
</bean>

پوائنٹ آف سیل کے لحاظ سے تقسیم کرنا فرض کرتا ہے کہ وہاں دستیاب سیلز پوائنٹ کیچ ریکارڈز کے لیے ہر کلسٹر نوڈ پر مطلوبہ ایگریگیٹ بنایا جائے گا، جس کے بعد کلائنٹ نوڈ حتمی خلاصہ انجام دے گا۔

میں ٹیوٹوریل پڑھ رہا ہوں۔ سب سے پہلے Ignite Compute Applicationمیں قیاس سے کرتا ہوں۔ ہر کلسٹر نوڈ پر میں IgniteRunnable() چلاتا ہوں، کچھ اس طرح:

  @Override
  public void run() {
    SalesPoint sp=salesPointCache.get(spId);
    sp.calculateSalesPointCount();
    ..
  }

میں جمع اور اپ لوڈنگ منطق شامل کرتا ہوں اور اسے ٹیسٹ ڈیٹا سیٹ پر چلاتا ہوں۔ سب کچھ مقامی طور پر ترقیاتی سرور پر کام کرتا ہے۔

میں دو CentOs ٹیسٹ سرورز لانچ کرتا ہوں، IP ایڈریس ڈیفالٹ-config.xml میں بتاتا ہوں، ہر ایک پر عمل کرتا ہوں۔

./bin/ignite.sh config/default-config.xml

دونوں اگنائٹ نوڈس چل رہے ہیں اور ایک دوسرے کو دیکھ سکتے ہیں۔ میں کلائنٹ ایپلی کیشن کے xml کنفیگریشن میں مطلوبہ ایڈریس بتاتا ہوں، یہ شروع ہوتا ہے، ٹاپولوجی میں تیسرا نوڈ شامل کرتا ہے اور فوراً ہی دو نوڈس دوبارہ ہوتے ہیں۔ لاگ لائن میں "ClassNotFoundException: model.SalesPoint" دکھاتا ہے۔

SalesPoint sp=salesPointCache.get(spId);

StackOverflow کا کہنا ہے کہ خرابی کی وجہ یہ ہے کہ CentOs سرورز پر کوئی کسٹم سیلزپوائنٹ کلاس نہیں ہے۔ ہم پہنچ چکے ہیں۔ "آپ کو ہر نوڈ پر اپنے جاوا کوڈ کو دستی طور پر تعینات کرنے کی ضرورت نہیں ہے" وغیرہ کے بارے میں کیا خیال ہے؟ یا کیا "آپ کا جاوا کوڈ" سیلز پوائنٹ کے بارے میں نہیں ہے؟

میں نے شاید کچھ یاد کیا ہے - میں دوبارہ تلاش کرنا، پڑھنا اور دوبارہ تلاش کرنا شروع کرتا ہوں۔ تھوڑی دیر کے بعد مجھے احساس ہوتا ہے کہ میں نے موضوع پر سب کچھ پڑھ لیا ہے، اب کوئی نئی بات نہیں ہے۔ جب میں تلاش کر رہا تھا، مجھے کچھ دلچسپ تبصرے ملے۔

ویلنٹین کولیچینکو، گرڈ گین سسٹمز میں لیڈ آرکیٹیکٹ، جواب StackOverflow پر، اپریل 2016:

Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.

ایک اور مستند رائے: ڈینس مگڈا، ڈائریکٹر آف پروڈکٹ مینجمنٹ، گرڈ گین سسٹمز۔

Habré پر مضمون مائیکرو سروسز کے بارے میں ڈینس مگڈا کے تین مضامین کا حوالہ دیتے ہیں: مائیکرو سروسز حصہ اول, مائیکرو سروسز حصہ دوم, مائیکرو سروسز حصہ III 2016-2017۔ دوسرے مضمون میں، ڈینس نے مینٹیننس سروس نوڈ اسٹارٹ اپ ڈاٹ جار کے ذریعے کلسٹر نوڈ شروع کرنے کا مشورہ دیا ہے۔ آپ xml کنفیگریشن اور کمانڈ لائن کے ساتھ لانچ بھی استعمال کر سکتے ہیں، لیکن پھر آپ کو ہر تعینات کلسٹر نوڈ پر دستی طور پر کسٹم کلاسز لگانے کی ضرورت ہے۔

That's it. Start (..)  node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.

بے شک، یہ ہے. یہاں یہ پتہ چلتا ہے، کیوں، یہ پراسرار بائنری فارمیٹ!

3. سنگل جار

ڈینس نے میری ذاتی درجہ بندی میں پہلا مقام حاصل کیا، IMHO تمام دستیاب میں سے سب سے مفید سبق ہے۔ اس میں مائیکرو سروسز کی مثال گیتھب کلسٹر نوڈس کو ترتیب دینے کی مکمل طور پر تیار مثال پر مشتمل ہے، جو بغیر کسی اضافی اسکواٹنگ کے مرتب کرتا ہے۔

میں اسے اسی طرح کرتا ہوں اور ایک واحد جار فائل حاصل کرتا ہوں جو کمانڈ لائن آرگومنٹ کے لحاظ سے "ڈیٹا نوڈ" یا "کلائنٹ نوڈ" کو لانچ کرتی ہے۔ اسمبلی شروع ہوتی ہے اور کام کرتی ہے۔ زیرو تعیناتی کو شکست ہوئی ہے۔

میگا بائٹس ٹیسٹ ڈیٹا سے دسیوں گیگا بائٹس جنگی ڈیٹا میں منتقلی نے ظاہر کیا کہ بائنری فارمیٹ ایک وجہ سے موجود ہے۔ نوڈس پر میموری کی کھپت کو بہتر بنانا ضروری تھا، اور یہیں سے BinaryObject بہت مفید ثابت ہوا۔

4. نتائج

Apache Ignite پروجیکٹ کی دستاویزات کے مبہم ہونے کے بارے میں سامنے آنے والی پہلی ملامت منصفانہ نکلی؛ 2016 کے بعد سے بہت کم تبدیلی آئی ہے۔ کسی ابتدائی کے لیے ویب سائٹ اور/یا ریپوزٹری کی بنیاد پر کام کرنے والے پروٹو ٹائپ کو جمع کرنا آسان نہیں ہے۔

کئے گئے کام کے نتائج کی بنیاد پر، یہ تاثر تھا کہ زیرو تعیناتی کام کرتی ہے، لیکن صرف سسٹم کی سطح پر۔ کچھ اس طرح: بائنری آبجیکٹ کو ریموٹ کلسٹر نوڈس کو کسٹم کلاسز کے ساتھ کام کرنا سکھانے کے لیے استعمال کیا جاتا ہے۔ زیرو تعیناتی - اندرونی میکانزم
اپاچی خود کو اگنائٹ کرتا ہے اور پورے کلسٹر میں سسٹم آبجیکٹ تقسیم کرتا ہے۔

مجھے امید ہے کہ میرا تجربہ نئے Apache Ignite صارفین کے لیے کارآمد ثابت ہوگا۔

ماخذ: www.habr.com