100+ ক্লায়েন্ট ডিবি থেকে কেন্দ্রীভূত প্রতিবেদনের ডাটাবেসে ডেটা একীভূত করতে পরামর্শের সন্ধান করছেন


10

আমি একটি ছোট (~ 50 কর্মচারী) সাএস সংস্থার জন্য এসকিউএল বিকাশকারী (ডিবিএ বা আর্কিটেক্ট নয়)। আমাকে কীভাবে তা নির্ধারণের কাজ সেরে দেওয়া হয়েছে:

  1. আমাদের 100+ ওলটিপি ডাটাবেসগুলি থেকে অফলোড অপারেশনাল প্রতিবেদন
  2. এই প্রতিবেদনগুলিকে একাধিক ক্লায়েন্ট ডাটাবেস থেকে ডেটা বিরুদ্ধে চালানোর অনুমতি দিন
  3. ভবিষ্যতে আরও বিশ্লেষণ-ভিত্তিক সমাধান সরবরাহ করতে আমাদের সংস্থাকে অবস্থান দিন

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

আমি আশা করছি যে আপনারা কিছু সংহত দক্ষতার সাথে আমাদের মতো একটি সেটআপের মুখোমুখি হতে পেরেছেন এবং আমাকে একটি সফল পথ দেখিয়ে দিতে সক্ষম হতে পারেন বা এমন কিছু সংস্থান থেকে আমাকে গাইড করতে পারেন যা সহায়ক হবে।

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

বেসিক কনফিগারেশন:

বর্তমানে আমাদের কাছে 100+ পৃথক ক্লায়েন্ট ডাটাবেস রয়েছে, সর্বাধিক আমাদের ডেটা সেন্টারে এসকিউএল সার্ভারে মোতায়েন করা হয় তবে কিছু তাদের ক্লায়েন্ট সার্ভারগুলিতে তাদের ডেটা সেন্টারের মধ্যে মোতায়েন করা হয় যা আমরা রিমোট করতে পারি। এগুলি সমস্ত এসকিউএল সার্ভার ২০০৮ আর 2 ডাটাবেস, তবে আমরা শীঘ্রই এসকিউএল 2016 এ আপগ্রেড করার পরিকল্পনা করছি।

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

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

উচ্চ-স্তরের প্রয়োজনীয়তা:

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

বর্তমানে আমাদের কাছে পৃথক ডাটাবেসে কিছু এসপিডি রয়েছে যা প্রকৃতপক্ষে একই হাসপাতাল ব্যবস্থার অংশ। এই ক্লায়েন্টরা তাদের সিস্টেমে সমস্ত এসপিডি-র বিরুদ্ধে রিপোর্ট করার ক্ষমতা চায়।

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

এখন পর্যন্ত চিন্তা:

লেনদেনের প্রতিরূপ মনে হচ্ছে এটি সর্বাধিক "রিয়েল-টাইম" সমাধান সরবরাহ করবে। আমি এই প্রতিক্রিয়াটি বিশেষভাবে সহায়ক বলে মনে করেছি, তবে আমি উদ্বিগ্ন যে স্কিমা পার্থক্যের সম্ভাবনা থাকলে এটি আমাদের পক্ষে কার্যকর হবে না: এসকিউএল সার্ভার একাধিক টু ওয়ান প্রতিলিপি

প্রশ্নগুলি সক্রিয় থাকাকালীন লগটি পুনরুদ্ধার করতে পারে না তা প্রদত্ত লগ শিপিং আদর্শ মনে হয় না। আমাকে হয় সবাইকে বের করে দিতে হবে যাতে লগটি পুনরুদ্ধার করতে পারে বা ডেটা বাসি হয়ে যায়। একাধিক ডাটাবেস থেকে ডেটা কেন্দ্রীভূত করতে এই পদ্ধতিটি ব্যবহার করা যায় কিনা সে সম্পর্কে আমি অস্পষ্ট, যেহেতু প্রতিটি শিপড লগই কেবল এটির দ্বারা প্রাপ্ত পৃথক ডাটাবেসের জন্য হবে।

এসকিউএল পরিষেবা ব্রোকারটি ব্যবহার করে, কোনও সারি প্রক্রিয়া করার জন্য বার্তাগুলির সংখ্যাটি ধরে রাখতে অক্ষম হলে বিলম্ব হওয়া প্রত্যাশিত হতে পারে।

