একটি সফ্টওয়্যার পাইপলাইনে ভাগ করা ডেটা এমপ্ল্যাপুলেটের জন্য কার্যকর প্রয়োগের কৌশল gies


13

আমি একটি বিদ্যমান ওয়েব পরিষেবার কয়েকটি দিকগুলি পুনরায় ফ্যাক্টর করার কাজ করছি। পরিষেবা API গুলি যেভাবে প্রয়োগ করা হয় তা হ'ল এক ধরণের "প্রসেসিং পাইপলাইন" থাকা, যেখানে ক্রম অনুসারে কাজগুলি করা হয়। আশ্চর্যজনকভাবে, পরবর্তী কাজগুলিকে আগের কাজগুলির সাথে গণনা করা তথ্যের প্রয়োজন হতে পারে এবং বর্তমানে এটি যেভাবে করা হয় তা হল "পাইপলাইন রাষ্ট্র" শ্রেণিতে ক্ষেত্র যুক্ত করে।

আমি ভাবছিলাম (এবং আশা করি?) যে পাইপলাইন ধাপগুলির মধ্যে জিলিয়ন ক্ষেত্রের সাথে ডেটা অবজেক্ট থাকার চেয়ে তথ্য ভাগ করার আরও ভাল উপায় আছে যার মধ্যে কিছু কিছু প্রক্রিয়াজাতকরণের পদক্ষেপগুলিকে বোঝায় এবং অন্যকে নয়। এই শ্রেণীর থ্রেড-নিরাপদ করে তোলা এটি একটি বড় বেদনা হবে (এটি এমনকি সম্ভব হবে কিনা তা আমি জানি না), এর আক্রমণকারীদের সম্পর্কে যুক্তি দেওয়ার কোনও উপায় নেই (এবং সম্ভবত এটির কোনওটি নেই)।

আমি কিছু অনুপ্রেরণা খুঁজে পেতে গ্যাং অফ ফোর ডিজাইনের নিদর্শনগুলির বইয়ের মাধ্যমে পেজিং করছি, তবে আমার মনে হয়নি যে সেখানে কোনও সমাধান রয়েছে (মেমেন্টো কিছুটা একই চেতনায় ছিল, তবে বেশ নয়)। আমি অনলাইনেও দেখেছি, তবে দ্বিতীয়টি আপনি "পাইপলাইন" বা "ওয়ার্কফ্লো" অনুসন্ধান করেন আপনি ইউনিক্স পাইপ তথ্য, বা মালিকানাধীন ওয়ার্কফ্লো ইঞ্জিন এবং ফ্রেমওয়ার্ক সহ প্লাবিত হবেন।

আমার প্রশ্নটি হল - আপনি কীভাবে কোনও সফ্টওয়্যার প্রসেসিং পাইপলাইনের কার্যকরকরণের রেকর্ডিংয়ের ইস্যুটিতে যোগাযোগ করবেন, যাতে পরবর্তী কাজগুলি পূর্বেরগুলির দ্বারা গণিত তথ্য ব্যবহার করতে পারে? আমার ধারণা ইউনিক্স পাইপগুলির মধ্যে প্রধান পার্থক্যটি হ'ল আপনি কেবল তাত্ক্ষণিক পূর্ববর্তী টাস্কের আউটপুট সম্পর্কে চিন্তা করবেন না।


অনুরোধ হিসাবে, কিছু ব্যবহারের ক্ষেত্রে চিত্র ব্যবহার করার জন্য সিউডোকোড:

"পাইপলাইন প্রসঙ্গ" অবজেক্টে এমন অনেকগুলি ক্ষেত্র রয়েছে যা বিভিন্ন পাইপলাইন পদক্ষেপগুলি পপুলেশন / পড়তে পারে:

public class PipelineCtx {
    ... // fields
    public Foo getFoo() { return this.foo; }
    public void setFoo(Foo aFoo) { this.foo = aFoo; }
    public Bar getBar() { return this.bar; }
    public void setBar(Bar aBar) { this.bar = aBar; }
    ... // more methods
}

পাইপলাইনের প্রতিটি পদক্ষেপও একটি বস্তু:

public abstract class PipelineStep {
    public abstract PipelineCtx doWork(PipelineCtx ctx);
}

public class BarStep extends PipelineStep {
    @Override
    public PipelineCtx doWork(PipelieCtx ctx) {
        // do work based on the stuff in ctx
        Bar theBar = ...; // compute it
        ctx.setBar(theBar);

        return ctx;
    }
}

