এই টেবিল ডিজাইনগুলির মধ্যে কোনটি পারফরম্যান্সের জন্য ভাল?


16

আমাকে অ্যাকাউন্টে সংগ্রহ করার জন্য প্রতিদিনের ব্যয় ট্র্যাক করে এমন কিছু তৈরি করতে বলা হয়েছে এবং আমি এটি ডেটাবেস টেবিল স্কিমা বের করার চেষ্টা করছি যা এটি সমর্থন করবে।

আমি যা জানি তা এখানে

  • সংস্থার 2.5 মিলিয়নেরও বেশি অ্যাকাউন্ট রয়েছে
  • এর মধ্যে বর্তমানে তারা প্রতি মাসে গড়ে 200,000 কাজ করে (যা কর্মীদের স্তরের সাথে পরিবর্তিত হয়, যা বর্তমানে কম)
  • তাদের 13 টি বিভিন্ন ধরণের দামের ট্র্যাক রয়েছে যা তারা ট্র্যাক করতে চায় এবং তারা সতর্ক করেছে যে তারা ভবিষ্যতে আরও যুক্ত করতে পারে
  • তারা চায় যে প্রতিদিন ব্যয়গুলি ট্র্যাক করা হোক
  • ব্যয় পুরো জায় জুড়ে বিভক্ত হয় না। তারা হয় প্রতি মাসে (200,000) কাজ করা অ্যাকাউন্টগুলির # টি জুড়ে বিভক্ত হয়ে পড়েছে, বা ব্যবহারকারীগণ একাউন্টের একটি গোষ্ঠীতে ব্যয় প্রয়োগ করতে অ্যাকাউন্ট শনাক্তকারীদের প্রবেশ করতে পারে, বা কোন অ্যাকাউন্টে ব্যয় প্রয়োগ করতে হবে তা কেবল তারা নির্দিষ্ট করতে পারে।

আমার প্রথম চিন্তাটি ছিল একটি সাধারণ ডাটাবেস:

অ্যাকাউন্ট আইডি
তারিখ
CostTypeId
পরিমাণ

এটি নিয়ে আমার সমস্যাটি হচ্ছে, গণিতটি করুন। এই টেবিলটি দ্রুত বিশাল আকার ধারণ করতে চলেছে। ধরে নিলে চলতি মাসের সমস্ত কাজের জন্য সমস্ত 13 টি ধরণের প্রযোজ্য অ্যাকাউন্ট প্রয়োগ করা হবে 200k * 13 * N days in month, যা প্রতি মাসে 75-80 মিলিয়ন রেকর্ডের কাছাকাছি বা প্রতি বছর এক বিলিয়ন রেকর্ডের কাছাকাছি।

আমার দ্বিতীয় চিন্তাটি এটিকে কিছুটা অস্বীকৃতি জানাতে হয়েছিল

অ্যাকাউন্ট আইডি
তারিখ
মোট খরচ
CostType1
CostType2
CostType3
CostType4
CostType5
CostType6
CostType7
CostType8
CostType9
CostType10
CostType11
CostType12
CostType13

এই পদ্ধতিটি আরও অস্বীকৃত এবং এটি প্রতিমাসে (6 200k * N days in month) বা প্রতি বছর প্রায় 72 মিলিয়ন রেকর্ড তৈরি করতে পারে । এটি প্রথম পদ্ধতির তুলনায় অনেক কম, তবে যদি ভবিষ্যতে সংস্থাটি নতুন কস্ট টাইপের বিষয়ে সিদ্ধান্ত নেয়, অন্য একটি ডাটাবেস কলাম যুক্ত করা দরকার।

দুটি পদ্ধতির মধ্যে কোনটি আপনি পছন্দ করেন? কেন? এমন আরও একটি বিকল্প আছে যা আপনি ভাবতে পারেন যে এটি আরও ভাল পরিচালনা করবে?

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

ডাটাবেসটি এসকিউএল সার্ভার 2005


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

উত্তর:


9

এক বছরে এক বিলিয়ন রেকর্ড বেশি নয়।

বিভাজন (প্রতি কস্টিপেতে সম্ভবত) এবং সংরক্ষণাগার সহ এটি পরিচালনাযোগ্য।

সংরক্ষণ করার জন্য ডেটা আইটেমের সংখ্যা এখনও 200 কে * 13 * এন col কলাম হিসাবে, আপনি প্রতি পৃষ্ঠায় কম সারি পাবেন এবং এটি সারিগুলির চেয়ে বেশি স্থান নেবে। "কস্টটাইপ 1" কোনও নির্দিষ্ট দৈর্ঘ্যের ডেটাটাইপ না হলেও আপনি লাভ করতে পারেন it's

