পুরানো তথ্য সংরক্ষণাগার

Question

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

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

---

তথ্য

• মোট ডাটাবেসে প্রায় 310'000'000 রেকর্ড রয়েছে।

• ডাটাবেসটির হার্ড ডিস্কে 250 গিগাবাইট প্রয়োজন।

• সার্ভার সংস্করণটি এসকিউএল সার্ভার ২০০৩ এর সাথে সামঞ্জস্যতা স্তরের এসকিউএল সার্ভার ২০০ ((90) রয়েছে তবে আমরা শীঘ্রই এসকিউএল সার্ভার ২০১২-তে আপগ্রেড করার পরিকল্পনা করছি

---

আমি দুটি সম্ভাবনা সম্পর্কে চিন্তা করেছি:

নতুন ডাটাবেস

প্রোডাকশন সার্ভারে থাকা অনুরূপ ডাটাবেস তৈরি করুন এবং নতুন ডাটাবেসে পুরানো সমস্ত ডেটা sertোকান।

• অসুবিধা: যেহেতু লিঙ্কযুক্ত সার্ভারগুলিকে আমাদের পরিবেশে অনুমোদিত নয়, প্রয়োজনে পুরানো ডেটাতে যোগদান করা কঠিন হবে

ইতিহাসের স্কিমা

প্রোডাকশন ডাটাবেসের মতো একই টেবিলগুলি সহ একটি নতুন স্কিমা ফে [হিস্ট] তৈরি করুন । নতুন স্কিমে এই নতুন টেবিলগুলিতে সমস্ত পুরানো ডেটা .োকান।

• সুবিধা: সহজ যোগদান, ভবিষ্যতে যদি পুরানো ডেটা প্রয়োজন হয়

---

---

• আপনি কি সমাধানগুলির মধ্যে অন্যটির চেয়ে বেশি পছন্দ করেন?
  • কেন?
• এর চেয়ে আরও ভাল সম্ভাবনা কি আছে?
• বিদ্যমান কোন সরঞ্জাম রয়েছে যার সাহায্যে এই কাজটি সহজেই সম্ভব?
• অন্য কোন চিন্তা?

আগাম ধন্যবাদ

সম্পাদন করা

অতিরিক্ত প্রশ্ন:

নতুন তৈরি আর্কাইভ টেবিলের জন্য কি প্রাথমিক / বিদেশী কী প্রয়োজন হবে?

বা তাদের কী কী কলাম / সীমাবদ্ধতা ছাড়াই কলামগুলি থাকা উচিত?

Comments

আপনি কোন সংস্করণটি ব্যবহার করছেন তা সম্ভবত উল্লেখযোগ্য এবং std / ent ইত্যাদি

— dwjv

এই ইঙ্গিতটির জন্য ধন্যবাদ, আমি অতিরিক্ত তথ্যে সংস্করণ যুক্ত করেছি। স্টাডি / এনট বলতে কী বুঝ? :-)

— এক্সরাফিম

আমার ক্ষমা, স্ট্যান্ডার্ড বা এন্টারপ্রাইজ সংস্করণ।

— dwjv

আহ ঠিক আছে :-) এটি এন্টারপ্রাইজ সংস্করণ

— এক্সেরফিম

Answer 1

আমি মনে করি আপনার অনেক প্রশ্নের উত্তর এটি নির্ভর করে। আপনার পারফরম্যান্সে কোন সমস্যা হচ্ছে? এটি অস্বাভাবিক বলে মনে হয় যে কোনও ডাটাবেসে কেবল 250 গিগাবাইট আকারে বাড়ানো থেকে পারফরম্যান্স সমস্যা হয়।

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

আপনি কি সমাধানগুলির মধ্যে অন্যটির চেয়ে বেশি পছন্দ করেন?

আমি সাধারণত ইতিহাসের ডেটাবেস পছন্দ করা, এবং আমি গাই এই জন্য ভাল কারণ বর্ণনা করে মনে তার প্রতিক্রিয়া ।

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

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

