চতুর DWH ডিজাইন পদ্ধতির ওভারভিউ

স্টোরেজ ডেভেলপমেন্ট একটি দীর্ঘ এবং গুরুতর ব্যবসা।

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

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

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

এবং যদি হঠাৎ করে একজন DWH বিকাশকারী হিসাবে আপনার শান্ত এবং আরামদায়ক জীবনে:

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

অথবা যদি আপনি কেবল শিখতে আগ্রহী হন যে আপনি কীভাবে স্টোরেজ তৈরি করতে পারেন - বিড়ালকে স্বাগতম!

"নমনীয়তা" মানে কি?

শুরু করার জন্য, আসুন "নমনীয়" বলার জন্য একটি সিস্টেমের কী বৈশিষ্ট্য থাকতে হবে তা সংজ্ঞায়িত করা যাক।

আলাদাভাবে, এটি উল্লেখ করা উচিত যে বর্ণিত বৈশিষ্ট্যগুলি বিশেষভাবে উল্লেখ করা উচিত পদ্ধতি, না প্রক্রিয়া এর উন্নয়ন। অতএব, আপনি যদি একটি উন্নয়ন পদ্ধতি হিসাবে চতুর সম্পর্কে পড়তে চান তবে অন্যান্য নিবন্ধগুলি পড়া ভাল। উদাহরণস্বরূপ, ঠিক সেখানে, হাব্রেতে, প্রচুর আকর্ষণীয় উপকরণ রয়েছে (যেমন পুনঃমূল্যায়ন и ব্যবহারিক, এবং সমস্যাযুক্ত).

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

সুতরাং, নমনীয় স্টোরেজ কি বৈশিষ্ট্য থাকা উচিত? এখানে তিনটি পয়েন্ট আছে:

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

এবং হ্যাঁ, একটি সিস্টেমে এই সমস্ত প্রয়োজনীয়তার সাথে সম্মতি সম্ভব (অবশ্যই, কিছু ক্ষেত্রে এবং কিছু সংরক্ষণের সাথে)।

নীচে আমি HD - এর জন্য সবচেয়ে জনপ্রিয় দুটি চটপটে ডিজাইন পদ্ধতি পর্যালোচনা করব অ্যাঙ্কর মডেল и ডেটা ভল্ট. বন্ধনীর বাইরে যেমন চমৎকার কৌশল রয়েছে, উদাহরণস্বরূপ, EAV, 6NF (এর বিশুদ্ধ আকারে) এবং NoSQL সমাধানের সাথে সম্পর্কিত সবকিছু - এই কারণে নয় যে সেগুলি একরকম খারাপ, এবং এমনও নয় যে এই ক্ষেত্রে নিবন্ধটি ভলিউম অর্জনের হুমকি দেবে। একটি গড় ডিসারের। এটি কেবলমাত্র এই সবগুলি একটি সামান্য ভিন্ন শ্রেণীর সমাধানকে বোঝায় - হয় এমন কৌশল যা আপনি নির্দিষ্ট ক্ষেত্রে প্রয়োগ করতে পারেন, আপনার প্রকল্পের সাধারণ স্থাপত্য নির্বিশেষে (যেমন EAV), বা বিশ্বব্যাপী বিভিন্ন তথ্য সংরক্ষণের দৃষ্টান্ত (যেমন গ্রাফ ডাটাবেস)। এবং অন্যান্য বিকল্প। NoSQL)।

"শাস্ত্রীয়" পদ্ধতির সমস্যা এবং নমনীয় পদ্ধতিতে তাদের সমাধান

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

1. সংযোগের অনমনীয় কার্ডিনালিটি

এই মডেল তথ্য একটি পরিষ্কার বিভাজনের উপর ভিত্তি করে পরিমাপ (মাত্রা) и ঘটনা (তথ্য). এবং এটি, অভিশাপ, যৌক্তিক - সর্বোপরি, অপ্রতিরোধ্য সংখ্যাগরিষ্ঠ ক্ষেত্রে ডেটা বিশ্লেষণ নির্দিষ্ট বিভাগে (মাত্রা) নির্দিষ্ট সংখ্যাসূচক সূচক (তথ্য) বিশ্লেষণে নেমে আসে।

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

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

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

এবং কিছুক্ষণ পরে, সহকর্মীরা একটি নতুন বিপণন কৌশল চালু করে যার মধ্যে একই সময়ে একাধিক প্রচার. এবং এখন আপনাকে একটি পৃথক বস্তুতে সম্পর্ক হাইলাইট করে টেবিলগুলি চূড়ান্ত করতে হবে।

(সমস্ত প্রাপ্ত বস্তু, যেখানে প্রচার চেক যোগদান করে, এখন উন্নত করা প্রয়োজন)।

ডেটা ভল্ট এবং অ্যাঙ্কর মডেলের লিঙ্ক

