12

আমি বর্তমানে স্ট্যাক ওভারফ্লো এর মন্তব্যের ডেটা ডাম্পের বিরুদ্ধে কিছু প্রশ্ন চালানোর চেষ্টা করছি। এখানে স্কিমা দেখতে কেমন:

CREATE TABLE `socomments` (
  `Id` int(11) NOT NULL,
  `PostId` int(11) NOT NULL,
  `Score` int(11) DEFAULT NULL,
  `Text` varchar(600) NOT NULL,
  `CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `UserId` int(11) NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `idx_socomments_PostId` (`PostId`),
  KEY `CreationDate` (`CreationDate`),
  FULLTEXT KEY `Text` (`Text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

আমি এই ক্যোয়ারীটি টেবিলের বিপরীতে চালিয়েছি, এবং এটি অবিশ্বাস্যরূপে ধীর হয়ে গেছে (এটিতে 29 মিলিয়ন সারি রয়েছে তবে এটিতে একটি সম্পূর্ণ-পাঠ্য সূচি রয়েছে):

SELECT *
FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)

সুতরাং আমি এটির প্রোফাইল দিয়েছি, এর ফলাফলগুলি:

|| Status                     || Duration ||
|| starting                   || 0.000058 ||
|| checking permissions       || 0.000006 ||
|| Opening tables             || 0.000014 ||
|| init                       || 0.000019 ||
|| System lock                || 0.000006 ||
|| optimizing                 || 0.000007 ||
|| statistics                 || 0.000013 ||
|| preparing                  || 0.000005 ||
|| FULLTEXT initialization    || 207.1112 ||
|| executing                  || 0.000009 ||
|| Sending data               || 0.000856 ||
|| end                        || 0.000004 ||
|| query end                  || 0.000004 ||
|| closing tables             || 0.000006 ||
|| freeing items              || 0.000059 ||
|| logging slow query         || 0.000037 ||
|| cleaning up                || 0.000046 ||

আপনি দেখতে পাচ্ছেন, এটি পুরোপুরি প্রারম্ভিককরণে দীর্ঘ সময় ব্যয় করে। এটা কি স্বাভাবিক? তা না হলে আমি কীভাবে এটি ঠিক করব?

mysql innodb full-text-search

— hichris123
সূত্র

আইডিয়া: ২ য় টেবিল তৈরি করুন যেখানে আপনি প্রতি পাঠ্য ক্ষেত্রে প্রতিটি ১,০০০ টি মন্তব্য রাখেন। এখন আপনি এই দ্বিতীয় সারণীতে প্রথমে অনুসন্ধান করুন এবং আপনি উদাহরণস্বরূপ id_group 2এবং পাবেন id_group 23। এটি আপনার প্রধান সারণীর ভিতরে অনুসন্ধান করুন এবং আপনার ক্যোয়ারী আইডিতে 2.000 থেকে 2.999 এবং 23.000 থেকে 23.999 পর্যন্ত সীমাবদ্ধ করুন। আপনি নতুন কীওয়ার্ড সংমিশ্রণ তৈরি করে সমস্ত মন্তব্য মিশ্রিত করার পরে অবশ্যই ২ য় ফলাফল আরও ফলাফলের ফলাফল করবে তবে শেষ পর্যন্ত এটি পুরো বিষয়টিকে ত্বরান্বিত করবে। অবশ্যই এটি ডিস্ক স্পেসের ব্যবহার দ্বিগুণ করে। নতুন মন্তব্যগুলি গ্রুপ-টেবিলে কনক্যাট করা উচিত ।

— মিটগুট

5

অন্যরা এটি একটি উদ্বেগজনক পরিস্থিতি পেয়েছেন

মাইএসকিউএল 5.6 এ ইনোডিবি ফুল-পাঠ্য অনুসন্ধান: পার্ট 3, পারফরম্যান্স
InnoDB ফুলটেক্সট অনুসন্ধানের সাথে QUERY এক্সপ্লোরেশন খুব ধীর is
- 16 সেপ্টেম্বর, 2010
- 5.0.51 এ, 5.0.75, 5.0 বিজেআর
- স্থিতি: কোনও প্রতিক্রিয়া নেই
নির্বাচন জিজ্ঞাসা স্থিতি সম্পূর্ণরূপে প্রারম্ভিক
- অক্টোবর 17, 2014
- মাইএসকিউএল 5.6.19
- স্থিতি: ঠিক করবে না

