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

আপনি যদি এখনও যুক্তিতে কোনও ত্রুটি খুঁজে না পান তবে পড়ুন।

সন্তুষ্ট

পলিগ্লট অধ্যবসায়
মাল্টি মডেল
মাল্টি-মডেল ডিবিএমএস রিলেশনাল মডেলের উপর ভিত্তি করে
     MS SQL সার্ভারে নথির মডেল
     MS SQL সার্ভারে গ্রাফ মডেল
নথি মডেলের উপর ভিত্তি করে মাল্টি-মডেল ডিবিএমএস
     MarkLogic মধ্যে সম্পর্কীয় মডেল
     MarkLogic মধ্যে গ্রাফ মডেল
মাল্টি-মডেল ডিবিএমএস "একটি প্রধান মডেল ছাড়াই"
     আরানগোডিবি
     OrientDB
     আজুর কসমসডিবি
একটি গ্রাফ মডেলের উপর ভিত্তি করে মাল্টি-মডেল ডিবিএমএস?
উপসংহার
সাক্ষাত্কার

পলিগ্লট অধ্যবসায়

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

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

এই উদাহরণটি, অবশ্যই, কিছুটা অতিরঞ্জিত, তবে সংশ্লিষ্ট উদ্দেশ্যে এক বা অন্য ডিবিএমএস বেছে নেওয়ার পক্ষে কিছু বিবেচনা পাওয়া যেতে পারে, উদাহরণস্বরূপ, এখানে.

এটা স্পষ্ট যে এই ধরনের চিড়িয়াখানায় একজন চাকর হওয়া সহজ নয়।

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

চিড়িয়াখানা পরিচালকের দৃষ্টিকোণ থেকে, সবকিছু এইরকম দেখায়:

• DBMS প্রস্তুতকারকের কাছ থেকে লাইসেন্স এবং প্রযুক্তিগত সহায়তার খরচে একাধিক বৃদ্ধি।
• অতিরিক্ত স্টাফিং এবং বর্ধিত সময়সীমা।
• তথ্যের অসামঞ্জস্যতার কারণে সরাসরি আর্থিক ক্ষতি বা জরিমানা।

সিস্টেমের মালিকানার মোট খরচ (TCO) উল্লেখযোগ্য বৃদ্ধি পেয়েছে। "একাধিক স্টোরেজ বিকল্প" এর পরিস্থিতি থেকে বেরিয়ে আসার কোন উপায় আছে কি?

মাল্টি মডেল

"মাল্টিভেরিয়েট স্টোরেজ" শব্দটি 2011 সালে ব্যবহার করা হয়েছিল। পদ্ধতির সমস্যা সম্পর্কে সচেতনতা এবং সমাধানের অনুসন্ধানে বেশ কয়েক বছর সময় লেগেছিল, এবং 2015 সালের মধ্যে, গার্টনার বিশ্লেষকদের মুখের মাধ্যমে, উত্তরটি তৈরি করা হয়েছিল:

• থেকে "NoSQL DBMS - 2015 এর জন্য বাজার নির্দেশিকা"
  

  DBMSs এর ভবিষ্যত, তাদের স্থাপত্য এবং সেগুলি ব্যবহারের উপায় হল মাল্টি-মডেল।

• থেকে "ODBMS - 2016 এর জন্য ম্যাজিক কোয়াড্রেন্ট"
  

  একটি একক প্ল্যাটফর্মের অংশ হিসাবে লিডিং অপারেশনাল ডিবিএমএসগুলি একাধিক মডেল অফার করবে - রিলেশনাল এবং অ-রিলেশনাল৷

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

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

