1 বিলিয়ন সারি এবং গণনা পরিচালনা করার জন্য ডেটাবেস ডিজাইন


10

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

সমস্যাটি হ'ল এটি মনে হয় যে ডাটাবেসটি beingোকানো হচ্ছে এমন হারের হারের সাথে লড়াই চালিয়ে যাচ্ছেন। কখনও কখনও যখন লোড বৃদ্ধি পায়, সন্নিবেশের সময়টি হঠাৎ করে তীব্রভাবে বেড়ে যায় (> 30 সেকেন্ড), যার ফলস্বরূপ আরও ডেটা বাফার করা যায় যা ফলস্বরূপ বৃহত্তর সন্নিবেশ এবং দীর্ঘতর সময়কাল সন্নিবেশিত করে।

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

বর্তমান নকশা

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

টেবিল ডিজাইন

  • আইডি (পিকে, অনন্য সনাক্তকারী)
  • ডিভাইসআইডি (এফকে, ইনট)
  • পার্সোনআইড (এফকে, ইনট)
  • যানবাহন (এফকে, ইনট)
  • টোকেনআইডি (এফকে, ইনট)
  • ইউটিটাইম (পিকে, ডেটটাইম 2 (3))
  • অক্ষাংশ (ভাসা)
  • দ্রাঘিমাংশ (ভাসা)
  • গতি (ছোট)
  • শিরোনাম (ছোট)
  • উপগ্রহ (টিনিনেন্ট)
  • আইওডাটা (ভেরিবিনারি (100))
  • ইগনিশন স্টেট (টিনিনেন্ট)
  • ব্যবহারকারী ইনপুট (ক্ষুদ্রকায়)
  • ক্রিয়েটটাইমআউটসি (তারিখের সময় 2 (3))

সূচক

  • DeviceId_CreateTimeUtc_Desc
  • ডিভাইসআইডি_আউটসিটাইম_ডেস্ক (ক্লাস্টারড)
  • PersonId_UtcTime_Desc
  • TokenId_UtcTime_Desc
  • VehicleId_UtcTime_Desc

প্রতি সপ্তাহে সূচকগুলি সহ 10 গিগাবাইট সময় নেয় এবং বর্তমানে মূল ডাটাবেসে প্রায় 300 জিবি ডেটা রয়েছে।

মূল ডাটাবেসে ডেটা টেবিলগুলির 1 টি ফাইলের নিজস্ব ফাইলগ্রুপ রয়েছে তবে এটি মূল ডাটাবেসের অন্যান্য টেবিলের মতো একই ডিস্কে রয়েছে। মাধ্যমিক ডাটাবেসটি একটি পৃথক ডিস্কে রয়েছে, তবে একই মেশিনে রয়েছে।

আমি মনে করি আমরা যখন একটি নতুন টেবিল বিভাজন (সপ্তাহ) ব্যবহার করা হয় তখন আমরা সাপ্তাহিক পুনর্নির্মাণ কাজও চালাচ্ছি। কোন সঙ্কুচিত করা হয় না।

মেশিনটি একটি 8-কোর এইচপি যা 12 জিবি মেমরি সহ, এবং মূল ডাটাবেসযুক্ত ডিস্কটি RAID 10 চলছে।

ধারনা

  • প্রাথমিক ডাটাবেসে সঞ্চিত ডেটার পরিমাণ সীমাবদ্ধ করুন যেমন সর্বোচ্চ 1 মাস। খুব কমপক্ষে এটি ডাটাবেসটিকে ব্যাকআপ / পুনরুদ্ধারের জন্য আরও পরিচালনাযোগ্য করে তুলবে, তবে আমরা কি এটি করে কোনও পারফরম্যান্সের উন্নতি দেখতে আশা করতে পারি?
  • বর্তমান ডেটা জন্য ফাইলগ্রুপে 2 টি ফাইল তৈরি করুন এবং এগুলি 2 টি বিভিন্ন শারীরিক পার্টিশনে বিতরণ করুন
  • বর্তমান ডেটা ধারণ করে মাস্টার-স্লেভ ডাটাবেসগুলি তৈরি করুন, সুতরাং সন্নিবেশ এবং পঠনগুলি বিভিন্ন ডাটাবেসে সম্পাদিত হয়
  • এসএসডি ডিস্কগুলিতে বর্তমান ডেটাগুলির জন্য ফাইলগুলি রাখুন (এসএসডি ডিস্কগুলির সাথে কোনও পারফরম্যান্সের পার্থক্য তৈরি করবে?)

