পৃথক এসকিউএল সার্ভার টেবিলগুলিতে বিএলএলবিগুলি সংরক্ষণ করার প্রস্তাব দেওয়া হচ্ছে কেন?


29

এই উচ্চ-আপোভিত এসও উত্তরটি অন্য টেবিলের সাথে কেবলমাত্র 1: 1 এর সম্পর্ক থাকলেও পৃথক টেবিলগুলিতে চিত্রগুলি রাখার পরামর্শ দেয়:

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

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

উত্তর:


15

যদিও আমি একমত নই যে বিএলএবগুলি কেবল অন্য টেবিলে থাকা উচিত - সেগুলি ডেটাবেজে মোটেই উচিত নয় । ফাইলটি যেখানে ডিস্কে থাকে সেদিকে একটি পয়েন্টার সঞ্চয় করুন এবং তারপরে কেবল এটি ডাটাবেস থেকে পান ...

তারা যে প্রাথমিক সমস্যাটি সৃষ্টি করেছে (তা আমার জন্য) তা সূচকের সাথে। কোয়েরি প্ল্যান সহ এক্সএমএল ব্যবহার করা, কারণ প্রত্যেকেরই কাজ এখন, একটি টেবিল তৈরি করা যাক:

SELECT TOP 1000
ID = IDENTITY(INT,1,1),
deq.query_plan
INTO dbo.index_test
FROM sys.dm_exec_cached_plans AS dec
CROSS APPLY sys.dm_exec_query_plan(dec.plan_handle) AS deq

ALTER TABLE dbo.index_test ADD CONSTRAINT pk_id PRIMARY KEY CLUSTERED (ID)

এটি কেবল 1000 সারি, তবে আকারটি পরীক্ষা করছে ...

sp_BlitzIndex @DatabaseName = 'StackOverflow', @SchemaName = 'dbo', @TableName = 'index_test'

এটি মাত্র 1000 সারিগুলির জন্য 40 এমবি এর বেশি। ধরে নিই যে আপনি প্রতি 1000 টি সারিতে 40 এমবি যুক্ত করেছেন, এটি বেশ কুৎসিত দ্রুত পেতে পারে। আপনি যখন 1 মিলিয়ন সারিগুলিতে আঘাত করবেন তখন কি হবে? এটি সেখানে প্রায় 1 টিবি ডেটা।

পাগল

আপনার ক্লাস্টারড সূচকটি ব্যবহার করার জন্য যে কোনও প্রশ্নের এখনই সেই সমস্ত বিএলএলওবা তথ্য মেমরির স্পষ্টির মধ্যে পড়তে হবে : যখন বিএলওবি ডেটা কলামটি রেফারেন্স করা হয়।

আপনি কি এসএকিউএল সার্ভার মেমোরি ব্যবহারের জন্য বিএলএলওগুলি সংরক্ষণ করার চেয়ে ভাল উপায়ের কথা ভাবতে পারেন? কারণ আমি নিশ্চিত।

এটি অবিচ্ছিন্ন সূচকে প্রসারিত করা:

CREATE INDEX ix_noblob ON dbo.index_test (ID)

CREATE INDEX ix_returnoftheblob ON dbo.index_test (ID) INCLUDE (query_plan)

বিএলওবি কলাম এড়াতে আপনি আপনার অবিচ্ছিন্ন সূচকগুলি ডিজাইন করতে পারেন যাতে নিয়মিত প্রশ্নগুলি ক্লাস্টারড সূচক এড়াতে পারে, তবে আপনার এই বিএলওবি কলামের সাথে সাথে আপনার ক্লাস্টারড সূচীটি প্রয়োজন।

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

তাদের সৃষ্ট আরও সমস্যা:

  • যদি কেউ কোনও SELECT *ক্যোয়ারী চালায় তবে তারা সেই সমস্ত বিএলওবি ডেটা পাবেন।
  • তারা ব্যাকআপগুলিতে স্থান নেয় এবং পুনরুদ্ধার করে, তাদের ধীর করে দেয়
  • তারা ধীরে ধীরে DBCC CHECKDB, কারণ আমি জানি আপনি দুর্নীতির জন্য যাচাই করছেন, তাই না?
  • এবং যদি আপনি কোনও সূচক রক্ষণাবেক্ষণ করেন তবে তারা এটিকেও ধীর করে দেয়।

