TL;DR: চার বছর আগে আমি একটি নতুন সার্ভার মনিটরিং টুলের জন্য একটি ধারণা নিয়ে Google ত্যাগ করেছি। ধারণাটি ছিল একটি পরিষেবাতে সাধারণত বিচ্ছিন্ন ফাংশনগুলিকে একত্রিত করা সংগ্রহ এবং লগ বিশ্লেষণ, মেট্রিক্স সংগ্রহ, সতর্কতা এবং ড্যাশবোর্ড। একটি নীতি হল যে পরিষেবাটি সত্যই হতে হবে দ্রুত, একটি সহজ, ইন্টারেক্টিভ, উপভোগ্য অভিজ্ঞতার সাথে devops প্রদান করে। এর জন্য বাজেটের মধ্যে থাকার সময় এক সেকেন্ডের ভগ্নাংশে মাল্টি-গিগাবাইট ডেটা সেট প্রক্রিয়াকরণ প্রয়োজন। বিদ্যমান লগ ম্যানেজমেন্ট টুলগুলি প্রায়শই ধীর এবং ক্লাঙ্কি হয়, তাই আমরা একটি ভাল চ্যালেঞ্জের মুখোমুখি হয়েছিলাম: ব্যবহারকারীদের একটি নতুন অভিজ্ঞতা দেওয়ার জন্য স্মার্টভাবে একটি টুল ডিজাইন করা।

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

ওল্ড স্কুল পাওয়ার

লগ বিশ্লেষণ সাধারণত একটি অনুসন্ধান দিয়ে শুরু হয়: একটি নির্দিষ্ট প্যাটার্নের সাথে মেলে এমন সমস্ত বার্তা খুঁজুন। Scalyr-এ, এগুলি হল অনেক সার্ভার থেকে দশ বা শত শত গিগাবাইট লগ। আধুনিক পন্থা, একটি নিয়ম হিসাবে, অনুসন্ধানের জন্য অপ্টিমাইজ করা কিছু জটিল ডেটা কাঠামোর নির্মাণ জড়িত। আমি অবশ্যই Google এ এটি দেখেছি, যেখানে তারা এই ধরণের জিনিসটিতে বেশ ভাল। কিন্তু আমরা অনেক কঠিন পদ্ধতিতে স্থির হয়েছি: লগের রৈখিক স্ক্যানিং। এবং এটি কাজ করেছে - আমরা একটি অনুসন্ধানযোগ্য ইন্টারফেস সরবরাহ করি যা আমাদের প্রতিযোগীদের চেয়ে দ্রুত মাত্রার অর্ডার (শেষে অ্যানিমেশন দেখুন)।

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

এই নিবন্ধ থেকে মূল গ্রহণ:

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

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

পাশবিক শক্তি পদ্ধতি

ঐতিহ্যগতভাবে, একটি বড় ডেটা সেট একটি কীওয়ার্ড সূচক ব্যবহার করে অনুসন্ধান করা হয়। সার্ভার লগগুলিতে প্রয়োগ করা হলে, এর অর্থ হল লগের প্রতিটি অনন্য শব্দ অনুসন্ধান করা। প্রতিটি শব্দের জন্য, আপনাকে সমস্ত অন্তর্ভুক্তির একটি তালিকা তৈরি করতে হবে। এটি এই শব্দ সহ সমস্ত বার্তা খুঁজে পাওয়া সহজ করে তোলে, উদাহরণস্বরূপ 'ত্রুটি', 'ফায়ারফক্স' বা "লেনদেন_16851951" - শুধু সূচীতে দেখুন।

আমি Google এ এই পদ্ধতি ব্যবহার করেছি এবং এটি ভাল কাজ করেছে। কিন্তু Scalyr-এ আমরা বাইট দ্বারা লগ বাইট অনুসন্ধান করি।

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

সূচকগুলি দুর্দান্ত, তবে তাদের সীমাবদ্ধতা রয়েছে। একটি শব্দ খুঁজে পাওয়া সহজ. কিন্তু 'googlebot' এবং '404'-এর মতো একাধিক শব্দ সহ বার্তা অনুসন্ধান করা অনেক বেশি কঠিন। 'অপরাধিত ব্যতিক্রম'-এর মতো একটি শব্দগুচ্ছের জন্য অনুসন্ধান করার জন্য একটি আরও জটিল সূচকের প্রয়োজন যা শুধুমাত্র সেই শব্দের সমস্ত বার্তাই নয়, শব্দের নির্দিষ্ট অবস্থানও রেকর্ড করে।