আরও তথ্যের প্রয়োজন হলে আমাকে জানান know কর্মক্ষমতা প্রভাবিত করে এমন মারাত্মকভাবে অনেকগুলি কারণ রয়েছে এবং সম্ভবত এটি সমানভাবে সম্পাদন করার বহু উপায়।


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

উত্তর:


8

প্রতি মিনিটে 5000 টি সন্নিবেশ করা হয় প্রতি সেকেন্ডে প্রায় 83 টি সন্নিবেশ। 5 টি সূচক সহ যা প্রতি সেকেন্ডে 400 টি শারীরিক সারি .োকানো হয়। যদি কাজের চাপটি স্মৃতিতে থাকে তবে এটি সার্ভারের ক্ষুদ্রতম এমনকি এমনকি কোনও সমস্যা তৈরি করবে না। এমনকি যদি এটি স্রেফ সারি সারি সন্নিবেশ করানো হত তবে আমি ভাবতে পারি এমন সবচেয়ে অকেজো উপায়। প্রতি সেকেন্ডে 83 টি তুচ্ছ প্রশ্নগুলি কোনও সিপিইউ দৃষ্টিকোণ থেকে আকর্ষণীয় নয়।

সম্ভবত, আপনি ডিস্ক-আবদ্ধ। আপনি অপেক্ষা পরিসংখ্যান দেখে বা এটি যাচাই করতে পারেন STATISTICS IO

আপনার প্রশ্নগুলি সম্ভবত বিভিন্ন পৃষ্ঠাগুলিকে অনেক স্পর্শ করে যাতে বাফার পুলটিতে সবার জন্য স্থান না থাকে। এটি ঘন ঘন পৃষ্ঠা পড়ার কারণ এবং সম্ভবত এলোমেলো ডিস্কও লেখার কারণ।

একটি টেবিলের কল্পনা করুন যেখানে ক্রমবর্ধমান কীটির কারণে আপনি কেবল শারীরিকভাবে সন্নিবেশ করান। কাজের সেটটি একটি পৃষ্ঠায় থাকবে: সর্বশেষটি। এটি ক্রমান্বয়ে আইও উত্পন্ন করবে পাশাপাশি অলস লেখক বা চেকপয়েন্ট প্রক্রিয়াটি ডিস্কে টেবিলের "শেষ" লিখবে।

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

আপনি মাঝখানে আপনার সূচকগুলি কাঠামোর মধ্যে রয়েছে (SomeValue, SequentialDateTime)। প্রথম উপাদানটি দ্বিতীয় দ্বারা সরবরাহিত ক্রমটি আংশিকভাবে এলোমেলো করে। আমার অনুমান SomeValueযে " " এর জন্য বেশ কয়েকটি সম্ভাব্য মান রয়েছে যাতে আপনার সূচীতে এলোমেলোভাবে স্থাপন করা সন্নিবেশ-পয়েন্ট থাকে।

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

আপনি যদি সাপ্তাহিক "পার্টিশনগুলির" আকারটি হ্রাস করতে পারেন বা সার্ভারের মেমরিটি কিছুটা বাড়িয়ে দিতে পারেন তবে আপনি সম্ভবত ভাল আছেন।

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

