ভাগ করা টেবিল স্ট্রাকচার সহ কীভাবে একটি বহু-ভাড়াটে ডাটাবেস তৈরি করবেন?


129

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

এখন পর্যন্ত আমি তিনটি বিকল্প দেখেছি:

  • মাল্টি-ডাটাবেস (প্রতিটি ভাড়াটে তার নিজস্ব পায় - গ্রাহক প্রতি 1 সার্ভারের মতো প্রায়)
  • মাল্টি স্কিমা (মাইএসকিউএল উপলভ্য নয়, প্রতিটি ভাড়াটে ভাগ করে নেওয়া ডাটাবেসে নিজস্ব স্কিমা পেয়েছে)
  • ভাগ করা স্কিমা (আমাদের বর্তমান পদ্ধতি, প্রতিটি কলামে অতিরিক্ত সনাক্তকারী রেকর্ড সহ)

মাল্টি-স্কিমা আমার প্রিয় (ব্যয় বিবেচনা করে)। তবে একটি নতুন অ্যাকাউন্ট তৈরি করা এবং মাইগ্রেশন করা বেশ বেদনাদায়ক বলে মনে হচ্ছে, কারণ আমাকে সমস্ত স্কিমার উপরে পুনরাবৃত্তি করতে হবে এবং তাদের সারণী / কলাম / সংজ্ঞা পরিবর্তন করতে হবে।

প্রশ্ন: মাল্টি স্কিমার মনে হয় প্রতিটি ভাড়াটেদের জন্য কিছুটা আলাদা টেবিল তৈরি করা হয়েছে - আমি এটি চাই না। এমন কোনও আরডিবিএমএস আছে যা আমাকে একাধিক স্কিমা মাল্টি-টেন্যান্ট সমাধান ব্যবহার করতে দেয়, যেখানে টেবিল কাঠামোটি সমস্ত ভাড়াটেদের মধ্যে ভাগ করা হয়?

পিএস দ্বারা বহুগুণ বলতে আমি আল্ট্রা-মাল্টির মতো কিছু বোঝায় (10.000+ ভাড়াটে)।


1
"মাল্টি স্কিমার মনে হয় প্রতিটি ভাড়াটেদের জন্য কিছুটা আলাদা টেবিল তৈরি করা হয়েছে" তাই? মাল্টি স্কিমা এবং সমস্ত একই টেবিলগুলিতে কী সমস্যা? আপনি কি বলছেন যে আপনি সমস্ত স্কিমে অভিন্ন টেবিল কাঠামো পুনরায় তৈরি করতে চান না? বা আপনি কি বলছেন যে আপনি সমস্ত স্কিমাতে অভিন্ন কাঠামো তৈরি করতে পারবেন না?
এসলট

ভাল / আকর্ষণীয় প্রশ্নের জন্য +1
অ্যাডাডাভদেব

2
@ এসলট আমি প্রতিদিন ১০০০+ সাইনআপের সাথে ১০,০০০+ ভাড়াটে আশা করি। একক টেবিল-সংজ্ঞাতে (সংজ্ঞা = ভাগ করা, ডেটা = বিচ্ছিন্ন) কয়েক মিলিয়ন এন্ট্রি থাকা আমার হাজার হাজার টেবিল-সংজ্ঞাতে হাজার হাজার এন্ট্রি থাকার চেয়ে ভাল বোধ করে। যেহেতু অনেকেই এটি করে না আমি বহু-স্কিমার সাথে এতটা আত্মবিশ্বাসী নই।
মার্সেল জ্যাকওয়ার্থ

1
আমি ড্যানিয়েলের সাথে একমত, মাল্টি-ডাটাবেসগুলি সেই পরিসংখ্যানগুলির ভিত্তিতে বাদ দেওয়া হয়েছে। আমি তার প্রতিফলন করতে আমার উত্তর আপডেট করেছি, তবে এটি ইতিহাসের জন্য আরও রাখছি। ভাগ করা পদ্ধতির স্পষ্টভাবে সম্ভবত সবচেয়ে যুক্তিসঙ্গত পদ্ধতির বলে মনে হচ্ছে।
অ্যাডাএদেভ