ডিবিএমএস	প্রাথমিক মডেল	অতিরিক্ত মডেল
আকাশবাণী	সম্পর্কীয়	গ্রাফ, নথি
এমএস এসকিউএল	সম্পর্কীয়	গ্রাফ, নথি
পোস্টগ্রি	সম্পর্কীয়	গ্রাফ*, নথি
মার্কলজিক	তথ্যচিত্র	গ্রাফ, রিলেশনাল
MongoDB	তথ্যচিত্র	মূল-মান, গ্রাফ*
ডেটাস্ট্যাক্স	প্রশস্ত-কলাম	ডকুমেন্টারি, গ্রাফ
Redis	প্রকৃত মূল্য	ডকুমেন্টারি, গ্রাফ*
আরানগোডিবি	-	গ্রাফ, নথি
OrientDB	-	গ্রাফ, ডকুমেন্ট, রিলেশনাল
আজুর কসমসডিবি	-	গ্রাফ, ডকুমেন্ট, রিলেশনাল

টেবিল নোট

সারণীতে তারকাচিহ্নগুলি চিহ্নিত বিবৃতিগুলির জন্য সংরক্ষণের প্রয়োজন:

• PostgreSQL DBMS গ্রাফ ডেটা মডেল সমর্থন করে না, কিন্তু এই পণ্যটি এটি সমর্থন করে এর উপর ভিত্তি করে, যেমন AgensGraph.
• MongoDB-এর ক্ষেত্রে, কোয়েরি ভাষায় গ্রাফ অপারেটরদের উপস্থিতি সম্পর্কে কথা বলা আরও সঠিক ($lookup, $graphLookup) গ্রাফ মডেলকে সমর্থন করার চেয়ে, যদিও, অবশ্যই, তাদের প্রবর্তনের জন্য গ্রাফ মডেলকে সমর্থন করার দিক থেকে ভৌত স্টোরেজ স্তরে কিছু অপ্টিমাইজেশান প্রয়োজন।
• রেডিসের সাথে, আমরা এক্সটেনশন বোঝাতে চাই রেডিসগ্রাফ.

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

মাল্টি-মডেল ডিবিএমএস রিলেশনাল মডেলের উপর ভিত্তি করে

নেতৃস্থানীয় DBMSs বর্তমানে সম্পর্কযুক্ত; গার্টনারের পূর্বাভাস সত্য বলে বিবেচিত হতে পারে না যদি RDBMSগুলি মাল্টি-মডেলিংয়ের দিকে গতিশীল না দেখায়। এবং তারা প্রদর্শন করে। এখন ধারণাটি যে একটি মাল্টি-মডেল ডিবিএমএস একটি সুইস ছুরির মতো, যা ভাল কিছু করতে পারে না, সরাসরি ল্যারি এলিসনকে নির্দেশ করা যেতে পারে।

লেখক অবশ্য, Microsoft SQL সার্ভারে মাল্টি-মডেলিং বাস্তবায়ন পছন্দ করেন, যার উদাহরণে নথি এবং গ্রাফ মডেলের জন্য RDBMS সমর্থন বর্ণনা করা হবে।

MS SQL সার্ভারে নথির মডেল

এমএস এসকিউএল সার্ভার কীভাবে ডকুমেন্ট মডেলের জন্য সমর্থন প্রয়োগ করে সে সম্পর্কে হ্যাব্রেতে ইতিমধ্যে দুটি দুর্দান্ত নিবন্ধ রয়েছে; আমি নিজেকে একটি সংক্ষিপ্ত রিটেলিং এবং ভাষ্যের মধ্যে সীমাবদ্ধ করব:

• SQL সার্ভার 2016 এ JSON এর সাথে কাজ করা
• SQL সার্ভার 2017 JSON

এমএস এসকিউএল সার্ভারে নথির মডেলটিকে সমর্থন করার উপায়টি রিলেশনাল ডিবিএমএসের জন্য বেশ সাধারণ: JSON নথিগুলি সাধারণ পাঠ্য ক্ষেত্রে সংরক্ষণ করার প্রস্তাব করা হয়েছে। নথি মডেলের জন্য সমর্থন এই JSON পার্স করার জন্য বিশেষ অপারেটর প্রদান করা হয়:

• JSON_VALUE স্কেলার অ্যাট্রিবিউট মান বের করতে,
• JSON_QUERY সাব-ডকুমেন্ট বের করতে।