একইভাবে একটি FooStepঅনুমানের জন্য , যার আগে অন্যান্য ডেটা সহ বারস্টেপ দ্বারা বার গণনা করা যেতে পারে। এবং তারপরে আমাদের কাছে আসল এপিআই কল রয়েছে:

public class BlahOperation extends ProprietaryWebServiceApiBase {
    public BlahResponse handle(BlahRequest request) {
        PipelineCtx ctx = PipelineCtx.from(request);

        // some steps happen here
        // ...

        BarStep barStep = new BarStep();
        barStep.doWork(crx);

        // some more steps maybe
        // ...

        FooStep fooStep = new FooStep();
        fooStep.doWork(ctx);

        // final steps ...

        return BlahResponse.from(ctx);
    }
}

6
কোনও মোডের জন্য পোস্টটি ছাড়াই কিন্তু পতাকাটি অতিক্রম করবেন না
রাচেট ফ্রিক

1
এগিয়ে যেতে হবে, আমার ধারণা নিয়মের সাথে নিজেকে পরিচিত করতে আমার আরও বেশি সময় ব্যয় করা উচিত। ধন্যবাদ!
RuslanD

1
আপনি কি আপনার প্রয়োগের জন্য অবিরাম কোনও ডেটা স্টোরেজ এড়িয়ে চলেছেন, বা এই মুহুর্তে কিছু আঁকড়ে আছে?
কোকোবরে

1
হাই রুসলানডি এবং স্বাগতম! এটি স্ট্যাক ওভারফ্লোয়ের চেয়ে প্রোগ্রামারদের পক্ষে প্রকৃতপক্ষে আরও উপযুক্ত, তাই আমরা এসও সংস্করণটি সরিয়েছি। @Ratchetfreak যা উল্লেখ করেছেন তা মনে রাখবেন, আপনি সংযমী মনোযোগের জন্য পতাকাঙ্কিত করতে পারেন এবং আরও উপযুক্ত সাইটে স্থানান্তরিত করার জন্য একটি প্রশ্ন জিজ্ঞাসা করতে পারেন, পোস্ট ক্রস করার দরকার নেই। দুটি সাইটের মধ্যে বাছাইয়ের নিয়মটি হ'ল প্রোগ্রামাররা যখন আপনার প্রকল্পগুলির ডিজাইনিং হোয়াইটবোর্ডের সামনে থাকেন তখন আপনি যে সমস্যার মুখোমুখি হন তা হ'ল এবং স্ট্যাক ওভারফ্লো আরও প্রযুক্তিগত সমস্যার জন্য (যেমন বাস্তবায়নের সমস্যাগুলি)। আরও তথ্যের জন্য আমাদের FAQ দেখুন
ইয়ানিস

1
আপনি যদি পাইপলাইনের পরিবর্তে কোনও আর্কিটেকচারটি প্রসেসিং ডিএজি (নির্দেশিত অ্যাসাইক্লিক গ্রাফ) এ পরিবর্তন করেন তবে আপনি পূর্ববর্তী পদক্ষেপের ফলাফল স্পষ্টভাবে পাস করতে পারবেন।
প্যাট্রিক

উত্তর:


4

পাইপলাইন ডিজাইন ব্যবহারের প্রধান কারণ হ'ল আপনি পর্যায়গুলি ডিকুয়াল করতে চান। হয় এক পর্যায়ে একাধিক পাইপলাইন (ইউনিক্স শেল সরঞ্জামগুলির মতো) ব্যবহার করা হতে পারে বা আপনি কিছু স্কেলিং সুবিধা অর্জন করার কারণে (যেমন, আপনি সহজেই একটি একক নোড আর্কিটেকচার থেকে একাধিক নোড আর্কিটেকচারে যেতে পারেন)।

উভয় ক্ষেত্রেই, পাইপলাইনের প্রতিটি পর্যায়ে তার কাজটি করার জন্য যা প্রয়োজন তা দেওয়া উচিত। আপনি কোনও বাহ্যিক স্টোর (উদাহরণস্বরূপ, ডাটাবেস) ব্যবহার করতে পারবেন না এমন কোনও কারণ নেই, তবে বেশিরভাগ ক্ষেত্রেই ডেটা এক পর্যায়ে থেকে অন্য পর্যায়ে পৌঁছে দেওয়া ভাল।

তবে এর অর্থ এই নয় যে প্রতিটি সম্ভাব্য ক্ষেত্রের সাথে আপনাকে অবশ্যই একটি বড় বার্তা অবজেক্টটি পাস করতে হবে বা করা উচিত (যদিও নীচে দেখুন)। পরিবর্তে, পাইপলাইনের প্রতিটি স্তরের তার ইনপুট এবং আউটপুট বার্তাগুলির জন্য ইন্টারফেসগুলি সংজ্ঞায়িত করা উচিত, যা কেবলমাত্র পর্যায়ে প্রয়োজনীয় ডেটা সনাক্ত করে।

