2019 সালের শরত্কালে, Mail.ru ক্লাউড iOS টিমে একটি দীর্ঘ-প্রতীক্ষিত ইভেন্ট ঘটেছে। অ্যাপ্লিকেশন স্টেটের ক্রমাগত সঞ্চয়স্থানের জন্য প্রধান ডাটাবেস মোবাইল বিশ্বের জন্য খুব বহিরাগত হয়ে উঠেছে লাইটনিং মেমরি-ম্যাপ করা ডেটাবেস (এলএমডিবি)। কাটের নীচে আমরা আপনাকে চারটি অংশে এটির একটি বিশদ পর্যালোচনা অফার করি। প্রথমত, আসুন এমন একটি অ-তুচ্ছ এবং কঠিন পছন্দের কারণগুলি সম্পর্কে কথা বলি। তারপরে আমরা LMDB আর্কিটেকচারের কেন্দ্রে তিনটি স্তম্ভ বিবেচনা করতে এগিয়ে যাব: মেমরি-ম্যাপ করা ফাইল, B+-ট্রি, লেনদেন এবং মাল্টিভারসন বাস্তবায়নের জন্য কপি-অন-রাইট পদ্ধতি। অবশেষে, ডেজার্টের জন্য - ব্যবহারিক অংশ। এতে আমরা নিম্ন-স্তরের কী-মান API-এর উপরে একটি সূচক সহ একাধিক টেবিল সহ একটি ডাটাবেস স্কিমা কীভাবে ডিজাইন এবং বাস্তবায়ন করা যায় তা দেখব।

সন্তুষ্ট

1. বাস্তবায়নের জন্য প্রেরণা
2. LMDB পজিশনিং
3. LMDB এর তিনটি স্তম্ভ
   3.1. তিমি #1। মেমরি-ম্যাপ করা ফাইল
   3.2. তিমি #2। B+-গাছ
   3.3. তিমি #3। অনুরূপ লিখ
4. কী-মান API-এর উপরে একটি ডেটা স্কিমা ডিজাইন করা
   4.1. মৌলিক বিমূর্ততা
   4.2. টেবিল মডেলিং
   4.3. টেবিলের মধ্যে মডেলিং সম্পর্ক

1. বাস্তবায়নের জন্য প্রেরণা

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

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

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

সিস্টেম সংগঠনের অভিনেতা মডেল অনুমান করে যে মাল্টিথ্রেডিং তার দ্বিতীয় সারাংশ হয়ে ওঠে। এতে মডেল অবজেক্টগুলি স্রোতের সীমানা অতিক্রম করতে পছন্দ করে। এবং তারা এটি মাঝে মাঝে এবং এখানে এবং সেখানে করে না, তবে প্রায় ক্রমাগত এবং সর্বত্র করে

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

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

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

অন্যান্য প্রয়োজনীয়তা আরো ঐতিহ্যগত এবং তাদের সম্পূর্ণ তালিকা নিম্নরূপ।

1. থ্রেড নিরাপত্তা.
2. মাল্টিপ্রসেসিং। শুধুমাত্র থ্রেডের মধ্যেই নয়, প্রধান অ্যাপ্লিকেশন এবং iOS এক্সটেনশনগুলির মধ্যেও রাজ্য সিঙ্ক্রোনাইজ করতে একই ডাটাবেস উদাহরণ ব্যবহার করার ইচ্ছা দ্বারা নির্দেশিত।
3. অ-পরিবর্তনযোগ্য বস্তু হিসাবে সঞ্চিত সত্তাকে উপস্থাপন করার ক্ষমতা
4. CRUD অপারেশনের মধ্যে কোনো গতিশীল বরাদ্দ নেই।
5. মৌলিক সম্পত্তির জন্য লেনদেন সমর্থন ACID: পারমাণবিকতা, ধারাবাহিকতা, বিচ্ছিন্নতা এবং নির্ভরযোগ্যতা।
6. সবচেয়ে জনপ্রিয় ক্ষেত্রে গতি.

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

2. LMDB পজিশনিং

LMDB একটি খুব ছোট লাইব্রেরি (শুধুমাত্র 10K সারি) যা ডাটাবেসের সর্বনিম্ন মৌলিক স্তর প্রয়োগ করে - স্টোরেজ।

উপরের চিত্রটি দেখায় যে SQLite এর সাথে LMDB তুলনা করা, যা উচ্চ স্তরের প্রয়োগ করে, সাধারণত কোর ডেটা সহ SQLite এর চেয়ে বেশি সঠিক নয়। একই স্টোরেজ ইঞ্জিনগুলিকে সমান প্রতিযোগী হিসাবে উদ্ধৃত করা আরও ন্যায্য হবে - বার্কলেডিবি, লেভেলডিবি, সোফিয়া, রকসডিবি, ইত্যাদি। এমনকি এমন উন্নয়ন রয়েছে যেখানে LMDB SQLite-এর জন্য স্টোরেজ ইঞ্জিন উপাদান হিসাবে কাজ করে। 2012 সালে এই ধরনের প্রথম পরীক্ষা হয়েছিল ব্যয় করা LMDB দ্বারা হাওয়ার্ড চু. Результаты এতটাই কৌতূহলী হয়ে উঠল যে তার উদ্যোগটি ওএসএস উত্সাহীরা গ্রহণ করেছিল এবং ব্যক্তির মধ্যে এর ধারাবাহিকতা খুঁজে পেয়েছিল লুমোএসকিউএল. 2020 সালের জানুয়ারিতে, এই প্রকল্পের লেখক ছিলেন ডেন শিয়ারার উপস্থাপিত এটি LinuxConfAu এ।

