আপনি একটি এসকিউএল সার্ভারে রাখতে পারেন এমন ডাটাবেসের সংখ্যার কি কোনও সীমা রয়েছে?

Question

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

প্রশ্নাবলি

• একটি এসকিউএল সার্ভারে আপনার যে মাইক্রো-ডাটাবেসগুলি থাকতে পারে / থাকতে হবে সেগুলি সম্পর্কে কি ব্যবহারিক সীমাবদ্ধতা রয়েছে?
• এটি সার্ভারের কার্যকারিতা প্রভাবিত করতে পারে?
• প্রতি 100 এমবি এর 10,000 ডাটাবেস, বা 1 টিবি-র একটি ডাটাবেস রাখা কি ভাল?

অতিরিক্ত তথ্য

আমি যখন "মাইক্রো-ডাটাবেসগুলি" বলি, তখন আমি সত্যিকার অর্থে "মাইক্রো" মানে না; আমি কেবল বোঝাতে চাইছি যে আমরা হাজার হাজার গ্রাহককে লক্ষ্য করছি, সুতরাং প্রতিটি স্বতন্ত্র ডাটাবেসটি মোট ডেটা স্টোরেজের এক হাজারতম বা তার চেয়ে কম হবে। বাস্তবে, প্রতিটি ডাটাবেস 100MB চিহ্নের কাছাকাছি থাকবে, এটি কতটা ব্যবহার করবে তার উপর নির্ভর করে।

10,000 টি ডাটাবেস ব্যবহারের মূল কারণটি স্কেলাবিলিটি। ঘটনাটি হ'ল, সিস্টেমটির ভি 1 এর একটি ডাটাবেস রয়েছে এবং যখন ডিবি লোডের নীচে চাপ দিচ্ছিল তখন আমাদের কিছুটা অস্বস্তিকর মুহুর্ত হয়েছিল।

এটি সিপিইউ, মেমোরি, I / O - উপরের সমস্তটিকে স্ট্রেইন করছিল। যদিও আমরা এই সমস্যাগুলি স্থির করেছি, তারা আমাদের উপলব্ধি করেছিল যে এক পর্যায়ে এমনকি বিশ্বের সেরা সূচকগুলিও যদি আমরা আশা করি যতটা সফল, আমরা কেবল আমাদের সমস্ত তথ্য একটি বড় আকারের মধ্যে রাখতে পারি না ' তথ্যশালা. সুতরাং ভি 2 এর জন্য আমরা শ্যাডিং করছি, তাই আমরা একাধিক ডিবি সার্ভারের মধ্যে লোডকে বিভক্ত করতে পারি।

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

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

Answer 1

আমি এসকিউএল সার্ভারগুলিতে একক নজরে 8 থেকে 10 হাজার ডাটাবেস নিয়ে কাজ করেছি। এটা সুন্দর না।

সার্ভারটি পুনরায় চালু করতে এক ঘন্টা বা আরও বেশি সময় লাগতে পারে। 10,000 ডাটাবেসের জন্য পুনরুদ্ধার প্রক্রিয়া সম্পর্কে চিন্তা করুন।

অবজেক্ট এক্সপ্লোরারে কোনও ডাটাবেস নির্ভরযোগ্যভাবে সনাক্ত করতে আপনি এসকিউএল সার্ভার ম্যানেজমেন্ট স্টুডিও ব্যবহার করতে পারবেন না।

ব্যাকআপগুলি একটি দুঃস্বপ্ন, যেহেতু ব্যাকআপগুলি সার্থক হওয়ার জন্য আপনার জায়গায় কার্যকর একটি দুর্যোগ পুনরুদ্ধারের সমাধান থাকা দরকার। আশা করি আপনার দল সব কিছু স্ক্রিপ্টিংয়ে দুর্দান্ত ।

আপনি সংখ্যার সাথে ডাটাবেসের নামকরণের মতো কাজ করা শুরু করেন M01022এবং পছন্দ করেন T9945। নিশ্চিত করুন যে আপনি সঠিক ডাটাবেসের মধ্যে কাজ করছি, যেমন করতে চেষ্টা M001022পরিবর্তে M01022পারেন উন্মাদক হবে না।

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