উভয় অপারেটরের দ্বিতীয় যুক্তি হল JSONPath-এর মত সিনট্যাক্সের একটি অভিব্যক্তি।

বিমূর্তভাবে, আমরা বলতে পারি যে এইভাবে সংরক্ষিত নথিগুলি একটি সম্পর্কযুক্ত ডিবিএমএসে "প্রথম-শ্রেণীর সত্তা" নয়, টিপলগুলির বিপরীতে। বিশেষত, MS SQL সার্ভারে বর্তমানে JSON নথিগুলির ক্ষেত্রে কোনও সূচী নেই, যা এই ক্ষেত্রগুলির মানগুলি ব্যবহার করে টেবিলে যোগদান করা এবং এমনকি এই মানগুলি ব্যবহার করে নথি নির্বাচন করা কঠিন করে তোলে৷ যাইহোক, এই জাতীয় ক্ষেত্রের জন্য একটি গণনা করা কলাম এবং এটিতে একটি সূচক তৈরি করা সম্ভব।

উপরন্তু, MS SQL সার্ভার অপারেটর ব্যবহার করে টেবিলের বিষয়বস্তু থেকে সুবিধাজনকভাবে একটি JSON নথি তৈরি করার ক্ষমতা প্রদান করে FOR JSON PATH - একটি সম্ভাবনা, একটি নির্দিষ্ট অর্থে, আগেরটির বিপরীতে, প্রচলিত স্টোরেজ। এটা স্পষ্ট যে একটি RDBMS যত দ্রুতই হোক না কেন, এই পদ্ধতিটি ডকুমেন্ট DBMSs-এর আদর্শের সাথে বিরোধিতা করে, যা মূলত জনপ্রিয় প্রশ্নের জন্য প্রস্তুত উত্তর সঞ্চয় করে এবং শুধুমাত্র উন্নয়নের সহজতার সমস্যা সমাধান করতে পারে, কিন্তু গতি নয়।

অবশেষে, এমএস এসকিউএল সার্ভার আপনাকে নথি নির্মাণের বিপরীত সমস্যার সমাধান করতে দেয়: আপনি JSON কে টেবিলে পচন করতে পারেন OPENJSON. নথিটি সম্পূর্ণ সমতল না হলে, আপনাকে ব্যবহার করতে হবে CROSS APPLY.

MS SQL সার্ভারে গ্রাফ মডেল

গ্রাফ (এলপিজি) মডেলের জন্য সমর্থন Microsoft SQL সার্ভারে সম্পূর্ণরূপে প্রয়োগ করা হয় অনুমানযোগ্যভাবে: নোড সংরক্ষণ করতে এবং গ্রাফ প্রান্তগুলি সংরক্ষণ করতে বিশেষ টেবিল ব্যবহার করার প্রস্তাব করা হয়েছে। এই ধরনের টেবিল এক্সপ্রেশন ব্যবহার করে তৈরি করা হয় CREATE TABLE AS NODE и CREATE TABLE AS EDGE যথাক্রমে।

প্রথম ধরণের টেবিলগুলি রেকর্ড সংরক্ষণের জন্য সাধারণ টেবিলের মতো, শুধুমাত্র বাহ্যিক পার্থক্য হল যে টেবিলটিতে একটি সিস্টেম ক্ষেত্র রয়েছে $node_id — ডাটাবেসের মধ্যে একটি গ্রাফ নোডের অনন্য শনাক্তকারী।

একইভাবে, দ্বিতীয় ধরণের টেবিলে সিস্টেম ক্ষেত্র রয়েছে $from_id и $to_id, এই জাতীয় টেবিলের এন্ট্রিগুলি নোডগুলির মধ্যে সংযোগগুলিকে স্পষ্টভাবে সংজ্ঞায়িত করে। প্রতিটি ধরনের সম্পর্ক সংরক্ষণ করতে একটি পৃথক টেবিল ব্যবহার করা হয়।