LMDB মূলত অ্যাপ্লিকেশন ডাটাবেসের জন্য একটি ইঞ্জিন হিসাবে ব্যবহৃত হয়। লাইব্রেরিটি ডেভেলপারদের কাছে তার চেহারার জন্য ঋণী OpenLDAP, যারা তাদের প্রকল্পের ভিত্তি হিসাবে বার্কলেডিবি নিয়ে অত্যন্ত অসন্তুষ্ট ছিল। একটি শালীন লাইব্রেরি থেকে শুরু btree, হাওয়ার্ড চু আমাদের সময়ের সবচেয়ে জনপ্রিয় বিকল্পগুলির মধ্যে একটি তৈরি করতে সক্ষম হয়েছিল। তিনি এই গল্পের পাশাপাশি এলএমডিবি-র অভ্যন্তরীণ কাঠামোর জন্য তার খুব দুর্দান্ত প্রতিবেদনটি উৎসর্গ করেছেন। "দ্য লাইটনিং মেমরি-ম্যাপ করা ডেটাবেস". স্টোরেজ সুবিধা জয় করার একটি ভাল উদাহরণ লিওনিড ইউরিয়েভ (ওরফে ইলেওহাইলোড 2015 এ তার প্রতিবেদনে ইতিবাচক প্রযুক্তি থেকে "এলএমডিবি ইঞ্জিন একটি বিশেষ চ্যাম্পিয়ন". এটিতে, তিনি ReOpenLDAP বাস্তবায়নের অনুরূপ কাজের প্রসঙ্গে LMDB সম্পর্কে কথা বলেছেন এবং LevelDB ইতিমধ্যেই তুলনামূলক সমালোচনার শিকার হয়েছে। বাস্তবায়নের ফলস্বরূপ, পজিটিভ টেকনোলজির এমনকি একটি সক্রিয়ভাবে উন্নয়নশীল কাঁটা ছিল এমডিবিএক্স খুব সুস্বাদু বৈশিষ্ট্য সহ, অপ্টিমাইজেশান এবং বাগ ফিক্স.

LMDB প্রায়শই স্টোরেজ হিসাবে ব্যবহৃত হয়। উদাহরণস্বরূপ, মজিলা ফায়ারফক্স ব্রাউজার বেছে নিয়েছে এটি বেশ কয়েকটি প্রয়োজনের জন্য এবং, সংস্করণ 9 থেকে শুরু করে, Xcode পছন্দের সূচী সংরক্ষণের জন্য এর SQLite।

মোবাইল ডেভেলপমেন্টের জগতেও ইঞ্জিন তার ছাপ ফেলেছে। এর ব্যবহারের চিহ্ন হতে পারে খুঁজে পেতে টেলিগ্রামের জন্য iOS ক্লায়েন্টে। লিঙ্কডইন আরও এগিয়ে গেছে এবং এলএমডিবিকে তার স্বদেশী ডেটা ক্যাশিং ফ্রেমওয়ার্ক রকেট ডেটার জন্য ডিফল্ট স্টোরেজ হিসাবে বেছে নিয়েছে, যার সম্পর্কে বলা 2016 সালে তার নিবন্ধে।

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

3. LMDB এর তিনটি স্তম্ভ

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

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

3.1। তিমি #1। মেমরি-ম্যাপ করা ফাইল

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

1. বিভিন্ন প্রক্রিয়া থেকে এটির সাথে কাজ করার সময় স্টোরেজে ডেটার ধারাবাহিকতা বজায় রাখা অপারেটিং সিস্টেমের দায়িত্ব হয়ে যায়। পরবর্তী বিভাগে, এই মেকানিক্সটি বিস্তারিতভাবে এবং ছবি সহ আলোচনা করা হয়েছে।
2. ক্যাশের অনুপস্থিতি গতিশীল বরাদ্দের সাথে যুক্ত ওভারহেড থেকে LMDB কে সম্পূর্ণরূপে বাদ দেয়। অনুশীলনে ডেটা পড়ার অর্থ ভার্চুয়াল মেমরিতে সঠিক ঠিকানায় একটি পয়েন্টার সেট করা এবং এর বেশি কিছু নয়। এটি সায়েন্স ফিকশনের মতো শোনাচ্ছে, কিন্তু স্টোরেজ সোর্স কোডে কলক-এর সমস্ত কল স্টোরেজ কনফিগারেশন ফাংশনে কেন্দ্রীভূত হয়।
3. ক্যাশের অনুপস্থিতির অর্থ তাদের অ্যাক্সেসের সিঙ্ক্রোনাইজেশনের সাথে যুক্ত লকগুলির অনুপস্থিতি। পাঠক, যার মধ্যে একই সময়ে পাঠকের সংখ্যা নির্বিচারে হতে পারে, তারা ডেটাতে যাওয়ার পথে একটি একক মিউটেক্সের মুখোমুখি হয় না। এই কারণে, সিপিইউগুলির সংখ্যার উপর ভিত্তি করে পড়ার গতির আদর্শ রৈখিক মাপযোগ্যতা রয়েছে। LMDB-তে, শুধুমাত্র পরিবর্তন করার ক্রিয়াকলাপগুলি সিঙ্ক্রোনাইজ করা হয়। এক সময়ে কেবল একজন লেখক থাকতে পারে।
4. ন্যূনতম ক্যাশিং এবং সিঙ্ক্রোনাইজেশন লজিক একটি মাল্টি-থ্রেডেড পরিবেশে কাজ করার সাথে সম্পর্কিত অত্যন্ত জটিল ধরণের ত্রুটিগুলি দূর করে। Usenix OSDI 2014 সম্মেলনে দুটি আকর্ষণীয় ডাটাবেস অধ্যয়ন ছিল: "সমস্ত ফাইল সিস্টেম সমানভাবে তৈরি করা হয় না: ক্র্যাশ-সামঞ্জস্যপূর্ণ অ্যাপ্লিকেশন তৈরির জটিলতার উপর" и "মজা এবং লাভের জন্য ডেটাবেস নির্যাতন". তাদের থেকে আপনি LMDB-এর অভূতপূর্ব নির্ভরযোগ্যতা এবং ACID লেনদেনের বৈশিষ্ট্যগুলির প্রায় নিশ্ছিদ্র বাস্তবায়ন সম্পর্কে তথ্য সংগ্রহ করতে পারেন, যা SQLite-এর থেকে উচ্চতর।
5. LMDB-এর ন্যূনতমতা তার কোডের মেশিনের উপস্থাপনাকে প্রসেসরের L1 ক্যাশে সম্পূর্ণরূপে পরবর্তী গতির বৈশিষ্ট্য সহ অবস্থিত করার অনুমতি দেয়।

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

মেমরি-ম্যাপ করা ফাইল সম্পর্কে সাধারণ তথ্য

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

প্রক্রিয়াটির জন্য বরাদ্দ ঠিকানার স্থানটি বিশাল। তাত্ত্বিকভাবে, ঠিকানার সংখ্যা শুধুমাত্র পয়েন্টারের আকার দ্বারা সীমাবদ্ধ, যা সিস্টেমের বিট ক্ষমতা দ্বারা নির্ধারিত হয়। যদি ফিজিক্যাল মেমরিকে 1-থেকে-1-এ ম্যাপ করা হয়, তাহলে প্রথম প্রক্রিয়াটি পুরো র‌্যাম জুড়ে দেবে এবং কোনো মাল্টিটাস্কিংয়ের কথা হবে না।

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

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

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

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

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

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

আইওএস-এ মেমরি-ম্যাপ করা ফাইলগুলির নির্দিষ্টকরণ

2018 সালে WWDC-তে একটি চমৎকার প্রতিবেদন ছিল "iOS মেমরি ডিপ ডাইভ". এটি আমাদের বলে যে iOS-এ, ফিজিক্যাল মেমরিতে থাকা সমস্ত পৃষ্ঠাগুলি 3 প্রকারের মধ্যে একটি: নোংরা, সংকুচিত এবং পরিষ্কার৷

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

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

ভাল খবর, ইতিমধ্যেই আগে উল্লিখিত, হল যে ডিফল্টরূপে LMDB ফাইল আপডেট করার জন্য mmap প্রক্রিয়া ব্যবহার করে না। এর মানে হল যে প্রদর্শিত ডেটা iOS দ্বারা পরিষ্কার মেমরি হিসাবে শ্রেণীবদ্ধ করা হয় এবং মেমরি পদচিহ্নে অবদান রাখে না। আপনি VM Tracker নামে একটি Xcode টুল ব্যবহার করে এটি যাচাই করতে পারেন। নীচের স্ক্রিনশটটি অপারেশন চলাকালীন ক্লাউড অ্যাপ্লিকেশনটির iOS ভার্চুয়াল মেমরির অবস্থা দেখায়। শুরুতে, 2টি LMDB দৃষ্টান্ত এতে শুরু করা হয়েছিল। প্রথমটিকে তার ফাইলটি 1GiB ভার্চুয়াল মেমরিতে প্রদর্শন করার অনুমতি দেওয়া হয়েছিল, দ্বিতীয়টি - 512MiB। উভয় স্টোরেজ একটি নির্দিষ্ট পরিমাণ আবাসিক মেমরি দখল করে থাকা সত্ত্বেও, তাদের কোনটিই নোংরা আকারে অবদান রাখে না।

এবং এখন খারাপ খবরের সময়। 64-বিট ডেস্কটপ অপারেটিং সিস্টেমে অদলবদল পদ্ধতির জন্য ধন্যবাদ, প্রতিটি প্রক্রিয়া তার সম্ভাব্য অদলবদলের জন্য বিনামূল্যে হার্ড ডিস্কের স্থান যতটা ভার্চুয়াল ঠিকানা স্থান দখল করতে পারে। আইওএস-এ কম্প্রেশন দিয়ে অদলবদল প্রতিস্থাপন করা তাত্ত্বিক সর্বাধিক হ্রাস করে। এখন সমস্ত জীবন্ত প্রক্রিয়াগুলিকে অবশ্যই প্রধান (র্যাম পড়ুন) মেমরিতে ফিট করতে হবে এবং যেগুলি মাপসই করে না সেগুলি অবশ্যই বন্ধ করতে বাধ্য হবে৷ এটি উপরে উল্লিখিত হিসাবে বলা হয়েছে প্রতিবেদন, এবং ইন অফিসিয়াল ডকুমেন্টেশন. ফলস্বরূপ, iOS mmap এর মাধ্যমে বরাদ্দের জন্য উপলব্ধ মেমরির পরিমাণ মারাত্মকভাবে সীমিত করে। এখানে এখানে আপনি এই সিস্টেম কল ব্যবহার করে বিভিন্ন ডিভাইসে বরাদ্দ করা যেতে পারে এমন মেমরির পরিমাণের অভিজ্ঞতামূলক সীমা দেখতে পারেন। সবচেয়ে আধুনিক স্মার্টফোন মডেলগুলিতে, iOS 2 গিগাবাইট দ্বারা উদার হয়ে উঠেছে, এবং আইপ্যাডের শীর্ষ সংস্করণগুলিতে - 4 দ্বারা। অনুশীলনে, অবশ্যই, আপনাকে সর্বনিম্ন সমর্থিত ডিভাইস মডেলগুলিতে ফোকাস করতে হবে, যেখানে সবকিছু খুব দুঃখজনক। আরও খারাপ, ভিএম ট্র্যাকারে অ্যাপ্লিকেশনটির মেমরির অবস্থা দেখে আপনি দেখতে পাবেন যে LMDB একমাত্র দাবি করা মেমরি-ম্যাপড মেমরি থেকে অনেক দূরে। সিস্টেম বরাদ্দকারী, রিসোর্স ফাইল, ইমেজ ফ্রেমওয়ার্ক এবং অন্যান্য ছোট শিকারী দ্বারা ভাল অংশগুলি খেয়ে ফেলা হয়।

ক্লাউডে পরীক্ষা-নিরীক্ষার ফলাফলের উপর ভিত্তি করে, আমরা এলএমডিবি দ্বারা বরাদ্দ করা মেমরির জন্য নিম্নলিখিত সমঝোতার মানগুলিতে এসেছি: 384-বিট ডিভাইসের জন্য 32 মেগাবাইট এবং 768-বিট ডিভাইসের জন্য 64। এই ভলিউমটি ব্যবহার করার পরে, যেকোন পরিবর্তনের ক্রিয়াকলাপ কোডের সাথে শেষ হতে শুরু করে MDB_MAP_FULL. আমরা আমাদের পর্যবেক্ষণে এই জাতীয় ত্রুটিগুলি লক্ষ্য করি, তবে সেগুলি যথেষ্ট ছোট যে এই পর্যায়ে সেগুলি উপেক্ষিত হতে পারে।

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

3.2। তিমি #2। B+-গাছ

একটি মূল-মান সঞ্চয়স্থানের উপরে টেবিলগুলি অনুকরণ করতে, নিম্নলিখিত ক্রিয়াকলাপগুলি অবশ্যই এর API-তে উপস্থিত থাকতে হবে:

1. একটি নতুন উপাদান সন্নিবেশ করা হচ্ছে।
2. একটি প্রদত্ত কী দিয়ে একটি উপাদান অনুসন্ধান করুন.
3. একটি উপাদান অপসারণ.
4. কীগুলির ব্যবধানে সেগুলি সাজানো হয় সেই ক্রমে পুনরাবৃত্তি করুন।

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

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

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

যার ফলে:

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

LMDB ডেটা সঞ্চয় করার জন্য B+ ট্রি নামক বি-ট্রির একটি বৈচিত্র ব্যবহার করে। উপরের চিত্রটি এতে বিদ্যমান তিন ধরণের নোড দেখায়:

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

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

পৃষ্ঠা নোডের অভ্যন্তরীণ বিষয়বস্তু নিয়ে কাজ করার পরে, আমরা নিম্নলিখিত আকারে একটি সরলীকৃত পদ্ধতিতে LMDB B-ট্রিকে আরও উপস্থাপন করব।

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

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

3.3। তিমি #3। অনুরূপ লিখ

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

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

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

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

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

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

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

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

4. কী-মান API-এর উপরে একটি ডেটা স্কিমা ডিজাইন করা

এলএমডিবি দ্বারা প্রদত্ত মৌলিক বিমূর্ততাগুলি দেখে আমাদের API বিশ্লেষণ শুরু করা যাক: পরিবেশ এবং ডেটাবেস, কী এবং মান, লেনদেন এবং কার্সার৷

কোড তালিকা সম্পর্কে একটি নোট

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

iOS বা macOS-এর জন্য একটি প্রকল্পের সাথে LMDB সংযোগ করার দ্রুততম উপায় হিসাবে, আমি আমার CocoaPod সুপারিশ করছি POSLMDB.

4.1. মৌলিক বিমূর্ততা

পরিবেশ

গঠন MDB_env LMDB-এর অভ্যন্তরীণ অবস্থার ভান্ডার। উপসর্গ ফাংশন পরিবার mdb_env আপনাকে এর কিছু বৈশিষ্ট্য কনফিগার করতে দেয়। সহজ ক্ষেত্রে, ইঞ্জিন আরম্ভ এই মত দেখায়.

mdb_env_create(env);​
mdb_env_set_map_size(*env, 1024 * 1024 * 512)​
mdb_env_open(*env, path.UTF8String, MDB_NOTLS, 0664);

Mail.ru ক্লাউড অ্যাপ্লিকেশনে, আমরা শুধুমাত্র দুটি প্যারামিটারের ডিফল্ট মান পরিবর্তন করেছি।

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

দ্বিতীয় প্যারামিটার, যার ডিফল্ট মান আমাদের উপযুক্ত নয়, থ্রেড নিরাপত্তা নিশ্চিত করার মেকানিক্স নিয়ন্ত্রণ করে। দুর্ভাগ্যবশত, অন্তত iOS 10-এর থ্রেড স্থানীয় স্টোরেজের সমর্থনে সমস্যা রয়েছে। এই কারণে, উপরের উদাহরণে, ভান্ডারটি পতাকা দিয়ে খোলা হয়েছে MDB_NOTLS. এর পাশাপাশি এটাও দরকার ছিল কাঁটা C++ মোড়ক lmdbxxএই বৈশিষ্ট্য এবং এটির সাথে ভেরিয়েবলগুলি কাটাতে।

ডেটাবেস

ডাটাবেস হল একটি পৃথক বি-ট্রি উদাহরণ, যা আমরা উপরে আলোচনা করেছি। এটির খোলা একটি লেনদেনের ভিতরে ঘটে, যা প্রথমে একটু অদ্ভুত বলে মনে হতে পারে।

MDB_txn *txn;​
MDB_dbi dbi;​
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);​
mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi);​
mdb_txn_abort(txn);

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