তারপরে আপনি কীভাবে আপনার প্রকৃত বার্তা অবজেক্টগুলি প্রয়োগ করেন তাতে আপনার অনেকটা নমনীয়তা রয়েছে। একটি পদ্ধতি হ'ল একটি বিশাল ডেটা অবজেক্ট ব্যবহার করা যা সমস্ত প্রয়োজনীয় ইন্টারফেস প্রয়োগ করে। আরেকটি হ'ল সাধারণের চারপাশে মোড়কের ক্লাস তৈরি করা Map। আর একটি হ'ল ডেটাবেসকে ঘিরে একটি মোড়ক ক্লাস তৈরি করা।


1

কিছু চিন্তা আছে যেগুলি মাথায় আসে, যার মধ্যে প্রথমটি আমার কাছে পর্যাপ্ত তথ্য নেই।

  • প্রতিটি পদক্ষেপ পাইপলাইন ছাড়িয়ে ব্যবহৃত ডেটা তৈরি করে, বা আমরা কেবল শেষ পর্যায়ে ফলাফলের যত্ন নিই?
  • অনেক বড় ডেটা উদ্বেগ আছে? অর্থাত। মেমরি উদ্বেগ, গতি উদ্বেগ, ইত্যাদি

উত্তরগুলি সম্ভবত নকশাটি সম্পর্কে আমাকে আরও মনোযোগ সহকারে ভাবতে বাধ্য করবে, তবে আপনি যা বলেছিলেন তার উপর ভিত্তি করে আমি প্রথমে বিবেচনা করব 2 টি পদ্ধতির।

প্রতিটি স্টেজের নিজস্ব অবজেক্ট হিসাবে স্ট্রাকচার করুন। নবম পর্যায়ের প্রতিনিধিদের তালিকা হিসাবে এন -1 পর্যায়ে 1 থাকবে। প্রতিটি পর্যায়ে ডেটা এবং ডেটা প্রক্রিয়াকরণ encapsulates; প্রতিটি বস্তুর মধ্যে সামগ্রিক জটিলতা এবং ক্ষেত্র হ্রাস করা। আপনার পরবর্তী পর্যায়ে প্রতিনিধিদের অনুসরণ করে পূর্বের পর্যায়ে থেকে প্রয়োজনীয় ডেটা অ্যাক্সেস করতে পারে। আপনার কাছে এখনও সমস্ত অবজেক্টের জুড়ে বেশ আঁটসাঁট পোশাক রয়েছে কারণ এটি গুরুত্বপূর্ণ পর্যায়ের ফলাফলগুলি (অর্থাত্ সমস্ত অনুগামী), তবে এটি উল্লেখযোগ্যভাবে হ্রাস পেয়েছে এবং প্রতিটি পর্যায় / অবজেক্ট সম্ভবত আরও পাঠযোগ্য এবং বোধগম্য। আপনি প্রতিনিধিদের তালিকাটিকে অলস করে এবং প্রয়োজনীয় হিসাবে প্রতিটি বস্তুতে প্রতিনিধি তালিকাটি জনপ্রিয় করতে একটি থ্রেড নিরাপদ সারি ব্যবহার করে এটি থ্রেডকে নিরাপদ করে তুলতে পারেন।

বিকল্পভাবে আমি সম্ভবত আপনার কাজগুলির সাথে অনুরূপ কিছু করব। একটি বৃহত ডেটা অবজেক্ট যা প্রতিটি স্তরের প্রতিনিধিত্ব করে functions এটি প্রায়শই অনেক দ্রুত এবং হালকা ওজনযুক্ত হয়, তবে এটি আরও বেশি জটিল এবং ত্রুটিযুক্ত কারণ এটি ডেটা অ্যাট্রিবিউটরের একটি বড় গাদা। স্পষ্টতই থ্রেড-নিরাপদ নয়।

সত্যই আমি পরে আরও একবার ইটিএল এবং অন্যান্য কিছু অনুরূপ সমস্যার জন্য করেছি। রক্ষণাবেক্ষণের চেয়ে ডেটা পরিমাণের কারণে আমি পারফরম্যান্সে ফোকাস ছিলাম। এছাড়াও, সেগুলি এক-অফ ছিল যা আবার ব্যবহার করা হবে না।


1