আসুন একটি উদাহরণ দিয়ে এটি ব্যাখ্যা করা যাক। গ্রাফ ডেটার চিত্রের মতো একটি বিন্যাস থাকতে দিন। তারপরে ডাটাবেসে সংশ্লিষ্ট কাঠামো তৈরি করতে আপনাকে নিম্নলিখিত DDL প্রশ্নগুলি চালাতে হবে:

CREATE TABLE Person (
  ID INTEGER NOT NULL,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Cafe (
  ID INTEGER NOT NULL, 
  name VARCHAR(100), 
) AS NODE;

CREATE TABLE likes (
  rating INTEGER
) AS EDGE;

CREATE TABLE friendOf
  AS EDGE;

ALTER TABLE likes
  ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);

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

SELECT Cafe.name
  FROM Person, likes, Cafe
  WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
  AND Person.name = 'John';

তদুপরি, এই জাতীয় সারণীগুলির সাথে কাজ করার সময় এই গ্রাফ প্যাটার্নগুলি ব্যবহার না করা বেশ কঠিন, যেহেতু সাধারণ এসকিউএল প্রশ্নগুলিতে অনুরূপ সমস্যাগুলি সমাধান করার জন্য সিস্টেম "গ্রাফ" নোড সনাক্তকারীগুলি পাওয়ার জন্য অতিরিক্ত প্রচেষ্টা করা প্রয়োজন ($node_id, $from_id, $to_id; একই কারণে, ডেটা সন্নিবেশ করার জন্য প্রশ্নগুলি এখানে দেখানো হয়নি কারণ সেগুলি অপ্রয়োজনীয়ভাবে কষ্টকর)।

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

নথি মডেলের উপর ভিত্তি করে মাল্টি-মডেল ডিবিএমএস

এই বিভাগে, আমি তাদের মধ্যে সবচেয়ে জনপ্রিয় নয়, MongoDB-এর উদাহরণ ব্যবহার করে ডকুমেন্ট ডিবিএমএস-এ মাল্টি-মডেল বাস্তবায়নের চিত্র তুলে ধরতে চাই (যেমন বলা হয়েছিল, এতে শুধুমাত্র শর্তসাপেক্ষ গ্রাফ অপারেটর রয়েছে $lookup и $graphLookup, শার্ড সংগ্রহে কাজ করছে না), তবে আরও পরিপক্ক এবং "এন্টারপ্রাইজ" DBMS এর উদাহরণ ব্যবহার করে মার্কলজিক.

সুতরাং, সংগ্রহে নিম্নলিখিত ধরণের এক্সএমএল নথিগুলির একটি সেট থাকতে দিন (মার্কলজিক আপনাকে JSON নথিগুলি সংরক্ষণ করার অনুমতি দেয়):

<Person INN="631803299804">
  <name>John</name>
  <surname>Smith</surname>
</Person>

MarkLogic মধ্যে সম্পর্কীয় মডেল

ব্যবহার করে নথির সংগ্রহের একটি রিলেশনাল ভিউ তৈরি করা যেতে পারে প্রদর্শন টেমপ্লেট (উপাদানের বিষয়বস্তু value নীচের উদাহরণে একটি নির্বিচারে XPath হতে পারে):

<template >
  <context>/Person</context>
  <rows>
    <row>
      <view-name>Person</view-name>
      <columns>
        <column>
          <name>SSN</name>
          <value>@SSN</value>
          <type>string</type>
        </column>
        <column>
          <name>name</name>
          <value>name</value>
        </column>
        <column>
          <name>surname</name>
          <value>surname</value>
        </column>
      </columns>
    </row>
  <rows>
</template>

আপনি একটি SQL ক্যোয়ারী (উদাহরণস্বরূপ, ODBC এর মাধ্যমে):

SELECT name, surname FROM Person WHERE name="John"

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

MarkLogic মধ্যে গ্রাফ মডেল

