কোনও আলাদা মাইক্রোসার্কিসের দ্বারা "মালিকানাধীন" ডাটাবেস থেকে ডেটা পড়া এত খারাপ কেন?


64

আমি সম্প্রতি মাইক্রোসারভাইস আর্কিটেকচারের এই দুর্দান্ত নিবন্ধটি পড়েছি: http://www.infoq.com/articles/microservices-intro

এতে বলা হয়েছে যে আপনি যখন অ্যামাজনে কোনও ওয়েব পৃষ্ঠা লোড করেন, তারপরে 100+ মাইক্রোসার্ভেসিসগুলি সেই পৃষ্ঠাটি পরিবেশন করতে সহযোগিতা করে।

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

আমি কি এখানে কিছু মিস করছি? ডেটা কেবলমাত্র একটি এপিআইয়ের মাধ্যমে পড়তে হবে এমন আরও কিছু কারণ আছে?

বলা বাহুল্য, আমার সংস্থাটি অ্যামাজনের তুলনায় উল্লেখযোগ্যভাবে ছোট (এবং সর্বদা থাকবে) এবং আমরা যে ব্যবহারকারী হতে পারি তার সর্বাধিক সংখ্যা প্রায় 5 মিলিয়ন।


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

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

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

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

উত্তর:


69

তথ্য গোপনে ডাটাবেসগুলি খুব ভাল নয়, যা যথেষ্ট প্রশংসনীয়, কারণ তাদের কাজটি আসলে তথ্য প্রকাশ করা। এটি যখন encapsulation এর কথা আসে তখন এটি তাদেরকে একটি লস্য সরঞ্জাম হিসাবে তৈরি করে। আপনি কেন encapsulation চান?

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

স্টোরেজ আবেদন স্তর থেকে সরাসরি স্তর কার্যাক্ষম কি একান্ত বিপরীত নির্ভরতা বিপর্যয় নীতি করতে পরামর্শ দেয়।


1
এটি একটি দুর্দান্ত পয়েন্ট! একটা জিনিস যা আমাকে কম চিন্তিত করে তোলে তা হ'ল পোস্টগ্রিসের এখন ডকুমেন্ট স্টোর এবং আরডিবিএমএস উভয়ের জন্য সমর্থন রয়েছে ( ছাড়াই / পার্টিকালস / 2014-04-30- পোস্টস্ট্রেসক্ল্ল- নোএসকিএল )। আপনার বক্তব্যটি এখনও বৈধ, তবে আমি এটি সাবধানতার সাথে বিবেচনা করব।
ডেভিড

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

1
@ ডেভিড যদিও এটি আকর্ষণীয় খবর, আমি বর্ণনা করা দৃশ্যের জন্য এটি বেশ অপ্রাসঙ্গিক। আপনি যদি কোনও ডকুমেন্ট ভিত্তিক কোনও সম্পর্কিত থেকে আপনার ডিবি স্কিমা পরিবর্তন করেন তবে এর উপর নির্ভরশীল সকলের ক্ষেত্রেও এটির একই প্রভাব থাকবে: আপনাকে সমস্ত প্রশ্নের পুনর্লিখন করতে হবে। একই সাথে এই সমস্ত পরিবর্তনগুলি মোতায়েন করার দুঃস্বপ্নও রয়েছে, যাতে উপাদানগুলির মধ্যে সামঞ্জস্যতা সিস্টেম জুড়ে বজায় থাকে।
back2dos

1
@ ডেভিড: কয়েকটি ভাল সংজ্ঞায়িত ভিউতে অ্যাক্সেসকে সীমাবদ্ধ করার অর্থ হল এর সাথে আসা কিছু সুবিধা সহ অন্য একটি API তৈরি করা। যতক্ষণ না এটি কেবল দেখা হয় ততক্ষণ আপনি কেবল পঠনযোগ্য অ্যাক্সেসের মধ্যে সীমাবদ্ধ। এবং একটি উপাদান থাকা পরিষেবা API এবং ভিউ এপিআই উভয়ের উপর নির্ভর করে এটি খুব ভঙ্গুর করে তোলে frag সুতরাং যদি আপনি কোনও উপাদান দর্শনের উপর নির্ভর করে থাকেন তবে আপনি এটিকে কেবল পঠনযোগ্য বা উচ্চ-রক্ষণাবেক্ষণের জন্য নির্ধারিত করে রেখেছেন। আমি এখানে প্রযুক্তিগত debtণ গন্ধ। এছাড়াও আপনি এমনভাবে আনুভূমিক বিভাজন যুক্ত করতে চাইতে পারেন যাতে আপনার ডাটাবেস আপনাকে অনুমতি দেয় না।
back2dos