কী এবং মান

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

typedef struct MDB_val {​
    size_t mv_size;​
    void *mv_data;​
} MDB_val;​​

একটি তুলনাকারী ব্যবহার করে, স্টোরটি কীগুলিকে আরোহী ক্রমে সাজায়৷ আপনি যদি এটিকে নিজের সাথে প্রতিস্থাপন না করেন, তাহলে ডিফল্টটি ব্যবহার করা হবে, যা লেক্সিকোগ্রাফিক ক্রমে বাইট-বাই-বাইট বাছাই করে।

লেনদেন

লেনদেনের কাঠামো বিস্তারিতভাবে বর্ণনা করা হয়েছে আগের অধ্যায়, তাই এখানে আমি সংক্ষেপে তাদের প্রধান বৈশিষ্ট্য পুনরাবৃত্তি করব:

1. সমস্ত মৌলিক বৈশিষ্ট্য সমর্থন করে ACID: পারমাণবিকতা, ধারাবাহিকতা, বিচ্ছিন্নতা এবং নির্ভরযোগ্যতা। আমি সাহায্য করতে পারি না কিন্তু মনে রাখবেন যে ম্যাকওএস এবং আইওএস-এ স্থায়িত্বের ক্ষেত্রে একটি বাগ রয়েছে যা MDBX-এ সংশোধন করা হয়েছিল। আপনি তাদের আরো পড়তে পারেন README.
2. মাল্টিথ্রেডিংয়ের পদ্ধতিটি "একক লেখক / একাধিক পাঠক" স্কিম দ্বারা বর্ণিত হয়েছে। লেখকরা একে অপরকে ব্লক করে, কিন্তু পাঠকদের অবরুদ্ধ করে না। পাঠকরা লেখক বা একে অপরকে অবরুদ্ধ করে না।
3. নেস্টেড লেনদেনের জন্য সমর্থন।
4. মাল্টিভারসন সমর্থন।

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