গ্রাফ (RDF) মডেলের সমর্থন সহ, সবকিছু একই রকম। আবার সাহায্য নিয়ে প্রদর্শন টেমপ্লেট আপনি উপরের উদাহরণ থেকে নথির সংগ্রহের একটি RDF উপস্থাপনা তৈরি করতে পারেন:

<template >
  <context>/Person</context>
    <vars>
      <var>
        <name>PREFIX</name>
        <val>"http://example.org/example#"</val>
      </var>
    </vars>
  <triples>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
      <object><value>xs:string( surname )</value></object>
    </triple>
    <triple>
      <subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
      <predicate><value>sem:iri( $PREFIX || name )</value></predicate>
      <object><value>xs:string( name )</value></object>
    </triple>
  </triples>
  </template>

আপনি একটি SPARQL ক্যোয়ারী দিয়ে ফলস্বরূপ RDF গ্রাফটি সম্বোধন করতে পারেন:

PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
  :631803299804 :name ?name ; :surname ?surname .
}

রিলেশনাল থেকে ভিন্ন, MarkLogic গ্রাফ মডেলটিকে অন্য দুটি উপায়ে সমর্থন করে:

1. একটি ডিবিএমএস আরডিএফ ডেটার একটি সম্পূর্ণ আলাদা স্টোরেজ হতে পারে (এতে ট্রিপলেট বলা হবে পরিচালিত উপরে বর্ণিত এর বিপরীতে নিষ্কাশিত).
2. বিশেষ ক্রমিককরণে RDF সহজভাবে XML বা JSON নথিতে ঢোকানো যেতে পারে (এবং তারপর ট্রিপলেট বলা হবে অব্যবস্থাপিত) এটি সম্ভবত মেকানিজমের বিকল্প idref এবং অন্যদের

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

মাল্টি-মডেল ডিবিএমএস "একটি প্রধান মডেল ছাড়াই"

বাজারে এমন ডিবিএমএসও রয়েছে যেগুলো নিজেদেরকে প্রাথমিকভাবে মাল্টি-মডেল হিসেবে অবস্থান করে, কোনো উত্তরাধিকারসূত্রে পাওয়া প্রধান মডেল ছাড়াই। এই অন্তর্ভুক্ত আরানগোডিবি, OrientDB (2018 সাল থেকে ডেভেলপমেন্ট কোম্পানি SAP এর অন্তর্গত) এবং কসমসডিবি (Microsoft Azure ক্লাউড প্ল্যাটফর্মের অংশ হিসাবে পরিষেবা)।

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

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

Habré-এ ArangoDB এবং OrientDB সম্পর্কে ইতিমধ্যেই একটি চমৎকার নিবন্ধ ছিল: NoSQL ডাটাবেসে যোগ দিন.

আরানগোডিবি

ArangoDB একটি গ্রাফ ডেটা মডেলের জন্য সমর্থন দাবি করে।

ArangoDB-তে একটি গ্রাফের নোডগুলি সাধারণ নথি, এবং প্রান্তগুলি একটি বিশেষ ধরনের নথি যা নিয়মিত সিস্টেম ক্ষেত্রগুলির সাথে থাকে (_key, _id, _rev) সিস্টেম ক্ষেত্র _from и _to. ডকুমেন্ট ডিবিএমএস-এর নথি ঐতিহ্যগতভাবে সংগ্রহে একত্রিত করা হয়। প্রান্তের প্রতিনিধিত্বকারী নথির সংগ্রহগুলিকে ArangoDB-তে প্রান্ত সংগ্রহ বলা হয়। যাইহোক, প্রান্ত সংগ্রহের নথিগুলিও নথি, তাই ArangoDB-তে প্রান্তগুলিও নোড হিসাবে কাজ করতে পারে।

কাঁচা তথ্য

আমাদের একটি সংগ্রহ করা যাক persons, যার নথিগুলি দেখতে এইরকম:

[
  {
    "_id"  : "people/alice" ,
    "_key" : "alice" ,
    "name" : "Алиса"
  },
  {
    "_id"  : "people/bob" ,
    "_key" : "bob" ,
    "name" : "Боб"  
  }
]