এই ধরনের পরিস্থিতি এড়াতে এটি বেশ সহজ বলে প্রমাণিত হয়েছে: আপনাকে বিক্রয় বিভাগকে বিশ্বাস করতে হবে না, এটি যথেষ্ট সমস্ত সম্পর্ক প্রাথমিকভাবে পৃথক টেবিলে সংরক্ষণ করা হয় এবং অনেক থেকে অনেক হিসাবে প্রক্রিয়া.

এই পদ্ধতির প্রস্তাব করা হয়েছে ড্যান লিনস্টেড দৃষ্টান্তের অংশ হিসাবে ডেটা ভল্ট এবং সম্পূর্ণরূপে সমর্থিত লার্স রনব্যাক в অ্যাঙ্কর মডেল.

ফলস্বরূপ, আমরা নমনীয় পদ্ধতির প্রথম স্বতন্ত্র বৈশিষ্ট্য পাই:

বস্তুর মধ্যে সম্পর্কগুলি পিতামাতার সত্তার বৈশিষ্ট্যগুলিতে সংরক্ষণ করা হয় না, তবে এটি একটি পৃথক ধরণের বস্তু।

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

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

2. ডেটা ডুপ্লিকেশন

নমনীয় আর্কিটেকচার দ্বারা সমাধান করা দ্বিতীয় সমস্যাটি প্রথম স্থানে কম স্পষ্ট এবং অন্তর্নিহিত। পরিমাপের ধরন SCD2 (ধীরে ধীরে দ্বিতীয় ধরনের পরিমাপ পরিবর্তন), যদিও শুধুমাত্র তাদের নয়।

ক্লাসিক সঞ্চয়স্থানে, একটি মাত্রা সাধারণত একটি টেবিল যা একটি সারোগেট কী (পিকে হিসাবে) এবং পৃথক কলামে ব্যবসায়িক কী এবং বৈশিষ্ট্যগুলির একটি সেট ধারণ করে।

যদি মাত্রা সংস্করণ সমর্থন করে, সংস্করণের সময়সীমা ক্ষেত্রগুলির মানক সেটে যোগ করা হয় এবং একাধিক সংস্করণ উৎসের প্রতি সারিতে সংগ্রহস্থলে উপস্থিত হয় (সংস্করণ বৈশিষ্ট্যগুলিতে প্রতিটি পরিবর্তনের জন্য একটি)।

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

একই সময়ে, এটি প্রায়শই ব্যবহৃত হয় অস্বাভাবিককরণ - কিছু বৈশিষ্ট্য ইচ্ছাকৃতভাবে একটি মান হিসাবে সংরক্ষণ করা হয়, এবং একটি রেফারেন্স বই বা অন্য মাত্রার রেফারেন্স হিসাবে নয়। এই পদ্ধতিটি একটি মাত্রা অ্যাক্সেস করার সময় যোগদানের সংখ্যা হ্রাস করে ডেটা অ্যাক্সেসের গতি বাড়ায়।

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

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

3. পরিশোধনের অরৈখিক জটিলতা

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

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

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

ডেটা ভল্ট এবং অ্যাঙ্কর মডেলে বস্তু এবং গুণাবলী সংরক্ষণ করা

নমনীয় আর্কিটেকচারের লেখকদের দ্বারা প্রস্তাবিত পদ্ধতিটি নিম্নরূপ প্রণয়ন করা যেতে পারে:

যা অপরিবর্তিত থাকে তা থেকে কী পরিবর্তন হয় তা আলাদা করা প্রয়োজন। যে বৈশিষ্ট্য থেকে আলাদাভাবে কী সংরক্ষণ করা হয়.

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

ডেটা ভল্ট এবং অ্যাঙ্কর মডেলে ঠিক কী অপরিবর্তিত হিসাবে বিবেচিত হতে পারে সে সম্পর্কে দৃষ্টিভঙ্গি আলাদা।

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

একই দৃষ্টান্তে অ্যাঙ্কর মডেল অপরিবর্তিত বলে বিবেচিত শুধুমাত্র সারোগেট কী সত্তা অন্য সবকিছু (প্রাকৃতিক কী সহ) তার বৈশিষ্ট্যগুলির একটি বিশেষ ক্ষেত্রে মাত্র। যার মধ্যে সমস্ত বৈশিষ্ট্য ডিফল্টরূপে একে অপরের থেকে স্বাধীন, তাই প্রতিটি বৈশিষ্ট্যের জন্য তৈরি করা আবশ্যক পৃথক টেবিল.

В ডেটা ভল্ট সত্তা কী ধারণকারী টেবিল বলা হয় হুবামি (হাব). হাবগুলিতে সর্বদা ক্ষেত্রগুলির একটি নির্দিষ্ট সেট থাকে:

• প্রাকৃতিক সত্তা কী
• সারোগেট কী
• উৎস লিঙ্ক
• রেকর্ডিং সময়

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

অন্যান্য সমস্ত সত্তা বৈশিষ্ট্য নামক বিশেষ টেবিলে সংরক্ষণ করা হয় উপগ্রহ (স্যাটেলাইট). একটি হাবে বেশ কয়েকটি উপগ্রহ থাকতে পারে যা বিভিন্ন বৈশিষ্ট্যের সেট সংরক্ষণ করে।

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

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

