দ্রুত, একটি বড় ক্যোয়ারী বা অনেকগুলি ছোট প্রশ্নগুলি কী?

Question

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

তাহলে কি কেবল সহজ নির্বাচন করা এবং তারপরে সিস্টেম কোডে তাদের "যোগদান" করা আরও দ্রুত হবে?

সিস্টেমটি পিএইচপি, জাভা, এসপি, যে কোনও ভাষা হতে পারে যা ডাটাবেসের সাথে সংযুক্ত থাকে।

সুতরাং প্রশ্নটি হ'ল কী সার্ভার সাইড (পিএইচপি, জাভা, এসপি, রুবি, পাইথন ...) থেকে ডেটাবেজে দ্রুত যাচ্ছেন যা আমাদের প্রয়োজন বা সার্ভারের দিক থেকে ডাটাবেসে যাওয়ার জন্য যা কিছু পায় তা চালিয়ে যায় এবং একটি রান করে ক্যোয়ারী যা কেবল একবারে একটি টেবিল থেকে কলামগুলি পান?

Comments

'এসকিউএল' এর কোন প্রয়োগ আপনি ব্যবহার করছেন? মাইএসকিউএল, মাইক্রোসফ্ট এসকিউএল সার্ভার, ওরাকল, পোস্টগ্রেস্কল, ইত্যাদি? আপনার ট্যাগ আপডেট করুন।

— আরএলএফ

— মাইএসকিএল

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

— a_horse_with_no_name

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

— jynus

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

— a_horse_with_no_name

Answer 1

আপনার প্রশ্নটি কী সমাধান করবে তা হ'ল JOIN DECOMPOSITION subject

বইয়ের পৃষ্ঠা 209 অনুসারে

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

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

আপনি এই প্রশ্নগুলি চালাতে পারেন:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

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

• ক্যাচিং আরও দক্ষ হতে পারে। অনেক অ্যাপ্লিকেশন ক্যাশে "অবজেক্টস" যা টেবিলগুলিতে সরাসরি মানচিত্র করে। এই উদাহরণস্বরূপ, ট্যাগযুক্ত বস্তুটি mysqlইতিমধ্যে ক্যাশে করা থাকলে, অ্যাপ্লিকেশনটি প্রথম ক্যোয়ারি এড়িয়ে যাবে। আপনি ক্যাশে 123, 567 বা 908 এর আইডি সহ পোস্টগুলি খুঁজে পেলে আপনি সেগুলি IN()তালিকা থেকে সরাতে পারেন । ক্যোয়ারী ক্যাশে এই কৌশলটি থেকেও উপকৃত হতে পারে। যদি কেবলমাত্র কোনও একটি টেবিল ঘন ঘন পরিবর্তিত হয় তবে একটি জয়েন পচিয়ে দেওয়া ক্যাশে অবৈধতার সংখ্যা হ্রাস করতে পারে।
• প্রশ্নগুলি পৃথকভাবে সম্পাদন করা কখনও কখনও লক বিরোধকে হ্রাস করতে পারে
• অ্যাপ্লিকেশনটিতে যোগদান করে তা বিভিন্ন সার্ভারে টেবিল রেখে ডেটাবেস স্কেল করা সহজ করে তোলে।
• প্রশ্নগুলি নিজেরাই আরও দক্ষ হতে পারে। এই উদাহরণে, IN()যোগদানের পরিবর্তে একটি তালিকা ব্যবহার করে মাইএসকিউএল সারি আইডিগুলি সাজিয়ে দেয় এবং একটি যোগদানের সাথে যতটা সম্ভব সম্ভব তার চেয়ে সারিগুলি আরও সুনির্দিষ্টভাবে পুনরুদ্ধার করতে দেয়।
• আপনি অপ্রয়োজনীয় সারি অ্যাক্সেসগুলি হ্রাস করতে পারেন। অ্যাপ্লিকেশনটিতে যোগদান করা মানে প্রতিটি সারিটি একবারে পুনরুদ্ধার করা, যদিও কোয়েরিতে একটি যোগদান মূলত একটি অস্বীকৃতি যা বারবার একই ডেটা অ্যাক্সেস করতে পারে। একই কারণে, এই ধরনের পুনর্গঠন মোট নেটওয়ার্ক ট্র্যাফিক এবং মেমরির ব্যবহারকে হ্রাস করতে পারে।
• কিছুটা হলেও, আপনি এই কৌশলটি ম্যানুয়ালি একটি হ্যাশ জয়েনকে নেস্টেড লুপস অ্যালগরিদম মাইএসকিউএল পরিবর্তে কোনও জোড় কার্যকর করার জন্য ব্যবহার হিসাবে প্রয়োগ করতে পারেন। একটি হ্যাশ জোড় আরও কার্যকর হতে পারে।

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