আপনি শব্দ খুঁজছেন না যখন আসল অসুবিধা আসে. ধরা যাক আপনি দেখতে চান বট থেকে কত ট্রাফিক আসছে। প্রথম চিন্তা হল 'বট' শব্দের লগগুলি অনুসন্ধান করা। এইভাবে আপনি কিছু বট পাবেন: Googlebot, Bingbot এবং আরও অনেক। কিন্তু এখানে 'বট' একটি শব্দ নয়, এর একটি অংশ। যদি আমরা সূচীতে 'বট' অনুসন্ধান করি, আমরা 'গুগলবট' শব্দের সাথে কোনো পোস্ট খুঁজে পাব না। আপনি যদি সূচকের প্রতিটি শব্দ পরীক্ষা করেন এবং তারপরে পাওয়া কীওয়ার্ডগুলির জন্য সূচী স্ক্যান করেন, অনুসন্ধানটি ব্যাপকভাবে ধীর হয়ে যাবে। ফলস্বরূপ, কিছু লগ প্রোগ্রাম আংশিক-শব্দ অনুসন্ধানের অনুমতি দেয় না বা (সর্বোচ্চ) নিম্ন কর্মক্ষমতা সহ বিশেষ বাক্য গঠনের অনুমতি দেয়। আমরা এটা এড়াতে চাই।

আরেকটি সমস্যা হল বিরাম চিহ্ন। আপনি থেকে সব অনুরোধ খুঁজে পেতে চান 50.168.29.7? ডিবাগিং লগ ধারণকারী সম্পর্কে কি [error]? সাবস্ক্রিপ্ট সাধারণত বিরাম চিহ্ন এড়িয়ে যায়।

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

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

কীওয়ার্ড ইনডেক্সগুলিও অনেক জায়গা নেয় এবং লগ ম্যানেজমেন্ট সিস্টেমে স্টোরেজ একটি বড় খরচ।

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

আপনার যদি পাশবিক সমস্যা থাকে (এবং প্রচুর বল) তাহলে ব্রুট ফোর্স কাজ করে

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

আমাদের অনুসন্ধান কোড মূলত একটি মোটামুটি বড় ভিতরের লুপ ছিল. আমরা 4K এ পৃষ্ঠাগুলিতে বার্তা সংরক্ষণ করি; প্রতিটি পৃষ্ঠায় কিছু বার্তা রয়েছে (UTF-8-এ) এবং প্রতিটি বার্তার জন্য মেটাডেটা। মেটাডেটা হল একটি কাঠামো যা মানের দৈর্ঘ্য, অভ্যন্তরীণ বার্তা আইডি এবং অন্যান্য ক্ষেত্রগুলিকে এনকোড করে। অনুসন্ধান চক্রটি দেখতে এইরকম ছিল:

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

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

প্রাথমিকভাবে, এটা মনে হয়েছিল যে এই ধরনের কোড ব্রুট ফোর্স অপ্টিমাইজেশনের জন্য খুব উপযুক্ত ছিল না। "বাস্তব কাজ" মধ্যে String.indexOf() এমনকি CPU প্রোফাইলে আধিপত্য বিস্তার করেনি। অর্থাৎ, একা এই পদ্ধতিটি অপ্টিমাইজ করা একটি উল্লেখযোগ্য প্রভাব আনবে না।

এটি তাই ঘটে যে আমরা প্রতিটি পৃষ্ঠার শুরুতে মেটাডেটা সংরক্ষণ করি, এবং UTF-8-এর সমস্ত বার্তার পাঠ্য অন্য প্রান্তে প্যাক করা হয়। এর সুবিধা নিয়ে, আমরা একবারে পুরো পৃষ্ঠাটি অনুসন্ধান করার জন্য লুপটি পুনরায় লিখেছি:

এই সংস্করণটি সরাসরি ভিউতে কাজ করে raw byte[] এবং সমগ্র 4K পৃষ্ঠা জুড়ে একবারে সমস্ত বার্তা অনুসন্ধান করে।

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

আমাদের প্রকৃত অনুসন্ধান অ্যালগরিদম উপর ভিত্তি করে লিওনিড ভলনিটস্কির দুর্দান্ত ধারণা. এটি বয়য়ার-মুর অ্যালগরিদমের অনুরূপ, প্রতিটি ধাপে অনুসন্ধান স্ট্রিংটির প্রায় দৈর্ঘ্য এড়িয়ে যায়। প্রধান পার্থক্য হল যে এটি মিথ্যা ম্যাচগুলি কমাতে এক সময়ে দুটি বাইট পরীক্ষা করে।

