একাধিক ভাড়াটে বা বহু উদাহরণ?


11

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

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

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

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

যাইহোক, প্রতিটি পদ্ধতির উপকারিতা এবং কনস দিয়ে আসে, তাই কোন পদ্ধতির সাথে যেতে হবে তা আমি সিদ্ধান্ত নিতে পারিনি। এখানে একটি তালিকা রয়েছে, তবে আমার সাথে এই দু'জনেরই জ্ঞানের অভাব রয়েছে, তাই আমি এমন কিছু জিনিস থাকতে পারি যা সম্পর্কে আমি অবগত নই, বা ওয়েবে আমি পাইনি এমন সমস্যার সমাধান হতে পারে: [প্রতিটি পদ্ধতির রয়েছে একটি আদেশযুক্ত তালিকা যা আমি একে একে তুলনা করে অনুসরণ করেছি]

বহু ভাড়াটে :

  1. ভাগ করা হোস্ট / হার্ডওয়্যার, ভাগ করা কোড এবং একাধিক ডাটাবেস।
  2. এটা সহজ কোড এবং ফিক্স বাগ কার্যকারিতা (ভাগ কোড) প্রসারিত করতে।
  3. এটা কঠিন হার্ডওয়্যার (ক মেঘ পরিষেবা ব্যবহার করতে পারে) প্রসারিত বা কোড পরিবর্তন না করে অন্য সিস্টেমে পৃথক ভাড়াটিয়া ডাটাবেস সরাতে।
  4. সর্বাধিক গুরুত্বপূর্ণ, যেমনটি আমি আগেও বলেছি, ব্যবহারকারীকে প্রকৃতপক্ষে তার প্রতিষ্ঠানের মালিকানাধীন, এবং অন্য সংস্থার তথ্য অ্যাক্সেস না করে তা নিশ্চিত করতে আমার সিস্টেমে একটি অতিরিক্ত স্তর যুক্ত করা দরকার।

মাল্টি ইনস্ট্যান্স :

  1. ভাগ বা ভাগ করা হোস্ট / হার্ডওয়্যার, প্রতি কোড কোড এবং উদাহরণস্বরূপ ডাটাবেস।
  2. এটা কঠিন কার্যকারিতা বা ফিক্স বাগ প্রসারিত করতে (আমি নিশ্চিত Docker মধ্যে এটা করতে যেখানে আপনি এক উদাহরণ হিসেবে বলা যায় বা Docker ধারক কার্যকারিতা / বৈশিষ্ট্য যোগ করতে পারেন, এবং অন্যদের এটি স্থাপন একটি উপায় না থাকলে নই)।
  3. এটা সহজ একটি ভিন্ন হোস্ট / হার্ডওয়্যারে পুরো উদাহরণস্বরূপ সরাতে।
  4. উদাহরণস্বরূপ, আমার সেই স্তরটির যত্ন নেওয়ার দরকার নেই কারণ প্রতিটি উদাহরণের নিজস্ব ডাটাবেস থাকবে।

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

ক্ষেত্রে যে সাহায্য করবে (হয়তো?), আমরা ব্যবহার করছি সালে Laravel ব্যাক এন্ড (সমস্ত RESTfully) জন্য প্রধান কাঠামো হিসেবে।


আপনি এটি একটি ডেটাবেজেও রাখতে পারেন। আপনি যদি একটি একক ডাটাবেসে শংসাপত্রগুলি সংরক্ষণ করেন তবে আমি বাকী ডেটা ভাগ করার বিন্দুটি দেখতে পাচ্ছি না।
গ্র্যান্ডমাস্টারবি

আমি মনে করি আপনি প্রতিটি ভাড়াটে এর ডেটা আলাদা করার বিষয়টি মিস করেছেন missed ভাগ করা ডাটাবেস শুধুমাত্র লগইন উদ্দেশ্যে।
আশের

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

