এসওএ-তে কোনও ডাটাবেস ভাগ করে নেওয়া কি পরিষেবাগুলির পক্ষে খারাপ অভ্যাস?

Question

আমি সম্প্রতি হোপ এবং উলফের এন্টারপ্রাইজ ইন্টিগ্রেশন প্যাটার্নস, এসওএ-র টমাস এরলের কয়েকটি বই এবং উদি দহন এট-এর বিভিন্ন ভিডিও এবং পডকাস্টগুলি পড়ছি। সিকিউআরএস এবং ইভেন্ট ড্রাইভ সিস্টেমে।

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

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

আমি ভেবেছিলাম এসওএ-র সীমানা কার্যকর করার অন্যতম উপায় - প্রতিটি পরিষেবার নিজস্ব ডেটাবেস থাকতে হবে তবে আমি এটি পড়েছি:

/programming/4019902/soa-joining-data-across-multiple-services

এবং এটি এটি করা ভুল জিনিস বলে প্রস্তাব দেয়।

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

Comments

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

— জেরেমি

আমি বুঝতে পারি যে প্রশ্নটি ভুল, এটি আমার উত্তরকে পুনর্বিবেচনা করতে বাধ্য করেছিল।

— পল টি ডেভিস

আমি মনে করি পরিষেবাগুলি অবশ্যই সংযুক্ত করতে হবে

— বি সেভেন

Answer 1

সত্যিকার অর্থে বিচ্ছেদ থাকলেই ডিকপলিং কাজ করে। আপনার যদি অর্ডার দেওয়ার ব্যবস্থা রয়েছে তবে তা বিবেচনা করুন:

• সারণী: গ্রাহক
• সারণী: অর্ডার

আপনার যদি এটিই হয়ে থাকে তবে এগুলি ডিকুয়াল করার কোনও কারণ নেই। অন্যদিকে, আপনার যদি এটি থাকে:

• সারণী: গ্রাহক
• সারণী: অর্ডার
• সারণী: CUSTOMER_NEWSLETTER

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

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

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

Comments

-1। সেগুলিকে সেখানে রাখার কোনও কারণ থাকলে কেবল সেগুলি পৃথক ডাটাবেসে থাকা উচিত। আপনার "এটি থেকে কিছু বেরিয়ে আসা" দরকার কারণ এটি অবশ্যই আপনার অ্যাপ্লিকেশনটিকে আরও জটিল করে তুলেছে।

— স্কটসক্ল্থেথস

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

— ক্রিস স্নো

হ্যাঁ, আপনার জটিলতার ব্যয় ওজন করা দরকার এবং যদি এটির মূল্য না হয় তবে আপনি কেবল পরিষেবাগুলিতে বিভক্ত হতে পারবেন না। বিভক্ত করা হলেও আমি খুঁজে পেয়েছি এমন একটি ভাগ করা ডাটাবেস ব্যবহার করা 3 টি বিকল্পের মধ্যে সবচেয়ে খারাপ।

— অবিচলিত

Answer 2

যেখানে আমি কাজ করি আমাদের একটি ইএসবি আছেযার সাথে 6 টি পৃথক অ্যাপ্লিকেশন (বা আমি "শেষপয়েন্টগুলি" বলি) সংযুক্ত। এই 6 টি অ্যাপ্লিকেশন 2 টি ডাটাবেস উদাহরণগুলিতে 3 টি ভিন্ন ওরেकल স্কিমার সাথে কাজ করে। এর মধ্যে কিছু অ্যাপ্লিকেশন একই স্কিমায় সহাবস্থান করে না কারণ সেগুলি সম্পর্কিত but সত্যিই এত দীর্ঘ সময় লাগে যে এক পর্যায়ে আমরা বিকাশ চালিয়ে যেতে সক্ষম হতে একটি বিদ্যমান স্কিমা "অস্থায়ীভাবে" পুনরায় ব্যবহার করার কথা ভেবেছিলাম। ডেটার "বিচ্ছেদ" প্রয়োগ করতে, সারণীর নামগুলি উপসর্গযুক্ত করা হয়, উদাহরণস্বরূপ গ্রাহকের জন্য "CST_"। এছাড়াও, আমাদের এমন একটি স্কিমা নিয়ে কাজ করতে হবে যা কিছু বৈধ কারণে আমরা নিখুঁত পরিবর্তন করতে পারি না ... এটি আমি জানি আশ্চর্য। অবশ্যই, এটি সর্বদা যেমন হয়, "অস্থায়ীভাবে"

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

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

