মাইএসকিউএলে বিভক্ত টেবিলগুলি। ভালো অনুশীলন?


14

আমি একটি বিদ্যমান প্রকল্পে কাজ শুরু করেছি এবং পূর্ববর্তী বিকাশকারী অভিন্ন স্কিমার সাথে আলাদা আলাদা ডেটা সহ 10 টি আলাদা টেবিলের মধ্যে একটি টেবিল বিভক্ত করেছিলেন।

টেবিলগুলি এর মতো দেখায়:

[tableName_0]
[tableName_1]
[tableName_2]
[tableName_3]
[tableName_4]
[tableName_5]
[tableName_6]
[tableName_7]
[tableName_8]
[tableName_9]

প্রাথমিক কীটি একটি পূর্ণসংখ্যা idক্ষেত্র। অ্যাপ্লিকেশনটিতে হ্যাশ অ্যালগরিদম ( idMod 10) ব্যবহার করে লকআপগুলি করার সময় কোন টেবিলটি অ্যাক্সেস করতে হবে তা জানতে। উদাহরণস্বরূপ id= 10 এর ফলাফল হবে [tableName_0]

সংযুক্ত, টেবিলগুলিতে সম্ভবত 100,000 সারি রয়েছে এবং বৃদ্ধির হার তুলনামূলকভাবে কম।

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

উত্তর:


17

আমি মনে করি সবাই এটিকে অতিরিক্ত জটিল করে তুলছে। এখানে মূল কথাটি হ'ল:

সংযুক্ত, টেবিলগুলিতে সম্ভবত 100,000 সারি রয়েছে এবং বৃদ্ধির হার তুলনামূলকভাবে কম।

এই হল পিষ্টক টুকরা হাতল কোনো RDBMS জন্য। একটি টেবিলের সাথে যান, এটিকে সঠিকভাবে সূচক করুন এবং এটিকে সমাধান করা সমস্যা হিসাবে বিবেচনা করুন।

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


3

আপনি মার্জ সারণীগুলি ব্যবহার করতে পারেন, তবে সেগুলি 4.x সংস্করণ থেকে বেশি পুরানো। আপনার অ্যাপ্লিকেশনটি ম্যানুয়ালি বিভাজিত হয়েছে কারণ তা হ'ল ক) আপনি একটি সত্যিকারের পুরানো সংস্করণ চালাচ্ছেন বা খ) মূল বিকাশকারী টেবিলের পার্টিশন সম্পর্কে অবগত ছিলেন না।

সংক্ষেপে আপনি যদি 5.1+ চালাচ্ছেন তবে আপনি মাইএসকিএলকে আপনার জন্য এই বিভাজনটি করতে দিতে পারেন। Http://dev.mysql.com/doc/refman/5.1/en/partitioning.html দেখুন যদি আপনি 5.5 ব্যবহার করছেন তবে আপনার অবশ্যই এই নির্দিষ্ট ডক্সটি পরীক্ষা করা উচিত কারণ কিছুটা পার্থক্য পাবেন।

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

কিছু উদাহরণ:

  • ঘন ঘন অ্যাক্সেস করা লুকিং কী-এর ভিত্তিতে স্ট্রেট বকেটিং (বা হ্যাশিং)। যদি আপনি প্রায়শই একটি প্রাথমিক বা অন্য অনন্য কী দ্বারা সন্ধান করেন তবে মাইএসকিএল আপনার কতগুলি পার্টিশন রয়েছে তার একটি ফ্যাক্টর দ্বারা অনুসন্ধানের স্থানটি কেটে ফেলতে পারে। আপনি যদি একটি কী দ্বারা বিভাজন করেন এবং তারপরে ঘন ঘন ঘন ঘন অন্য কী দ্বারা অনুসন্ধান করেন তবে এটি ক্ষতিকারক হতে পারে Note আপনি যদি কোনও কী দ্বারা অনুসন্ধান করে ডেটা বিভাজনিত না হয়ে থাকেন তবে অবশ্যই এটির জন্য আরও অনুসন্ধান করতে হবে (প্রতিটি পার্টিশনের জন্য একটি, খ / সি, খালি তথ্যটি কোথায় আছে তা জানে না)
  • পরিস্থিতি বিবেচনা করুন যখন আপনার কাছে একটি অস্থায়ী রেকর্ড রয়েছে যা তারিখ অনুসারে বৃদ্ধি পায় এবং আপনি পর্যায়ক্রমে পূর্ববর্তী মাসে ছাঁটাই করেন। আপনি যদি তারিখ অনুসারে পার্টিশন করছেন তবে আপনি কেবল একটি পার্টিশনটি ফেলে দিতে পারেন যা কোনও টেবিলে ফেলে দেওয়ার মতো দ্রুত, যত বড়ই হোক না কেন। আপনি যদি তারিখ অনুসারে এই জাতীয় টেবিল ছাঁটাই করতে চান তবে যেখানে প্রতিটি স্বতন্ত্র সারি মুছে ফেলা হবে সেখানে আপনাকে এক বা একাধিক ডিলিট ক্যোয়ারী সরবরাহ করতে হবে। এর নেতিবাচক দিকটি হ'ল মাইএসকিএল স্বয়ংক্রিয়ভাবে নতুন পার্টিশন তৈরি করে না একবার আপনি এই দৃশ্যের জন্য সর্বাধিক তারিখে পৌঁছেছেন; আপনার প্রয়োজন অনুসারে পার্টিশন যুক্ত করতে আপনার নিজের বাড়তি রক্ষণাবেক্ষণের অতিরিক্ত স্ক্রিপ্টগুলি দরকার।
  • আপনি যদি মাইসাম চেক ব্যবহার করেন এবং পুনরুদ্ধারগুলি অনেক দ্রুত হয়। একটি 100 জি মাইসাম টেবিল বিবেচনা করুন। আপনি যদি ক্র্যাশ হওয়া টেবিলটি পুনরুদ্ধার করতে চান তবে আপনার কমপক্ষে প্রায় 100 জিপি স্পেস ডিস্কের স্থান প্রয়োজন। যদি এটি সমান আকারের 10 টি বিভিন্ন অংশে বিভক্ত হয়ে থাকে তবে আপনার কেবলমাত্র 10G স্পেস প্রয়োজন (এবং দ্রুত পুনরুদ্ধারের জন্য কম কী_সোর্ট_বফার মেমরি); তবে প্রতিটি বিভাজনের জন্য একটি পুনরাবৃত্তি করতে হবে।

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

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