2
থেকে dynjo একটি উত্তরে: " গ্রেট নিবন্ধ সঠিক বিষয়ের ওপর রায়ান বিগ থেকে"
ফেলিক্স Gagnon-Grenier

উত্তর:


95

তবে অবশ্যই কিছু সংস্থা রয়েছে যারা ভয় করে যে তাদের ডেটা আপোস হতে পারে, তাই আমরা অন্যান্য সমাধানগুলি মূল্যায়ন করছি।

এটি দুর্ভাগ্যজনক, কারণ গ্রাহকরা কখনও কখনও এই ভ্রান্ত ধারণা থেকে ভোগেন যে কেবল শারীরিক বিচ্ছিন্নতা যথেষ্ট সুরক্ষা দিতে পারে।

মাল্টি-টেন্যান্ট ডেটা আর্কিটেকচার শিরোনামে একটি আকর্ষণীয় এমএসডিএন নিবন্ধ রয়েছে , যা আপনি যাচাই করতে চাইতে পারেন। এইভাবে লেখকরা ভাগ করা পদ্ধতির দিকে ভুল ধারণাটিকে সম্বোধন করলেন:

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

কারিগরি এবং ব্যবসায়িক বিবেচনার ক্ষেত্রে নিবন্ধটি একটি সংক্ষিপ্ত বিশ্লেষণ করে যেখানে নির্দিষ্ট পদ্ধতির চেয়ে অন্যটির চেয়ে বেশি উপযুক্ত হতে পারে:

ভাড়াটিয়ার সংখ্যা, প্রকৃতি এবং আপনি যে সমস্ত ভাড়াটিয়ার পরিবেশন করার আশা করছেন তা আপনার ডেটা আর্কিটেকচারের সিদ্ধান্তকে বিভিন্ন উপায়ে প্রভাবিত করে। নিম্নলিখিত কয়েকটি প্রশ্ন আপনাকে আরও বিচ্ছিন্ন পদ্ধতির দিকে পক্ষপাত করতে পারে, অন্যরা আপনাকে আরও ভাগ করে নেওয়া পদ্ধতির দিকে পক্ষপাত করতে পারে।

  • আপনি কতজন সম্ভাব্য ভাড়াটিয়া লক্ষ্য করার প্রত্যাশা করছেন? আপনি কর্তৃপক্ষের সাথে সম্ভাব্য ব্যবহারের প্রাক্কলন করতে পারার কাছাকাছি হতে পারেন না, তবে বিশালতার আদেশের দিক দিয়ে চিন্তা করুন: আপনি শত শত ভাড়াটেদের জন্য কোনও অ্যাপ্লিকেশন তৈরি করছেন? হাজার হাজার মানুষ? হাজার হাজার? আরো? আপনার ভাড়াটিয়ার বেসটি যত বেশি আপনি প্রত্যাশা করেন, আপনি তত বেশি ভাগ করে নেওয়া পদ্ধতির বিষয়টি বিবেচনা করতে চান।

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

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

  • আপনি কি প্রতি-ভাড়াটে মান-সংযুক্ত পরিষেবাগুলি যেমন প্রতি-ভাড়াটে ব্যাকআপ এবং সামর্থ্য পুনরুদ্ধার করার প্রস্তাব করবেন? এই ধরনের পরিষেবাগুলি আরও বিচ্ছিন্ন পদ্ধতির মাধ্যমে অফার করা সহজ।


আপডেট: ভাড়াটেদের প্রত্যাশিত সংখ্যা সম্পর্কে আরও আপডেট করার জন্য।

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

সেই প্যারামিটারটি থেকে, এটি ভাগ করা-ডাটাবেসের মতো দেখায়, একক-স্কিমা পদ্ধতির পক্ষে সবচেয়ে উপযুক্ত। আপনি ভাড়াটিয়া প্রতি প্রায় 50Mb সঞ্চয় করছেন এবং কোনও ভাড়াটে অ্যাড-অন পাবেন না এই বিষয়টি এই পদ্ধতিরটিকে আরও উপযুক্ত করে তোলে।