উপরের তালিকাটি কেবলমাত্র সেই সমস্যাগুলির একটি ছোট্ট নমুনা যা আপনার জন্য সেই ধরণের স্কেলে পরিচালনা করার জন্য পরিকল্পনা করতে হবে।

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

সাবকি: HKEY_LOCAL_MACHINE Y সিস্টেম ST বর্তমানকন্ট্রোলসেট \ নিয়ন্ত্রণ
নাম: পরিষেবাদি পাইপটাইমআউট
প্রকার: REG_DWORD
ডেটা: পরিষেবা শুরুর সময়সীমা শেষ হওয়ার আগে মিলিসেকেন্ডের সংখ্যা

উদাহরণস্বরূপ, পরিষেবার সময় শেষ হওয়ার আগে 600 সেকেন্ড (10 মিনিট) অপেক্ষা করতে 600000 টাইপ করুন।

---

আমার উত্তর লেখার পর থেকে আমি বুঝতে পেরেছি যে প্রশ্নটি আজুরের কথা বলছে। সম্ভবত এসকিউএল ডাটাবেসে এটি করা এতটা সমস্যাযুক্ত নয়; সম্ভবত এটি আরও সমস্যাযুক্ত। ব্যক্তিগতভাবে, আমি সম্ভবত একটি একক ডাটাবেস ব্যবহার করে একটি সিস্টেম ডিজাইন করেছি, সম্ভবত একাধিক সার্ভার জুড়ে উল্লম্বভাবে ছাঁটাই করা হয়েছে, তবে অবশ্যই গ্রাহক হিসাবে এক-ডাটাবেস-নয়।

Comments

ভাল জিনিস. পোস্টারটি একাধিক ডাটাবেস ব্যবহার করার পদ্ধতি বিবেচনা করতে পারে তবে ডাটাবেস প্রতি একাধিক গ্রাহক যাতে ডাটাবেসের সংখ্যা সীমাবদ্ধ করতে পারে তবে তারা একাধিক সার্ভারে স্কেল করতে সক্ষম হতে পারে।

— টনি

আমি বর্তমানে উচ্চ 4 টি পরিসংখ্যানে একটি ডিবি গণনা সহ একটি উদাহরণ পরিচালনা করি এবং এগুলির অনেকগুলি প্রতিধ্বনিত করতে পারি। এই স্কেলটিতে অপারেট করার সময় উত্থাপিত আরও একটি সমস্যা হ'ল দীর্ঘ সময় ধরে সম্পাদনের পরিকল্পনাগুলি ক্যাশে করতে না পারা। ফলাফলটি অনেকগুলি সিপিইউ বার্নের পুনরায় সংশ্লেষিত ক্যোয়ারী পরিকল্পনাগুলি।

— aloc

Answer 2

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

আপনার ক্লায়েন্টের জন্য কেন আপনার 1 টি ডাটাবেস ব্যবহার করা উচিত তার ক্ষেত্রে আমার ক্ষেত্রে।

পেশাদাররা

• সহজ রক্ষণাবেক্ষণ। একটি ডিবি থাকার অর্থ আপনাকে কেবল নিজের জায়গার রক্ষণাবেক্ষণের কাজটি অনেকের পরিবর্তে এক জায়গায় করতে হবে। ব্যাক আপ নিতে 1000 টি বিভিন্ন ডাটাবেস পরিচালনা করার দুঃস্বপ্নটি কল্পনা করুন। 1000 ডিবি'র পরিসংখ্যান আপডেট করার বা সূচী পুনর্নির্মাণ সম্পর্কে বা DBCC CHECKDBকীভাবে?

• স্থাপনা কোড। ধরা যাক আপনার অ্যাপ্লিকেশন কোড বা রিপোর্টিংয়ে কোনও সঞ্চিত পদ্ধতিতে আপনার সমস্যা আছে। আপনার দ্রুত পরিবর্তন করা দরকার ... এখন আপনাকে সেই পরিবর্তনটি 1000+ ডিবিতে স্থাপন করতে হবে। না, ধন্যবাদ, আমি বরং না।

