** মাইএসকিউএল-তে মেমরি স্টোরেজ ইঞ্জিন ব্যবহার করার জন্য কী ** নয়?


28

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

  1. আমার কাছে টেবিলগুলি প্রশ্নবিদ্ধ রাখতে পর্যাপ্ত র‌্যাম থাকা দরকার।
  2. মেশিন বন্ধ হয়ে গেলে টেবিলগুলি হারিয়ে যায়।

আমি বিশ্বাস করি যে # 1 টি সমস্যা হওয়া উচিত নয় যেহেতু আমি AWS ইসি 2 ব্যবহার করছি এবং প্রয়োজনে আরও মেমরি দিয়ে একটি উদাহরণ টাইপে যেতে পারি। আমি বিশ্বাস করি যে প্রয়োজন অনুসারে ডিস্কে ফেলার মাধ্যমে আমি # 2 হ্রাস করতে পারি।

আর কী ইস্যু আছে? মেমরি ইঞ্জিনটি কি কখনও মাইআইএসএএম বা ইনোডিবি এর চেয়ে খারাপ পারফরম্যান্স দিতে পারে? আমি মনে করি আমি এমন কিছু পড়েছি যা এই ইঞ্জিনের সাথে সূচকগুলি পৃথক; এই যে আমার সম্পর্কে চিন্তা করা প্রয়োজন?

উত্তর:


27

Http://dev.mysql.com/doc/refman/5.1/en/memory-stores-engine.html এ বৈশিষ্ট্য প্রাপ্যতার তালিকার দিকে তাকানো দুটি সম্ভাব্য সমস্যা হ'ল:

  1. কোনও লেনদেন বা এফকে সমর্থন নয়, অর্থাত আপনার নিজের কোডে লেনদেনের অখণ্ডতা এবং রেফারেনশিয়াল অখণ্ডতা পরিচালনা করতে হবে (যা আপনার পক্ষে ডিবিকে দেওয়ার অনুমতি দেওয়ার চেয়ে অনেক কম দক্ষ হতে পারে, যদিও এটি আপনার অ্যাপের উপর নির্ভর করে প্রত্যাশিত আচরণ নিদর্শন)।
  2. সারণী স্তর কেবলমাত্র লকিং: আপনার অ্যাপ্লিকেশনটিতে একই টেবিলের একাধিক সমবর্তী লেখকের প্রয়োজন হয় বা আপনার পড়া অপারেশনগুলি তালাবন্ধ ব্যবহার করে ধারাবাহিক ডেটা পড়ার তাগিদে নিশ্চিত হয় - এমন ক্ষেত্রে ডিস্ক ভিত্তিক টেবিল যা বর্তমানে প্রচুর পরিমাণে র‌্যামে ক্যাশে দেওয়া থাকলে আরও সূক্ষ্ম লক গ্রানুলারিটি আরও ভাল পারফর্ম করবে supports

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

বিকল্প হতে পারে:

  1. ডিস্ক ভিত্তিক সারণীগুলি ব্যবহার করুন তবে নিশ্চিত করুন যে কোনও নির্দিষ্ট সময়ে এগুলি সমস্ত র‌্যামে রাখার জন্য আপনার কাছে পর্যাপ্ত পরিমাণের চেয়ে বেশি র্যাম রয়েছে (এবং "পর্যাপ্ত র‌্যাম" আপনার মেশিনে ওএসের অন্য কোনও প্রক্রিয়ার জন্য অ্যাকাউন্ট হিসাবে বিবেচনা করার প্রয়োজনের চেয়ে বেশি হতে পারে ensure আইও বাফার / ক্যাশে এবং আরও)
  2. প্রতিটি সূচকের SELECT * FROM <table> ORDER BY <pkey fields>জন্য প্রতিটি টেবিলের সাথে মেমরির সাথে পূর্ববর্তী বিষয়বস্তুটিকে মেমোরিতে প্রিললোড করতে প্রতিটি সূচনাতে সারণীর পুরো সামগ্রী (সমস্ত ডেটা এবং সূচী পৃষ্ঠাগুলি) স্ক্যান করুনSELECT <indexed fields> FROM <table> ORDER BY <index fields>

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


একটি মেমরির ডাটাবেসের জন্য কেন আপনার লেনদেনের অখণ্ডতার প্রয়োজন হবে? বিদ্যুৎ বন্ধ হয়ে গেলে আপনি যাইহোক সবকিছু হারাচ্ছেন।
osa

@ লস: ধরে নিচ্ছেন যে এটি সবকিছুকে ক্রমিক করার পরিবর্তে একযোগে অ্যাক্সেসের অনুমতি দেয়, আপনি এর জন্য কিছুটা নিরপেক্ষতা ব্যবস্থাপনার ব্যবস্থা করতে চাইবেন।
ডেভিড স্পিললেট

14

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

আপনার কাছে যদি যথেষ্ট পরিমাণে বাফার পুল থাকে, তবে পড়ার ক্রিয়াকলাপের জন্য InnoDB সম্পূর্ণ মেমরির বাসিন্দা হয়ে উঠবে। ডাটাবেসে ক্যাশে রয়েছে । তারা নিজেকে উষ্ণ!

