এই ডাটাবেসে আগুন লেগেছে...

একটা টেকনিক্যাল গল্প বলি।

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

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


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

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

দৈনন্দিন সিঙ্ক ডিজাইন

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

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

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

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

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

প্রথমটিকে বলা হয় ফায়ারবেস রিয়েল-টাইম ডেটাবেস, এবং দ্বিতীয় - ফায়ারবেস ক্লাউড ফায়ারস্টোর. তাদের উভয় থেকে পণ্য ফায়ারবেস স্যুট গুগল তাদের API গুলিকে যথাক্রমে বলা হয় firebase.database(…) и firebase.firestore(…).

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

কারণ আপনাকে নির্দেশ করতে হবে Firebase Firebase প্রশ্নে, এবং ফায়ার স্টোর Firebase সম্পর্কে একটি প্রশ্নে, অন্তত কয়েক বছর আগে স্ট্যাক ওভারফ্লো সম্পর্কে আপনাকে বোঝানোর জন্য।

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

যে জয়লাভে বহু প্রাণহানি হয়

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

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

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

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

তিনি তার চেম্বার থেকে হাজির হয়ে ঘোষণা করলেন:

"একটি বড় JSON নথি? না. আপনি পৃথক নথিতে ডেটা বিভক্ত করবেন, যার প্রতিটির আকার 1 মেগাবাইটের বেশি হবে না।"

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

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

"অ্যারেগুলির অ্যারে যা পুনরাবৃত্তিমূলকভাবে অন্যান্য উপাদান ধারণ করতে পারে? না. অ্যারেতে শুধুমাত্র নির্দিষ্ট দৈর্ঘ্যের বস্তু বা সংখ্যা থাকবে, যেমন ঈশ্বরের ইচ্ছা।"

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

HTTP, কমান্ড লাইন টুল বা অ্যাডমিন প্যানেলের মাধ্যমে JSON আমদানি এবং রপ্তানি? না. আপনি শুধুমাত্র Google ক্লাউড স্টোরেজে ডেটা রপ্তানি এবং আমদানি করতে সক্ষম হবেন৷ এটা এখন বলা হয় কি, আমি মনে করি. এবং যখন আমি বলি "আপনি," আমি কেবল তাদেরই সম্বোধন করছি যাদের কাছে প্রকল্পের মালিকের শংসাপত্র রয়েছে৷ বাকি সবাই গিয়ে টিকিট তৈরি করতে পারবে।"

আপনি দেখতে পাচ্ছেন, ফায়ারবেস ডেটা মডেল বর্ণনা করা সহজ। এটিতে একটি বিশাল JSON নথি রয়েছে যা JSON কীগুলিকে URL পাথের সাথে সংযুক্ত করে। সঙ্গে লিখলে HTTP PUT в / ফায়ারবেস নিম্নলিখিত:

{
  "hello": "world"
}

The GET /hello ফিরে আসবে "world". মূলত এটি ঠিক যেমন আপনি আশা করতে চান কাজ করে. ফায়ারবেস বস্তুর সংগ্রহ /my-collection/:id একটি JSON অভিধানের সমতুল্য {"my-collection": {...}} মূলে, যার বিষয়বস্তু পাওয়া যায় /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

এটি ঠিক কাজ করে যদি প্রতিটি সন্নিবেশে একটি সংঘর্ষ-মুক্ত আইডি থাকে, যার জন্য সিস্টেমের একটি আদর্শ সমাধান রয়েছে।

অন্য কথায়, ডাটাবেসটি 100% JSON(*) সামঞ্জস্যপূর্ণ এবং HTTP এর সাথে দুর্দান্ত কাজ করে, যেমন CouchDB। কিন্তু মূলত আপনি এটি একটি রিয়েল-টাইম API এর মাধ্যমে ব্যবহার করেন যা ওয়েবসকেট, অনুমোদন এবং সদস্যতাগুলিকে বিমূর্ত করে। অ্যাডমিন প্যানেলের উভয় ক্ষমতাই রয়েছে, যা রিয়েল-টাইম সম্পাদনা এবং JSON আমদানি/রপ্তানি উভয়ের অনুমতি দেয়। আপনি যদি আপনার কোডে একই কাজ করেন, আপনি যখন বুঝতে পারবেন যে প্যাচ এবং ডিফ JSON স্থির অবস্থা পরিচালনার রুটিন কাজগুলির 90% সমাধান করে তখন কতটা বিশেষ কোড নষ্ট হবে তা দেখে আপনি অবাক হবেন।

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

তারা একটি রিয়েল-টাইম NoSQL ডাটাবেস নিয়েছিল এবং এটিকে স্বতঃ-যোগদান এবং একটি পৃথক নন-JSON কলাম সহ একটি ধীর নন-এসকিউএলে পরিণত করেছে। GraftQL মত কিছু.

গরম জাভা

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

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

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

আমি ফায়ারস্টোর তৈরির পিছনে সমস্ত যুক্তি জানি না। ব্ল্যাক বক্সের ভিতরে উদ্ভূত উদ্দেশ্য সম্পর্কে অনুমান করাও মজার অংশ। দুটি অত্যন্ত অনুরূপ কিন্তু অতুলনীয় ডাটাবেসের এই মিলন খুবই বিরল। এটা যেমন কেউ ভেবেছিল: "Firebase শুধুমাত্র একটি ফাংশন যা আমরা Google ক্লাউডে অনুকরণ করতে পারি", কিন্তু বাস্তব-বিশ্বের প্রয়োজনীয়তাগুলি সনাক্ত করার বা সেই সমস্ত প্রয়োজনীয়তা পূরণ করে এমন দরকারী সমাধান তৈরি করার ধারণাটি এখনও আবিষ্কার করেনি৷ “ডেভেলপারদের এটি সম্পর্কে চিন্তা করতে দিন। শুধু UI কে সুন্দর করুন... আপনি কি আরও আগুন যোগ করতে পারবেন?"

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

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

আপনি যদি এই সম্পর্কে তথ্যের জন্য Google ডক্সে অনুসন্ধান করেন, আশা করি আপনি BigTable এবং BigQuery এর মতো কিছুর দিকে নির্দেশিত হবেন৷ যাইহোক, এই সমস্ত সমাধানগুলির সাথে এত ঘন কর্পোরেট সেলস জার্গন রয়েছে যে আপনি দ্রুত ফিরে যাবেন এবং অন্য কিছু খুঁজতে শুরু করবেন।

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

(*) এটি একটি রসিকতা, এর মতো কিছু নেই 100% JSON সামঞ্জস্যপূর্ণ.

বিজ্ঞাপনের অধিকারগুলিতে

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

উত্স: www.habr.com