আমাদের বাস্তবায়নের জন্য প্রতিটি অনুসন্ধানের জন্য একটি 64K লুকআপ টেবিল তৈরি করা প্রয়োজন, কিন্তু আমরা যে গিগাবাইট ডেটা অনুসন্ধান করছি তার তুলনায় এটি কিছুই নয়। অভ্যন্তরীণ লুপ একটি একক কোরে প্রতি সেকেন্ডে বেশ কয়েকটি গিগাবাইট প্রক্রিয়া করে। অনুশীলনে, প্রতিটি কোরে স্থিতিশীল কর্মক্ষমতা প্রায় 1,25 জিবি প্রতি সেকেন্ডে, এবং উন্নতির জন্য জায়গা রয়েছে। অভ্যন্তরীণ লুপের বাইরের কিছু ওভারহেড দূর করা সম্ভব, এবং আমরা জাভার পরিবর্তে সি-তে একটি অভ্যন্তরীণ লুপ নিয়ে পরীক্ষা করার পরিকল্পনা করছি।

আমরা শক্তি ব্যবহার করি

আমরা আলোচনা করেছি যে লগ অনুসন্ধান "মোটামুটিভাবে" প্রয়োগ করা যেতে পারে, কিন্তু আমাদের কতটা "ক্ষমতা" আছে? কিছুটা.

1 কোর: সঠিকভাবে ব্যবহার করা হলে, একটি আধুনিক প্রসেসরের একটি একক কোর তার নিজের অধিকারে বেশ শক্তিশালী।

8 কোর: আমরা বর্তমানে Amazon hi1.4xlarge এবং i2.4xlarge SSD সার্ভারে চলছি, প্রতিটি 8টি কোর (16 থ্রেড) সহ। উপরে উল্লিখিত হিসাবে, এই কোরগুলি সাধারণত ব্যাকগ্রাউন্ড অপারেশন নিয়ে ব্যস্ত থাকে। যখন ব্যবহারকারী একটি অনুসন্ধান সঞ্চালন করে, তখন ব্যাকগ্রাউন্ড অপারেশনগুলি স্থগিত করা হয়, অনুসন্ধানের জন্য সমস্ত 8টি কোর মুক্ত করে৷ অনুসন্ধানটি সাধারণত একটি বিভক্ত সেকেন্ডে সম্পূর্ণ হয়, যার পরে পটভূমির কাজ পুনরায় শুরু হয় (থ্রটলিং প্রোগ্রাম নিশ্চিত করে যে অনুসন্ধান প্রশ্নের ব্যারেজ গুরুত্বপূর্ণ পটভূমির কাজে হস্তক্ষেপ করে না)।

16 কোর: নির্ভরযোগ্যতার জন্য, আমরা সার্ভারকে মাস্টার/স্লেভ গ্রুপে সংগঠিত করি। প্রতিটি মাস্টার তার কমান্ডের অধীনে একটি SSD এবং একটি EBS সার্ভার আছে। প্রধান সার্ভার ক্র্যাশ হলে, SSD সার্ভার অবিলম্বে তার জায়গা নেয়। প্রায় সব সময়, মাস্টার এবং স্লেভ ভাল কাজ করে, যাতে প্রতিটি ডেটা ব্লক দুটি ভিন্ন সার্ভারে অনুসন্ধানযোগ্য হয় (ইবিএস স্লেভ সার্ভারের একটি দুর্বল প্রসেসর রয়েছে, তাই আমরা এটি বিবেচনা করি না)। আমরা তাদের মধ্যে কাজটি ভাগ করি, যাতে আমাদের কাছে মোট 16 টি কোর উপলব্ধ থাকে।

অনেক কোর: অদূর ভবিষ্যতে, আমরা এমনভাবে সার্ভার জুড়ে ডেটা বিতরণ করব যাতে তারা সকলেই প্রতিটি অ-তুচ্ছ অনুরোধ প্রক্রিয়াকরণে অংশগ্রহণ করে। প্রতিটি কোর কাজ করবে. [বিঃদ্রঃ: আমরা পরিকল্পনাটি বাস্তবায়ন করেছি এবং অনুসন্ধানের গতি 1 টিবি/সেকেন্ডে বাড়িয়েছি, নিবন্ধের শেষে নোটটি দেখুন].

