`Nvachar / nchar` কখন এসকিউএল সার্ভার 2019 ব্যবহার করা হবে?

Question

এসকিউএল সার্ভারের সাথে 2019 মাইক্রোসফ্ট ইউটিএফ -8 সমর্থনCHAR এবং VARCHARডেটা প্রকারের জন্য প্রবর্তন করে এবং বলে:

ব্যবহৃত বৈশিষ্ট্যের উপর নির্ভর করে এই বৈশিষ্ট্যটি উল্লেখযোগ্য সঞ্চয় স্থান সরবরাহ করতে পারে। উদাহরণস্বরূপ, কোনও ইউটিএফ -8 সক্ষম কল্যান ব্যবহার করে এনসিএইচআর (10) থেকে সিএইচআর (10) এ ASCII স্ট্রিং সহ বিদ্যমান কলামের ডেটা টাইপ পরিবর্তন করে স্টোরেজ প্রয়োজনীয়তার প্রায় 50% হ্রাসে অনুবাদ করে। এই হ্রাসটি হ'ল NCHAR (10) এর জন্য স্টোরেজের জন্য 22 বাইট প্রয়োজন, যখন CHAR (10) একই ইউনিকোড স্ট্রিংয়ের জন্য 12 বাইট প্রয়োজন।

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

আমি অবাক হচ্ছি এর অর্থ কি আমরা ব্যবহার বন্ধ করতে পারি nvarcharএবং ncharকলামগুলি ইউটিএফ -16 প্রয়োগ করে?

UTFএনকোডিং সহ চর ডেটা ধরণগুলি ব্যবহার না করে এবং এন-চরগুলি ব্যবহার চালিয়ে যাওয়ার জন্য কেউ কি কোনও দৃশ্য ও কারণ নির্দেশ করতে পারে?

Comments

আপনি এটি পরীক্ষা করে কেন রিপোর্ট করবেন না? এছাড়াও আমাদের জানতে দিন যে আপনি এনভারচর থেকে বারচরে রূপান্তর করতে কতটা প্রচেষ্টা ব্যয় করেছেন - পরিবর্তিত টেবিলগুলি কত সময় নিয়েছে এবং আপনি পরীক্ষায় কতটা সময় ব্যয় করেছেন এবং কোন সমস্যার মুখোমুখি হয়েছেন।

— কলিন 't হার্ট

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

— gotqn

নোট করুন যে এসকিউএল সার্ভার NVarchar কলামগুলির জন্য ইউনিকোড সংক্ষেপণকে সমর্থন করে যখন পৃষ্ঠা বা ROW সংকোচন ব্যবহার করা হয়। ডকস.মাইক্রোসফট.ইন- ইউএস

— ডেভিড ব্রাউন - মাইক্রোসফ্ট

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

— জেরোইন মোস্টার্ট

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

— জেরোইন মোস্টার্ট

Answer 1

এটি সারণী এবং সূচকের আকার হ্রাস করতে পারে (জোর যুক্ত করা)

আকার কমানো একমাত্র সম্ভাব্য হলে সবচেয়ে অক্ষরের মূলত হয় [space], 0 - 9, A - Z, a - z, এবং কিছু মৌলিক যতিচিহ্ন। অক্ষরের এই নির্দিষ্ট সংকলনের বাইরে (ব্যবহারিক ব্যবহারের শর্তাবলী, স্ট্যান্ডার্ড ASCII মান 32 - 126), আপনি আকার / UTF-16 এর তুলনায় সর্বোত্তম হতে পারবেন NVARCHARবা অনেকগুলি ক্ষেত্রে বৃহত্তর।

আমি ডেটা স্থানান্তর করার পরিকল্পনা করছি কারণ আমি বিশ্বাস করি যে কম ডেটা পড়লে সিস্টেমের পক্ষে সর্বোত্তম পারফরম্যান্স ঘটতে পারে।