তারা বলে যেমন "KISS"


3
@ রেচেল আমি নিশ্চয়ই একটি বৃহত ডেটা সেট করে একটি পার্টিশন স্কিমা বাস্তবায়নের পরামর্শ দিচ্ছি। যদি তারা মাসে-মাসে কাজ করে এবং প্রতিবেদন করার দিকে মনোনিবেশ করে থাকে তবে সেই মানসিকতার সাথে মিল রেখে পার্টিশন কী বেছে নেওয়া ভাল choose এছাড়াও, আপনি যদি নিজের পার্টিশনটি সঠিকভাবে কনফিগার করেন তবে আপনি সহজেই টেবিল থেকে স্টেজিং টেবিলগুলিতে সহজেই ডেটা স্যুইচ করতে পারেন যা বড় ডেটা লোড করে এবং ডালাগুলি মুছে ফেলার জন্য ঘন্টার পরিবর্তে কয়েক সেকেন্ড সময় লাগে sets
ডেভিড

6

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

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

আপনি যদি টেবিলটি বিভাজন করা চয়ন করেন, আপনি অ্যাক্সেসের সময় উন্নত করতে এবং সময় সন্নিবেশ করতে পারেন।


4

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

উদাহরণস্বরূপ, এটিএমের পরিবেশনার মোট ব্যয়টি অ্যাকাউন্টের মধ্যে বিভক্ত ছিল যা ব্যবহারের তুলনামূলক পরিমাণের ভিত্তিতে এটিএম ব্যবহার করেছিল। সুতরাং যদি $ 1m এর এটিএম সার্ভিসিংয়ে ব্যয় করা হয় এবং কেবল 5 জন গ্রাহক এটি একবার ব্যবহার করেন এবং একজন গ্রাহক এটি 5 বার ব্যবহার করেন, তবে সেই এক গ্রাহকের জন্য ব্যাঙ্ক $ .5m এবং অন্য গ্রাহকদের জন্য প্রতিটি ব্যয় $ .1m। অন্যান্য ড্রাইভারগুলি অনেক বেশি জটিল হতে পারে।

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


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

3

পারফরম্যান্স সুবিধাটি নির্বিশেষে, আমি অবশ্যই 1 বিকল্পের পক্ষে যাব O বিকল্প 2 আমার মতে পলকে অর্থ প্রদানের জন্য পিটারকে ছিনতাই করবে।


2

আমি বিকল্প 1 দিয়ে যাব এবং তারপরে রিপোর্টিংয়ের গতি যদি রাস্তায় সমস্যা হয়ে যায় তবে আমি টেবিল 2ও যুক্ত করব এবং রাতারাতি / অফপেক প্রক্রিয়াতে কোনও ধরণের স্বয়ংক্রিয়ভাবে এটি একটি রিপোর্টিং ডাটাবেসে পপুলেট করব।

এরপরেও আপনি যদি দৈনিক টেবিল 2-র কাঠামোটিকে আরও সাপ্তাহিক, মাসিক, ত্রৈমাসিক, বার্ষিক রোলআপগুলিতে সীমাবদ্ধ করা হয় তবে তা বিবেচনা করতে পারেন।

তবে, যেমনটি আমি বলেছি, আমি 'কাঁচা' তথ্যও যথাযথ (সাধারণকরণ) আকারে সঞ্চয় করতে পছন্দ করব।


0

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


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

AccountDate
-----------
AccountId  
Date  
AcDtID (surrogate key)

Costs
-------
AcDtID
CostTypeId  
Amount  

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


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

সম্ভবত, তবে তারপরে আপনি সত্যিই একটি ট্রানসিটিভ নির্ভরতা প্রবর্তন করেন। এই রেকর্ডগুলি কি কখনও আপডেট হবে? বা শুধু লিখিত এবং তারপর কেবল পড়া?

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

তারপরে প্রতিটি আপডেটের জন্য 2 টি আপডেটের প্রয়োজন হবে এবং টোটালকোস্ট ফিল্ডটি অসঙ্গতির ঝুঁকি যুক্ত করে।

ট্রানজিটিভ নির্ভরতা, তবে অগত্যা অসঙ্গতির ঝুঁকি নয় - একটি চেক () সীমাবদ্ধতা গ্যারান্টি দিতে পারে যে টোটালকস্ট সর্বদা ব্যয়ের যোগফল is
মাইক শেরিল 'ক্যাট রিক্যাল'

0

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

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