আশাকরি এটা সাহায্য করবে!


7
কারণ ব্যবহারকারীরা সাধারণত নির্বাচন করুন * টাইপ করুন।
ব্রেন্ট ওজার

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

11

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

এরিকের নির্দেশিত বেশিরভাগ নেতিবাচক দিকগুলি হ্রাস করার বিষয়ে বিবেচনার জন্য কয়েকটি বিকল্প হ'ল:

এই দুটি অপশনই বিএলওবিগুলি সম্পূর্ণরূপে এসকিউএল সার্ভারে বা পুরোপুরি বাইরে স্টোর করার মধ্যবর্তী স্থল হিসাবে নকশাকৃত path বাফার পুলে (অর্থাত মেমরি) স্থান নষ্ট না করে তারা বিএলওবিগুলিকে ডেটা মডেলের অংশ হতে এবং লেনদেনে অংশ নিতে অনুমতি দেয়। BLOB ডেটা এখনও ব্যাকআপগুলিতে অন্তর্ভুক্ত রয়েছে, যা তাদের আরও স্থান নিতে এবং ব্যাকআপ নিতে আরও সময় নেয় এবংপুনঃস্থাপন করা. তবে এটিকে সত্যিকারের নেতিবাচক হিসাবে দেখার পক্ষে আমার পক্ষে খুব কঠিন সময় হয়েছে যে যদি এটি অ্যাপের অংশ হয় তবে এটি কোনওভাবে ব্যাক আপ করা দরকার, এবং কেবল একটি স্ট্রিং কলাম থাকা পথটি সম্পূর্ণ সংযোগ বিচ্ছিন্ন হয়ে গেছে এবং BLOB ফাইলগুলি পাওয়ার অনুমতি দেয় ডিবিতে এটির কোনও ইঙ্গিত ছাড়াই মুছে ফেলা হয়েছে (অর্থাত্ অবৈধ পয়েন্টার / ফাইল হারিয়ে যাওয়া)। এটি ডিবি-র মধ্যে ফাইলগুলি "মুছে ফেলার" অনুমতি দেয় তবে ফাইল সিস্টেমে এখনও বিদ্যমান থাকে যা শেষ পর্যন্ত পরিষ্কার করতে হবে (অর্থাত মাথাব্যথা)। তবে, ফাইলগুলি যদি বিশাল হয় তবে পাথ কলাম বাদে এসকিউএল সার্ভারের বাইরে পুরোপুরি ছেড়ে দেওয়া ভাল।

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

সুতরাং, আপনি নিতে পারেন এমন বেশ কয়েকটি পদ্ধতি রয়েছে এবং সর্বোত্তম কী আপনার পরিবেশ এবং আপনি কী অর্জন করতে চাইছেন তার উপর নির্ভর করে।


আমি ছাপে ছিলাম যে এসকিউএল সার্ভার কেবলমাত্র টেবিলের মধ্যে কিছু উত্সর্গীকৃত বিএলএলওবা ডেটা কাঠামোর জন্য একটি পয়েন্টার সঞ্চয় করে

