গ্রাহক প্রতি ডাটাবেস তৈরি করতে আমি কী সমস্যা পাব?


48

আমার স্ট্যাকওভারফ্লো পডকাস্টগুলি থেকে মনে আছে যে ফোগ ক্রিক ফোগবগজের জন্য গ্রাহক প্রতি ডেটাবেস ব্যবহার করে । আমি ধরে নিলাম এর অর্থ ফোগবগজ অন ডিমান্ড সার্ভারগুলিতে 10s এর হাজার হাজার ডাটাবেস রয়েছে।

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

গ্রাহক প্রতি ডাটাবেস ব্যবহার করে আমার কী সমস্যাগুলি আশা করা উচিত? আমি কীভাবে এগুলি সমাধান করতে পারি?

আমার প্রাথমিক চিন্তা

গ্রাহক প্রতি একটি ডাটাবেসের সুবিধা

  • সহজ ডাটাবেস স্কিমা
  • সহজ ব্যাকআপ - আপনি প্রতিটি গ্রাহককে সত্যই অন্য গ্রাহকদের উপর প্রভাব ফেলতে না পারে ব্যাকআপ করতে পারেন।
  • প্রদত্ত গ্রাহকদের ডেটা রফতানি করা সহজ করে তোলে।
  • আরও ভাল ক্যাশে পারফরম্যান্স - আরও সক্রিয় টেবিলগুলির মধ্যে একটিতে লেখা কেবল সেই একক গ্রাহককেই প্রভাবিত করে যা এই লিখনটি সম্পাদন করে।
  • হার্ডওয়্যার জুড়ে স্কেল করা সহজ। উদাহরণস্বরূপ, যখন আমাদের 1 থেকে 2 সার্ভারে যেতে হবে তখন আমরা আমাদের অর্ধেক গ্রাহককে নতুন সার্ভারে স্থানান্তর করি।

অসুবিধেও

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

2
মনে রাখবেন যে "ডাটাবেস" অর্থ বিভিন্ন লোকের কাছে বিভিন্ন জিনিস। ওরাকল বিশ্বে, ব্যবহারকারী প্রতি একটি ডাটাবেস বিশাল ওভারকিল হবে। তবে মাইএসকিউএলে "ডাটাবেস" "স্কিমা" এর সমার্থক শব্দ।
গাইস

আমি এটি mysql অর্থে বলতে চাই। USE CompanyData;
রিক হেইউড


আমি স্কিমার সংস্করণ করা অসুবিধে করব না ... আরও কাজ, তবে সামগ্রিকভাবে ভাল
নীল ম্যাকগুইগান

উত্তর:


40

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

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

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


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

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

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

14

আমার অভিজ্ঞতায় আপনার গ্রাহক প্রতি একটি ডাটাবেস তৈরি করা উচিত নয়। আমাকে যদি আপনি একটি উদাহরণ দিতে:

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

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

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


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

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

1
আপনি ঠিক কী ভুল হয়েছে তার উদাহরণ দিতে পারলে ভাল লাগবে। অবশ্যই নিশ্চিত যে সমস্ত ডেটাবেস আপ-টু-ডেট রয়েছে, তবে সিদ্ধান্ত নিতে আমাদের পক্ষে বনাম কনস পরিমাপ করতে সক্ষম হতে হবে।
বরিস ক্যালেন্স

9

প্রতিটি গ্রাহক কোন সংস্করণে আছেন তা ট্র্যাক করার জন্য আপনি সম্ভবত অন্য একটি ডাটাবেস রাখতে চান, তবে কোনটি শেষ পর্বের সংশোধন করেছে বা না করেছে সে সম্পর্কে আপনি নজর রাখতে পারেন।

আপগ্রেডগুলির স্ক্রিপ্ট করা এতটা কঠিন হবে না ... আপনি ডাটাবেসের ক্যাটালগটিতে এমন কিছু লিখতে পারেন এবং প্রতিটি ডাটাবেসকে সর্বশেষ সংস্করণে আনার জন্য প্রয়োজনীয় পরিবর্তনগুলি প্রয়োগ করেছিলেন, সম্ভবত যে কারণে কোনও কারণে আপগ্রেড করা উচিত নয় sk

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

alter schema.table ...
select ... from schema.table

...

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

...

এছাড়াও, সচেতন হন যে তারা স্ট্যাক এক্সচেঞ্জের জন্য মাইএসকিউএল ব্যবহার করছেন না, তারা এসকিউএল সার্ভার ব্যবহার করছেন।