এর চেয়ে আরও ভাল সম্ভাবনা কি আছে?

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

নতুন তৈরি আর্কাইভ টেবিলের জন্য কি প্রাথমিক / বিদেশী কী প্রয়োজন হবে? বা তাদের কী কী কলাম / সীমাবদ্ধতা ছাড়াই কলামগুলি থাকা উচিত?

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

অন্য কোন চিন্তা?

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

Answer 2

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

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

Comments

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

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

Answer 3

আমার অভিজ্ঞতায় একটি দ্বিতীয় ডাটাবেস দুটি কারণে পছন্দসই পছন্দ হবে।

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

প্রাথমিক ডাটাবেস থেকে আপনার এখনও সমস্ত historicতিহাসিক ডেটা মুছতে হবে তবে এটি নির্ধারিত হতে পারে।

Answer 4

লাইসেন্সের জন্য এখন অবহেলা করা কারণ আমি এখানে আমার সময় কাটাচ্ছি না।

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

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

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

টেবিল বিভাজন একটি দুর্দান্ত সমাধান এবং একটি সংরক্ষণাগার টেবিল / স্কিমা এর অনেক সুবিধা বহন করে তবে ব্যবহারকারী / প্রশ্নের ক্ষেত্রে স্বচ্ছতা সরবরাহ করে। এটি বলেছিল, এটি কার্যকর করা সবচেয়ে জটিল এবং চলমান যত্নের প্রয়োজন যা কোনও শিক্ষানবিশের পক্ষে সহজ নয়।

কিছু গুরুত্বপূর্ণ বিবেচনা:

• প্রশ্নগুলি কি historicalতিহাসিক / ঠান্ডা ডেটা নিয়মিত ফিরিয়ে দেয় বা শীত ডেটা অবিশ্বাস্যভাবে অ্যাক্সেস করা হয়?
• Dataতিহাসিক ডেটা কি অপরিবর্তনীয় বা নিয়মিত আপডেট / মুছে ফেলা হয়?
• 310 মি সারিগুলি সারি আকারের উপর নির্ভর করে "মাঝারি" (1 টি টেবিলের মধ্যে সমস্ত ধরে নেওয়া)। আপনার কি সারি আকারের ডেটা আছে? 310 মিটার সারিটি কত জিবি?
• সেই টেবিলের বৃদ্ধির হার কত?
• আপনি কি অ্যাপ্লিকেশন কোড এবং এর এসকিউএল কোয়েরিগুলি সংশোধন করতে পারবেন?

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

এছাড়াও, আপনি যদি আপগ্রেড করার কথা ভাবছেন, তবে 2016 এবং নতুন স্ট্র্যাচ ডাটাবেস বৈশিষ্ট্যটি বিবেচনা করুন: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Answer 5

নিম্নলিখিত কারণে আমি পৃথক লজিকাল ডাটাবেসে ডাটাবেস বিভক্ত করতে পছন্দ করব:

1. রিসোর্স প্রয়োজনীয়তা

এটি একটি পৃথক ডাটাবেসে বিভক্ত করে, এটি একটি ভিন্ন ড্রাইভে সংরক্ষণ করা যায় এবং মূল উত্পাদনের ডেটাতে আলাদা হারে পর্যবেক্ষণ করা যেতে পারে।

2. কর্মক্ষমতা

একটি পৃথক ডাটাবেসে ডেটা বিভক্ত করার মাধ্যমে, সামগ্রিক কর্মক্ষমতাটিকে সহায়তা করে মূল প্রোডাকশন ডাটাবেসটি আকারে হ্রাস পেয়েছে।

3. সহজ ব্যাকআপ

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

দ্রষ্টব্য: আমি মনে করি আপনার অনেক প্রশ্নের উত্তর সবই আপনার পরিস্থিতি, উপাত্তের প্রকৃতি এবং আপনার যে পারফরম্যান্স সমস্যার সাথে ছিল তা নির্ভর করে।