সাবধান হও. ইউটিএফ -8 কোনও জাদু নয় "সবকিছু ঠিক করুন" স্যুইচ। অন্যান্য সমস্ত জিনিস সমান হচ্ছে, হ্যাঁ, কম পড়া কার্যকারিতা উন্নত করে। তবে এখানে "অন্যান্য সমস্ত জিনিস" সমান নয় । এমনকি যখন কেবলমাত্র স্ট্যান্ডার্ড এএসসিআইআই অক্ষর সংরক্ষণ করা হয় (অর্থাত: সমস্ত অক্ষর 1 বাইট হয়, সুতরাং সংরক্ষণের তুলনায় অর্ধেক জায়গার প্রয়োজন হয় NVARCHAR), ইউটিএফ -8 ব্যবহারের জন্য সামান্য পারফরম্যান্স জরিমানা রয়েছে। আমি বিশ্বাস করি যে সমস্যাটি ইউটিএফ -8 একটি পরিবর্তনশীল দৈর্ঘ্যের এনকোডিং হওয়ার কারণে, যার অর্থ এটি একটি সম্পূর্ণ চরিত্র কিনা বা পরবর্তী বাইটটি এর একটি অংশ কিনা তা জানতে প্রতিটি বাইটটি পড়ার সাথে সাথে তা ব্যাখ্যা করতে হবে। এর অর্থ হ'ল সমস্ত স্ট্রিং অপারেশনগুলির শুরুতে শুরু হওয়া এবং বাই বাই বাই চালানো দরকার। অন্য দিকে,NVARCHAR / ইউটিএফ -16 সর্বদা 2 বাইট (এমনকি পরিপূরক অক্ষর দুটি 2-বাইট কোড পয়েন্ট সমন্বিত থাকে), তাই 2-বাইট খণ্ডে সমস্ত কিছু পড়া যায়।

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

NVARCHAR(MAX)ইউনিকোড কম্প্রেশন যেহেতু সেই ডেটাটাইপটির সাথে কাজ করে না, ব্যবহার করার সময় জিনিসগুলি আরও জটিল হয়ে ওঠে, এমনকি যদি মানটি সারিতে রাখার জন্য যথেষ্ট পরিমাণে ছোট থাকে। তবে, ডেটা যদি পর্যাপ্ত পরিমাণে ছোট হয় তবে এটি সারি বা পৃষ্ঠা সংক্ষেপণ থেকে উপকৃত হওয়া উচিত (সেক্ষেত্রে এটি আসলে ইউটিএফ -8 এর চেয়ে দ্রুত হয়ে যায়)। তবে অফ-সারি ডেটা কোনও সংক্ষেপণ ব্যবহার করতে পারে না। তবুও, টেবিলটিকে একটি ক্লাস্টারযুক্ত কলামস্টোর সূচক তৈরি করা এর আকারকে হ্রাস করে দেয় NVARCHAR(MAX)(এমনকি যদি এটি ক্লাস্টারড কলামস্টোর সূচক ব্যবহার করার সময় ইউটিএফ -8 এর চেয়ে কিছুটা বড় হয়)।

যে কেউ ইউটিএফ এনকোডিং সহ চর ডেটা ধরণের ব্যবহার না করার জন্য কোনও দৃশ্য ও কারণ নির্দেশ করতে পারে

স্পষ্টভাবে. আসলে, বেশিরভাগ ক্ষেত্রেই এটি ব্যবহার করার জন্য আমি সত্যিই বাধ্যতামূলক কারণ খুঁজে পাই না। কেবলমাত্র ইউটিএফ -8 থেকে সত্যই উপকার পাওয়া যায়:

1. ডেটা বেশিরভাগ স্ট্যান্ডার্ড ASCII (মান 0 - 127)
2. এটি ইউনিকোড হওয়া দরকার কারণ এটি কোনও একক 8-বিট কোড পৃষ্ঠাতে উপলব্ধ (যেমন ) এর চেয়ে আরও বিস্তৃত অক্ষর সংরক্ষণ করতে পারে mightVARCHAR
3. বেশিরভাগ ডেটা সারি-সারি সঞ্চিত থাকে (সুতরাং পৃষ্ঠা সংক্ষেপণ এমনকি কাজ করে না)
4. আপনার কাছে পর্যাপ্ত ডেটা রয়েছে যা আপনার প্রয়োজন-অ-ক্যোরিয়াম-পারফরম্যান্স কারণে আকার হ্রাস করতে চান (যেমন ব্যাকআপের আকার হ্রাস করুন, ব্যাকআপ / পুনরুদ্ধার করার জন্য প্রয়োজনীয় সময় কমিয়ে দিন ইত্যাদি)
5. আপনি ক্লাস্টারড কলামস্টোর সূচক ব্যবহার করতে পারবেন না (সম্ভবত সারণীর ব্যবহার এই ক্ষেত্রে কর্মক্ষমতা আরও খারাপ করে?)

