যোগদানের চেয়ে পৃথক প্রশ্নগুলি কি দ্রুত?


44

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

টিএল; ডিআর : আমার যোগদান করা ক্যোয়ারীটি যদি ব্যক্তিগত অনুসন্ধানগুলি চালানোর চেয়ে বেশি সময় নেয় তবে এটি আমার দোষ নাকি এটি প্রত্যাশিত?

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

আমি একসাথে একটি খুব সাধারণ উদাহরণ রাখার চেষ্টা করেছি:

এসকিউএল ফিডল

স্কিমা সেটআপ :

CREATE TABLE MASTER 
( ID INT NOT NULL
, NAME VARCHAR2(42 CHAR) NOT NULL
, CONSTRAINT PK_MASTER PRIMARY KEY (ID)
);

CREATE TABLE DATA
( ID INT NOT NULL
, MASTER_ID INT NOT NULL
, VALUE NUMBER
, CONSTRAINT PK_DATA PRIMARY KEY (ID)
, CONSTRAINT FK_DATA_MASTER FOREIGN KEY (MASTER_ID) REFERENCES MASTER (ID)
);

INSERT INTO MASTER values (1, 'One');
INSERT INTO MASTER values (2, 'Two');
INSERT INTO MASTER values (3, 'Three');

CREATE SEQUENCE SEQ_DATA_ID;

INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 1, 1.3);
INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 1, 1.5);
INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 1, 1.7);
INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 2, 2.3);
INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 3, 3.14);
INSERT INTO DATA values (SEQ_DATA_ID.NEXTVAL, 3, 3.7);

প্রশ্ন এ :

select NAME from MASTER
where ID = 1

ফলাফল :

| NAME |
--------
|  One |

প্রশ্ন বি :

select ID, VALUE from DATA
where MASTER_ID = 1

ফলাফল :

| ID | VALUE |
--------------
|  1 |   1.3 |
|  2 |   1.5 |
|  3 |   1.7 |

অনুসন্ধান সি :

select M.NAME, D.ID, D.VALUE 
from MASTER M INNER JOIN DATA D ON M.ID=D.MASTER_ID
where M.ID = 1

ফলাফল :

| NAME | ID | VALUE |
---------------------
|  One |  1 |   1.3 |
|  One |  2 |   1.5 |
|  One |  3 |   1.7 |

অবশ্যই, আমি এগুলি দিয়ে কোনও পারফরম্যান্স পরিমাপ করিনি, তবে কেউ পর্যবেক্ষণ করতে পারেন:

  • ক্যোরি এ + বি ক্যোয়ারি সি এর মতো ব্যবহারযোগ্য তথ্যের পরিমাণের পরিমাণ প্রদান করে Qu
  • A + বি ক্লায়েন্টকে 1 + 2x3 == 7 "ডেটা সেল" ফিরিয়ে দিতে হবে
  • সি ক্লায়েন্টকে 3x3 == 9 "ডেটা সেল" ফিরিয়ে দিতে হবে, কারণ যোগদানের সাথে আমি স্বাভাবিকভাবেই ফলাফলের সেটগুলিতে কিছু অপ্রয়োজনীয়তা অন্তর্ভুক্ত করি।

এ থেকে জেনারালাইজিং (এটি যতদূর পাওয়া যাবে):

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

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


মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।
জ্যাক ডগলাস

1
আমি একটি বেঞ্চমার্ক চালিয়েছি এবং মিডিয়ামের একটি নিবন্ধে ফলাফল পোস্ট করেছি । আমি এখানে একটি উত্তর যুক্ত করতে পারতাম, তবে ইতিমধ্যে এটি অন্য একটি প্রশ্নে করেছিলাম এবং একাধিক প্রশ্নের একই উত্তর পোস্ট করা ভ্রূণ্য
বেনিয়ামিন

উত্তর:


45

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

যে কোনও পারফরম্যান্সের দৃশ্যে, আপনাকে সমাধানগুলি দ্রুত এবং কী তা দ্রুত পরীক্ষা করতে হবে এবং তা পরীক্ষা করতে হবে

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

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

এটি সম্ভবত সম্ভবত যে ডাটাবেস স্কিমা বা সূচীগুলি আপনি যে প্রশ্নগুলিতে ফেলেছেন সেগুলি আরও ভালভাবে পরিবেশন করার জন্য উন্নত করা যেতে পারে।

একটি যুক্ত প্রশ্নের সাথে সর্বদা একই পরিমাণে তথ্য প্রাপ্ত পৃথক প্রশ্নের চেয়ে বেশি ডেটা ফেরত আসতে হয়।

সাধারণত এটি হয় না। বেশিরভাগ সময় ইনপুট সেট বড় হলেও, ফলাফল সেট ইনপুটগুলির যোগফলের তুলনায় অনেক ছোট হবে।

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

