নেস্টেড সংস্থাগুলি এবং পাতার সত্তা সম্পত্তিতে গণনা - এসকিউএল বা নোএসকিউএল পদ্ধতির

Question

আমি মেনু / রেসিপি ম্যানেজমেন্ট নামে একটি শখের প্রকল্পে কাজ করছি।

আমার সত্তাগুলি এবং তাদের সম্পর্কগুলি দেখতে এ রকম।

এ Nutrientএর বৈশিষ্ট্য রয়েছে CodeএবংValue

একটি Ingredientএর একটি সংগ্রহ আছেNutrients

এ Recipeএর সংগ্রহ রয়েছে Ingredientsএবং মাঝে মাঝে অন্যের সংগ্রহ থাকতে পারেrecipes

ক Mealএর সংগ্রহ আছে RecipesএবংIngredients

ক Menuএর একটি সংগ্রহ আছেMeals

সম্পর্ক হিসাবে চিত্রিত করা যেতে পারে

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

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

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

আমি এমন একটি পটভূমি পরিষেবা থাকার কথা ভাবছিলাম যা মেনু নিউট্রিয়েন্টস ( {MenuId, NutrientId, Value}) নামে একটি সারণী বজায় রাখে এবং উপাদানগুলির (খাবার, রেসিপি, উপাদান) কোনও পরিবর্তন হলে কার্যকর পুষ্টির সাহায্যে এই টেবিলটিকে পপুলেটেড / আপডেট করবে।

আমি অনুভব করি যে কোনও গ্রাফডিবি এই প্রয়োজনীয়তার জন্য উপযুক্ত হবে তবে নোএসকিউএল-এর সাথে আমার এক্সপোজার সীমিত।

আমি একটি প্রদত্ত মেনুর পুষ্টি প্রদর্শন করার প্রয়োজনীয়তার বিকল্প সমাধান / পদ্ধতির কী তা জানতে চাই।

আশা করি আমার দৃশ্যের বর্ণনাটি পরিষ্কার।

Comments

আমরা কয়টি অবজেক্টে কথা বলছি? পারফরম্যান্স সত্যিই একটি সমস্যা হতে পারে?

— ফ্লপ করুন

@ ফ্লুপ গড়ে একটি মেনুতে 8 টি খাবার থাকতে পারে, প্রতিটি খাবারে 2 টি রেসিপি এবং 2 টি উপাদান থাকতে পারে, প্রতিটি রেসিপিতে 6-8 টি উপাদান থাকতে পারে।

— চান্দু

আপনার তীরগুলি কি ভুল পথে চলছে না?

— ব্র্যাঙ্কো দিমিত্রিজেভিক

আপনি কি Nerd ডিনার সত্তা ফ্রেমওয়ার্ক নমুনা দেখেছেন?

— আকাশ কাওয়া

Answer 1

প্রয়োজনীয়তা এবং আর্কিটেকচারের ভিত্তিতে কর্মক্ষমতা উন্নতির বিকল্প থাকতে পারে:

• আপনি আরডিবিএমএস (এসকিউএল সার্ভার) স্তরে পঠন পারফরম্যান্স উন্নত করতে সূচিযুক্ত দর্শন (ম্যাট্রালাইজড) ব্যবহার করতে পারেন । মূলত, আপনাকে যা করতে হবে তা হ'ল: নিয়মিত দর্শন তৈরি করুন। সেই দৃশ্যে একটি ক্লাস্টার্ড সূচক তৈরি করুন ।
  
  
  
  

• অ্যাপ্লিকেশন পর্যায়ে নগদ নগদকরণ ব্যবস্থার ব্যবহার কার্যকারিতা উন্নত করবে।
  নগদকরণ ব্যবহার যদি এটি সম্ভব এবং সম্ভব হয় তবে সিঙ্গলটন অলস নগদকরণের মতো নগদ কৌশল থাকা আপনাকে সহায়তা করবে।

NoSql:
আছে SQL সম্পর্কে ভাল নিবন্ধ বনাম NoSql প্রচুর, মত এই এবং এই

অংশের স্বার্থ আমিঃ

NoSql ব্যবহার করতে যেখানে:

