ওয়েব অ্যাপের প্রতিটি ক্লায়েন্টের জন্য একটি নতুন টেবিল তৈরি করা ভাল ধারণা হতে পারে?


10

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

একটি ওয়েব ভিত্তিক অ্যাপ্লিকেশনটি কল্পনা করুন - আসুন অ্যাকাউন্টিং সফটওয়্যারটি বলতে দিন - যার 20,000 ক্লায়েন্ট রয়েছে এবং প্রতিটি ক্লায়েন্টের একটি টেবিলটিতে 1000+ এন্ট্রি রয়েছে। এটি 20 মিলিয়ন সারি যা আমি জানি অবশ্যই জটিল প্রশ্নগুলি ধীর করতে পারে।

এর মতো ক্ষেত্রে, প্রতিটি ক্লায়েন্টের জন্য ডাটাবেসে একটি নতুন টেবিল তৈরি করা কি আরও বেশি অর্থবোধ করে? 20k (বা আরও বেশি!) সারণী থাকার ক্ষেত্রে ডাটাবেসগুলি কীভাবে প্রতিক্রিয়া জানায়?

উত্তর:


15

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

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


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

1
@ ক্রিসএফ, হুবহু - এমন অনেকগুলি কেস রয়েছে যেখানে প্রযুক্তি বা ব্যবসায়িক মডেল ক্লায়েন্টের জন্য পৃথক ডিবি চাইবে। তবে আমি একই ডিবিতে পৃথক সারণির কারণ মনে করতে পারি না ।
গ্র্যান্ডমাস্টারবি

1
@ গ্র্যান্ডমাস্টারবি - আমার মনে হয় @ উইল ভুল প্রশ্ন করছেন।
ক্রিসএফ

1
@ উইল: যদি সম্ভব হয় তবে একটি ওরাকল ইউজার গ্রুপের বৈঠকে যান বা অন্য কোনও উচ্চ-শেষ ডাটাবেসের সমতুল্য। আপনি দেখতে পাবেন যে "ছোট" এবং "বৃহত্তর" আপনার ধারণাগুলি প্রচুর পুনর্বিন্যাসের প্রয়োজন। এটা আমার সাথে ঘটেছিল. ইঙ্গিত: এটি যদি একটি ডিস্কে ফিট করে তবে এটি ডিবিএ স্ট্যান্ডার্ডের দ্বারা বড় নয়।
ডেভিড থর্নলি

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

5

খারাপ ধারণা মত শোনাচ্ছে।

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

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


অনুমতি পেলে আমি আপনার দুটি অনুচ্ছেদের প্রত্যেকটির জন্য একবার উত্থাপন করতাম।
ডেভিড থর্নলি

3

এখানে একটি নিবন্ধটি আমি সবসময় লোকদের পড়ার জন্য অনুরোধ করি, যখন তারা এই প্রশ্নটি করে:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html


আমি কোন ধারণা করে একটি ডিবি = এক্স টেবিল প্রতি প্রকৃত ফাইল তৈরি করে ফেলা
উইল

1
এটি ব্যবহৃত প্রকৃত আরডিবিএমএসের উপর নির্ভর করে। মাইএসকিউএল এটি করে (আপনি মাইএসএএম ব্যবহার করলে টেবিল প্রতি তিনটি পর্যন্ত ফাইল)। অন্যরা নাও পারে।
Mchl

এসকিউএল সার্ভারের এন্টারপ্রাইজ সংস্করণ এটি করবে যদি আপনি এটি সেভাবে ডিজাইন করেন তবে স্বয়ংক্রিয়ভাবে নয়।
জেফো

ওরাকল অবশ্যই তা করে না।
ব্যবহারকারী 281377

ওরাকল এসকিউএল সার্ভার যেভাবে এটি করতে পারে ঠিক সেভাবে এটি করতে পারে তবে আমি কেন কল্পনা করতে পারি না যে আপনি কেন নিজের স্কিমাটি প্রতি টেবিলের জন্য একটি ফাইল রাখার জন্য ডিজাইন করবেন। একাধিক ফাইলে ডাটাবেস বিভক্ত করা অর্থপূর্ণ, তবে টেবিলের জন্য একটি ফাইল নয়।
ডিন হার্ডিং

1

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

এই ধরণের টেবিলের জন্য একটি নোএসকিউএল টাইপ ডিবি ব্যবহার করা যেতে পারে।

20 কে ক্লায়েন্ট সহ, ডাটাবেসগুলি আপনার দুর্বলতম লিঙ্ক নাও হতে পারে, তবে কেন এই এত জটিলতার পরিচয় দিন?


Client আপনি ক্লায়েন্টআইডি বা আইওয়ের সাহায্যে তারিখের ক্ষেত্রের ভিত্তিতে একাধিক ফাইলের জন্য একটি একক টেবিল বিভাজন করতে পারেন `- আপনি এটির অর্থ কী তা নিশ্চিত হন না। কোন ব্যাখ্যা?
উইল

অপারেটিং সিস্টেমে একাধিক ফাইল। একটি সার্ভার কেবল একটির পরিবর্তে অনেকগুলি ফাইলে আরও পড়তে / লিখতে পারে।
জেফো

আমার ধারণা আমি বোঝাতে চাইছি: আমি কখনও এ জাতীয় কথা শুনিনি, এটি করার বিষয়ে আমি আরও তথ্য কোথায় পাই? :-) কিন্তু আমি গুগল আপ আঘাত করব ~
উইল

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx সূচিপত্রগুলি তালিকাভুক্ত টেবিলের চেয়ে আলাদা ফাইলগুলিতে থাকলে (বা সম্ভবত ড্রাইভ?) আপনি ব্যাকআপ পারফরম্যান্স সমস্যার সমাধান করতে পারেন।
জেফো

0

এটা সত্যিই খারাপ পদ্ধতির।

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

ইউজার_আইডি দ্বারা ডেটা বাছাই করুন এবং যদি এটি সম্ভব না হয় তবে প্রচুর পরিমাণে র‍্যাম বা এসএসডি ডিস্ক পান।

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