সরলতা নির্ভরযোগ্যতা নিশ্চিত করে

ব্রুট ফোর্স পদ্ধতির আরেকটি সুবিধা হল এর মোটামুটি সামঞ্জস্যপূর্ণ কর্মক্ষমতা। সাধারণত, অনুসন্ধান সমস্যা এবং ডেটা সেটের বিশদ বিবরণের জন্য খুব সংবেদনশীল নয় (আমি অনুমান করি এজন্যই এটিকে "মোটা" বলা হয়)।

কীওয়ার্ড সূচক কখনও কখনও অবিশ্বাস্যভাবে দ্রুত ফলাফল তৈরি করে, এবং অন্য সময় তা হয় না। ধরা যাক আপনার কাছে 50 GB লগ আছে যেখানে 'customer_5987235982' শব্দটি ঠিক তিনবার দেখা যাচ্ছে। এই শব্দের জন্য একটি অনুসন্ধান সূচক থেকে সরাসরি তিনটি অবস্থান গণনা করে এবং অবিলম্বে সম্পূর্ণ হবে৷ কিন্তু জটিল ওয়াইল্ডকার্ড অনুসন্ধান হাজার হাজার কীওয়ার্ড স্ক্যান করতে পারে এবং অনেক সময় নিতে পারে।

অন্যদিকে, ব্রুট ফোর্স অনুসন্ধানগুলি যে কোনও প্রশ্নের জন্য কমবেশি একই গতিতে সঞ্চালিত হয়। দীর্ঘ শব্দের জন্য অনুসন্ধান করা ভাল, কিন্তু এমনকি একটি একক অক্ষর অনুসন্ধান করা বেশ দ্রুত।

ব্রুট ফোর্স পদ্ধতির সরলতার অর্থ হল এর কর্মক্ষমতা তার তাত্ত্বিক সর্বাধিকের কাছাকাছি। অপ্রত্যাশিত ডিস্ক ওভারলোড, লক কনটেশন, পয়েন্টার ধাওয়া, এবং ব্যর্থতার হাজার হাজার অন্যান্য কারণের জন্য কম বিকল্প রয়েছে। আমি আমাদের ব্যস্ততম সার্ভারে গত সপ্তাহে Scalyr ব্যবহারকারীদের করা অনুরোধগুলি দেখেছি। 14 অনুরোধ ছিল. ঠিক তাদের আটজন এক সেকেন্ডের বেশি সময় নিয়েছে; 000% 99 মিলিসেকেন্ডের মধ্যে সম্পন্ন হয়েছে (যদি আপনি লগ বিশ্লেষণের সরঞ্জাম ব্যবহার না করে থাকেন, আমাকে বিশ্বাস করুন: এটা দ্রুত).

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

কর্মে লগ অনুসন্ধান করুন

এখানে একটি সংক্ষিপ্ত অ্যানিমেশন রয়েছে যা স্ক্যালার অনুসন্ধানকে অ্যাকশনে দেখায়। আমাদের একটি ডেমো অ্যাকাউন্ট রয়েছে যেখানে আমরা প্রতিটি পাবলিক গিথুব সংগ্রহস্থলে প্রতিটি ইভেন্ট আমদানি করি। এই ডেমোতে, আমি এক সপ্তাহের মূল্যের ডেটা পরীক্ষা করি: প্রায় 600 MB কাঁচা লগ।

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

উপসংহার ইন

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

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

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

সম্পাদনা: শিরোনাম এবং পাঠ্য "প্রতি সেকেন্ডে 20 GB এ অনুসন্ধান" থেকে "প্রতি সেকেন্ডে 1 TB অনুসন্ধান" এ পরিবর্তিত হয়েছে যাতে গত কয়েক বছরে কর্মক্ষমতা বৃদ্ধি পায়। গতির এই বৃদ্ধি প্রাথমিকভাবে EC2 সার্ভারের ধরন এবং সংখ্যার পরিবর্তনের কারণে আমরা আজকে আমাদের বর্ধিত গ্রাহক বেসকে পরিবেশন করতে যাচ্ছি। শীঘ্রই কিছু পরিবর্তন আসছে যা অপারেশনাল দক্ষতায় আরেকটি নাটকীয় উন্নতি ঘটাবে এবং আমরা সেগুলি শেয়ার করার জন্য অপেক্ষা করতে পারি না।

উত্স: www.habr.com