একটি পরীক্ষা এন্ট্রি যোগ করা হচ্ছে

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

mdb_env_create(&env);
mdb_env_open(env, "./testdb", MDB_NOTLS, 0664);

mdb_txn_begin(env, NULL, 0, &txn);
mdb_dbi_open(txn, NULL, 0, &dbi);
mdb_txn_abort(txn);

char k = 'k';
MDB_val key;
key.mv_size = sizeof(k);
key.mv_data = (void *)&k;

int v = 997;
MDB_val value;
value.mv_size = sizeof(v);
value.mv_data = (void *)&v;

mdb_txn_begin(env, NULL, 0, &txn);
mdb_put(txn, dbi, &key, &value, MDB_NOOVERWRITE);
mdb_txn_commit(txn);

MDB_txn *txn1, *txn2, *txn3;
MDB_val val;

// Открываем 2 транзакции, каждая из которых смотрит
// на версию базы данных с одной записью.
mdb_txn_begin(env, NULL, 0, &txn1); // read-write
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn2); // read-only

// В рамках первой транзакции удаляем из базы данных существующую в ней запись.
mdb_del(txn1, dbi, &key, NULL);
// Фиксируем удаление.
mdb_txn_commit(txn1);

// Открываем третью транзакцию, которая смотрит на
// актуальную версию базы данных, где записи уже нет.
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn3);
// Убеждаемся, что запись по искомому ключу уже не существует.
assert(mdb_get(txn3, dbi, &key, &val) == MDB_NOTFOUND);
// Завершаем транзакцию.
mdb_txn_abort(txn3);