2
@ ডেভিড: দীর্ঘমেয়াদে কোডটি লিখতে যত সহজ হয় তার চেয়ে কোড পরিবর্তন করা আরও সহজ। আর্কিটেকচার বলে না যে "আপনার কোডটি এ জাতীয়ভাবে লেখা উচিত নয়", এতে বলা হয়েছে "যদি আপনি এটি করেন তবে আপনি এটি বজায় রাখার চেষ্টা করে ভয়াবহ দুঃস্বপ্ন ভোগ করবেন"। আপনি যদি প্রোটোটাইপগুলি কথা বলছেন তবে রক্ষণাবেক্ষণের প্রয়োজন হয় না। এগিয়ে যান. একটি প্রোটোটাইপটি যত সহজে সম্ভব একটি পয়েন্ট প্রমাণ করতে হবে। কিন্তু যখন কোনও সিস্টেমে সিসিফিয়ান স্ব-উত্সাহিত অত্যাচারে লিপ্ত না হয়ে সমস্ত প্রমাণিত পয়েন্ট একীভূত করার চেষ্টা করা হয়, আপনি অতিরিক্ত মাইল ছাড়াই ভাল।
back2dos

55

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

এখন, আপনি যদি তাদের ডাটাবেসে উঁকি দিয়ে যান

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

আপনাকে কেবল পঠনের অ্যাক্সেস দেওয়া হলে শেষ দুটি পয়েন্টগুলি ঘটতে পারে না, তবে অন্যান্য পয়েন্টগুলি যথেষ্ট ভাল কারণের চেয়ে বেশি are ভাগ করা ডাটাবেস একটি খারাপ জিনিস।

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


4
দয়া করে মনে রাখবেন যে পুরো প্রকল্পটিতে আপনি কেবলমাত্র বিকাশকারী হয়ে থাকলেও উপরের পয়েন্টগুলির সমস্তটি বৈধ। একটি জটিল প্রকল্প পরিচালনা করা, এমনকি নিজের দ্বারা, এই সমস্ত উদ্বেগকে ডাকে।
itbruce

15

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

আপনার উপাদান ব্যবসায় ডোমেনের বাইরে থাকা একটি ডাটাবেস থেকে লেখা এবং পড়া এমনকি এই স্থাপত্যশৈলীর বিপরীতে।

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

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

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

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


4

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

সেই সময়ে আমি যে সমস্যাগুলি দেখিনি যে পূর্বের উত্তরগুলি আমার দেখা উচিত ছিল বলে সুপারিশ করে তাই আমি মনে করি পূর্বের উত্তরে উত্থাপিত পয়েন্টগুলি আরও বিশদে বিশদভাবে দেখার জন্য এটি উপযুক্ত is

দৃশ্য: আপনি একটি আরডিবিএমএসের সাথে সরাসরি কয়েকটি উপাদান বেঁধে রাখেন এবং আপনি দেখেন যে একটি নির্দিষ্ট উপাদান পারফরম্যান্সের বোতল-ঘাড়ে পরিণত হচ্ছে

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

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

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

ডাটাবেসটিকে অস্বীকৃতি জানাতে পারে, তবে আপনি পারবেন না কারণ অন্যান্য সমস্ত উপাদান প্রভাবিত হবে

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

এই অ্যাপ্লিকেশনটির বিরতি একমাত্র উপায় যেখানে অ্যাপ্লিকেশন কোডটি "নির্বাচন করুন * ..." এর মতো কিছু ব্যবহার করে এবং কোনও অতিরিক্ত কলাম পরিচালনা করে না। আমার কাছে যে অ্যাপ্লিকেশনটিতে একটি বাগ হবে?