সম্পাদনা

আমার বিবরণ লেখার সময় আমি ভুলে গিয়েছিলাম যে আপনি বলেছেন যে আপনার টেবিলটি 100 কে সারি is আপনার টেবিলের সম্পূর্ণ স্কিমা এবং এটির গড় সারির দৈর্ঘ্য নির্দিষ্ট করে বলা শক্ত তবে সাধারণভাবে এটি মাঝারি আকারের এমনকি হালকা হার্ডওয়্যারের জন্যও লাগে। একই সময়ে, যদি এটি এখন বা নিকট ভবিষ্যতে সমস্যা সৃষ্টি না করে তবে সময় ব্যয় করবেন না এবং এটিকে পরিবর্তন করে ঝুঁকি প্রবর্তন করবেন না।


3

পূর্ববর্তী বিকাশকারী আপনার জন্য যা করেছে তা পার্টিশন-বাই-হ্যাশের নিজস্ব বাস্তবায়ন। মাইএসকিউএল আক্ষরিকভাবে মাইএসকিউএল 5.1 থেকে এটি সমর্থন করে:

http://dev.mysql.com/doc/refman/5.1/en/partitioning-hash.html

আমি কোনও ভাল কারণ ভাবতে পারি না তাই দেশীয় সংস্করণ [1] এর উপর নির্ভর করে বরং আপনার নিজের পার্টিশন বাই হ্যাশ প্রয়োগ করুন। স্কিমা পরিবর্তনগুলি সম্পাদন করা দুঃস্বপ্ন হবে।

আমি খুব কমই পার্টিশন-বাই-হ্যাশ (দেশীয় বাস্তবায়ন) এর প্রস্তাব দিই। আমি মনে করি এটি কার্যকর হবে যদি আপনি এটি একবারে প্রতিটি পার্টিশন সমান্তরাল অনুসন্ধান করতে ব্যবহার করতে পারেন (যা মাইএসকিউএল করবে না)। আপনি যদি একাধিক পার্টিশন জুড়ে অনুসন্ধান করতে চান তবে আপনার বর্ণিত স্কীমটি প্রায়শই ধীর হবে।

[1] তবে অন্যান্য বিভাজনমূলক ধরণের কয়েকটিতে আপনার নিজের বিভাজনটি রোল করার পক্ষে এটি বুদ্ধিমান হতে পারে। মাইএসকিউএল আপনার পার্টিশনটিকে আপনার প্রাথমিক কী এবং সমস্ত অনন্য সূচকের অংশ করতে বাধ্য করে।


2

প্রশ্নের জবাবে:

এটি একটি কার্যকর সমাধান কিনা

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

প্রশ্নের জবাবে:

... যদি এটি কোনও পরিস্থিতিতে একটি ভাল অনুশীলন হয়

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

উদাহরণস্বরূপ কোনও ওয়েব লগ টেবিলটি রূপটি গ্রহণ করতে পারে:

datetime TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
uri VARCHAR(1024),
host VARCHAR(255),
user_agent VARCHAR(255),
etc...

আপনার সমাধান ওয়েবলগ ডাটাবেসে যেমন প্রয়োজন তেমন সারণি তৈরি করে:

weblogs.20120301
weblogs.20120302
weblogs.20120303

প্রভৃতি

এইভাবে, ডেটা রক্ষণাবেক্ষণযোগ্য এবং অনুসন্ধানযোগ্য থেকে যায়। নিষ্কাশন একটি সাধারণ পর্যায়ক্রমিক প্রক্রিয়া হয়ে ওঠে। পুরানো ডেটাতে ক্রমাগত অপারেশনগুলি লক আউট হয় না।

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


0

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

সুতরাং প্রশ্নটি হল: সেই বিভাজনটি কী পারফরম্যান্সের পক্ষে মূল্যবান, বা এটি পারফরম্যান্সের ক্ষতি করে?

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

আমি যখন টেবিলকে বিভক্ত করব কিনা সে সম্পর্কে আমি যখন চিন্তা করি তখন আমি পারফরম্যান্স অর্জন এবং প্রোগ্রামিং জটিলতার মধ্যে বাণিজ্য বন্ধ বিবেচনা করতাম।

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


0

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

আমার> 10 টি টেবিলগুলিতে> 30 জিবি বিভাজনযুক্ত টেবিল রয়েছে। এই টেবিলগুলির কেবলমাত্র আইডি রয়েছে - BLOB এবং আমার কাছে সহজেই রাখা যায়। এবং আইএনএনওডিবি বাফার সংরক্ষণ করতে আমি মাইআইএসএএম ব্যবহার করি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.