এটি জিওএফের চেইন প্যাটার্নের মতো দেখাচ্ছে।

কমন্স-চেইন কী করে তা দেখার জন্য একটি ভাল সূচনা পয়েন্ট হবে ।

জটিল প্রক্রিয়াকরণ প্রবাহের সম্পাদনের আয়োজনের জন্য একটি জনপ্রিয় কৌশল হ'ল ক্লাসিক "গ্যাং অফ ফোর" ডিজাইনের নিদর্শনগুলির বইতে বর্ণিত (অন্যান্য অনেক জায়গার মধ্যে) বর্ণিত হিসাবে "দায়িত্বের চেইন" প্যাটার্ন। যদিও এই নকশা প্যাটেনটি বাস্তবায়নের জন্য প্রয়োজনীয় মৌলিক এপিআই চুক্তিগুলি অত্যন্ত সহজ, তবুও এটি বেস অ্যাপ্লিকেশনটি কার্যকর যা প্যাটার্নটি ব্যবহার করার সুবিধার্থে এবং (আরও গুরুত্বপূর্ণভাবে) একাধিক বিবিধ উত্স থেকে কমান্ড প্রয়োগের রচনাটিকে উত্সাহিত করে।

এই প্রান্তের দিকে, চেইন এপিআই একটি "শৃঙ্খলে" মিলিত হতে পারে এমন একটি "কমান্ড" এর একটি সিরিজ হিসাবে একটি গণনা মডেল করে। কমান্ডের এপিআইতে একটি একক পদ্ধতি ( execute()) থাকে, যা গণনার গতিশীল অবস্থা সম্বলিত একটি "প্রসঙ্গ" পরামিতিটি পাস করে এবং যার রিটার্ন মানটি একটি বুলিয়ান যা নির্ধারণ করে যে বর্তমান চেইনের জন্য প্রক্রিয়াজাতকরণ সম্পন্ন হয়েছে কি না ( সত্য), বা প্রক্রিয়াকরণটি পরবর্তী কমান্ডের শৃঙ্খলে প্রেরণ করা উচিত (মিথ্যা)।

"প্রসঙ্গ" অ্যাবস্ট্রাকশনটি যে পরিবেশে চালিত হয় সেগুলি থেকে কমান্ড প্রয়োগগুলি বিচ্ছিন্ন করার জন্য ডিজাইন করা হয়েছে (যেমন কোনও কমান্ড যা কোনও পরিবেশের বা পোর্টলেট উভয়ই পরিবেশের কোনওরকমের API চুক্তিতে সরাসরি আবদ্ধ না হয়ে ব্যবহার করা যেতে পারে)। কমান্ডগুলির জন্য যাদের প্রতিনিধিদলের পূর্বে সংস্থানগুলি বরাদ্দ করা দরকার, এবং তারপরে তাদের ছেড়ে দেওয়া (এমনকি যদি কোনও ডেলিগেট-টু কমান্ড একটি ব্যতিক্রম ছুঁড়ে ফেলে), "ফিল্টার" "কমান্ড" এক্সটেনশন postprocess()এই পরিষ্কারের জন্য একটি পদ্ধতি সরবরাহ করে । অবশেষে, কমান্ডগুলি (বা চেইন) আসলে কার্যকর করা হয় সেই সিদ্ধান্তের পিছনে মঞ্জুর করার জন্য কমান্ডগুলি "ক্যাটালগ" এ সংরক্ষণ করা যায় এবং সন্ধান করা যেতে পারে।

চেইন অফ রেসপন্সিবিলিটি প্যাটার্ন এপিআইয়ের উপযোগিতা সর্বাধিক করতে, মৌলিক ইন্টারফেস চুক্তিগুলি উপযুক্ত জেডিকে ব্যতীত শূন্য নির্ভরতা সহ এমনভাবে সংজ্ঞায়িত করা হয়। এই এপিআইগুলির সুবিধার ভিত্তি বর্গ শ্রেণীর প্রয়োগগুলি যেমন ওয়েব পরিবেশের জন্য (যেমন সার্ভলেট এবং পোর্টলেট) আরও বেশি বিশেষজ্ঞ (তবে alচ্ছিক) প্রয়োগ করা হয় are