এবং সেই স্কেলটিতে মাইএসকিএলে কীভাবে ওভারহেডের পারফরম্যান্স করব তা আমার কোনও ধারণা নেই, আমি মনে করি না যে আমি কখনও মাইএসকিএলে 30 'ডাটাবেস' পেয়েছি।


আপনার ডিবিতে কোনও সংস্করণ তথ্য সারণী রাখবেন না কেন?
বরিস ক্যালেন্স

@ বরিস: কারণ আপনার যখন কয়েক ডজন বা শত শত ডাটাবেস রয়েছে তখন এটির সংস্করণ জিজ্ঞাসা করার জন্য প্রতিটি ডাটাবেসের সাথে সংযোগ স্থাপন করার জন্য গাধাটির ব্যথা অনেক বেশি। প্রত্যেকের নিজের ট্র্যাক করা কোনও খারাপ ধারণা নয়, তবে ডিবিএর জন্য মাস্টার তালিকা থাকাও মূল্যবান
জো

7

আমার কাছে একটি ওয়েব / ডিবি হোস্টিং ক্লায়েন্ট রয়েছে যাতে একই সংখ্যক টেবিল (162) এবং একই টেবিল স্ট্রাকচার সহ 750+ গ্রাহক ডাটাবেস রয়েছে। সংযুক্ত, আমার ক্লায়েন্টের সমস্ত গ্রাহকের ডেটা মোট 524GB (95% InnoDB)

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

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

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

আমার ক্লায়েন্টের ক্ষেত্রে, আমার সংস্থা মাইএসকিউএল 5.5 এর 9 ডিবি সার্ভারগুলি (কোয়াড কোড, 32 জিবি র‌্যাম, 824 জি রেড 10) থেকে দ্রুত ডিবি সার্ভারগুলিতে (ডুয়াল হেক্সা কোর [সঠিক 12 সিপিইউ], 192 গিগাবাইট র‌্যাম, 1.7 টিবি রেড 10) কমিয়েছে .9 (একাধিক সিপিইউগুলির সুবিধা নিতে সারণীতে)। এছাড়াও, প্রতি গিগাবাইটের 50 টি পার্টিশনে 150 গিগা ইন্নাডব বাফার পুলটি কল্পনা করুন (একাধিক ইনোডিবি বাফার পুলগুলি মাইএসকিউএল 5.5-তে একটি নতুন বৈশিষ্ট্য)। একটি ছোট স্কেল আউট, কিন্তু ব্যাপক পরিমাণে, আমার ক্লায়েন্টের অনন্য অবকাঠামোর জন্য কাজ করেছিল।

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


2
আমি জানি এটি সত্যিই পুরানো, তবে আমি ভাবছি যে উচ্চ-লেখার পরিবেশে এসএসডি সম্পর্কে আপনার মন্তব্যের পিছনে কী যুক্তি রয়েছে। আপনি আমাকে আলোকিত করতে পারেন?
এলেক্সেনাইড

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

2

মাইএসকিউএল পৃথক ডিরেক্টরিতে ডাটাবেস তৈরি করে তাই অনেকগুলি অন্তর্নিহিত অপারেটিং সিস্টেম এবং কতগুলি ফোল্ডার / ফাইল এটি পরিচালনা করতে পারে তার উপর নির্ভর করে। আধুনিক অপারেটিং সিস্টেমগুলির সাথে সমস্যা হওয়া উচিত নয় তবে সেখানেই প্রচুর বাধা আসবে।


1

আপনাকে ডেটাবেস বা অ্যাপের বিভিন্ন সংস্করণ হোস্ট করতে হবে বলে কিছু নেই isn't গ্রাহক প্রতি এক ডিবি করে ডাটাবেস এবং অ্যাপ্লিকেশনটির একটি সংস্করণ রেখে কেবল ডেটা বিচ্ছিন্ন করে কী ভুল? অবশ্যই প্রতিটি গ্রাহকের ডিবিকে বর্তমান কার্যকারী সংস্করণের টেমপ্লেট থেকে ক্লোন করতে হবে। সুরক্ষা এবং ডেটা বিচ্ছিন্নতার দিক থেকে, আমি মনে করি এটি আদর্শ।

আমি কেবলমাত্র খারাপ দিকটি দেখতে পাচ্ছি যে কোনও নতুন সংস্করণ তৈরি করার সময় আপনাকে প্রতিটি ডাটাবেস ম্যানুয়ালি আপডেট করতে হবে। যদিও এটি সহজেই স্বয়ংক্রিয় করা যেতে পারে।

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