যেহেতু মাইএসকিউএল ডকুমেন্টেশন এই থ্রেডের স্থিতিতে খুব ক্ষুদ্র

সম্পূর্ণ পাঠ্যক্রম

সার্ভারটি একটি প্রাকৃতিক ভাষার পূর্ণ-পাঠ্য অনুসন্ধান সম্পাদনের জন্য প্রস্তুতি নিচ্ছে।

আপনার একমাত্র আশ্রয় হ'ল কম ডেটা সহ প্রস্তুতি করা। কীভাবে?

পরামর্শ # 1

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

SELECT B.* FROM
(SELECT id FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)) A
LEFT JOIN socomments B USING (id);

এটি একটি কুরুচিপূর্ণ ব্যাখ্যা পরিকল্পনা তৈরি করতে পারে তবে আমি মনে করি প্রোফাইলটি আরও ভাল হবে। মৌলিক ধারণা হল: আপনি আগ্রাসী পূর্ণ টেক্সট অনুসন্ধান Query থাকে, তাহলে এটা যে সময় তথ্য অন্তত পরিমাণ জড়ো করা FULLTEXT initializationএইভাবে সময় হ্রাস, ফেজ।

আমি এর আগেও বহুবার এই পরামর্শ দিয়েছি

পরামর্শ # 2

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

innodb_ft_cache_size
- Def মান 8000000 (7.629 এম)
- সর্বোচ্চ মান 80000000 (76.29 এম)
innodb_ft_total_cache_size
- Def মান 640000000 (610 এম)
- সর্বাধিক মান 1600000000 (1525 এম = 1.49 জি)

একটি মুহূর্ত জন্য এটি সম্পর্কে চিন্তা করুন। পাঠ্য ক্ষেত্রটি ভ্রচার ()০০)। বলুন গড় 300 বাইট। তাদের মধ্যে আপনার 29,000,000 মিলিয়ন রয়েছে। এটি হবে 8 জিবি একটি সামান্য হতে হবে। সম্ভবত ইনোডাব_ফুট_ক্যাচি_ সাইজ এবং ইনানোডব_ফুট_টোটাল_ক্যাচি_ সাইজ বাড়ানোও সহায়তা করতে পারে।

নিশ্চিত করুন যে বৃহত্তর InnoDB ফুলটেক্স বাফারগুলির জন্য আপনার যথেষ্ট পরিমাণে র‌্যাম রয়েছে।

একবার চেষ্টা করে দেখো !!!

— RolandoMySQLDBA
সূত্র

উভয় পরামর্শ চেষ্টা করে, সময়টি প্রায় 10 সেকেন্ডের মধ্যে 200 সেকেন্ডে নামিয়ে আনে। আশ্চর্যের বিষয় হ'ল বাফার পুলটি 9% ব্যবহারের জন্যই ...

— hichris123

আবার অংশের ভিতরে একটি প্লাস চিহ্ন রাখার চেষ্টা করুন:

SELECT B.* FROM (SELECT id FROM socomments WHERE MATCH (Text) AGAINST ('+"fixed the post"' IN BOOLEAN MODE)) A LEFT JOIN socomments B USING (id);

এবং দেখুন এটি কোনও পার্থক্য করে কিনা।

— রোল্যান্ডোমাইএসকিউএলডিবিএ

আমি কারণ হিসাবে একটি প্লাস চিহ্ন সাইন আপ? ডক ( dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html ) বলেছেন

A leading or trailing plus sign indicates that this word must be present in each row that is returned. InnoDB only supports leading plus signs.

আপনার বিশেষ ক্ষেত্রে সঠিক বাক্যাংশটি fixed the postঅবশ্যই উপস্থিত থাকতে হবে।

— রোল্যান্ডোমাইএসকিউএলডিবিএ

একই ফলাফল। সামান্য দ্রুত এবং ধীর, সুতরাং সম্ভবত এটি কার্যকর করা হয়েছিল যখন মিনিটের পার্থক্যের কারণে।