স্যাটেলাইটগুলি হাবের সাথে যোগাযোগ করে বিদেশী চাবি (যা 1-থেকে-অনেক কার্ডিনালিটির সাথে মিলে যায়)। এর মানে হল যে একাধিক অ্যাট্রিবিউট মান (উদাহরণস্বরূপ, একই গ্রাহকের জন্য একাধিক যোগাযোগের ফোন নম্বর) এই "ডিফল্ট" আর্কিটেকচার দ্বারা সমর্থিত।

В অ্যাঙ্কর মডেল চাবি সংরক্ষণ করা টেবিল বলা হয় নোঙ্গর. এবং তারা রাখে:

• শুধুমাত্র সারোগেট কী
• উৎস লিঙ্ক
• রেকর্ডিং সময়

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

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

তবে এখানে একটি প্রতারণামূলক মুহূর্ত রয়েছে: যদি বিভিন্ন সিস্টেমের বৈশিষ্ট্যগুলি একটি সত্তায় একত্রিত করা হয় তবে সম্ভবত কিছু আছে আঠালো নিয়ম, যার দ্বারা সিস্টেমকে বুঝতে হবে যে বিভিন্ন উত্স থেকে রেকর্ডগুলি সত্তার একটি উদাহরণের সাথে মিলে যায়৷

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

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

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

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

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

ডেটা ভল্ট এবং অ্যাঙ্কর মডেলের মধ্যে আরেকটি গুরুত্বপূর্ণ পার্থক্য হল উপস্থিতি লিঙ্কের জন্য বৈশিষ্ট্য:

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

ফ্যাক্ট স্টোরেজ

এ পর্যন্ত, আমরা প্রধানত মডেলিং পরিমাপ সম্পর্কে কথা বলেছি। ঘটনাগুলো একটু কম ক্লিয়ার কাট।

В ডেটা ভল্ট তথ্য সংরক্ষণের জন্য একটি সাধারণ বস্তু - লিঙ্ক, যার স্যাটেলাইটে বাস্তব সূচক যোগ করা হয়।

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

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

তদনুসারে, অ্যাঙ্কর মডেলে ফ্যাক্ট কী প্রসারিত করার সময় মডুলারিটির সাথে কোনও সমস্যা নেই (এটি কেবলমাত্র সংশ্লিষ্ট অ্যাঙ্করে একটি নতুন সম্পর্ক যুক্ত করার জন্য যথেষ্ট), তবে ঘটনাগুলি প্রদর্শন করার জন্য মডেলটিকে ডিজাইন করা কম সোজা, "কৃত্রিম" অ্যাঙ্কর প্রদর্শিত হতে পারে যে ব্যবসার অবজেক্ট মডেল প্রতিফলিত সুস্পষ্ট নয়.

কিভাবে নমনীয়তা অর্জন করা হয়

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

থেকে ডেটা ভল্ট লাভ নির্ভর করবে স্যাটেলাইটের মধ্যে বৈশিষ্ট্যের বন্টনের উপর এবং এর জন্য অ্যাঙ্কর মডেল — পরিমাপ বস্তুর প্রতি সংস্করণের গড় সংখ্যার প্রায় সরাসরি সমানুপাতিক।

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

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

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

ডার্ক পার্শ্ব

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

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

বেশ কয়েকটি তথ্য রয়েছে যা এই পরিস্থিতিটিকে সহজ করে তোলে:

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

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

উদাহরণস্বরূপ, এখানে এই নিবন্ধে একটি টেবিল থেকে একটি নির্বাচন সহ অ্যাঙ্কর মডেলের একটি বিশদ তুলনামূলক কর্মক্ষমতা পরীক্ষা রয়েছে।

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

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

মোটে

বিবেচনা করা নমনীয় আর্কিটেকচারের মূল সারমর্ম হল তাদের "ডিজাইন" এর মডুলারিটি।

এই সম্পত্তি অনুমতি দেয়:

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

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

অ্যাপস

সত্তার ধরন ডেটা ভল্ট

ডেটা ভল্ট সম্পর্কে আরও:
ড্যান লিস্ট্যাড ওয়েবসাইট
রাশিয়ান ভাষায় ডেটা ভল্ট সম্পর্কে সব
হ্যাব্রেতে ডেটা ভল্ট সম্পর্কে

সত্তার ধরন অ্যাঙ্কর মডেল

অ্যাঙ্কর মডেল সম্পর্কে আরও:

অ্যাঙ্কর মডেল নির্মাতাদের সাইট
অ্যাভিটোতে অ্যাঙ্কর মডেল বাস্তবায়নের অভিজ্ঞতা সম্পর্কে একটি নিবন্ধ

সাধারণ বৈশিষ্ট্য এবং বিবেচিত পদ্ধতির মধ্যে পার্থক্য সহ সংক্ষিপ্ত সারণী:

উত্স: www.habr.com