কীভাবে ড্যানোরালাইমেশন একটি অ্যাপ্লিকেশন ভাঙ্গতে পারে? আমার কাছে এফইউডি লাগছে।

স্কিমার নির্ভরতা:

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

মূল তথ্য

আমরা সাধারণত যে মাইক্রোসার্ফিসের কেবলমাত্র পঠনযোগ্য অ্যাক্সেস পেতে চাই সেই স্কিমাটি সাধারণত এন্টারপ্রাইজের জন্য " মাস্টার ডেটা " হিসাবে বর্ণনা করি । এটিতে মূল তথ্য রয়েছে যা এন্টারপ্রাইজের জন্য প্রয়োজনীয়।

.তিহাসিকভাবে এর অর্থ হ'ল আমরা যে স্কিমাটির উপর নির্ভরতা যুক্ত করব তা হ'ল পরিপক্ক এবং স্থিতিশীল (এন্টারপ্রাইজটির কিছুটা মৌলিক এবং অপরিবর্তনীয়)।

নিয়মমাফিককরণ

যদি 3 টি ডাটাবেস ডিজাইনাররা যান এবং একটি সাধারণ ডিবি স্কিমা ডিজাইন করেন তবে তারা একই নকশায় শেষ হবে। ঠিক আছে, কিছু 4NF / 5NF প্রকরণ থাকতে পারে তবে খুব বেশি নয়। আরও কী রয়েছে যে একাধিক প্রশ্ন রয়েছে যা ডিজাইনার মডেলটি যাচাই করতে চাইতে পারে যাতে ডিজাইনার আত্মবিশ্বাসী হতে পারে যে তারা 4 এনএফ-তে পৌঁছেছে (আমি কি খুব আশাবাদী? লোকেরা কি 4NF এ যাওয়ার চেষ্টা করছেন?)।

আপডেট: এখানে 4NF দ্বারা আমি বলতে চাইছি স্কিমার সমস্ত টেবিলগুলি 4NF পর্যন্ত তাদের সর্বোচ্চ স্বাভাবিক ফর্মটিতে পৌঁছেছে (সমস্ত টেবিলগুলি 4NF পর্যন্ত যথাযথভাবে স্বাভাবিক করা হয়েছে)।

আমি বিশ্বাস করি যে নরমালাইজেশন ডিজাইন প্রক্রিয়া হ'ল ডাটাবেস ডিজাইনাররা একটি সাধারণীকৃত ডেটাবেস স্কিমার উপর নির্ভর করে ধারণাটি নিয়ে সাধারণত স্বাচ্ছন্দ্য বোধ করেন।

নরমালাইজেশন প্রক্রিয়া একটি পরিচিত "সঠিক" নকশায় ডিবি ডিজাইন পায় এবং সেখান থেকে পরিবর্তিত হওয়াগুলি পারফরম্যান্সের জন্য অস্বীকৃত হওয়া উচিত।

  1. সমর্থিত ডিবি প্রকারের ভিত্তিতে বিভিন্নতা থাকতে পারে (জেএসএন, আরএআরএ, জিও টাইপ সমর্থন ইত্যাদি)
  2. কেউ কেউ 4NF / 5NF এর উপর ভিত্তি করে পরিবর্তনের পক্ষে তর্ক করতে পারে
  3. আমরা শারীরিক প্রকরণকে বাদ দিই (কারণ এটি কোনও ব্যাপার নয়)
  4. আমরা এটি ওয়ালটিপি ডিজাইনের মধ্যে সীমাবদ্ধ রাখি, ডিডাব্লু ডিজাইন নয় কারণ এগুলি সেই স্কীমা যা আমরা কেবলমাত্র পঠনযোগ্য অ্যাক্সেসকে দিতে চাই

যদি 3 প্রোগ্রামার যেখানে প্রয়োগ করার জন্য নকশাকে দেওয়া হয় (কোড হিসাবে) তখন প্রত্যাশাটি 3 টি বিভিন্ন বাস্তবায়নের (সম্ভাব্যভাবে খুব আলাদা) হয়ে থাকে।