সিটি প্রতিটি টেবিল সারির জন্য কেবল একটি সংস্করণ সনাক্ত করে। সূক্ষ্মতা নির্ভর করে ডেটা পুনরুদ্ধার করতে এবং একটি কেন্দ্রীয় ভান্ডারে এটি সন্নিবেশ করানোর জন্য আমরা প্রতিটি ডাটাবেসের বিরুদ্ধে এসএসআইএস প্যাকেজের মতো কিছু দ্রুত প্রক্রিয়া করতে পারি তার উপর নির্ভরশীল।

আমাদের প্রতিটি ডাটাবেস পৃথকভাবে প্রতিলিপি বিবেচনা করা এবং তারপর বিভিন্ন প্রতিলিপি উত্স থেকে ডেটা একত্রিত করার জন্য সম্ভবত কিছু ধরণের ডেটা ভার্চুয়ালাইজেশন কৌশল ব্যবহার করা উচিত?

আপনি যে কোনও পরামর্শ বা দিকনির্দেশনা দিতে ইচ্ছুক তা প্রশংসিত হবে।


1
আপনার (কাছাকাছি) রিয়েল-টাইম প্রয়োজনের কারণে, আমি কেবল কিছু বার্তা সারি বাস্তবায়ন (বিতরণ গ্যারান্টির) সাথে ইভেন্ট ভিত্তিক প্রক্রিয়াকরণটিতে নজর দেব। আশা করি এটি সহায়তা করে
গ্রিমাল্ডি

1
আমি মিশ্রণে HTAP নিক্ষেপ করব। en.m.wikedia.org/wiki/Hybrid_Transactional/… সাধারণ স্টোরটি জনবহনের জন্য বিআইএমএল এবং এসএসআইএস।
মাইকেল গ্রিন

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

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

1
হ্যাঁ কলামস্টোর কিন্তু মেমরির মধ্যেও যদি আপনার সার্ভার স্পেস আপনাকে সেখানে যেতে দেয়। আমি সম্প্রতি সুনীল আগরওয়ালের কথা শুনেছি। এমএসের নিয়মের অফ আঙুলটি শূন্য ল্যাটেন্সি প্রতিবেদনের সুবিধার জন্য প্রায় 3% ওলটিপি’র অবনতি হয়েছিল। দুঃখজনকভাবে কোনও বিনামূল্যে মধ্যাহ্নভোজন নেই; আপনি রিপোর্টিং ডিবি ধরে রাখতে নতুন দৃষ্টান্ত তৈরি করতে পারেন বা HTAP সমর্থন করার জন্য পর্যাপ্ত হেডরুম অর্জনের জন্য আপনি নতুন উদাহরণ তৈরি করতে পারেন। আমি এই প্যাটার্নের পক্ষে কথা বলছি না। এটি আপনার পক্ষে কাজ নাও করতে পারে। কেবল আপনাকে সচেতন করতে চেয়েছিলেন এটি বিদ্যমান ছিল।
মাইকেল গ্রিন

উত্তর:


1

আমাদের প্রতিটি ডাটাবেস পৃথকভাবে প্রতিলিপি বিবেচনা করা এবং তারপর বিভিন্ন প্রতিলিপি উত্স থেকে ডেটা একত্রিত করার জন্য সম্ভবত কিছু ধরণের ডেটা ভার্চুয়ালাইজেশন কৌশল ব্যবহার করা উচিত?

হ্যাঁ. আপনি একক দৃষ্টিতে একাধিক গ্রাহক ডাটাবেস হোস্ট করতে পারেন, এবং তারপরে ভিউগুলি সহ তাদের জুড়ে জিজ্ঞাসা করতে বা একীভূত ডেটাবেসে লোড করতে পারেন।


এই মতামতগুলি সেটআপ করার আরও কি দুর্দান্ত উপায় আছে ... যেমন ফিল্ড 1, ফিল্ড 2, ফিল্ড 3 [ডাটাবেস 1] থেকে নির্বাচন করুন। [স্কিমা] [ ।] [tablename]
bperry

1