// Убеждаемся, что в рамках второй транзакции, открытой на момент
// существования записи в базе данных, её всё ещё можно найти по ключу.
assert(mdb_get(txn2, dbi, &key, &val) == MDB_SUCCESS);
// Проверяем, что по ключу получен не абы какой мусор, а валидные данные.
assert(*(int *)val.mv_data == 997);
// Завершаем транзакцию, работающей хоть и с устаревшей, но консистентной базой данных.
mdb_txn_abort(txn2);

আমি সুপারিশ করছি যে আপনি SQLite এর সাথে একই কৌশলটি চেষ্টা করুন এবং দেখুন কি হয়।

মাল্টিভারসন একজন iOS ডেভেলপারের জীবনে খুব সুন্দর সুবিধা নিয়ে আসে। এই সম্পত্তি ব্যবহার করে, আপনি ব্যবহারকারীর অভিজ্ঞতা বিবেচনার ভিত্তিতে স্ক্রীন ফর্মগুলির জন্য ডেটা উত্সের আপডেটের হার সহজে এবং স্বাভাবিকভাবে সামঞ্জস্য করতে পারেন। উদাহরণস্বরূপ, আসুন Mail.ru ক্লাউড অ্যাপ্লিকেশনটির একটি বৈশিষ্ট্য গ্রহণ করি যেমন সিস্টেম মিডিয়া গ্যালারি থেকে সামগ্রী স্বয়ংক্রিয়ভাবে লোড করা। একটি ভাল সংযোগের সাথে, ক্লায়েন্ট সার্ভারে প্রতি সেকেন্ডে বেশ কয়েকটি ফটো যুক্ত করতে সক্ষম। আপনি যদি প্রতিটি ডাউনলোডের পরে আপডেট করেন UICollectionView ব্যবহারকারীর ক্লাউডে মিডিয়া বিষয়বস্তু সহ, আপনি এই প্রক্রিয়া চলাকালীন প্রায় 60 fps এবং মসৃণ স্ক্রোলিং ভুলে যেতে পারেন। ঘন ঘন স্ক্রীন আপডেটগুলি প্রতিরোধ করতে, আপনাকে কোনওভাবে অন্তর্নিহিত ডেটা পরিবর্তনের হার সীমিত করতে হবে UICollectionViewDataSource.

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

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

