সূচকগুলি: নোডের সংখ্যা একই হয় তবে পূর্ণসংখ্যা বনাম স্ট্রিং পারফরম্যান্স

Question

আমি পোস্টগ্রিএসকিউএল (9.4) ডাটাবেস সহ রুবি অন রেলে একটি অ্যাপ্লিকেশন বিকাশ করছি। আমার ব্যবহারের ক্ষেত্রে, টেবিলগুলিতে কলামগুলি খুব ঘন ঘন দেখা হবে, কারণ অ্যাপ্লিকেশনটির পুরো পয়েন্টটি একটি মডেলের খুব নির্দিষ্ট বৈশিষ্ট্য অনুসন্ধান করছে।

আমি বর্তমানে সিদ্ধান্ত নিচ্ছি যে কলামগুলির জন্য কোনও integerটাইপ ব্যবহার করবেন বা সাধারণ স্ট্রিং টাইপ (উদাহরণস্বরূপ character varying(255), যা রেলগুলির মধ্যে পূর্বনির্ধারিত ) ব্যবহার করবেন কিনা তা আমি নিশ্চিত নই কারণ সূচীতে পারফরম্যান্সের পার্থক্য কী হবে তা আমি নিশ্চিত নই।

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

তবে সূচিযুক্ত স্ট্রিংটি প্রায় 20 টি অক্ষরের দীর্ঘ হতে পারে, যা স্মৃতিতে পূর্ণসংখ্যার প্রায় 5x হয় (যদি একটি পূর্ণসংখ্যা 4 বাইট হয়, এবং স্ট্রিংগুলি প্রতি অক্ষর 1 বাইটে খাঁটি ASCII হয়, তবে এটি ধারণ করে)। আমি জানি না কীভাবে ডাটাবেস ইঞ্জিনগুলি সূচক বর্ণনগুলি করতে পারে, তবে যদি এটি স্ট্রিংয়ের সাথে ঠিক মেলে না যায় তবে "স্ক্যান" করতে হয় , তবে সংক্ষেপে এর অর্থ দাঁড়ায় যে স্ট্রিংয়ের চেহারাটি একটি পূর্ণসংখ্যার চেয়ে 5x ধীর হতে পারে; পূর্ণসংখ্যার অনুসন্ধানের জন্য ম্যাচ হওয়া পর্যন্ত "স্ক্যান" 20 এর পরিবর্তে 4 বাইট হবে I'm আমি যা কল্পনা করছি:

দেখার মানটি (পূর্ণসংখ্যা) 4:

স্ক্যানিং ............................ ফাউন্ড | রেকর্ডস পাচ্ছে ... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | |

দেখার মানটি (স্ট্রিং) "কিছু_ভল" (8 বাইট):

স্ক্যানিং ................................................. .................................... ফাউন্ড | রেকর্ডস পাচ্ছে ... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | |

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

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

---

আমি জিজ্ঞাসা করার কারণটি হ'ল রেলগুলির enumটাইপ ম্যাপগুলি স্ট্রিং কীগুলির সাথে পূর্ণসংখ্যা দেয়, তবে সেগুলি ব্যবহারকারী-মুখী কলামগুলি বোঝায় না। মূলত, আপনি যাচাই করতে পারবেন না যে এনাম মানটি একটি বৈধ, কারণ ArgumentErrorকোনও বৈধতা চালানোর আগে একটি অবৈধ মান হ'ল কারণ । কোনও stringধরণের ব্যবহার বৈধকরণের অনুমতি দেয়, তবে যদি কোনও পারফরম্যান্স ব্যয় হয় তবে আমি বৈধতা সমস্যাটি ঘুরিয়ে ফেলতে চাই।

Answer 1

সংক্ষিপ্ত উত্তর: প্রতিটি দিকের integerচেয়ে varcharবা দ্রুত text। ছোট টেবিল এবং / বা সংক্ষিপ্ত কীগুলির জন্য খুব বেশি গুরুত্ব পাবে না। কীগুলির দৈর্ঘ্য এবং সারি সংখ্যা সহ পার্থক্য বৃদ্ধি পায় grows