আপনার উপরের বর্ণনা অনুসারে নীচের লিঙ্কটি আপনাকে এবং আমি একই দৃশ্যে কাজ করতে সহায়তা করবে single একক গ্রাহক সহ একাধিক প্রকাশক।

  1. 1,2,3 এর মতো ডিফল্ট মান সহ সার্ভার_আইডির মতো আরও একটি কলাম যুক্ত করুন এবং এটি সম্মিলিত প্রাথমিক কী তৈরি করুন।

  2. প্রকাশনাগুলি তৈরি এবং নিবন্ধগুলি যুক্ত করার সময়, নিবন্ধের বৈশিষ্ট্যটি নাম ব্যবহারের ক্ষেত্রে অ্যাকশনটি ডেটা মুছতে সেট করা দরকার। যদি নিবন্ধটিতে একটি সারি ফিল্টার থাকে তবে কেবল ফিল্টারের সাথে মেলে এমন ডেটা মুছুন। এটি নিউ পাবলিকেশন উইজার্ড আর্টিকেল প্রোপার্টি ডায়ালগ ব্যবহার করে বা প্রতিলিপি সঞ্চিত প্রক্রিয়াগুলি sp_addarticle ব্যবহার করে এবং @pre_creation_cmd আর্গুমেন্টের জন্য মোছার মান নির্দিষ্ট করে সেট করা যেতে পারে। এইভাবে, যখন কেন্দ্রীয় গ্রাহক একাধিক প্রকাশনার স্ন্যাপশটগুলি থেকে আরম্ভ বা পুনরায় পুনঃনির্মাণ করা হয়, তখন পূর্বে প্রয়োগ করা স্ন্যাপশট ডেটা সংরক্ষণ করা হবে কারণ কেবলমাত্র ফিল্টার ক্লজের সাথে মেলে ডেটা মুছে ফেলা হবে।

এখানে চিত্র বর্ণনা লিখুন

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/


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

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

আপনার সমাধানটি আমি বুঝতে পেরেছি তা নিশ্চিত করুন। ধরা যাক প্রকাশক এ সংস্করণ 1-এ রয়েছে এবং প্রকাশক বি 2 সংস্করণে রয়েছে। 1) আপনি উভয় প্রকাশকের স্কিমা পরিবর্তনের প্রতিলিপি বন্ধ করেছেন (সেটআপে প্রতিলিপি_ডিডিএল = 0 ব্যবহার করে)। ২) সংস্করণ ২-এ একটি নতুন কলাম অন্তর্ভুক্ত রয়েছে, যাতে আপনি এটি ম্যানুয়ালি কেন্দ্রীয় গ্রাহক হিসাবে যুক্ত করতে পারেন। 3) পাবলিশার বি (আপগ্রেড করা) এ আপনি নিজেই নতুন কলামটিকে প্রতিলিপিতে (sp_articlecolumn ব্যবহার করে) যুক্ত করতে পারবেন। প্রকাশক এ তে কোনও পরিবর্তন করা হয় না এটি কি উভয় প্রকাশককে অনুলিপি না ভাঙিয়ে কেন্দ্রীয় গ্রাহকের প্রতিলিপি চালিয়ে যেতে অনুমতি দেবে?
বপারি

নীচের লিঙ্কটি দেখুন .. dba.stackexchange.com/questions/142449/…
গুলরেজ খান


1

একটি সম্ভাব্য আর্কিটেকচার:

ডেটা গুদাম ভিত্তিক সমাধান হিসাবে রিপোর্টিং বিবেচনা করুন।

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

এরপরে, ইটিএল: উত্স থেকে ডেটা গুদামে স্থানান্তর করা।

পরিবর্তন ট্র্যাকিং ব্যবহার করা এখানে একটি সম্ভাব্য বাস্তবায়ন।

প্রথমত, কেউ এমন কী মতামত বাস্তবায়িত করতে পারে যা তারা গ্রহণ করে তার ক্ষেত্রে সংস্করণ নির্দিষ্ট, তবে তারা কী ফিরে আসে সে অনুসারে অভিন্ন। উদাহরণস্বরূপ, যদি ব্যক্তি G লিঙ্গ সংস্করণ ২ সংস্করণে উপস্থিত থাকে তবে সংস্করণ 1-তে নেই, তবে সংস্করণ একের জন্য যে ব্যক্তিটি দেখতে পাবেন সে ফিরে আসতে পারে, বলুন, সংস্করণ 1-এর জন্য নালু।

গুদাম গ্রাহকের জন্য, সম্পূর্ণরূপে দর্শনগুলি পড়া, তথ্য একই আকার (সম্পূর্ণ ভিন্নতার সাথে)।

পরিবর্তন ট্র্যাকিং প্রতিটি রিফ্রেশে ডেটা পরিবর্তনের প্রয়োজন তা নির্ধারণের একটি (তুলনামূলকভাবে) হালকা ওজনের উপায় সরবরাহ করে।

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

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

এটি আপনার পক্ষে অবশ্যই সঠিক কিনা তা বলা শক্ত হবে।

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