কার্সার

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

4.2। টেবিল মডেলিং

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

টেবিল স্কিমা

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

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

ক্রমিক কী এবং মান

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

বাঁচাতে NodeKey বস্তুর মধ্যে স্টোরেজ প্রয়োজন MDB_val কাঠামোর শুরুর ঠিকানায় ডেটা পয়েন্টারকে অবস্থান করুন এবং ফাংশন দিয়ে তাদের আকার গণনা করুন sizeof.

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = sizeof(NodeKey),
        .mv_data = (void *)key
    };
}

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

একটি বাইনারি তুলনাকারীর সাথে কী অর্ডার করা

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

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

// value (hex dump)
000 (0000)
256 (0001)
001 (0100)
257 (0101)
...
254 (fe00)
510 (fe01)
255 (ff00)
511 (ff01)

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

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

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

একটি বাহ্যিক তুলনাকারীর সাথে কী অর্ডার করা হচ্ছে

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameBuffer[256];​
} NodeKey;

এর সরলতা সত্ত্বেও, বেশিরভাগ ক্ষেত্রে এটি অত্যধিক মেমরি গ্রহণ করে। নামের জন্য বাফার 256 বাইট নেয়, যদিও গড় ফাইল এবং ফোল্ডারের নাম খুব কমই 20-30 অক্ষরের বেশি হয়।

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

typedef struct NodeKey {​
    EntityId parentId;​
    uint8_t type;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeKey;

আরও, সিরিয়ালাইজ করার সময়, ডেটার আকার নির্দিষ্ট করা হয় না sizeof সম্পূর্ণ কাঠামো, এবং সমস্ত ক্ষেত্রের আকার একটি নির্দিষ্ট দৈর্ঘ্য এবং বাফারের প্রকৃতভাবে ব্যবহৃত অংশের আকার।

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = offsetof(NodeKey, nameBuffer) + key->nameLength,
        .mv_data = (void *)key
    };
}

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

LMDB প্রতিটি ডাটাবেসের নিজস্ব কী তুলনা ফাংশন থাকতে দেয়। এটি ফাংশন ব্যবহার করে করা হয় mdb_set_compare খোলার আগে কঠোরভাবে। সুস্পষ্ট কারণে, এটি ডাটাবেসের সারা জীবন পরিবর্তন করা যাবে না। তুলনাকারী ইনপুট হিসাবে বাইনারি বিন্যাসে দুটি কী পায় এবং আউটপুটে এটি তুলনা ফলাফল প্রদান করে: (-1) এর চেয়ে কম, (1) এর চেয়ে বেশি বা (0) এর সমান। এর জন্য সিউডোকোড NodeKey যে মত দেখায়

int compare(MDB_val * const a, MDB_val * const b) {​
    NodeKey * const aKey = (NodeKey * const)a->mv_data;​
    NodeKey * const bKey = (NodeKey * const)b->mv_data;​
    return // ...
}​

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

ক্রমিক মান

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

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

NSData *data = serialize(object);​
MDB_val value = {​
    .mv_size = data.length,​
    .mv_data = (void *)data.bytes​
};

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

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

typedef struct NodeValue {​
    EntityId localId;​
    EntityType type;​
    union {​
        FileInfo file;​
        DirectoryInfo directory;​
    } info;​
    uint8_t nameLength;​
    uint8_t nameBuffer[256];​
} NodeValue;​

রেকর্ড যোগ করা এবং আপডেট করা

ক্রমিক কী এবং মান স্টোরে যোগ করা যেতে পারে। এটি করতে, ফাংশনটি ব্যবহার করুন mdb_put.

// key и value имеют тип MDB_val​
mdb_put(..., &key, &value, MDB_NOOVERWRITE);

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

এন্ট্রি পড়া

LMDB-তে রেকর্ড পড়তে, ফাংশনটি ব্যবহার করুন mdb_get. যদি কী-মান জোড়া পূর্বে ডাম্প করা কাঠামো দ্বারা উপস্থাপিত হয়, তাহলে এই পদ্ধতিটি এইরকম দেখায়।

NodeValue * const readNode(..., NodeKey * const key) {​
    MDB_val rawKey = serialize(key);​
    MDB_val rawValue;​
    mdb_get(..., &rawKey, &rawValue);​
    return (NodeValue * const)rawValue.mv_data;​
}

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