এছাড়াও - সারি-স্তরের লকিং এবং এমভিসিসি (পাঠকরা লেখকদের অবরুদ্ধ করেন না) এর মূল্যটিকে অবমূল্যায়ন করবেন না। লেখকদের যখন ডিস্কে অবিরাম থাকতে হয় তখন এটি "ধীর" হতে পারে। তবে কমপক্ষে আপনি সেই লেখার ক্রিয়াকলাপটি ব্লক করবেন না যেমন আপনি কোনও মেমরি টেবিলের উপরে থাকবেন (এমভিসিসি নেই; টেবিল স্তর লকিং নেই)।


3

রেকর্ড এর জন্য. আমি কিছু তথ্যের জন্য মেমোরিতে মাইএসকিএল টেবিলগুলি পরীক্ষা করেছি। এবং আমি একই তথ্য সঞ্চয় করার জন্য পিএইচপি এর এপিসি (এপিসিইউ) পরীক্ষা করেছি।

58000 রেজিস্ট্রি জন্য। (বর্ণচরক + পূর্ণসংখ্যা + তারিখ)।

  1. মূল তথ্য 24mb পাঠ্য বিন্যাসে (সিএসভি ফর্ম্যাট)।
  2. পিএইচপি'র এপিসি 44.7 এমবি র‌্যাম ব্যবহার করে।
  3. মাইএসকিএল-এর সারণীতে 575mb র্যাম ব্যবহার করা হয়েছে।

টেবিলটিতে কেবল একটি একক সূচক রয়েছে তাই আমি মনে করি না যে এটি প্রধান কারণ।

উপসংহার:

মেমরি টেবিল "বড়" টেবিলগুলির জন্য বিকল্প নয় কারণ এটি অত্যধিক মেমরি ব্যবহার করে।


2
এটি একটি বড় উত্তর। মেমোরি স্টোরেজ ইঞ্জিনটি ছোট ডাটা প্রকারগুলি ব্যবহার করে, বিটিআরইকে সূচক প্রকার হিসাবে স্পষ্টভাবে সংজ্ঞায়িত করে এবং র‌্যামে লোড হওয়া ডেটার পরিমাণ সীমাবদ্ধ করে টিউন করা যায়। এটি ছোট সেটগুলির জন্য এখনও কার্যকর একটি বিকল্প। আগ্রাসী ডিস্ক আই / ও এর মতো অন্যান্য কারণও রয়েছে। আমার পোস্টগুলি দেখুন ডিবিএ.স্ট্যাকেক্সেঞ্জার.কম / সেকশনস / 15১৫6/২ এবং ডিবিএ.স্ট্যাকেক্সচেঞ্জ / প্রশ্নগুলি / ২৮68৮/২ )
রোল্যান্ডোমাইএসকিউএলডিবিএ

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

6
কারণটি অবশ্যই আপনার "MEMORY tables use a fixed-length row-storage format. Variable-length types such as VARCHAR are stored using a fixed length." ভ্রচারের কারণে রয়েছে: dev.mysql.com/doc/refman/5.6/en/memory-stores-engine.html কার্যকরভাবে এটি প্রদর্শিত হবে মেমরি ইঞ্জিনের সাহায্যে VARCHAR CHAR হয়ে যায়।
ম্যাথু 1471

2

মেমোরি-ভিত্তিক টেবিলগুলির অন্য অসুবিধা হ'ল একই ক্যোয়ারিতে এগুলি একাধিকবার উল্লেখ করা যায় না। কমপক্ষে সেই আচরণটি v5.4 পর্যন্ত পাওয়া গেছে। কীভাবে সিটিই (v8.x) এর সাথে জটিল পদ্ধতির জন্য মেম-ভিত্তিক মধ্যবর্তী টেবিলগুলি ব্যবহার করার দরকার নেই।


1

মাইএসকিউএল এবং মারিয়াডিবি ম্যানুয়াল অনুসারে, বিএলওবি এবং সিএলওবি (বিভিন্ন পাঠ্য প্রকার) মেমোরি স্টোরেজ দ্বারা সমর্থিত নয়। আমাদের নিজস্ব উদ্দেশ্যে, এটি মেমরি স্টোরেজ ইঞ্জিনকে প্রায় অকেজো করে তুলেছে।

http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html

MEMORY টেবিলগুলিতে BLOB বা পাঠ্য কলাম থাকতে পারে না।

https://mariadb.com/kb/en/mariadb/memory-storage-engine/

ভেরিয়েবল-দৈর্ঘ্যের ধরণের যেমন ভ্রচারের স্মৃতি সারণীতে ব্যবহার করা যেতে পারে। BLOB বা পাঠ্য কলামগুলি মেমরি টেবিলগুলির জন্য সমর্থিত নয়।

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


1

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


1

আগের উত্তরগুলি ছাড়াও। সরাসরি MySQL 5.7 ম্যানুয়াল থেকে:

"আপডেটগুলি প্রক্রিয়া করার সময় একক থ্রেড এক্সিকিউশন এবং টেবিল লক ওভারহেডের ফলাফল হিসাবে বিতর্ক দ্বারা স্মরণীয় কার্য সম্পাদন বাধা হয় load

... এবং এটি একটি সত্যিকারের সীমাবদ্ধতা। উদাহরণস্বরূপ: যখন আপনি একাধিক সেশনগুলি সুন্দর দ্রুত স্মৃতি টেম্প টেবিলগুলি তৈরি করার চেষ্টা করছেন তখন একক থ্রেডিং মারাত্মক পারফরম্যান্স বাধা সৃষ্টি করতে পারে।

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