এত সহজ না। আপনি এখানে কিছু ভাল তথ্য পেতে পারেন , এলআরবি পয়েন্টার (ম্যাক্স) ধরণের জন্য ভারচর, ভার্বাইনারি, ইত্যাদি কি আকার? তবে মূল বিষয়গুলি হ'ল:

  • TEXT, NTEXTএবং IMAGEডেটাটাইপস (ডিফল্টরূপে): 16 বাইট পয়েন্টার
  • VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX)(ডিফল্ট অনুসারে):
    • যদি ডাটাটি সারিতে ফিট করতে পারে তবে এটি সেখানে রাখা হবে
    • যদি ডেটা প্রায় কম হয়। ৪০,০০০ বাইট (লিঙ্কযুক্ত ব্লগ পোস্টটি উচ্চতর সীমা হিসাবে ৪০,০০০ দেখায় তবে আমার পরীক্ষায় কিছুটা উচ্চতর মান দেখানো হয়েছিল) এবং যদি এই কাঠামোর জন্য সারিতে কোনও জায়গা থাকে তবে এলওবি পৃষ্ঠাগুলির সাথে 1 থেকে 5 এর মধ্যে সরাসরি লিঙ্ক থাকবে, এখানে শুরু হবে প্রথম লিঙ্কের জন্য প্রথম 8000 বাইটের 24 টি বাইট, এবং প্রতিটি অতিরিক্ত লিঙ্কে 12 বাইট দ্বারা 8000 বাইটের প্রতিটি অতিরিক্ত সেটের জন্য সর্বোচ্চ 72 বাইট পর্যন্ত যেতে হবে।
    • যদি ডেটা প্রায় শেষ হয়। ৪০,০০০ বাইট বা যথাযথ সংখ্যক সরাসরি লিঙ্কগুলি সংরক্ষণ করার জন্য পর্যাপ্ত জায়গা নেই (উদাহরণস্বরূপ সারিটিতে কেবল ৪০ বাইট বাকি আছে এবং একটি ২০,০০০ বাইট মানের জন্য ৩ টি লিঙ্কের প্রয়োজন যা 48 বাইটের জন্য দুটি অতিরিক্ত লিঙ্কের জন্য প্রথম প্লাস 12 এর জন্য 24 বাইট রয়েছে) মোট প্রয়োজনীয় সারি-সারি স্পেস), তারপরে একটি পাঠ্য গাছের পৃষ্ঠায় 24 বাইট পয়েন্টার থাকবে যেখানে এলওবি পৃষ্ঠাগুলির লিঙ্ক রয়েছে)।

7

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

  1. আলাদা টেবিলে ডেটা রাখার অর্থ আপনি এটিকে একটি পৃথক ডাটাবেসে সঞ্চয় করতে পারেন। এর নির্ধারিত রক্ষণাবেক্ষণের জন্য সুবিধা থাকতে পারে। উদাহরণস্বরূপ, আপনি DBCC CHECKDBকেবল সেই ডাটাবেসে চালাতে পারবেন যাতে বিএলওবি ডেটা রয়েছে।

  2. আপনি যদি সর্বদা BLOB- এ 8000 বাইটের বেশি না রাখেন তবে কিছু সারিটির জন্য এটি সারি-সারি সংরক্ষণ করা সম্ভব । আপনি এটি চাইবেন না কারণ এটি ক্লাস্টারড ইনডেক্স ব্যবহার করে ডেটা অ্যাক্সেস করে এমন ক্যোয়ারীগুলি ধীর করে দেবে এমনকি যদি ক্যোমের দ্বারা কলামটির প্রয়োজন না হয়। আলাদা টেবিলে ডেটা রাখলে এই ঝুঁকি দূর হয়।

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

  4. একটি ক্লাস্টারযুক্ত কলাম স্টোর সূচী একটি বিএলওবি কলামযুক্ত একটি টেবিলে সংজ্ঞায়িত করা যায় না। এই সীমাবদ্ধতা অপসারণ করা হয়েছে এসকিউএল সার্ভার 2017 এ সরানো হবে।

  5. যদি আপনি শেষ পর্যন্ত সিদ্ধান্ত নেন যে ডেটাটি এসকিউএল সার্ভারের বাইরে সরানো উচিত তখনই ডেটা আলাদা টেবিলে থাকলে পরিবর্তন করা আরও সহজ হতে পারে।


1
কিছু ভাল পয়েন্ট এখানে (+1)। তবে # 3 (পুনরায়: অফ-সারি ডেটার জন্য 24 বাইট পয়েন্টার) সম্পর্কে পরিষ্কার হওয়ার জন্য, এটি সর্বদা সঠিক নয়। আমি আমার উত্তরের নীচে ব্যাখ্যা করেছি (সংক্ষেপে) কীভাবে ডেটাটাইপ, মানের আকার এবং সারিতে মুক্ত স্থানের পরিমাণ কীভাবে পয়েন্টারের আকার নির্ধারণ করে।
সলোমন রুটজকি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.