স্ট্রিং ... 20 অক্ষর দীর্ঘ, যা স্মৃতিতে পূর্ণসংখ্যার প্রায় 5x হয় (যদি একটি পূর্ণসংখ্যা 4 বাইট হয়, এবং স্ট্রিংগুলি প্রতিটি চরিত্রের 1 বাইটে খাঁটি ASCII হয়, তবে এটি ধারণ করে)

সুনির্দিষ্টভাবে বলতে গেলে, অক্ষরের ধরণগুলি ( textবা varchar) ডিস্কে 20 এএসসিআইআই অক্ষর এবং র‍্যামে 23 বাইটের জন্য ঠিক 21 বাইট দখল করে । বিস্তারিত মূল্যায়ন:

• ভারচার (এন) এর ওভারহেড কী?

এছাড়াও গুরুত্বপূর্ণ: COLLATIONনিয়মগুলি চরিত্রের ডেটা বাছাই করতে আরও ব্যয়বহুল করে তোলে - সংখ্যার ডেটা ধরণের বিপরীতে:

• যখন সমস্ত মান 36 টি হয়, তখন তালিকা বনাম বর্ণের সাথে সূচীকরণটি লক্ষণীয়ভাবে দ্রুত হয়

সূচকের আকার সম্ভবত বেশিরভাগ ক্ষেত্রে পারফরম্যান্সের পার্থক্যের সিংহ ভাগের জন্য দায়ী। ইনডেক্স টিউপল প্রতি ওভারহেড বিবেচনা করুন (মূলত একটি টেবিলের সমান): আইটেম পয়েন্টারটির জন্য 4 বাইট এবং টিউপল শিরোলেখের জন্য 24 বাইট । সুতরাং সূচকটি দ্বিগুণ integerহবে 36 বাইটের ( অ্যালাইনমেন্ট প্যাডিংয়ের 4 বাইট সহ ) এবং varchar(20)20 এসসিআইআই অক্ষর সহ এটি 52 বাইট হবে (এছাড়াও প্যাডিং সহ)। বিবরণ:

• পড়ার পারফরম্যান্সের জন্য PostgreSQL কনফিগার করা

সমস্ত তত্ত্ব একপাশে: কেবল পরীক্ষা করা ভাল:

• পোস্টগ্রিএসকিউএল সারণি সারির আকার পরিমাপ করুন

পোস্টগ্রিস 9.5 অক্ষর ডেটার দীর্ঘ স্ট্রিং বাছাইয়ের জন্য একটি অনুকূলকরণ প্রবর্তন করেছে (মূল শব্দ "সংক্ষেপিত কীগুলি" )। তবে লিনাক্সে কিছু সি লাইব্রেরির ফাংশনগুলির একটি বাগ প্রজেক্টটি পোস্টগ্রিস 9.5.2-তে নন-সি কোলেশনগুলির জন্য বৈশিষ্ট্যটি অক্ষম করতে বাধ্য করেছিল। রিলিজ নোটে বিশদ।

তবে, যদি আপনি প্রকৃতপক্ষে পোস্টগ্র্যাসের ধরণগুলি ব্যবহার করেন তবে enumএগুলির বেশিরভাগ বিবেচনা অপ্রাসঙ্গিক, যেহেতু সেগুলি integerঅভ্যন্তরীণভাবে মান সহ কার্যকর করা হয় । ম্যানুয়াল:

একটি enumমান ডিস্কে চারটি বাইট দখল করে।

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

Comments

varchar(255)বনাম যেমন SQL সার্ভারে কোনও লুকানো অপ্টিমাইজেশন নেই varchar(260)। এসকিউএল সার্ভার x.x এর সাথে এমন কিছু থাকতে পারে তবে এটি দীর্ঘদিন ধরে সত্য নয়।

— a_horse_with_no_name

@ এ_হর্স_বিহীন_নাম_নাম: ধন্যবাদ, আমি সেই অনুযায়ী স্পষ্ট করেছিলাম

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

এটি গ্রহণে এত দীর্ঘ সময় নেওয়ার জন্য দুঃখিত, আমি এই প্রকল্পের বিকাশে ধীর হয়েছি;)

— ক্রিস সাইরেফাইস

দয়া করে উত্তরটি এখনও পোস্টগ্রিস 10 এর জন্য বৈধ?

— ম্যাটি

@ ম্যাটি: এখনও বৈধ। এবং আমি এখন পর্যন্ত pg 11 এর জন্য কোনও পরিবর্তন দেখছি না।

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