পর্যবেক্ষণ

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

• Sep 05, 2012: ঘন ঘন ক্যোয়ারী ক্যাশে অবৈধকরণের ওভারহেড কি কোনও মূল্যবান?
• Jun 07, 2014: মাইএসকিউএল 5.6 থেকে ডিফল্ট সূচনা দিয়ে কেন ক্যুরিয়_ক্যাচি_প্রকারটি অক্ষম করা আছে?

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

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

কিছু পারফরম্যান্সে সন্তুষ্ট হতে পারে এবং কোডটি আর স্পর্শ না করে। অন্যান্যরা সহজেই বুঝতে পারেন না যে তারা যদি রচনাতে যোগদানের চেষ্টা করেন তবে তারা যে কাটতে পারে সেগুলি লাভ করতে পারে।

যারা বিকাশকারী তাদের জন্য ইচ্ছুক ...

একবার চেষ্টা করে দেখো !!!

Comments

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

— রিক জেমস

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

— রোল্যান্ডোমাইএসকিউএলডিবিএ

আমার যদি অধিকার এবং সময় থাকত তবে কীভাবে এটি ওরাকল পরিবেশে কাজ করে তা দেখতে আমি পছন্দ করব।

— রিক হেন্ডারসন

এটির আরও দ্রুততর হওয়ার একটি উপায় হ'ল আপনি অর্ডার করছেন তবে একটি বৃহত তালিকার অর্ডার দেওয়ার চেয়ে ছোট তালিকা অর্ডার করা সামগ্রিকভাবে কম গণনা হবে।

— ইভান সিরোকি

Answer 2

ইন Postgres (এবং সম্ভবত একটি অনুরূপ পরিমাণ কোনো RDBMS, মাইএসকিউএল একটি ক্ষুদ্রতর ব্যাপ্তি), তার চেয়ে কম প্রশ্নের প্রায় সবসময় হয় অনেক দ্রুত।

একাধিক প্রশ্নের পার্সিং এবং পরিকল্পনার ওভারহেড বেশিরভাগ ক্ষেত্রে সম্ভাব্য লাভের চেয়ে ইতিমধ্যে বেশি।

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

আপনি ডিবি সার্ভার এবং ক্লায়েন্টের মধ্যে আরও ডেটা স্থানান্তর করেন। মানগুলি পূর্ণ হাতের জন্য এটি नगणিক হতে পারে বা একটি বিশাল পার্থক্য করতে পারে।

যদি একাধিক ক্যোয়ারী ডেটাবেস সার্ভারে একাধিক রাউন্ড ট্রিপগুলি বোঝায়, আপনি একাধিকবার নেটওয়ার্ক ল্যাটেন্সি এবং লেনদেনের ওভারহেড সংগ্রহ করেন, সম্ভবত এমনকি সংযোগ ওভারহেডও। বড়, বড় ক্ষতি।

আপনার সেটআপের উপর নির্ভর করে একা নেটওয়ার্কের বিলম্বিতকরণের দৈর্ঘ্যের আদেশে বাকি সমস্তগুলির চেয়ে বেশি সময় নিতে পারে।

এসও সম্পর্কিত সম্পর্কিত প্রশ্ন:

• কোনটা ভাল? বর্গক্ষেত্র বা আপনার প্রয়োগে গণনা সম্পাদন করা হচ্ছে

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

Comments

কৌতুহলের বাইরে, আপনি কি খুব বড় বিবেচনা করবেন ?

— সাবেলফোস্টে

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

— এরউইন ব্র্যান্ডসেটেটার

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

— জাস্টামার্টিন

@ জাস্টামার্টিন: আরডিবিএমএস-এর ক্যোয়ারী পরিকল্পনাকারী - সঠিক জিজ্ঞাসা অনুমান করে যে ধরণের ক্যোয়ারী প্রায় অবশ্যই দ্রুততর তা মনে হচ্ছে। সম্পর্কিত returns lots of redundant data for "parent" table: আপনি নিরর্থক তথ্য কেন ফিরিয়ে দেবেন? আপনার প্রয়োজনীয় ডেটা কেবল ফিরিয়ে দিন।

— এরউইন ব্র্যান্ডসেটেটার

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

— জাস্টামার্টিন