এসকিউএল সার্ভার ডাটাবেস শারডিং - সাধারণ ডেটা / নন শারড ডেটা দিয়ে কী করা যায়


10

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

আমরা এখন কোম্পানির বৃদ্ধি এবং ভবিষ্যতের বোঝা পরিচালনা করতে পারি তা নিশ্চিত করার জন্য আমরা ডাটাবেসটি তীক্ষ্ণ করতে চাইছি।

কোন বিশেষ ডেটা তীক্ষ্ণ করা উচিত আমরা তা স্থির করেছি। এটি আমাদের ডাটাবেসের একটি উপসেট যা অত্যন্ত কার্যকর।

যাইহোক, আমার প্রশ্নটি শারদযুক্ত ডেটা সম্পর্কিত যা সাধারণ / সর্বজনীন regarding এর মতো ডেটার উদাহরণ উদাহরণস্বরূপ কোনও ইনভেন্টরি টেবিল বা সম্ভবত কোনও কর্মচারী টেবিল, ব্যবহারকারীর টেবিল ইত্যাদি হতে পারে।

আমি এই সাধারণ / সর্বজনীন ডেটা পরিচালনা করতে দুটি বিকল্প দেখতে পাচ্ছি:

1) ডিজাইন 1 - বহিরাগত ডাটাবেসে সাধারণ / সর্বজনীন ডেটা রাখুন। সমস্ত লেখাগুলি এখানে ঘটবে। এই ডেটাটি প্রতিটি শার্ডকে এই ডেটাটি পড়তে এবং অভ্যন্তরীণভাবে টি-স্কেল প্র্যাক্সে অন্তর্ভুক্ত হওয়ার অনুমতি দিয়ে প্রতিটি শারডে প্রতিলিপি করা হবে।

2) ডিজাইন 2 - প্রতিটি শार्ডকে সমস্ত সাধারণ / সর্বজনীন ডেটার নিজস্ব কপি দিন। প্রত্যেকটি শারদ স্থানীয়ভাবে এই টেবিলগুলিতে লিখতে দিন এবং অন্য সমস্ত শার্ডগুলিতে এই ডেটাটি আপডেট / সিঙ্ক করতে বর্ধিত স্কয়ার একীভূত প্রতিলিপিটি ব্যবহার করুন।

নকশা # 1 সম্পর্কে উদ্বেগ

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

2) রেফারেন্সিয়াল অখণ্ডতা একটি ক্ষতি। ক্রস ডাটাবেস রেফারেন্সিয়াল অখণ্ডতা করা সম্ভব নয়।

3) সিস্টেমের বৃহত অঞ্চলগুলি পুনরায় পুনর্নির্মাণ করা যাতে এটি নতুন ইউনিভার্সাল ডাটাবেসে সাধারণ তথ্য লিখতে জানে তবে শার্ডগুলি থেকে সাধারণ ডেটা পড়তে পারে।

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

নকশা # 2 সম্পর্কে উদ্বেগ

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

আমি ডিজাইন অপশন # 2 নিয়ে কেউ চলে গেছে কিনা তা জানতে আগ্রহী। আমি জানতে আগ্রহী যে আমি ২ য় বা চতুর্থ ডিজাইনের বিকল্পটি দেখছি না যা আমি দেখতে পাচ্ছি না।

তুমাকে অগ্রিম ধন্যবাদ.


10
এই উদাহরণস্বরূপ, "একটি খুব বড় আকারের এন্টারপ্রাইজ ডেটাবেস" এবং হার্ডওয়্যারটি কী "ইতিমধ্যে একটি খুব উচ্চ স্তরের পর্যন্ত মাপানো হয়েছে"? 10 এর মধ্যে 10 বার, শারডিং সমাধান নয়, তাই আপনি যে সমস্যাটি সমাধান করছেন তা ভাবছেন।
মার্ক স্টোর-স্মিথ

5
সমস্ত গম্ভীরতার সাথে আপনি বলেছেন যে আপনার ওয়েব সার্ভারগুলি আপনার এসকিউএল বাক্সকে "হাতুড়ি" দেয়। কোন অনুপাত পড়ে: লেখ? কর্মক্ষমতা, ব্যয় বা জটিলতার জন্য ট্রেড-অফ সহ ডেটারটি কীভাবে হওয়া দরকার, তার উপর নির্ভর করে ট্রেড-অফ না করে শেডিং ছাড়াই পঠনের অনেকগুলি উপায় রয়েছে। এবং অবশ্যই লেখার জন্য কিউ করার উপায় রয়েছে, আবার কীভাবে ন্যানোসেকেন্ডের বিশ্রামের ডেটা থাকা দরকার তার উপর নির্ভর করে।
অ্যারন বারট্র্যান্ড

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

2
আপনার কাছে 64 লজিকাল প্রসেসর রয়েছে এবং সিপিইউ কি বাধা? ঠিক কি সিপিইউ ড্রাইভিং, recompiles? তুমি কি জানো?
অ্যারন বার্ট্র্যান্ড

1
আপনার শার্টিং শেষ হয়ে গেলে আপনার প্যান্টগুলি পরীক্ষা করুন।
সোয়াশেক

উত্তর:


5

আপনার প্রশ্ন এই উপর দৃষ্টি নিবদ্ধ:

যাইহোক, আমার প্রশ্নটি শারদযুক্ত ডেটা সম্পর্কিত যা সাধারণ / সর্বজনীন regarding এর মতো ডেটার উদাহরণ উদাহরণস্বরূপ কোনও ইনভেন্টরি টেবিল বা সম্ভবত কোনও কর্মচারী টেবিল, ব্যবহারকারীর টেবিল ইত্যাদি হতে পারে।

যখন আপনি শারডিং করছেন, এবং আপনার কাছে এমন ডেটা রয়েছে যা সমস্ত শার্ডকে দেখতে হবে, আপনাকে কয়েকটি বৈশিষ্ট্য সহ সেই ডেটাটিকে শ্রেণিবদ্ধ করতে হবে:

এটি ঘন ঘন পরিবর্তন হয়? আপনার উদাহরণগুলিতে আপনি তালিকা, কর্মচারী এবং ব্যবহারকারী তালিকাভুক্ত করেছেন listed সাধারণত জায়গুলি খুব দ্রুত পরিবর্তিত হয়, তবে কর্মচারী রেকর্ডগুলি কেবল পর্যায়ক্রমে পরিবর্তিত হয় (বলুন, প্রতি দিন কয়েক শত আপডেট)।

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

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

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

এখন, আপনার উদ্বেগ সম্পর্কে:

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

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

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

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

আমি এখানে বহু-ভাড়াটে ডেটাবেসগুলি ভাগ করার জন্য আরও ন্যূনতম পরিকল্পনা ও মতামত রেখেছি , যেমন পৃথক শার্ডগুলির উপর পারফরম্যান্স টিউনিং, প্রতি শারদ অনুসারে বিভিন্ন ব্যাকআপ / পুনরুদ্ধার কৌশল এবং স্কিমা স্থাপন চ্যালেঞ্জ।


0

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

তবে এসকিউএল সার্ভার এটির জন্য আপনার সেরা সমাধান কিনা তা আমি প্রশ্ন করব। কাজের চাপটি কি আরও ওএলটিপি বা ডাব্লু / বিআইয়ের মতো?

চিয়ার্স, ডেভ সিস্ক


-2

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


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