প্রতিটি ভাড়াটে এক বিশাল পরিমাণে ডেটা (গ্রাহক, পরিষেবা, পণ্য ... ইত্যাদি) রাখে এবং এইভাবে এবং কার্য সম্পাদন / সুরক্ষা সংক্রান্ত উদ্বেগগুলির জন্য, আমি প্রতিটি ভাড়াটিয়াকে বিভিন্ন ডেটা সেন্টার / ডাটাবেসে পৃথক করতে চাই।
আশের

@ আনাস আপনি কি দুটি বিকল্পের কিছু নিয়ে সিদ্ধান্ত নিয়েছেন? এবং কেন? যাদের উত্তর একই ধরণের (আমার মত) রয়েছে তাদের জন্য উত্তরটি কার্যকর হবে
alecardv

উত্তর:


8

এই মুহূর্তে আমি নিজেকে ঠিক একই প্রশ্ন করছি।

আমি মাল্টি-ইনস্ট্যান্স একক ভাড়াটে সমাধানের দিকে ঝুঁকছি তবে এখনও একটি নির্দিষ্ট সিদ্ধান্ত নিই নি। আমাকে আমার কিছু চিন্তাভাবনা শেয়ার করুন:

বহু-ভাড়াটিয়া স্থাপত্যের প্রধান ঐতিহাসিক সুবিধা একটি হল পরিকাঠামো সম্পদের ভাল ব্যবহার দ্বারা mutualisation (একক অপারেটিং সিস্টেম, একক ডাটাবেজ, একক আবেদন স্তর) এবং ভাল বলেন সম্পদের দখল (এক ব্যবহারকারী যখন দূরে আরেকটি একই রিসোর্স ব্যবহার করতে পারেন) ।

এটি সফ্টওয়্যার জীবনচক্রকেও ব্যাপকভাবে সরল করে তোলে : আপনি এক নজরে নতুন সংস্করণ স্থাপন করেন, সমস্ত গ্রাহক একই সাথে আপডেট হয়।

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

  • ধারক-ভিত্তিক PaaS
  • কনটেইনারগুলির সরবরাহ এবং স্বয়ংক্রিয়-স্কেলিং (ইলাস্টিক পাত্রে)

সুতরাং হার্ডওয়্যার এবং প্ল্যাটফর্ম পরিচালনা আর কোনও সফ্টওয়্যার সরবরাহকারীর উদ্বেগ নয়। পরিকাঠামো এবং প্লাটফর্মের স্তরে পূর্বের চেয়ে সম্পদগুলি আরও কার্যকরভাবে পারস্পরিক সমন্বিত হয়

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

এছাড়াও:

  • PaaS API এর মাধ্যমে নতুন দৃষ্টান্ত তৈরির অটোমেশন সম্ভব
  • শূন্য ডাউনটাইম সহ নতুন সংস্করণ স্থাপনের অটোমেশন PaaS API এর মাধ্যমে সম্ভব (কিছুটা জায়গায় রাখার দরকার পড়ে)
  • স্কেলিং সবসময় বাইরে থাকে, কখনই শেষ হয় না। দৃষ্টান্ত পর্যায়ে আমাদের বিশাল ডেটাসেটগুলি নিয়ে চিন্তা করতে হবে না।

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

যা আমাকে খুব প্রাথমিক পর্যায়ে (প্রাক-বিনিয়োগ) প্রারম্ভিক প্রকল্পের জন্য একক-ভাড়াটিয়া বিকাশের চূড়ান্ত সুবিধার দিকে নিয়ে আসে:

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

নোট: আমি স্পষ্টতই এখানে এমন একটি ব্যবসায়িক অ্যাপের কথা ভাবছি যেখানে গ্রাহকরা ব্যবসায় হবেন (একাধিক স্বতন্ত্র ব্যবহারকারীর সাথে প্রত্যেকে) এবং ব্যক্তি নয়। প্রতিটি পৃথক ব্যবহারকারীর (বা এটি হবে?) আলাদা আলাদা অ্যাপ্লিকেশন চালানোর কোনও অর্থ হবে না


4