• সহজ দৃশ্যমানতা। এসএসএমএসে 1000+ ডিবি (কাঁপানো) খোলার চেষ্টা করা মাত্র চিত্র । এটি ব্যবহারিকভাবে সমস্যাটিকে অকেজো করে তুলবে এবং এসএসএমএস খোলার জন্য এবং রেন্ডার করতে একটি আশ্চর্যজনক সময় লাগবে। মনে রাখবেন, এটি যদি আপনি একটি শালীন নামকরণ কনভেনশন নিয়ে আসতে সক্ষম হন।

কনস

• নিরাপত্তা। লোকেরা যদি অন্য ডিবি হিসাবে থাকে তবে অন্যান্য গ্রাহকের ডেটা দেখার থেকে বাঁচানো সহজ হবে। তবে এটিকে রোধ করতে কিছু সাধারণ জিনিস আপনি করতে পারেন।

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

শেষ পর্যন্ত আমি মনে করি যে আপনার সেরা বেটে আপনার আবেদনের জন্য একটি ডিবি রয়েছে এবং কেবল ডিবিতে গ্রাহকের ডেটা বিভক্ত করা। এটি আপনাকে যে সমস্যাগুলি দিবে তা 1000+ ডাটাবেসগুলি পরিচালনা করার দুঃস্বপ্নের তুলনায় কিছুই হবে না।

Answer 3

এসকিউএল সার্ভারের সর্বাধিক সক্ষমতা স্পেসিফিকেশন উল্লেখ করে যে এখানে 32,767 এর সীমা রয়েছে।

এটি পারফরম্যান্সকে প্রভাবিত করবে কিনা, উত্তরটি হ্যাঁ, তবে এটি যেভাবে কার্য সম্পাদনকে প্রভাবিত করবে, এবং এটি যথেষ্ট হবে কিনা তা অগণিত কারণের উপর নির্ভর করবে।

এটি 10,000 টি ডাটাবেসে বিভক্ত করার কোনও ভাল কারণ না থাকলে আমি এক ডাটাবেসের সাথে যাব। একটি ব্যাকআপ বা 10,000 ব্যাকআপ? একটি সততা পরীক্ষা, বা 10,000? ১০,০০০ ছোট ডিবি ব্যবহার করার উপযুক্ত কারণ থাকতে পারে তবে এটি নির্ধারণের জন্য আপনি যথেষ্ট বিশদ জানাননি। আপনি যে প্রশ্নটি জিজ্ঞাসা করেছেন তা বেশ বিস্তৃত এবং সর্বোত্তম উত্তরটি কী তা জানার পক্ষে পর্যাপ্ত তথ্য নেই।

Answer 4

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

এসকিউএল সার্ভার সম্পর্কিত কিছু ভাল সংস্থান এখানে বিশেষত:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

আমি অন্যান্য উত্তরের সাথে থাকব, এতে আমি ডিফল্ট হিসাবে বহু-ভাড়াটেদের দিকে দৃ strongly ়ভাবে ঝুঁকতে থাকব , যদি না আপনি যদি মাল্টি-ইনস্ট্যান্সের পক্ষে মজাদার কারণী হন।

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

আপনি "মিলিয়ন" গ্রাহকের কথা বলছেন, কোনও বড় আকারের ক্লাউড-ভিত্তিক সফ্টওয়্যারকে পরিষেবা হিসাবে বিবেচনা করুন, জিমেইল, যাই হোক না কেন, আপনি খুব কমই মনে করেন যে তারা প্রতিটি নতুন সাইনআপের জন্য সম্পূর্ণ নতুন ডাটাবেস তৈরি করে, এখন আপনি কি করেন?

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

Answer 5

সিঙ্গেল-ডাটাবেসের পরামর্শে আমি যে ডাউনসাইডটি দেখতে পাচ্ছি তার মধ্যে একটি হ'ল ডেটা রোলিংয়ের সাথে করণীয় - আপনার যদি ভাড়াটে সেট আপ-এর প্রতি ডাটাবেস থাকে তবে আপনি প্রতিটি ক্লায়েন্টের ডেটা স্বাধীনভাবে পুনরুদ্ধার করতে পারেন (এবং নির্দিষ্ট সময়ে নির্দিষ্ট সময়ে)। যদি সেগুলি সবই একটি ডাটাবেসে থাকে তবে এটি আরও শক্ত হয়ে যায় (এবং তত বেশি ত্রুটি হওয়ার আশঙ্কা রয়েছে কারণ এটি সম্ভবত INSERT / UPDATE / DELETE বিবৃতি দিয়ে করা দরকার)।