উপরোক্ত উদ্ধৃত এমএসডিএন নিবন্ধে তিনটি সুরক্ষা নিদর্শন উল্লেখ করেছে যা ভাগ করে নেওয়া-ডাটাবেস পদ্ধতির জন্য সুরক্ষা বিবেচনা করে:

আপনি যখন নিজের অ্যাপ্লিকেশনটির ডেটা সুরক্ষা ব্যবস্থা নিয়ে আত্মবিশ্বাসী হন, আপনি আপনার ক্লায়েন্টদের একটি পরিষেবা স্তরের চুক্তি দিতে সক্ষম হবেন যা শক্তিশালী ডেটা সুরক্ষা গ্যারান্টি সরবরাহ করে। আপনার এসএলএ-তে, গ্যারান্টিগুলি বাদ দিয়ে, আপনি ডেটা আপোস না হওয়ার বিষয়টি নিশ্চিত করার জন্য আপনি কী কী ব্যবস্থা নেবেন তাও আপনি বর্ণনা করতে পারেন।

আপডেট 2: স্পষ্টতই মাইক্রোসফ্ট ছেলেরা এই বিষয়টি সম্পর্কে একটি নতুন নিবন্ধ সরিয়ে নিয়েছে / তৈরি করেছে, মূল লিঙ্কটি চলে গেছে এবং এটিই নতুন একটি: মাল্টি-টেন্যান্ট সাআস ডাটাবেস টেন্যান্সি প্যাটার্ন (শাই কেরারের কাছে)


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

1
@ মার্সেল: তবে সুরক্ষার বিষয়ে গ্রাহকদের ধারণার দিকটি বাদে আমি বিশ্বাস করি যে কোনও সিদ্ধান্তের ভিত্তিতে মাল্টি-টেন্যান্ট গ্রহণ করা উচিত, সেই বিষয়ে আমি এমএসডিএন নিবন্ধ থেকে উদ্ধৃত 4 দফার মতো বিষয়ের উপর ভিত্তি করে থাকি: ১. ভাড়াটেদের প্রত্যাশিত সংখ্যা । - 2. প্রতিটি ভাড়াটে জন্য স্টোরেজ প্রয়োজনীয়। - ৩. সমবর্তী ব্যবহারকারীদের প্রত্যাশিত সংখ্যা। - 4. প্রতি ভাড়াটে অ্যাডোনস প্রত্যাশিত।
ড্যানিয়েল ভ্যাসালো

1
বিভাগটি নির্দেশ করার জন্য ধন্যবাদ। সংখ্যা = 10 কে, স্টোরেজ = 50 এমবি, ভাড়াটে প্রতি একত্রে সমাপ্ত ব্যবহারকারী = 2, অ্যাডনস = 0 তাই বর্তমানের ভাগাভাগি করার পদ্ধতিটি সবচেয়ে যুক্তিসঙ্গত বলে মনে হয়। আমি মনে করি গ্রাহকদের আসলে কী প্রয়োজন / প্রত্যাশা রয়েছে তা জানতে আমি পরের সপ্তাহে কিছু কল করব। জার্মানি এবং ডেটা / আইটি-সুরক্ষা সত্যিই শক্ত গল্প।
মার্সেল জ্যাকওয়ার্থ

1
কেবল এখন থেকে এটি পড়ার জন্য, উল্লিখিত নিবন্ধটির আর অস্তিত্ব নেই, কেউ একটি অনুলিপি তৈরি করেছেন, সম্ভবত?
gmslzr

1
@ গুইলেসালাজার আমি নিশ্চিত যে এটি একইরকম নয় তবে আমি অনুমান করি এটি হ'ল - ডকস.মাইক্রোসফট /en - us / azure /sql - database/… (@ ড্যানিয়েলভাসালো যদি এটি একই হয় তবে সম্ভবত আপনার লিঙ্কটি আপডেট করার বিষয়ে বিবেচনা করুন) উত্তর :-))
শায়ে কেরার

20

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

অন্তর্ভুক্ত করার কারণগুলি:

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

আমি আশা করি এটি কিছু কার্যকর ইনপুট সরবরাহ করে! আরও কারণ আছে, কিন্তু আমার মন ফাঁকা হয়ে গেছে। যদি এটি পিছনে ফিরে আসে তবে আমি আপডেট করব :)