এখন এমনকি সমস্ত পড়তে এবং লিখতে মেমরির সাথে মানানসই হলেও আপনার এখনও এলোমেলো নোংরা পৃষ্ঠা ফ্লাশিং আইও থাকতে পারে। এ থেকে মুক্তি পাওয়ার একমাত্র উপায় হ'ল আপনার সূচীতে সহ-অবস্থিত অবস্থানগুলিতে লেখা। আপনি যদি নিজের সূচিগুলিকে মোটামুটি (আরও) সিকুয়েন্সাল কীগুলি ব্যবহার করতে রূপান্তর করতে পারেন যা অনেক সাহায্য করবে।

দ্রুত সমাধান হিসাবে আমি ক্লায়েন্ট এবং প্রধান টেবিলের মধ্যে একটি বাফারিং স্তর যুক্ত করব। হতে পারে একটি মঞ্চ টেবিলে 15 মিনিটের লেখাগুলি জমা করুন এবং পর্যায়ক্রমে এটি ফ্লাশ করুন। এটি লোড স্পাইকগুলি কেড়ে নেয় এবং বড় টেবিলে লিখতে আরও দক্ষ পরিকল্পনা ব্যবহার করে।


1
@ উসর খুব বিস্তৃত এবং সুস্পষ্ট বর্ণিত উত্তরের জন্য ধন্যবাদ! সার্ভারের মেমরিটি বাড়ানোর বিষয়ে আমরা আসলে আলোচনা করেছি, এর কতটা প্রভাব ফেলবে তা না জেনে - তবে এখন আমাদের কাছে এটি করার জন্য খুব বাধ্য করার কারণ রয়েছে :) আপনি ঠিক বলেছেন যে "সামোভ্যালু" আংশিকভাবে সন্নিবেশ পয়েন্টগুলিকে এলোমেলো করে তোলে - সম্ভবত সেখানে রয়েছে প্রায় 10000 ডিভাইস আইডি মঞ্চের টেবিলের বিষয়ে, আপনার পরামর্শটি কোনও সূচক ছাড়াই একটি টেবিল এবং তারপরে প্রতি X মিনিটে মূল টেবিলের মধ্যে প্রবেশ করানো কোনও কাজ?
সন্ডারগার্ড

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

1
যদি মঞ্চের টেবিলটি ছোট হয় এবং আপনার প্রশ্নগুলি এর সাথে বেঁচে থাকতে পারে তবে আপনার মোটেও সূচকের প্রয়োজন হবে না। তবে আপনি পারলেন ;; একটি কৌশল হ'ল একটি পরিচয় কলামে সিআই তৈরি করা (যেমন আপনি বলেছেন)। এটি সিআই বড় এবং অন্যান্য সূচকগুলি ছোট হলে এটি বিস্ময়করভাবে কাজ করতে পারে। কারণ সিআই র লেখাগুলি এখন ক্রমযুক্ত তারা আপনার সমস্যায় অনেক কম অবদান রাখে। অর্থনীতির আকারের পার্থক্য থাকলে এই কৌশলটি সবচেয়ে সফল; আর একটি ধারণা হবে প্রতিদিন একটি টেবিল রাখা। হতে পারে মাসিক মার্জ।
usr ডিরেক্টরির

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

2
গুরুতরভাবে যদিও, যে কেউ একই সমস্যার মুখোমুখি হচ্ছে, যদি আপনার প্রচুর লেখার পরিমাণ পাওয়া যায় এবং কেবল কয়েকটি পাঠ্য হয় তবে আপনি আসলেই শেষে যুক্ত হতে এবং কোনও সূচীকরণ বিলম্ব করতে চান। অন্যদিকে, আপনি যদি দ্রুত পঠন করতে চান এবং সন্নিবেশ করতে কতক্ষণ সময় লাগে সেদিকে খেয়াল রাখবেন না আপনাকে ক্লাস্টারড ইনডেক্সের প্রয়োজন।
টিকটাক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.