1. শুধুমাত্র পঠনযোগ্য লেনদেনের জন্য, মান কাঠামোর পয়েন্টারটি লেনদেন বন্ধ না হওয়া পর্যন্ত বৈধ থাকার গ্যারান্টি দেওয়া হয়। যেমনটি আগে উল্লেখ করা হয়েছে, বি-ট্রি পৃষ্ঠাগুলি যেখানে একটি বস্তু অবস্থিত, কপি-অন-রাইট নীতির জন্য ধন্যবাদ, যতক্ষণ না অন্তত একটি লেনদেনের দ্বারা উল্লেখ করা হয় ততক্ষণ পর্যন্ত অপরিবর্তিত থাকে। একই সময়ে, তাদের সাথে যুক্ত শেষ লেনদেন সম্পূর্ণ হওয়ার সাথে সাথে, পৃষ্ঠাগুলি নতুন ডেটার জন্য পুনরায় ব্যবহার করা যেতে পারে। যদি বস্তুর লেনদেন থেকে বেঁচে থাকার প্রয়োজন হয় যা সেগুলি তৈরি করেছে, তারপরও সেগুলিকে কপি করতে হবে।
2. একটি রিডরাইট লেনদেনের জন্য, ফলাফলের মান কাঠামোর নির্দেশক শুধুমাত্র প্রথম পরিবর্তন পদ্ধতি (ডেটা লেখা বা মুছে ফেলা) পর্যন্ত বৈধ হবে।
3. যদিও গঠন NodeValue পূর্ণাঙ্গ নয়, তবে ছাঁটা (উপবিভাগ "একটি বহিরাগত তুলনাকারী ব্যবহার করে কী অর্ডার করা" দেখুন), আপনি পয়েন্টারের মাধ্যমে নিরাপদে এর ক্ষেত্রগুলিতে অ্যাক্সেস করতে পারেন। প্রধান জিনিস এটি dereference না হয়!
4. কোনো অবস্থাতেই প্রাপ্ত পয়েন্টারের মাধ্যমে কাঠামো পরিবর্তন করা উচিত নয়। সমস্ত পরিবর্তন শুধুমাত্র পদ্ধতির মাধ্যমে করা আবশ্যক mdb_put. যাইহোক, আপনি এটি যতই কঠিন করতে চান না কেন, এটি সম্ভব হবে না, যেহেতু এই কাঠামোটি যেখানে মেমরি অঞ্চলটি অবস্থিত সেটি শুধুমাত্র পঠন মোডে ম্যাপ করা হয়েছে।
5. প্রসেস অ্যাড্রেস স্পেসে একটি ফাইল রিম্যাপ করুন, উদাহরণস্বরূপ, ফাংশনটি ব্যবহার করে সর্বাধিক স্টোরেজ আকার বাড়ানোর উদ্দেশ্যে mdb_env_set_map_size সাধারণভাবে সমস্ত লেনদেন এবং সম্পর্কিত সত্তাকে সম্পূর্ণরূপে বাতিল করে এবং বিশেষভাবে নির্দিষ্ট বস্তুর দিকে নির্দেশ করে।

অবশেষে, আরেকটি বৈশিষ্ট্য এতটাই ছলনাময় যে এর সারমর্ম প্রকাশ করা অন্য একটি অনুচ্ছেদে মানায় না। খ-বৃক্ষ সম্পর্কে অধ্যায়ে, আমি এর পৃষ্ঠাগুলি কীভাবে মেমরিতে সাজানো হয় তার একটি চিত্র দিয়েছি। এটি এই থেকে অনুসরণ করে যে সিরিয়ালাইজড ডেটা সহ বাফারের শুরুর ঠিকানাটি একেবারে নির্বিচারে হতে পারে। এই কারণে, তাদের নির্দেশক কাঠামো গৃহীত MDB_val এবং একটি কাঠামোর একটি পয়েন্টারে হ্রাস করা হলে, এটি সাধারণ ক্ষেত্রে আনলাইনড হতে দেখা যায়। একই সময়ে, কিছু চিপের আর্কিটেকচারের (iOS-এর ক্ষেত্রে এটি armv7) প্রয়োজন হয় যে কোনও ডেটার ঠিকানা মেশিন শব্দের আকারের একাধিক বা অন্য কথায়, সিস্টেমের বিট আকার ( armv7 এর জন্য এটি 32 বিট)। অন্য কথায়, একটি অপারেশন মত *(int *foo)0x800002 তাদের উপর পালানোর সমতুল্য এবং একটি রায় দিয়ে মৃত্যুদন্ড কার্যকর করে EXC_ARM_DA_ALIGN. এই ধরনের একটি দুঃখজনক ভাগ্য এড়াতে দুটি উপায় আছে।

প্রথমটি একটি সুস্পষ্টভাবে সারিবদ্ধ কাঠামোতে ডেটার প্রাথমিক অনুলিপিতে ফোঁড়া। উদাহরণস্বরূপ, একটি কাস্টম তুলনাকারীতে এটি নিম্নরূপ প্রতিফলিত হবে।

int compare(MDB_val * const a, MDB_val * const b) {
    NodeKey aKey, bKey;
    memcpy(&aKey, a->mv_data, a->mv_size);
    memcpy(&bKey, b->mv_data, b->mv_size);
    return // ...
}