কমান্ড বাস্তবায়নগুলি এই সুপারিশগুলির সাথে সামঞ্জস্য করার জন্য তৈরি করা হয়েছে, ওয়েব অ্যাপ্লিকেশন কাঠামোর (যেমন স্ট্রুটস) "ফ্রন্ট কন্ট্রোলার" এর চেইন অফ রেসপন্সিবিলিটি API গুলি ব্যবহার করা সম্ভব হবে, তবে ব্যবসায়ের ক্ষেত্রে এটি ব্যবহার করতে সক্ষম হওয়া উচিত যুক্তি এবং দৃistence়তা স্তরগুলি কম্পোজিশনের প্রয়োজনীয় জটিলতাগুলি মডেল করার জন্য composition তদতিরিক্ত, একটি সাধারণ উদ্দেশ্যে প্রসঙ্গে কাজ করে এমন কমান্ডকে আলাদা আলাদা কমান্ডে পৃথক করার ফলে ইউনিট পরীক্ষামূলক এমন কমান্ডগুলি সহজেই তৈরি করা সম্ভব হয়, কারণ সরবরাহিত প্রসঙ্গে সংশ্লিষ্ট রাষ্ট্রীয় পরিবর্তনগুলি পর্যালোচনা করে একটি আদেশ কার্যকর করার প্রভাব সরাসরি পরিমাপ করা যায় can ...


0

একটি প্রথম সমাধান যা আমি কল্পনা করতে পারি তা হল পদক্ষেপগুলি সুস্পষ্ট করা। তাদের প্রত্যেকটি একটি টুকরো ডেটা প্রক্রিয়াকরণ করতে এবং পরের প্রক্রিয়া অবজেক্টে প্রেরণ করতে সক্ষম একটি বস্তুতে পরিণত হয়। প্রতিটি প্রক্রিয়া একটি নতুন (আদর্শ অপরিবর্তনীয়) পণ্য তৈরি করে, যাতে প্রক্রিয়াগুলির মধ্যে কোনও ইন্টারঅ্যাকশন না হয় এবং তারপরে ডেটা ভাগ করে নেওয়ার কারণে কোনও ঝুঁকি থাকে না। যদি কিছু প্রক্রিয়া অন্যদের তুলনায় বেশি সময় ব্যয় করে তবে আপনি দুটি প্রক্রিয়ার মধ্যে কিছুটা বাফার রাখতে পারেন। আপনি যদি মাল্টিথ্রেডিংয়ের জন্য কোনও সময়সূচী সঠিকভাবে ব্যবহার করেন তবে এটি বাফারগুলি ফ্লাশ করার জন্য আরও রিসোর্সগুলি বরাদ্দ করবে।

দ্বিতীয় সমাধান হতে পারে পাইপলাইনের পরিবর্তে "বার্তা" চিন্তা করা, সম্ভবত একটি উত্সর্গীকৃত কাঠামোর সাথে। আপনার তখন কিছু "অভিনেতা" অন্য অভিনেতাদের কাছ থেকে বার্তা পেয়েছেন এবং অন্যান্য অভিনেতাদের কাছে অন্যান্য বার্তা প্রেরণ করেছেন। আপনি আপনার অভিনেতাদের একটি পাইপলাইনে সংগঠিত করেন এবং আপনার প্রাথমিক ডেটা প্রথম অভিনেতা কে চেইন শুরু করেন। বার্তাগুলি প্রেরণে ভাগ করে নেওয়ার কারণে ভাগ করার কোনও ডেটা নেই। আমি জানি যে স্কালার অভিনেতার মডেলটি জাভাতে ব্যবহার করা যেতে পারে, যেহেতু এখানে স্কালার নির্দিষ্ট কিছু নেই, তবে আমি কখনই এটি জাভা প্রোগ্রামে ব্যবহার করি নি।

সমাধানগুলি সমান এবং আপনি প্রথমটির সাথে দ্বিতীয়টি প্রয়োগ করতে পারেন। মূলত, মূল ধারণাগুলি হ'ল তথ্য ভাগ করে নেওয়ার কারণে traditionalতিহ্যগত সমস্যাগুলি এড়াতে এবং আপনার পাইপলাইনে প্রক্রিয়াগুলির প্রতিনিধিত্বমূলক স্পষ্ট এবং স্বতন্ত্র সত্তা তৈরির জন্য অপরিবর্তনীয় ডেটা নিয়ে কাজ করা। আপনি যদি এই শর্তগুলি পূরণ করেন তবে আপনি সহজেই পরিষ্কার, সহজ পাইপলাইন তৈরি করতে পারেন এবং এগুলি একটি সমান্তরাল প্রোগ্রামে ব্যবহার করতে পারেন।


আরে, আমি আমার প্রশ্নটি কয়েকটি সিউডোকোড দিয়ে আপডেট করেছি - আমরা আসলে ধাপগুলি সুস্পষ্টভাবে জানি।
RuslanD
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.