আমার কাছে সম্ভবত "স্বাভাবিকায়নের বিশ্বাস" নিয়ে প্রশ্ন রয়েছে।

ব্রেকিং স্কিমা পরিবর্তন?

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

কলাম / সারণী বাদ দিয়ে বা ব্রেকিং টাইপ পরিবর্তন করে ব্রেকিং পরিবর্তনগুলি সম্ভবত সম্ভব। সম্ভাব্য হ্যাঁ, তবে ব্যবহারিক দিক দিয়ে আমি এখানে কোনও সমস্যাই অনুভব করি না। সম্ভবত কারণ বোঝা যাচ্ছে যে ব্রেকিং পরিবর্তনগুলি কী এবং এগুলি ভালভাবে পরিচালনা করা হয়েছে?

আমি কেবলমাত্র ভাগ-পঠনযোগ্য স্কিমার প্রসঙ্গে স্কিমা পরিবর্তনগুলি ভাঙার ক্ষেত্রে শুনতে আগ্রহী

কোনও মাইক্রোসারওয়াইস সম্পর্কে আরও গুরুত্বপূর্ণ এবং তাৎপর্যপূর্ণ কী: এর এপিআই বা এর ডাটাবেস স্কিমা? এপিআই, কারণ এটি বিশ্বের অন্যান্য অংশের সাথে চুক্তি।

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

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

এপিআই এর সমস্যাগুলি?

এখন যদি API এরগুলি নিখুঁত এবং সহজ হয় তবে সমস্ত পয়েন্টগুলি মোট হ'ল কারণ আমরা সর্বদা স্থানীয় পঠনযোগ্য অ্যাক্সেসের পরিবর্তে সর্বদা একটি API পছন্দ করি। সুতরাং কেবল স্থানীয় পঠনযোগ্য অ্যাক্সেস বিবেচনা করার প্রেরণা হ'ল এপিআই ব্যবহার করে কিছু সমস্যা হতে পারে যা স্থানীয় অ্যাক্সেস এড়ানো হয়।

What motivates people to desire local read-only access?

এপিআই অপ্টিমাইজেশন:

লিঙ্কডইনগুলিতে তাদের এপিআই অনুকূলকরণের বিষয়টি এবং তাদের স্কেলটিতে কেন এটি গুরুত্বপূর্ণ তা নিয়ে একটি আকর্ষণীয় উপস্থাপনা রয়েছে (২০০৯ থেকে) 2009 http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment

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

যদি লিঙ্কডইন-এর মতো পরিশীলিত API তে না থাকে তবে আপনি খুব সহজেই এমন পরিস্থিতিতে দেখতে পারবেন যেখানে:

  • আপনার দরকারের তুলনায় এপিআই অনেক বেশি ডেটা নিয়ে আসে (অপব্যয়)
  • চ্যাটি এপিআই যেখানে আপনাকে অনেকবার এপিআই কল করতে হবে

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

আমার সন্দেহ আছে যে সেখানে একটি সংখ্যক লোক রয়েছে যারা এটি এটিকে যুক্ত করতে পারে:

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

এই উত্তরটি অনেক দীর্ঘ হয়েছে। দুঃক্ষিত !!


একটি কলাম যুক্ত করা সাধারণত অ্যাপ্লিকেশনগুলিকে বিরতি দেয়। আপনার যদি "বেতন" থাকে তবে অ্যাপ্লিকেশনটি যা সমস্ত বেতনের সমাপ্ত হয় যখন একটি নতুন কলাম "বেতন_সামগ্রী" চালু হয়।
kubanczyk

সত্যি? আমি মনে করি আপনার "ব্রেক" এর সংজ্ঞা উপর নির্ভর করে। অ্যাপটি যদি "বেতন_সামগ্রী" ব্যতীত প্রত্যাশার মতো প্রযোজনা ও পরিচালিত হয় তবে আপনি কেন এখন সেই অ্যাপ্লিকেশনটিকে ভাঙ্গা ভাবেন?
রব বাইগ্রাভ

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

0

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

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