— hichris123

5

আপনি যদি ইনোডিবি ফুলটেক্সটেক্স সূচকগুলি ব্যবহার করছেন, আপনি যদি অনেকগুলি মুছে ফেলা সারি রয়েছে এমন একটি সারণীর বিরুদ্ধে জিজ্ঞাসাবাদ করেন তবে প্রায়শই প্রশ্নগুলি "FULLTEXT সূচনা" অবস্থায় স্থির থাকে। InnoDB- র পূর্ণাঙ্গ প্রয়োগে, মুছে ফেলা সারিগুলি ছাঁটাই করা হয় না যতক্ষণ না পরবর্তী অপ্টিমাইজ অপারেশনটি আক্রান্ত টেবিলের বিরুদ্ধে চালানো হয়। দেখুন: https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html

মোছা রেকর্ডগুলির জন্য পূর্ণ-পাঠ্য সূচক এন্ট্রিগুলি সরাতে, পূর্ণ-পাঠ্য সূচীটি পুনর্নির্মাণ করতে আপনাকে অবশ্যই তালিকাবদ্ধ টেবিলের ইনডোডবি_পটিমাইজ_ফুলটেক্সট_অনালি = ওএন চালিত করতে হবে T

যে কেউ মুছে ফেলা হয়েছে তবে মুছে ফেলা রেকর্ডের তথ্যও পরিদর্শন করতে পারে তথ্য_সেমি ..in নোডব_ফুট_ডিলিট জিজ্ঞাসা করে

এটি সমাধানের জন্য, নিয়মিতভাবে InnoDB ফুলটেক্স ইনডেক্স সহ টেবিলগুলির বিরুদ্ধে অপটিমাইজ সারণী চালানো উচিত।

— টিলার
সূত্র

আমি এটিতে যুক্তি পেয়েছি, তবে আপনি কি তা যাচাই করতে পারবেন innodb_optimize_fulltext_only=1এবং একটি OPTIMIZEটেবিলটি "অপেক্ষায়" মুছে ফেলা সারিগুলির যত্ন নিতে পারে? dba.stackexchange.com/questions/174486/…

— রিডসিও

1

মাইএসকিউএলে একটি নিশ্চিত ত্রুটি রয়েছে ( মুছে ফেলা ডোকিডি ইনোডিবি ফুলটেক্সট টেবিলগুলির অপ্টিমাইজ চলাকালীন রক্ষণ করা হয় না ) যা ভারী মুছুন লোডের (আঁচড় থেকে টেবিলটি পুনর্নির্মাণ না করে) পারফরম্যান্স ট্যাঙ্ক করে।

সম্পর্কিত ।

— Riedsio
সূত্র

0

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

সোলার জাভা প্ল্যাটফর্মের উপর ভিত্তি করে তাই আপনি যদি জাভা-ভিত্তিক অ্যাপ্লিকেশন পরিচালনা করেন তবে এটি আপনার জন্য প্রাকৃতিক পছন্দ হবে, স্পিনিক্স সি ++ তে লেখা এবং মাইএসকিউএল হিসাবে একই ফ্যাশনে ডেমন চরিত্রে অভিনয় করবেন। আপনি অনুসন্ধান করতে চান এমন ডেটা দিয়ে বাহ্যিক ইঞ্জিনটি খাওয়ানোর সাথে সাথে আপনি মাইএসকিউএল থেকেও কিছু প্রশ্ন সরিয়ে নিতে পারেন। আপনার ক্ষেত্রে কোন ইঞ্জিনটি ভাল তা আমি আপনাকে বলতে পারি না, আমি বেশিরভাগ স্পিনিক্স ব্যবহার করি এবং এখানে ব্যবহারের উদাহরণ রয়েছে: http://astellar.com/2011/12/replacing-mysql-full-text-search-with-sphinx/

— vfedorkov
সূত্র

'ফুলটেক্সট ইনিশিয়ালাইজেশন'-এ ব্যয় করা প্রচুর পরিমাণে সম্পূর্ণ পাঠ্য অনুসন্ধানের ফলাফল

পরামর্শ # 1

পরামর্শ # 2

একবার চেষ্টা করে দেখো !!!