একটা কালেকশনও থাকুক cafes:

[
  {
    "_id" : "cafes/jd" ,
    "_key" : "jd" ,
    "name" : "Джон Донн"  
  },
  {
    "_id" : "cafes/jj" ,
    "_key" : "jj" ,
    "name" : "Жан-Жак"
  }
]

তারপর কালেকশন likes এই মত চেহারা হতে পারে:

[
  {
    "_id" : "likes/1" ,
    "_key" : "1" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jd",
    "since" : 2010 
  },
  {
    "_id" : "likes/2" ,
    "_key" : "2" ,
    "_from" : "persons/alice" ,
    "_to" : "cafes/jj",
    "since" : 2011 
  } ,
  {
    "_id" : "likes/3" ,
    "_key" : "3" ,
    "_from" : "persons/bob" ,
    "_to" : "cafes/jd",
    "since" : 2012 
  }
]

প্রশ্ন এবং ফলাফল

আরাঙ্গোডিবিতে ব্যবহৃত AQL ভাষায় একটি গ্রাফ-স্টাইল প্রশ্ন, কে কোন ক্যাফে পছন্দ করে সে সম্পর্কে মানব-পঠনযোগ্য তথ্যে ফিরে আসে, দেখতে এইরকম:

FOR p IN persons
  FOR c IN OUTBOUND p likes
  RETURN { person : p.name , likes : c.name }

একটি রিলেশনাল স্টাইলে, যেখানে আমরা সম্পর্কগুলিকে সঞ্চয় করার পরিবর্তে "কম্পিউটিং" করছি, এই ক্যোয়ারীটি এভাবে পুনরায় লেখা যেতে পারে (যাইহোক, সংগ্রহ ছাড়াই likes ছাড়া করতে পারে):

FOR p IN persons
  FOR l IN likes
  FILTER p._key == l._from
    FOR c IN cafes
    FILTER l._to == c._key
    RETURN { person : p.name , likes : c.name }

উভয় ক্ষেত্রে ফলাফল একই হবে:

[
  { "person" : "Алиса" , likes : "Жан-Жак" } ,
  { "person" : "Алиса" , likes : "Джон Донн" } ,
  { "person" : "Боб" , likes : "Джон Донн" }
]

আরো প্রশ্ন এবং ফলাফল

যদি উপরের ফলাফল বিন্যাসটি একটি নথি DBMS-এর চেয়ে রিলেশনাল DBMS-এর জন্য বেশি সাধারণ বলে মনে হয়, আপনি এই ক্যোয়ারীটি চেষ্টা করতে পারেন (অথবা আপনি ব্যবহার করতে পারেন COLLECT):

FOR p IN persons
  RETURN {
    person : p.name,
    likes : (
      FOR c IN OUTBOUND p likes
      RETURN c.name
    )
}

ফলাফল এই মত দেখাবে:

[
  { "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"]  } ,
  { "person" : "Боб" , likes : ["Джон Донн"] }
]

OrientDB

OrientDB-তে একটি নথি মডেলের উপরে একটি গ্রাফ মডেল বাস্তবায়নের ভিত্তি সুযোগ ডকুমেন্ট ফিল্ডে, কম বা বেশি স্ট্যান্ডার্ড স্কেলার মান ছাড়াও, বিভিন্ন ধরণের মান রয়েছে যেমন LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. এই ধরনের মান হল লিঙ্ক বা লিঙ্কের সংগ্রহ সিস্টেম শনাক্তকারী নথি।

সিস্টেম দ্বারা নির্ধারিত নথি শনাক্তকারীর একটি "শারীরিক অর্থ" রয়েছে, যা ডাটাবেসে রেকর্ডের অবস্থান নির্দেশ করে এবং এটি দেখতে এরকম কিছু দেখায়: @rid : #3:16. সুতরাং, রেফারেন্স বৈশিষ্ট্যের মানগুলি নির্বাচনের শর্তগুলির পরিবর্তে (যেমন রিলেশনাল মডেলের মতো) সত্যিই পয়েন্টার (গ্রাফ মডেলের মতো)।