Comments

+1 - প্রতি-ভাড়াটে এক-ডাটাবেস হওয়ার খুব কম অতি-পছন্দসই সুবিধা benefits

— ম্যাক্স ভার্নন

Answer 6

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

প্রসারিত করার জন্য প্রেরণা

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

উদ্বেগ জবাব

• সার্ভারটি পুনঃসূচনা করতে দীর্ঘ সময় লাগে: ঠিক আছে, তবে সাধারণ ক্রিয়াকলাপে আমরা কোনও সার্ভার পুনরায় আরম্ভ করার ইচ্ছা করি না। সিস্টেমটি শেষ পর্যন্ত 24/7 অনলাইন হতে হবে, সুতরাং যদি আমাদের ডাউনটাইম থাকে তবে এটি নির্ধারিত হবে, যাইহোক।
• ব্যাকআপস / দুর্যোগ পুনরুদ্ধার: আমরা ক্লাউডবেরি ব্যবহার করছি, যা সবকিছু স্বয়ংক্রিয় করে দেয়। কোন সমস্যা নেই.
• ডাটাবেসগুলির নামকরণ / এসএসএমএসে তাদের সনাক্তকরণ: গ্রাহকের নামের উপর ভিত্তি করে নামকরণ কনভেনশন সহজ। নামগুলি ভাগ করা থাকলে সিরিয়াল অঙ্কগুলি যুক্ত করুন।
• রক্ষণাবেক্ষণ: প্রতিটি ডেটাবেস যদি আমি কল্পনা করেছিলাম ততই ছোট, সূচিগুলি ম্যানুয়ালি পুনর্নির্মাণ করার দরকার নেই।
• ডিপ্লোয়িং কোড: আমরা সত্তা ফ্রেমওয়ার্ক ব্যবহার করি, সুতরাং প্রতিটি স্কিমা পরিবর্তন স্বয়ংক্রিয়ভাবে নতুন রিলিজ সহ প্রতিটি ডাটাবেসে আবর্তিত হবে। এটি সত্য, যদিও, আমরা যদি উত্পাদনের এমন কোনও পারফরম্যান্স সমস্যা আবিষ্কার করি যেটিকে সাধারণ সূচকের ঝাঁকুনির সাহায্যে স্থির করা যায় তবে কেবল এটিকে বাইরে ফেলে দেওয়া এত সহজ নয়। অন্যদিকে, প্রতিটি ডাটাবেস এত ছোট হওয়ার সাথে সাথে, উত্পাদন শার্টগুলিতে শোস্টোপার পারফরম্যান্স সংক্রান্ত সমস্যাগুলি হওয়ার সম্ভাবনা কম। এবং সাধারণ ডাটাবেসটি একটি একক ডিবি থেকে যায়, যা এই উদ্বেগগুলি প্রয়োগ করে না।

আপনার যদি মনে হয় আমি কিছু মিস করছি তবে মন্তব্যে আপনার কাছ থেকে ফিরে শুনে আমি খুশি হব!

Comments

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

— জে জেলোস

আমি বিশ্বাস করি যে আজকের ডিবি প্রযুক্তি ব্যবহার করে 'শার্পিং' করার প্রায় সব কারণই আর বৈধ নয়। আমি বিশ্বাস করি আপনি হয় রাস্তাটির জন্য আফসোস করবেন অথবা আপনি বুঝতে পারবেন না যে আপনি তুলনামূলকভাবে কতটা খারাপ আছেন এবং তাই অজ্ঞতার কারণে আফসোস করবেন না। আমি ম্যাক্সের উত্তরের সাথে একমত এবং এর থেকে আরও ভাল করে ব্যাখ্যা করতে পারলাম না।

— জো