সম্পাদনা:
যেহেতু আমি এই উত্তরটি পোস্ট করেছি, এখন এটি স্পষ্ট হয়ে গেছে যে আমরা 10,000+ ভাড়াটে কথা বলছি। আমার অভিজ্ঞতা শত শত বৃহত্তর ডাটাবেসের মধ্যে - আমি মনে করি না 10,000 টি পৃথক ডাটাবেসগুলি আপনার দৃশ্যের জন্য খুব পরিচালনাযোগ্য হতে চলেছে, তাই আমি এখন আপনার দৃশ্যের জন্য মাল্টি-ডিবি পদ্ধতির পক্ষে নিচ্ছি না। বিশেষত এটি এখন স্পষ্ট হিসাবে আপনি প্রতিটি ভাড়াটে জন্য ছোট ডেটা ভলিউম কথা বলছেন!

আমার উত্তরটি এখানে যেমন রাখছে তেমনি এটি একই রকম নৌকায় অন্য লোকের জন্য কিছুটা ব্যবহার করতে পারে (কম ভাড়াটে সহ)


হ্যাঁ, দুঃখিত যে আমি এর আগে এটি পরিষ্কার করেছিলাম না। এখনও +1। ;)
মার্সেল জ্যাকওয়ার্থ

ডেটা সুরক্ষার কথা বলছেন, আপনি কি বলবেন যে প্রতিটি ডাটাবেস পৃথক সার্ভার / ভিএমগুলিতে স্থাপন করা উচিত? অথবা একক / ক্লাস্টারযুক্ত সার্ভারে বিভিন্ন এসকিএল ব্যবহারকারীদের সাথে সমস্ত ডাটাবেস থাকা কি যথেষ্ট নিরাপদ?
শায়ে

@ শায় - না, তাদের আলাদা আলাদা সার্ভারে রাখার দরকার নেই - কল্পনা করুন আপনার 100s রয়েছে, এটি আপনার প্রচুর সার্ভারের উদাহরণ / লাইসেন্সের দরকার যা আপনি শুরু করতে চান। ড্যানিয়েলের উত্তর আরও উপরে দেখুন, সেখানে কিছু ভাল লিঙ্ক রয়েছে।
অ্যাডাডাভদেব

আমি আবার যুক্তি দিয়ে বলব যে মাল্টি-ডিবি মানে 10,000 টি আলাদা আলাদা ডাটাবেস এবং টার্নের রক্ষণাবেক্ষণের ব্যয়টি উল্লেখযোগ্য পরিমাণে বাড়িয়ে দেয়, আপনি এখনও আপনার মেঘের অবকাঠামোতে অটোমেশন স্ক্রিপ্টগুলি ব্যবহার করে এই জন্তুকে দমন করতে পারেন যে সবকিছু প্রোগ্রামিকভাবে পরিচালিত হয়ে যায়, কিছুতেই কোনও মানবিক প্রচেষ্টা করা দরকার হয় না iring
Korayem

17

নীচে তারা সেলসফোর্স.কম-এ একটি সাদা-কাগজের লিঙ্কটি দিয়েছেন যে তারা কীভাবে বহু-ভাড়াটে প্রয়োগ করে:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

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

ঝামেলা কেন?

প্রতিটি ভাড়াটিয়া ডাটাবেস স্তরে পরিবর্তন না করে রান-সময়ে তাদের নিজস্ব ডেটা স্কিমটি কাস্টমাইজ করতে পারে (টেবিল পরিবর্তন করে)। এটি অবশ্যই এরকম কিছু করার শক্ত উপায় তবে এটি খুব নমনীয়।


10

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

প্রতি স্কিমা মডেল কেবল প্রত্যেকটির জন্য অনন্য স্কিমার জন্য কার্যকর নয়, যদিও এখনও সমস্ত ভাড়াটেদের জুড়ে মাইগ্রেশন চালানো কঠিন হয়ে পড়ে এবং 1000 এর স্কিমাতে পোস্টগ্র্রেস ঝামেলা শুরু করতে পারে।

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

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