ArangoDB-এর মত, OrientDB-এ প্রান্তগুলিকে পৃথক নথি হিসাবে উপস্থাপন করা হয় (যদিও যদি একটি প্রান্তের নিজস্ব বৈশিষ্ট্য না থাকে তবে এটি তৈরি করা যেতে পারে। লাইটওয়েট, এবং এটি একটি পৃথক নথির সাথে সঙ্গতিপূর্ণ হবে না)।

কাঁচা তথ্য

কাছাকাছি একটি বিন্যাসে ডাম্প বিন্যাস OrientDB ডাটাবেস, ArangoDB-এর পূর্ববর্তী উদাহরণের ডেটা এইরকম দেখতে হবে:

[
     {
      "@type": "document",
      "@rid": "#11:0",
      "@class": "Person",
      "name": "Алиса",
      "out_likes": [
        "#30:1",
        "#30:2"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#12:0",
      "@class": "Person",
      "name": "Боб",
      "out_likes": [
        "#30:3"
      ],
      "@fieldTypes": "out_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#21:0",
      "@class": "Cafe",
      "name": "Жан-Жак",
      "in_likes": [
        "#30:2",
        "#30:3"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#22:0",
      "@class": "Cafe",
      "name": "Джон Донн",
      "in_likes": [
        "#30:1"
      ],
      "@fieldTypes": "in_likes=LINKBAG"
    },
    {
      "@type": "document",
      "@rid": "#30:1",
      "@class": "likes",
      "in": "#22:0",
      "out": "#11:0",
      "since": 1262286000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:2",
      "@class": "likes",
      "in": "#21:0",
      "out": "#11:0",
      "since": 1293822000000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    },
    {
      "@type": "document",
      "@rid": "#30:3",
      "@class": "likes",
      "in": "#21:0",
      "out": "#12:0",
      "since": 1325354400000,
      "@fieldTypes": "in=LINK,out=LINK,since=date"
    }
  ]

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

প্রশ্ন এবং ফলাফল

OrientDB-তে ArangoDB-এর উদাহরণ থেকে ক্যোয়ারীটির উদ্দেশ্যের অনুরূপ একটি প্রশ্ন এইরকম দেখাচ্ছে:

SELECT name AS person_name, OUT('likes').name AS cafe_name
   FROM Person
   UNWIND cafe_name

ফলাফল নিম্নলিখিত আকারে প্রাপ্ত করা হবে:

[
  { "person_name": "Алиса", "cafe_name": "Джон Донн" },
  { "person_name": "Алиса", "cafe_name": "Жан-Жак" },
  { "person_name": "Боб",  "cafe_name": "Жан-Жак" }
]

যদি ফলাফলের বিন্যাসটি আবার খুব "রিলেশনাল" বলে মনে হয়, তাহলে আপনাকে লাইনটি মুছে ফেলতে হবে UNWIND():

[
  { "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
  { "person_name": "Боб",  "cafe_name": [ "Жан-Жак" ' }
]

OrientDB-এর ক্যোয়ারী ল্যাঙ্গুয়েজ গ্রেমলিন-এর মত সন্নিবেশ সহ SQL হিসাবে বর্ণনা করা যেতে পারে। সংস্করণ 2.2-এ, একটি সাইফার-সদৃশ অনুরোধ ফর্ম উপস্থিত হয়েছিল, MATCH :

MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_name

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

আজুর কসমসডিবি

অল্প পরিমাণে, ArangoDB এবং OrientDB সম্পর্কে উপরে যা বলা হয়েছে তা Azure CosmosDB-তে প্রযোজ্য। CosmosDB নিম্নলিখিত ডেটা অ্যাক্সেস API প্রদান করে: SQL, MongoDB, Gremlin এবং Cassandra।

SQL API এবং MongoDB API ডকুমেন্ট মডেলে ডেটা অ্যাক্সেস করতে ব্যবহৃত হয়। গ্রেমলিন এপিআই এবং ক্যাসান্ড্রা এপিআই - যথাক্রমে গ্রাফ এবং কলাম বিন্যাসে ডেটা অ্যাক্সেস করার জন্য। সমস্ত মডেলের ডেটা CosmosDB অভ্যন্তরীণ মডেল বিন্যাসে সংরক্ষিত হয়: এআরএস ("অ্যাটম-রেকর্ড-সিকোয়েন্স"), যা নথির কাছাকাছিও।

কিন্তু ব্যবহারকারীর দ্বারা নির্বাচিত ডেটা মডেল এবং ব্যবহৃত API পরিষেবাতে একটি অ্যাকাউন্ট তৈরি করার সময় স্থির করা হয়। অন্য মডেলের বিন্যাসে এক মডেলে লোড করা ডেটা অ্যাক্সেস করা সম্ভব নয়, যেমনটি এইরকম কিছু দ্বারা চিত্রিত হয়েছে:

এইভাবে, Azure CosmosDB-তে মাল্টি-মডেল আজ শুধুমাত্র একটি প্রস্তুতকারকের থেকে বিভিন্ন মডেলকে সমর্থন করে একাধিক ডেটাবেস ব্যবহার করার ক্ষমতা, যা মাল্টি-ভেরিয়েন্ট স্টোরেজের সমস্ত সমস্যার সমাধান করে না।

একটি গ্রাফ মডেলের উপর ভিত্তি করে মাল্টি-মডেল ডিবিএমএস?

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

গ্রাফ মডেলের উপরে একটি রিলেশনাল মডেল কীভাবে বাস্তবায়ন করা যায় সেই প্রশ্নটি পরবর্তীটির গঠনের সময়ও বিবেচনা করা হয়েছিল। কিভাবে তিনি বলেন,উদাহরণস্বরূপ, ডেভিড ম্যাকগভর্ন:

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

একটি গ্রাফ মডেলের উপরে একটি নথি মডেল বাস্তবায়ন করার সময়, আপনাকে মনে রাখতে হবে, উদাহরণস্বরূপ, নিম্নলিখিতগুলি:

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

কিছু বিজ্ঞাপন

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

আমি আশা করি নিম্নলিখিত নিবন্ধগুলির মধ্যে একটিতে NitrosBase-এ মডেল ম্যাচিং কেমন দেখাচ্ছে তা বর্ণনা করব।

উপসংহার

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

1. আমরা কি ঐতিহ্যগত মডেল বা কোনো ধরনের "হাইব্রিড" মডেল সমর্থন করার কথা বলছি?
2. মডেলগুলি কি "সমান", নাকি তাদের মধ্যে একটি অন্যদের বিষয়?
3. মডেলগুলি কি একে অপরের প্রতি "উদাসীন"? এক মডেলে লেখা ডেটা কি অন্যটিতে পড়া যায় বা এমনকি ওভাররাইট করা যায়?

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

শুধুমাত্র নিবন্ধিত ব্যবহারকারীরা জরিপে অংশগ্রহণ করতে পারবেন। সাইন ইন করুনকরুন।

আপনি কি মাল্টি-মডেল ডিবিএমএস ব্যবহার করেন?

• আমরা এটি ব্যবহার করি না, আমরা একটি DBMS এবং একটি মডেলে সবকিছু সঞ্চয় করি

• আমরা ঐতিহ্যগত DBMSs-এর মাল্টি-মডেল ক্ষমতা ব্যবহার করি

• আমরা বহুভুজ অধ্যবসায় অনুশীলন করি

• আমরা নতুন মাল্টি-মডেল DBMS ব্যবহার করি (Arango, Orient, CosmosDB)

19 ব্যবহারকারী ভোট দিয়েছেন। 4 জন ব্যবহারকারী বিরত ছিলেন।

উত্স: www.habr.com