উভয় বিকল্পকে সমর্থন করাও সম্ভব (একাধিক উদাহরণ জুড়ে ভাড়াটেদের পুল)।

আমি প্রাকৃতিক বিচ্ছিন্নতার বহু কারণের পক্ষে favor প্রতিটি গ্রাহকের উদাহরণটি তার নিজস্ব প্রক্রিয়াগুলিতে চলে এবং এটির নিজস্ব ডেটাবেজে ডেটা আলাদা করা হয়। আপনি যখন চান তখন প্রতি গ্রাহক / উদাহরণ ভিত্তিতে নতুন সংস্করণগুলিতে উদাহরণগুলি আপগ্রেড করতে পারেন।

ভাড়াটে ভিত্তিক সিস্টেমগুলি তথ্য সুরক্ষা ঝুঁকি নিয়ে আসে। "WHERE tenantId = x" ধারাটি ভুলে যাওয়া কত সহজ তা বিবেচনা করুন। ভাড়াটে সক্ষম সিস্টেমটি ব্যবহারের মূল কারণটি হ'ল পারফরম্যান্স, প্রসেসগুলি ভারী ওজন, কোনও প্রক্রিয়া ভাগ করে আপনি একটি মেশিন থেকে আরও বেশি পেতে পারেন। এটি আমি আরও 32-বিট বিশ্বে সত্য বলে মনে করি তখন এটি আজকাল 64৪ বিট মেশিনে রয়েছে যা অনেক বেশি র‌্যাম রয়েছে।

একটি ডাটাবেস এবং ওয়েব অ্যাপ্লিকেশন উদাহরণগুলির মতো পরিবেশ তৈরি এবং কনফিগার করতে একটি মাল্টি-ইনস্ট্যান্স সিস্টেমে সম্ভবত কিছুটা আরও সরঞ্জামাদি প্রয়োজন। আপনার যুক্তি দিতে পারে যে আপনার একক উদাহরণ মোতায়েনের জন্য আপনার কোনওভাবেই এই স্ক্রিপ্ট হওয়া দরকার। এটি করার ক্ষেত্রে বিকাশ এবং পরীক্ষার পরিবেশ নির্ধারণের দক্ষতার মতো অন্যান্য সুবিধাও রয়েছে

যতক্ষণ না আপনি তার জন্য কেস তৈরি করতে পারেন ততক্ষণ আমি ভাড়াটে ক্ষমতা ছেড়ে চলে যাব (প্রক্রিয়া ভাগ করে নেওয়ার মাধ্যমে ইঞ্জিনিয়ারিং কস্ট বনাম অর্থ সাশ্রয় করা (হার্ডওয়্যার) অবকাঠামো)।


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

আমি @ জোপ্পের সাথে সম্পূর্ণভাবে একমত, আরও কয়েকটি বিষয় এখানে: ১. গ্রাহকরা কি অন্য সকলের মতো একই সময়ে আবেদনটি আপগ্রেড করতে ইচ্ছুক? কিছু গ্রাহকের নিয়ম রয়েছে যা অ্যাপ্লিকেশন আপগ্রেড করার আগে দীর্ঘ পরীক্ষার চক্র প্রয়োজন। অন্যরা সর্বদা নতুন হতে চান এবং বিক্রেতার পরীক্ষার উপর নির্ভর করতে চান। বহু ভাড়াটিয়া দুঃস্বপ্ন হয়ে উঠতে পারে। ২. ঝুঁকিগুলি: ডেটা-সংবেদনশীলতার স্তরটি কী? জোপ্প যেমন উল্লেখ করেছেন, ফিল্টারিং ভুলে যাওয়া এবং সংবেদনশীল ডেটা অন্যের কাছে প্রকাশ করা সহজ। বহু-প্রজাস্বত্বের সাথে আপনার বিরুদ্ধে মামলা হতে পারে, একটি বহু-উদাহরণে, আপনি দোষ চাপানোর চেষ্টা করতে পারেন। ;)
ড্যানিলো টমমসিনা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.