যদি আপনার ডিবি 3 এনএফ হয় এবং আপনি কোনওভাবে যোগদান না করেন (আপনি কেবল একগুচ্ছ টেবিলগুলি নির্বাচন করছেন এবং সমস্ত বস্তু একসাথে রেখেছেন, বেশিরভাগ মানুষ ওয়েব অ্যাপ্লিকেশনে কী করে A

ব্যবহৃত হলে এর জন্য প্রস্তুত থাকুন:

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

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

Comments

বিশদ জন্য ধন্যবাদ। লিঙ্কগুলি পরীক্ষা করে আপনার কাছে ফিরে আসবে।

— চান্দু

Answer 2

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

order.Subtotal = order.Items.Sum(item => item.Price);
order.Tax = order.Subtotal * 0.25m; // just a value
order.Total = order.Subtotal + order.Tax;

// fast forward time
var subTotal = order.Items.Sum(item => item.Price);
var tax = subTotal * 0.25m;
var total = subTotal + tax;

if (toal == order.Total) {
   Console.Log("Why the hell I've just re-calculated total?");
}

Answer 3

আমি কমান্ড ক্যোয়ারির দায়িত্বশীলতার বিভাজন প্যাটার্নটি দেখার পরামর্শ দিই ।

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

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

নেটে প্রচুর সংস্থান রয়েছে, সিকিউআরএস এবং ডিডিডি অনুসন্ধান করুন (এবং শেষ পর্যন্ত ইভেন্ট সোর্সিং)।

এই প্যাটার্নটি এসকিউএল এবং নো এসকিএল উভয় ক্ষেত্রেই ব্যবহার করা যেতে পারে।

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

এই পদ্ধতির সাহায্যে কিছু জড়িত রয়েছে তবে এটি খুব স্কেল্যাবল এবং এক্সটেনসিবল।

Comments

এটি সেই পদ্ধতির ছিল যা আমি ভাবছিলাম, তবে কীভাবে পঠিত মডেলটির ডেটা পাবেন তা সম্পর্কে নিশ্চিত ছিলেন না (মূলত কিছু প্রক্রিয়াটি আমাকে মডেল পড়ার জন্য ডেটা পেতে পারে)।

— চান্দু

সাধারণত প্রতিটি পরিবর্তনে পঠিত মডেল আপডেট হয়। ক্রুড অপারেশনগুলি ব্যবহার না করে আপনার কমান্ডগুলি (টাস্ক ভিত্তিক) সহ ইউআই বাস্তবায়ন করা উচিত। এইভাবে প্রতিটি একক কমান্ডটি পড়ার মডেলটিতে প্রতিফলিত হয়। আপনার অন্যান্য প্রশ্নগুলি কার্যকর করার দরকার নেই don't ডিজাইনিং কমান্ড সিস্টেমটিকে ব্যবহারকারীর আসল উদ্দেশ্য ক্যাপচার করতে দেয়।

Answer 4

এটি মেনুগুলি এবং পুষ্টির প্রাথমিকভাবে পেতে কীভাবে করবেন তার উপর এটি নির্ভর করে। আপনি কেন এটি দক্ষ হবে না বলে মনে করেন?

আমি যা বুঝি সেখান থেকে আপনি ডিবিতে যান, মেনুটি পান, তারপরে আবার যান, প্রতিটি রেসিপি পান, তারপরে আবার যান এবং প্রতিটি উপাদান এবং আরও কিছু পান। এটি সত্যিই অদক্ষ, কারণ সার্ভারে প্রচুর অনুসন্ধান এবং রাউন্ড-ট্রিপ রয়েছে যা বিলম্বের মূল উত্স। এটি SELECT N + 1 সমস্যা হিসাবে পরিচিত।

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

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

Comments

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

— চান্দু

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

Answer 5

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

আপনি উল্লেখ করেছেন যে পৃষ্ঠাটি পুনরায় লোড করা ডেটাবেজে একটি নতুন ক্যোয়ারী তৈরি করছে। আপনি আরও উল্লেখ করেছেন যে ডাটাবেসটি মাঝেমধ্যে আপডেট করা হবে এবং যখন আপনি চান যে আপডেটগুলি সময়মতো পৃষ্ঠায় প্রদর্শিত হবে। আপনার প্রশ্নের ওভারহেড হ্রাস করার সর্বোত্তম পদ্ধতি সেগুলি না করা। আপনি যদি একই প্রশ্নগুলি বার বার চালিয়ে যাচ্ছেন এবং একই ফলাফলগুলি পেয়ে থাকেন তবে কেন কিছুক্ষণ তাদেরকে ক্যাশে করবেন না? আপনার প্রকল্পের বাকী অংশটি সংশোধন না করে কিছু প্রবাহকে প্রবাহে প্রয়োগ করতে সক্ষম হওয়া উচিত। আমি বিশ্রাম সম্পর্কে পড়ার পরামর্শ দেব। আপনি যদি কোনও rdbms এ প্রকল্পটি প্রয়োগ করেন বা এই ধরণের পারফরম্যান্স সহ সমস্যাগুলি যদি আপনাকে ডাটাবেসে যেতে হয় তার সংখ্যা হ্রাস করে সবচেয়ে ভাল পরিচালনা করা হয়। বলুন আপনার কাছে একই রেসিপিটির জন্য 60 সেকেন্ডের মধ্যে 100 টি অনুরোধ রয়েছে। যদি আপনি 60 সেকেন্ডের জন্য ক্যাশে থাকেন তবে আপনি কেবলমাত্র একবারে ডাটাবেসটিকে আঘাত করেছেন যাতে এটি পারফরম্যান্সের 100x উন্নতি করে। Nosql এ স্যুইচ করে সেই একই স্তরের উন্নতি দেখতে আরও অনেক বেশি কাজ করা দরকার।

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

Answer 6

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

Answer 7

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