যেহেতু ডাটাবেসটিকে ডেটা একসাথে করাতে হয়, তাই বড় ডেটাসেটের জন্য কেউ ধরে নিতে পারে যে পৃথক ব্যক্তির চেয়ে ডাটাবেসটিকে একক যোগ করা ক্যোয়ারিতে আরও কাজ করতে হয়, যেহেতু (কমপক্ষে) ক্লায়েন্টকে আরও ডেটা ফেরত দিতে হয়।

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

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

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

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

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


নেটওয়ার্ক ব্যান্ডউইথের জন্য +1 একটি সীমাবদ্ধ সম্পদ।
হরি হার্কার

ওপি বলছে যে যোগদানের ডেটা ফলাফলের সেটগুলি সর্বদা বড়। > একটি যোগদান করা ক্যোয়ারীতে সর্বদা পৃথক প্রশ্নের চেয়ে বেশি ডেটা ফেরত আসতে হয়। আমি মনে করি এটি বস্তুনিষ্ঠভাবে সত্য (জন্য> =), উদাহরণস্বরূপ ফলাফল সেট আকারে পৃথক, তারের চেয়ে আরও বেশি ডেটা। এটি সত্য নয় যেখানে আপনার উদাহরণ রয়েছে? যদি আমি লেখকদের সাথে যোগদান করি -> পোস্ট এবং লেখকদের একটি "জীবনী" নামে একটি ক্ষেত্র রয়েছে যা 1 এমবি জেএসওন ক্ষেত্র, 100 টি পোস্টের লেখকের জন্য, তারের উপর দিয়ে আমি 100MB বনাম 1MB প্রেরণ করব। এটা কি ভুল?
হাইট্রোমো

6

অবশ্যই, আমি এগুলি দিয়ে কোনও পারফরম্যান্স পরিমাপ করি নি

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

আপনি ডেটা বাড়ানোর সাথে সাথে ক্যোয়ারের এক এবং দুটি গতি অন্যদিকে বদলে যাবে, তবে ডাটাবেস জয়েন তত দ্রুত হবে।

অভ্যন্তরীণ যোগদানের তথ্য মুছে ফেলা হলে কী হবে তাও আপনার বিবেচনা করা উচিত।


2

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

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

মাঝারি আকারের ক্যোয়ারির জন্য চালিত হতে কয়েক মিনিট সময় নেওয়ার জন্য পরিমিত পরিমাণে ডেটা ফেরত পাওয়া অজানা নয়। সঠিক সূচক এবং ভাল পরিসংখ্যান এরপরে এটি মিলিসেকেন্ডে হ্রাস করে।


-3

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

শেষে, আপনি যা অভিজ্ঞতা অর্জন করেন তা হ'ল অনেক বিকাশকারী দেখতে পান। ডিবিএরা সর্বদা "না, একটি যোগদান কর" বলে থাকে তবে বাস্তবতা হ'ল এক্ষেত্রে একাধিক সাধারণ নির্বাচন করা আরও দ্রুত।


5
যোগদানের ক্ষেত্রে কোনও "নেটওয়ার্ক অদক্ষতা" নেই - এটি সমস্ত ডেটাবেস সার্ভারে ঘটে তাই কোনও নেটওয়ার্ক জড়িত নেই (যদি না আপনি একটি ডিবি লিঙ্কের মাধ্যমে যোগদান করছেন!)
ক্রিস স্যাকসন

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

3
@ টমটম আপনার কাছে একটি পয়েন্ট থাকতে পারে বা নাও থাকতে পারে (যেমন ডেভিড অলড্রিজ পয়েন্ট, সংক্ষেপণের বিষয়) তবে আপনার শব্দটি বিভ্রান্তিকর। "যোগদানের নেটওয়ার্ক অদক্ষতা" ? সত্যিই, এটি ঠিক করুন যাতে এটি আপনার বোঝার অর্থটি স্পষ্ট।
ypercubeᵀᴹ

@ ক্রিসস্যাক্সন নিশ্চিত করুন যে চিত্রটি আপনার কাছে একটি প্রতিবেদনের "শিরোনাম-> বেস-> টেবিল-সারি" এর জন্য সারণী রয়েছে এবং আপনার সমস্ত সারি প্রয়োজন যাতে আপনি এই 3 টি টেবিলের সাথে অন্তর্ভুক্ত হন। প্রতিটি টেবিলের লম্বা ভার্চার রয়েছে তাই যা হয় তা প্রতিটি সারিটির জন্য আপনি এই দীর্ঘ ভার্চার পুনরাবৃত্তি করছেন। অ্যাপ্লিকেশন স্তরটিকে এই সমস্ত স্ট্রিংয়ের জন্য মেমরি বরাদ্দ করতে হবে এবং তারপরে আপনার মডেলটির জন্য তাদের গোষ্ঠী করা দরকার। সুতরাং আমি মনে করি
সেটাই

@ মাইকে যা আপনি নির্বাচিত মত প্রকাশের উপর নির্ভর করে, যোগদানের জন্য নয়। এবং নেটওয়ার্ক সংকোচনের হতে পারে। ওরাকল ডেটাবেস এসকিউএল * নেট পুনরাবৃত্ত সদৃশ মানগুলি nicetheory.io/2018/01/11/… সরান
ক্রিস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.