আমরা আমাদের অ্যাপ্লিকেশন ডোমেনটিকে বিভিন্ন স্কিমা / ডাটাবেসে বিভক্ত করতে এবং ESB- তে পরিষেবাগুলি যখন এটি ঘটে তখন সঠিকভাবে কাজ করার জন্য (এটি শীঘ্রই বড়দিন, আমরা আঙ্গুলগুলি কর্স করছি) করতে পারি

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

পরিশেষে, আমি স্কট হুইটলকের শেষ অনুচ্ছেদে পুনরায় মন্তব্য করব না, বিশেষত এটি

আমি উদ্বেগ আলাদা করার কারণে আমি বিভিন্ন শারীরিক ডাটাবেসে টেবিলগুলি আলাদা করব না।

সত্যই গুরুত্বপূর্ণ। কোনও কারণ না থাকলে তা করবেন না।

Answer 3

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

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

এটি সহজ কথায় বলতে: আপনি যদি শিথিলভাবে কাপলড সিস্টেমে সন্ধান করছেন তবে ডেটা মিলিয়ে থাকবেন না। "লিঙ্গুয়া ফ্র্যাঙ্কা " চরিত্রে অভিনয় করে ওয়েল এনক্যাপসুলেটেড সিস্টেম এবং এর মধ্যে একটি সু-কাঠামোগত যোগাযোগ চ্যানেলের জন্য যান ।

Comments

এবং ... শিরোনাম প্রশ্নের সরাসরি উত্তর: "হ্যাঁ, আমি এটি একটি এসওএতে একটি ডাটাবেস ভাগ করে নেওয়া ঝুঁকিপূর্ণ অনুশীলন হিসাবে বিবেচনা করব", যদি এটি করা সবচেয়ে যুক্তিসঙ্গত জিনিস বলে মনে হয় তবে সম্ভবত কিছু গুরুতর নকশার ত্রুটি রয়েছে।

— ZioBrando

Answer 4

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

Answer 5

সঠিকভাবে করা হলে, ব্যবসায়ের উদ্বেগকে বিভিন্ন ডাটাবেসে (বা কমপক্ষে বিভিন্ন স্কিমার) আলাদা করা একটি পুণ্য ।

দয়া করে মার্টিন ফোলারের সিকিউআরএস প্যাটার্নের বর্ণনা দেখুন :

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

এবং এন সার্ভিসবাস আর্কিটেকচারাল নীতিগুলি :

কমান্ড ক্যোয়ারী বিচ্ছেদ

এই সমস্যাটি এড়ানোর একটি সমাধান ক্লায়েন্ট এবং সার্ভারের উপরে এমনকি সিস্টেম-স্তরে কমান্ড এবং কোয়েরিগুলিকে পৃথক করে। এই সমাধানে দুটি "পরিষেবা" রয়েছে যা ক্লায়েন্ট এবং সার্ভার উভয়ই বিস্তৃত হয় - একটি হ'ল কমান্ডের দায়িত্বে (তৈরি করুন, আপডেট করুন, মুছুন), অন্যটি অনুসন্ধানের দায়িত্বে (পড়ুন)। এই পরিষেবাগুলি কেবল বার্তাগুলির মাধ্যমে যোগাযোগ করে - একজন অন্যের ডেটাবেস অ্যাক্সেস করতে পারে না ...

এবং কমান্ড এবং কোয়েরি দায়বদ্ধতার বিভাজন (সিকিউআরএস)

কমান্ড এবং প্রশ্নের দায়বদ্ধতা বিভাজন

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