আমার পরীক্ষাটি দেখায় যে প্রায় সব ক্ষেত্রেই এনভিসার্কার দ্রুত ছিল, বিশেষত যখন আরও বেশি ডেটা ছিল। প্রকৃতপক্ষে, সারি প্রতি 5k অক্ষরের গড় 21k সারিগুলিকে ইউটিএফ -8 এর জন্য 165 এমবি এবং সঙ্কুচিত হওয়ার জন্য 236 এমবি প্রয়োজন NVARCHAR। এবং এখনও NVARCHARঅতিবাহিত সময়ে 2x দ্রুত এবং সিপিইউ সময়ে কমপক্ষে 2x দ্রুত (কখনও কখনও আরও) ছিল। তবুও, এটি ডিস্কে আরও 71 এমবি গ্রহণ করেছে।

এর বাইরেও, আমি ইউটিএফ -8 ব্যবহার করার পরামর্শ দেব না, কমপক্ষে সিটিপি 2 হিসাবে, এই বৈশিষ্ট্যটিতে পাওয়া বিভিন্ন ধরণের বাগের কারণে।

এই নতুন বৈশিষ্ট্যের বিশদ বিশ্লেষণের জন্য, ইউটিএফ -16 এবং ইউটিএফ -8 এর মধ্যে পার্থক্যের ব্যাখ্যা এবং এই বাগগুলির তালিকা সহ, দয়া করে আমার পোস্টটি দেখুন:

এসকিউএল সার্ভার 2019 এ নেটিভ ইউটিএফ -8 সমর্থন: ত্রাণকর্তা বা ভ্রান্ত নবী?

Answer 2

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

আপনার নিজের ভাবনার চেয়ে আরও বেশি পরিবর্তন করার দরকার হতে পারে, যেমন একটি nchar(1)টাইপ দুটি বাইট স্টোরেজ সরবরাহ করে। যে কোনো চরিত্র সংরক্ষণ করতে যথেষ্ট বিএমপি (কোড পয়েন্ট 00FFFF করার 000000)। এই সীমার কিছু অক্ষর ইউটিএফ -8 এ কেবলমাত্র 1 বাইটের সাথে এনকোড করা হবে অন্যদের 2 বা এমনকি 3 বাইটের প্রয়োজন হবে ( আরও বিশদের জন্য এই তুলনা চার্টটি দেখুন)। সুতরাং, ইউটিএফ -8-তে একই সংখ্যার অক্ষরের কভারেজ নিশ্চিতকরণের প্রয়োজন char(3)।

উদাহরণ স্বরূপ:

DECLARE @T AS table 
(
    n integer PRIMARY KEY,
    UTF16 nchar(1) COLLATE Latin1_General_CI_AS,
    UTF8 char(1) COLLATE Latin1_General_100_CI_AS_SC_UTF8
);

INSERT @T (n, UTF16, UTF8)
SELECT 911, NCHAR(911), NCHAR(911);

পরিচিত ত্রুটি দেয়:

এমএসজি 8152, স্তর 16, রাজ্য 30, লাইন এক্সএক্সএক্সএক্স
স্ট্রিং বা বাইনারি ডেটা কেটে যাবে।

অথবা যদি ট্রেস পতাকা 460 সক্রিয় থাকে:

এমএসজি 2628, স্তর 16, রাজ্য 1, লাইন
এক্সএক্সএক্সএক্স স্ট্রিং বা বাইনারি ডেটা টেবিল '@ টি', কলাম 'ইউটিএফ 8' কেটে যাবে। কাটা মান: ''।

UTF8 কলামটি প্রসারিত করার জন্য char(2)বা varchar(2)ত্রুটির সমাধান করে NCHAR(911):

DECLARE @T AS table 
(
    n integer PRIMARY KEY,
    UTF16 nchar(1) COLLATE Latin1_General_CI_AS,
    UTF8 varchar(2) COLLATE Latin1_General_100_CI_AS_SC_UTF8
);

INSERT @T (n, UTF16, UTF8)
SELECT 911, NCHAR(911), NCHAR(911);

যাইহোক, যদি এটি উদাহরণস্বরূপ ছিল NCHAR(8364), আপনার কলামটি আরও char(3)বা আরও বাড়াতে হবে varchar(3)।

এটিও নোট করুন যে ইউটিএফ -8 কোলিশানগুলি সমস্ত পরিপূরক অক্ষর ব্যবহার করে, সুতরাং প্রতিরূপে কাজ করবে না ।

অন্য যে কোনও কিছু বাদ দিয়ে, ইউটিএফ -8 সমর্থন কেবলমাত্র এই সময়ে পূর্বরূপে রয়েছে, সুতরাং উত্পাদন ব্যবহারের জন্য উপলভ্য নয়।