একটি বিকল্প উপায় হল কম্পাইলারকে আগেই জানিয়ে দেওয়া যে কী-মানের কাঠামোগুলি অ্যাট্রিবিউট-সারিবদ্ধ নাও হতে পারে aligned(1). এআরএম-এ আপনি একই প্রভাব ফেলতে পারেন অর্জন এবং প্যাকড অ্যাট্রিবিউট ব্যবহার করে। এটি বিবেচনা করে যে এটি কাঠামো দ্বারা দখলকৃত স্থানটি অপ্টিমাইজ করতে সহায়তা করে, এই পদ্ধতিটি আমার কাছে পছন্দনীয় বলে মনে হয়, যদিও приводит ডেটা অ্যাক্সেস অপারেশনের খরচ বৃদ্ধির জন্য।

typedef struct __attribute__((packed)) NodeKey {
    uint8_t parentId;
    uint8_t type;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeKey;

রেঞ্জ প্রশ্ন

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

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

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

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

সৌভাগ্যবশত, LMDB API প্রাথমিকভাবে কার্সারের অবস্থান করার একটি কার্যকর উপায় প্রদান করে। এটি করার জন্য, আপনাকে একটি কী তৈরি করতে হবে যার মান স্পষ্টতই ব্যবধানের উপরের সীমানায় অবস্থিত কী-এর চেয়ে কম বা সমান। উদাহরণস্বরূপ, উপরের চিত্রের তালিকার সাথে সম্পর্কিত, আমরা একটি কী করতে পারি যার মধ্যে ক্ষেত্র parentId 2 এর সমান হবে, এবং বাকি সব শূন্য দিয়ে পূর্ণ। এই ধরনের একটি আংশিকভাবে ভরাট কী ফাংশন ইনপুটে সরবরাহ করা হয় mdb_cursor_get অপারেশন ইঙ্গিত MDB_SET_RANGE।

NodeKey upperBoundSearchKey = {​
    .parentId = 2,​
    .type = 0,​
    .nameLength = 0​
};​
MDB_val value, key = serialize(upperBoundSearchKey);​
MDB_cursor *cursor;​
mdb_cursor_open(..., &cursor);​
mdb_cursor_get(cursor, &key, &value, MDB_SET_RANGE);

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

do {​
    rc = mdb_cursor_get(cursor, &key, &value, MDB_NEXT);​
    // processing...​
} while (MDB_NOTFOUND != rc && // check end of table​
         IsTargetKey(key));    // check end of keys group​​

কি চমৎকার যে mdb_cursor_get ব্যবহার করে পুনরাবৃত্তির অংশ হিসাবে, আমরা কেবল কীই নয়, মানও পাই। যদি, নমুনার শর্তগুলি পূরণ করার জন্য, আপনাকে অন্যান্য জিনিসগুলির মধ্যে, রেকর্ডের মান অংশ থেকে ক্ষেত্রগুলি পরীক্ষা করতে হবে, তবে সেগুলি অতিরিক্ত অঙ্গভঙ্গি ছাড়াই বেশ অ্যাক্সেসযোগ্য।

4.3। টেবিলের মধ্যে মডেলিং সম্পর্ক

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

​

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

সূচক টেবিল

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

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

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

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

পরবর্তী, আমরা বিবেচনা করব কিভাবে এই ত্রুটিগুলি দূর করা যায়।

টেবিলের মধ্যে সম্পর্ক সংগঠিত করা

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

টেবিলের মধ্যে সম্পর্ক সংগঠিত করার জন্য আরেকটি প্যাটার্ন হল "অপ্রয়োজনীয় কী". এর সারমর্ম হল কীটিতে অতিরিক্ত বৈশিষ্ট্য যুক্ত করা, যা সাজানোর জন্য নয়, সংশ্লিষ্ট কী পুনরায় তৈরি করার জন্য প্রয়োজন৷ Mail.ru ক্লাউড অ্যাপ্লিকেশনটিতে এটির ব্যবহারের বাস্তব উদাহরণ রয়েছে, তবে, যাতে একটি গভীর ডুব এড়ানো যায় নির্দিষ্ট iOS ফ্রেমওয়ার্কের প্রেক্ষাপটে, আমি একটি কাল্পনিক, কিন্তু একটি পরিষ্কার উদাহরণ দেব

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

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

উপসংহার

আমরা LMDB বাস্তবায়নের ফলাফলগুলিকে ইতিবাচকভাবে মূল্যায়ন করি। এর পরে, আবেদন জমার সংখ্যা 30% কমেছে।

সম্পন্ন কাজের ফলাফল iOS টিম অতিক্রম অনুরণিত. বর্তমানে, অ্যান্ড্রয়েড অ্যাপ্লিকেশনের একটি প্রধান "ফাইল" বিভাগও LMDB ব্যবহারে সুইচ করেছে, এবং অন্যান্য অংশগুলি পথে রয়েছে৷ সি ল্যাঙ্গুয়েজ, যেখানে কী-ভ্যালু স্টোর প্রয়োগ করা হয়, প্রাথমিকভাবে C++ এ ক্রস-প্ল্যাটফর্মের চারপাশে একটি অ্যাপ্লিকেশন ফ্রেমওয়ার্ক তৈরি করতে একটি ভাল সাহায্য ছিল। অবজেক্টিভ-সি এবং কোটলিনে প্ল্যাটফর্ম কোডের সাথে ফলাফল সি++ লাইব্রেরীকে নির্বিঘ্নে সংযোগ করতে একটি কোড জেনারেটর ব্যবহার করা হয়েছিল জিনি ড্রপবক্স থেকে, কিন্তু এটি একটি সম্পূর্ণ ভিন্ন গল্প।

উত্স: www.habr.com