হাইলোড++, আন্দ্রে গুশচিন (জ্যাবিক্স): উচ্চ কার্যক্ষমতা এবং নেটিভ পার্টিশন

আমরা দেখব কিভাবে Zabbix ব্যাকএন্ড হিসাবে TimescaleDB ডাটাবেসের সাথে কাজ করে। আমরা আপনাকে দেখাব কিভাবে স্ক্র্যাচ থেকে শুরু করতে হয় এবং কিভাবে PostgreSQL থেকে মাইগ্রেট করতে হয়। আমরা দুটি কনফিগারেশনের তুলনামূলক কর্মক্ষমতা পরীক্ষাও প্রদান করব।

হাইলোড++ সাইবেরিয়া 2019। টমস্ক হল। জুন 24, 16:00. থিসিস এবং উপহার. পরবর্তী HighLoad++ সম্মেলন 6 এবং 7 এপ্রিল, 2020-এ সেন্ট পিটার্সবার্গে অনুষ্ঠিত হবে। বিস্তারিত এবং টিকিট লিংক.

আন্দ্রে গুশচিন (এর পরে - এজি): – আমি একজন ZABBIX প্রযুক্তিগত সহায়তা প্রকৌশলী (এরপরে "Zabbix" হিসাবে উল্লেখ করা হয়েছে), একজন প্রশিক্ষক। আমি 6 বছরেরও বেশি সময় ধরে প্রযুক্তিগত সহায়তায় কাজ করছি এবং পারফরম্যান্সের সাথে সরাসরি অভিজ্ঞতা আছে। আজ আমি নিয়মিত PostgreSQL 10 এর সাথে তুলনা করার সময় TimescaleDB যে পারফরম্যান্স প্রদান করতে পারে সে সম্পর্কে কথা বলব। এছাড়াও, এটি সাধারণভাবে কীভাবে কাজ করে সে সম্পর্কে কিছু পরিচায়ক অংশ।

শীর্ষ উত্পাদনশীলতা চ্যালেঞ্জ: ডেটা সংগ্রহ থেকে ডেটা পরিষ্কার করা পর্যন্ত

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

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

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

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

ক্যাশিং সমস্যা কিভাবে সমাধান করবেন?

আমি এখন Zabbix সম্পর্কে বিশেষভাবে কথা বলব। Zabbix-এ, প্রথম এবং দ্বিতীয় কল ক্যাশিং ব্যবহার করে সমাধান করা হয়।

ডেটা সংগ্রহ এবং প্রক্রিয়াকরণ - আমরা এই সমস্ত ডেটা সংরক্ষণ করতে RAM ব্যবহার করি। এই তথ্য এখন আরো বিস্তারিত আলোচনা করা হবে.

এছাড়াও ডাটাবেসের দিকে প্রধান নির্বাচনের জন্য কিছু ক্যাশিং রয়েছে - গ্রাফ এবং অন্যান্য জিনিসগুলির জন্য।

Zabbix সার্ভারের পাশেই ক্যাশিং: আমাদের কাছে ConfigurationCache, ValueCache, HistoryCache, TrendsCache আছে। এটা কি?

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

Zabbix-এ ক্যাশিং। তথ্য সংগ্রহ

এখানে চিত্রটি বেশ বড়:

স্কিমের প্রধানগুলি হল এই সংগ্রাহক:

এগুলি হল সমাবেশের প্রক্রিয়াগুলি, বিভিন্ন "পোলার" যা বিভিন্ন ধরণের সমাবেশগুলির জন্য দায়ী৷ তারা icmp, ipmi, এবং বিভিন্ন প্রোটোকলের মাধ্যমে ডেটা সংগ্রহ করে এবং এটি সমস্ত প্রিপ্রসেসিংয়ে স্থানান্তর করে।

প্রি-প্রসেসিং HistoryCache

এছাড়াও, যদি আমাদের কাছে গণনা করা ডেটা উপাদান থাকে (যারা Zabbix এর সাথে পরিচিত তারা জানেন), অর্থাৎ, গণনা করা, একত্রিত ডেটা উপাদান, আমরা সেগুলি সরাসরি ValueCache থেকে গ্রহণ করি। এটা কিভাবে পূরণ হয়েছে আমি আপনাকে পরে বলব। এই সমস্ত সংগ্রাহক তাদের কাজ পেতে ConfigurationCache ব্যবহার করে এবং তারপরে তাদের প্রিপ্রসেসিংয়ে পাঠায়।

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

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

হিস্ট্রি সিঙ্কারের কাজ

Zabbix-এর প্রধান প্রক্রিয়া (যেহেতু এটি একটি মনোলিথিক আর্কিটেকচার) হল হিস্ট্রি সিঙ্কার। এটি হল মূল প্রক্রিয়া যা প্রতিটি ডেটা উপাদানের পারমাণবিক প্রক্রিয়াকরণের সাথে বিশেষভাবে ডিল করে, অর্থাৎ প্রতিটি মান:

• মান আসে (এটি HistoryCache থেকে নেয়);
• কনফিগারেশন সিঙ্কারে পরীক্ষা করে: গণনার জন্য কোনো ট্রিগার আছে কিনা - সেগুলি গণনা করে;
  যদি থাকে - ইভেন্ট তৈরি করে, কনফিগারেশন অনুযায়ী প্রয়োজনে সতর্কতা তৈরি করার জন্য বৃদ্ধি তৈরি করে;
• পরবর্তী প্রক্রিয়াকরণ, সমষ্টির জন্য রেকর্ড ট্রিগার; আপনি যদি শেষ ঘন্টা এবং আরও অনেক কিছু মিলিয়ে দেখেন, এই মানটি ValueCache দ্বারা মনে রাখা হবে যাতে ইতিহাসের টেবিলে না যায়; এইভাবে, ValueCache প্রয়োজনীয় ডেটা দিয়ে পূর্ণ হয় যা ট্রিগার, গণনা করা উপাদান, ইত্যাদি গণনা করার জন্য প্রয়োজনীয়;
• তারপর ইতিহাস সিঙ্কার ডাটাবেসে সমস্ত ডেটা লেখে;
• ডাটাবেস তাদের ডিস্কে লেখে - এখানেই প্রক্রিয়াকরণ প্রক্রিয়া শেষ হয়।

তথ্যশালা. ক্যাশিং

ডাটাবেসের দিকে, আপনি যখন ইভেন্টের গ্রাফ বা কিছু প্রতিবেদন দেখতে চান, তখন বিভিন্ন ক্যাশে থাকে। তবে এই প্রতিবেদনে আমি তাদের সম্পর্কে কথা বলব না।

MySQL এর জন্য রয়েছে Innodb_buffer_pool, এবং বিভিন্ন ক্যাশের একটি গুচ্ছ যা কনফিগার করা যেতে পারে।
কিন্তু এইগুলি প্রধান হল:

• শেয়ার্ড_বাফার;
• কার্যকরী_ক্যাশে_সাইজ;
• শেয়ার্ড_পুল।

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

ডাটাবেস কর্মক্ষমতা সম্পর্কে

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

এছাড়াও একটি খুব জনপ্রিয় ভিজ্যুয়ালাইজেশন সমাধান হল Grafana, যা আমাদের ব্যবহারকারীরা ব্যবহার করে। Zabbix API এবং ডাটাবেসের মাধ্যমে উভয়ের মাধ্যমে সরাসরি লগ ইন করতে সক্ষম। এটি ডেটা প্রাপ্তির জন্য একটি নির্দিষ্ট প্রতিযোগিতাও তৈরি করে: ফলাফল এবং পরীক্ষার দ্রুত ডেলিভারি মেনে চলার জন্য ডাটাবেসের একটি সূক্ষ্ম, আরও ভাল টিউনিং প্রয়োজন।

ইতিহাস সাফ করা হচ্ছে। Zabbix-এর হাউসকিপার আছে

Zabbix-এ ব্যবহৃত তৃতীয় কলটি হল হাউসকিপার ব্যবহার করে ইতিহাস সাফ করা। হাউসকিপার সমস্ত সেটিংস অনুসরণ করে, অর্থাৎ, আমাদের ডেটা উপাদানগুলি কতক্ষণ সংরক্ষণ করতে হবে (দিনে), প্রবণতা কতক্ষণ সংরক্ষণ করতে হবে এবং পরিবর্তনের গতিশীলতা নির্দেশ করে।

আমি TrendCache সম্পর্কে কথা বলিনি, যা আমরা ফ্লাইতে গণনা করি: ডেটা আসে, আমরা এটি এক ঘন্টার জন্য একত্রিত করি (বেশিরভাগই এইগুলি শেষ ঘন্টার সংখ্যা), পরিমাণ গড়/সর্বনিম্ন এবং আমরা এটি প্রতি ঘন্টায় একবার রেকর্ড করি পরিবর্তনের গতিশীলতার সারণী ("ট্রেন্ডস")। "হাউসকিপার" নিয়মিত নির্বাচন ব্যবহার করে ডাটাবেস থেকে ডেটা শুরু করে এবং মুছে দেয়, যা সবসময় কার্যকর হয় না।

কিভাবে বুঝতে হবে যে এটি অকার্যকর? আপনি অভ্যন্তরীণ প্রক্রিয়াগুলির কর্মক্ষমতা গ্রাফে নিম্নলিখিত ছবিটি দেখতে পারেন:

আপনার ইতিহাস সিঙ্কার ক্রমাগত ব্যস্ত (লাল গ্রাফ)। এবং উপরে যায় যে "লাল" গ্রাফ. এটি একটি "হাউসকিপার" যেটি শুরু হয় এবং ডাটাবেসটি নির্দিষ্ট করা সমস্ত সারি মুছে ফেলার জন্য অপেক্ষা করে৷

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

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

আপনি পরবর্তী কি করতে পারেন? আপনি এটি বন্ধ করেছেন, আপনার গ্রাফ সমতল হয়েছে... এই ক্ষেত্রে আর কী সমস্যা হতে পারে? কি সাহায্য করতে পারেন?

বিভাজন (বিভাগ করা)

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

আপনার সেটআপের উপর নির্ভর করে (আপনি একদিনে কত ডেটা তৈরি করেন), তারা সাধারণত ন্যূনতম সেট করে - এটি 1 দিন / ব্যাচ এবং "ট্রেন্ডস" এর জন্য, পরিবর্তনের গতিশীলতা - 1 মাস / নতুন ব্যাচ। আপনার যদি খুব বড় সেটআপ থাকে তবে এটি পরিবর্তন হতে পারে।

সেটআপের আকার সম্পর্কে এখনই বলা যাক: প্রতি সেকেন্ডে 5 হাজার নতুন মান পর্যন্ত (তথাকথিত এনভিপিএস) - এটি একটি ছোট "সেটআপ" হিসাবে বিবেচিত হবে। গড় - প্রতি সেকেন্ডে 5 থেকে 25 হাজার মান। উপরে যা আছে তা ইতিমধ্যেই বড় এবং খুব বড় ইনস্টলেশন যার জন্য ডাটাবেসের খুব সতর্ক কনফিগারেশন প্রয়োজন।

খুব বড় ইনস্টলেশনে, 1 দিন সর্বোত্তম নাও হতে পারে। আমি ব্যক্তিগতভাবে MySQL-এ প্রতিদিন 40 গিগাবাইটের পার্টিশন দেখেছি (এবং আরও হতে পারে)। এটি একটি খুব বড় পরিমাণ ডেটা, যা কিছু সমস্যা হতে পারে। এটা কমানো প্রয়োজন।

কেন আপনি বিভাজন প্রয়োজন?

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

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

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

NoSQL এর জন্য ইলাস্টিক সার্চ

সম্প্রতি, 3.4-এ, আমরা একটি NoSQL সমাধান প্রয়োগ করেছি। ইলাস্টিকসার্চে লেখার ক্ষমতা যোগ করা হয়েছে। আপনি নির্দিষ্ট ধরনের লিখতে পারেন: আপনি চয়ন করুন - হয় সংখ্যা বা কিছু চিহ্ন লিখুন; আমাদের স্ট্রিং টেক্সট আছে, আপনি ইলাস্টিকসার্চে লগ লিখতে পারেন... তদনুসারে, ওয়েব ইন্টারফেসটি ইলাস্টিকসার্চেও অ্যাক্সেস করবে। এটি কিছু ক্ষেত্রে দুর্দান্ত কাজ করে তবে এই মুহূর্তে এটি ব্যবহার করা যেতে পারে।

টাইমস্কেলডিবি। হাইপারটেবল

4.4.2-এর জন্য আমরা TimescaleDB-এর মতো একটা জিনিসের দিকে মনোযোগ দিয়েছি। এটা কি? এটি PostgreSQL এর জন্য একটি এক্সটেনশন, অর্থাৎ এটির একটি নেটিভ PostgreSQL ইন্টারফেস রয়েছে। এছাড়াও, এই এক্সটেনশনটি আপনাকে টাইমসিরিজ ডেটার সাথে আরও দক্ষতার সাথে কাজ করতে এবং স্বয়ংক্রিয় পার্টিশন করার অনুমতি দেয়। এটা কিসের মত দেখতে:

এটি হাইপারটেবল - টাইমস্কেলে এমন একটি ধারণা রয়েছে। এটি একটি হাইপারটেবিল যা আপনি তৈরি করেন এবং এতে অংশগুলি রয়েছে। খণ্ডগুলি হল পার্টিশন, এগুলি চাইল্ড টেবিল, যদি আমি ভুল না করি। এটা সত্যিই কার্যকর.

TimescaleDB এবং PostgreSQL

TimescaleDB নির্মাতারা যেমন আশ্বস্ত করে, তারা বিশেষভাবে সন্নিবেশে প্রশ্ন প্রক্রিয়াকরণের জন্য আরও সঠিক অ্যালগরিদম ব্যবহার করে, যা তাদের ডেটাসেট সন্নিবেশের ক্রমবর্ধমান আকারের সাথে প্রায় ধ্রুবক পারফরম্যান্স রাখতে দেয়। অর্থাৎ, Postgres-এর 200 মিলিয়ন সারিগুলির পরে, স্বাভাবিকটি খুব বেশি ঝুলতে শুরু করে এবং কার্যক্ষমতা আক্ষরিকভাবে শূন্যে হারায়, যখন টাইমস্কেল আপনাকে যে কোনও পরিমাণ ডেটা সহ যতটা সম্ভব দক্ষতার সাথে সন্নিবেশ সন্নিবেশ করার অনুমতি দেয়।

TimescaleDB কিভাবে ইনস্টল করবেন? ইহা সহজ!

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

Zabbix-এ আমরা কেবল এক্সটেনশন সক্রিয় করি। আমি মনে করি যারা পোস্টগ্রেসে এক্সটেনশন ব্যবহার করেছেন... আপনি কেবল এক্সটেনশন সক্রিয় করুন, আপনি যে Zabbix ডাটাবেসটি ব্যবহার করছেন তার জন্য এটি তৈরি করুন।

এবং শেষ ধাপ...

টাইমস্কেলডিবি। ইতিহাস টেবিলের স্থানান্তর

আপনাকে একটি হাইপারটেবিল তৈরি করতে হবে। এর জন্য একটি বিশেষ ফাংশন রয়েছে - হাইপারটেবল তৈরি করুন। এটিতে, প্রথম প্যারামিটারটি এই ডাটাবেসে প্রয়োজনীয় টেবিলটি (যার জন্য আপনাকে একটি হাইপারটেবল তৈরি করতে হবে)।

যে ক্ষেত্রটি তৈরি করতে হবে, এবং chunk_time_interval (এটি অংশগুলির ব্যবধান (যে পার্টিশনগুলি ব্যবহার করা প্রয়োজন)। 86 হল একদিন।

মাইগ্রেট_ডেটা প্যারামিটার: যদি আপনি সত্যে সন্নিবেশ করেন, তাহলে এটি সমস্ত বর্তমান ডেটা পূর্ব-তৈরি করা অংশগুলিতে স্থানান্তরিত করবে।

আমি নিজে মাইগ্রেট_ডেটা ব্যবহার করেছি - আপনার ডাটাবেস কত বড় তার উপর নির্ভর করে এটি যথেষ্ট সময় নেয়। আমার কাছে এক টেরাবাইটের বেশি ছিল - এটি তৈরি করতে এক ঘণ্টার বেশি সময় লেগেছে। কিছু ক্ষেত্রে, পরীক্ষার সময়, আমি পাঠ্য (history_text) এবং স্ট্রিং (history_str) এর জন্য ঐতিহাসিক ডেটা মুছে ফেলেছি যাতে সেগুলি স্থানান্তর না হয় - সেগুলি আমার কাছে সত্যিই আকর্ষণীয় ছিল না।

এবং আমরা আমাদের db_extention-এ শেষ আপডেট করি: আমরা timecaledb ইনস্টল করি যাতে ডাটাবেস এবং বিশেষ করে, আমাদের Zabbix বুঝতে পারে যে সেখানে db_extention আছে। তিনি এটি সক্রিয় করেন এবং টাইমস্কেলডিবি-র জন্য প্রয়োজনীয় সেই "বৈশিষ্ট্যগুলি" ব্যবহার করে ডাটাবেসের সঠিক সিনট্যাক্স এবং প্রশ্নগুলি ব্যবহার করেন।

সার্ভার কনফিগারেশন

আমি দুটি সার্ভার ব্যবহার করেছি। প্রথম সার্ভারটি একটি মোটামুটি ছোট ভার্চুয়াল মেশিন, 20টি প্রসেসর, 16 গিগাবাইট RAM। আমি এটিতে পোস্টগ্রেস 10.8 কনফিগার করেছি:

অপারেটিং সিস্টেম ছিল ডেবিয়ান, ফাইল সিস্টেম ছিল xfs। আমি এই নির্দিষ্ট ডাটাবেসটি ব্যবহার করার জন্য ন্যূনতম সেটিংস তৈরি করেছি, Zabbix নিজে যা ব্যবহার করবে তা বিয়োগ করে। একই মেশিনে একটি Zabbix সার্ভার, PostgreSQL এবং লোড এজেন্ট ছিল।

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

আমি শুধুমাত্র 50টি এজেন্ট ব্যবহার করে (আরো যোগ করে) নয়, বরং ডাইনামিক ডেটা উপাদান ব্যবহার করে এবং আপডেটের ব্যবধানকে 4 সেকেন্ডে কমিয়ে আপডেটের ব্যবধান এবং লোড নিজেই নিয়ন্ত্রণ করেছি।

কর্মক্ষমতা পরীক্ষা. PostgreSQL: 36 হাজার NVPs

প্রথম লঞ্চ, আমার প্রথম সেটআপটি ছিল এই হার্ডওয়্যারের বিশুদ্ধ PostreSQL 10 (প্রতি সেকেন্ডে 35 হাজার মান)। সাধারণভাবে, আপনি স্ক্রিনে দেখতে পাচ্ছেন, ডেটা সন্নিবেশ করতে এক সেকেন্ডের ভগ্নাংশ সময় লাগে - সবকিছু ভাল এবং দ্রুত, এসএসডি ড্রাইভ (200 গিগাবাইট)। একমাত্র জিনিস হল 20 জিবি বেশ দ্রুত পূরণ হয়।

ভবিষ্যতে এরকম অনেক গ্রাফ থাকবে। এটি একটি স্ট্যান্ডার্ড Zabbix সার্ভার কর্মক্ষমতা ড্যাশবোর্ড।

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

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

কর্মক্ষমতা পরীক্ষা. PostgreSQL: 50 হাজার NVPs

এর পরে, আমি একই হার্ডওয়্যারে প্রতি সেকেন্ডে লোড বাড়িয়ে 50 হাজার মান করেছি। হাউসকিপার দ্বারা লোড করার সময়, গণনা সহ 10-2 সেকেন্ডে 3 হাজার মান রেকর্ড করা হয়েছিল। কি, আসলে, নিম্নলিখিত স্ক্রিনশটে দেখানো হয়েছে:

"গৃহকর্মী" ইতিমধ্যেই কাজে হস্তক্ষেপ করতে শুরু করেছে, কিন্তু সাধারণভাবে, ইতিহাস-সিঙ্কার ট্র্যাপারদের উপর লোড এখনও 60% (তৃতীয় গ্রাফ, উপরে ডানদিকে)। হিস্ট্রি ক্যাশে ইতিমধ্যেই সক্রিয়ভাবে পূরণ করা শুরু করে যখন হাউসকিপার চলছে (নীচে বাম)। এটি প্রায় অর্ধ গিগাবাইট ছিল, 20% পূর্ণ।

কর্মক্ষমতা পরীক্ষা. PostgreSQL: 80 হাজার NVPs

তারপর আমি প্রতি সেকেন্ডে 80 হাজার মান বাড়িয়েছি:

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

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

আমি অন্য একটি সার্ভার নিয়েছি যেখানে ইতিমধ্যে 48টি প্রসেসর এবং 128 গিগাবাইট RAM রয়েছে:

আমি এটিকে "টিউন"ও করেছি - ইতিহাস সিঙ্কার (60 টুকরা) ইনস্টল করেছি এবং গ্রহণযোগ্য কার্যক্ষমতা অর্জন করেছি। প্রকৃতপক্ষে, আমরা "শেল্ফে" নই, তবে এটি সম্ভবত উত্পাদনশীলতার সীমা, যেখানে ইতিমধ্যে এটি সম্পর্কে কিছু করা প্রয়োজন।

কর্মক্ষমতা পরীক্ষা. টাইমস্কেলডিবি: 80 হাজার এনভিপি

আমার প্রধান কাজ ছিল TimescaleDB ব্যবহার করা। প্রতিটি গ্রাফ একটি ডিপ দেখায়:

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

PostgreSQL কর্মক্ষমতা পরীক্ষা: 120 হাজার NVPs

এর পরে, আমি ডেটা উপাদানগুলির সংখ্যার মান অর্ধ মিলিয়নে বাড়িয়েছি এবং প্রতি সেকেন্ডে 125 হাজারের গণনাকৃত মান পেয়েছি:

এবং আমি এই গ্রাফ পেয়েছি:

নীতিগতভাবে, এটি একটি কার্যকরী সেটআপ, এটি বেশ দীর্ঘ সময়ের জন্য কাজ করতে পারে। কিন্তু যেহেতু আমার কাছে মাত্র 1,5 টেরাবাইট ডিস্ক ছিল, তাই আমি এটি কয়েক দিনের মধ্যে ব্যবহার করেছি। সবচেয়ে গুরুত্বপূর্ণ বিষয় হল যে একই সময়ে TimescaleDB-তে নতুন পার্টিশন তৈরি করা হয়েছিল, এবং এটি পারফরম্যান্সের জন্য সম্পূর্ণ অলক্ষিত ছিল, যা MySQL সম্পর্কে বলা যাবে না।

সাধারণত, পার্টিশনগুলি রাতে তৈরি করা হয়, কারণ এটি সাধারণত সন্নিবেশকে ব্লক করে এবং টেবিলের সাথে কাজ করে এবং পরিষেবার অবনতি ঘটাতে পারে। এ ক্ষেত্রে এমনটা হয় না! প্রধান কাজ ছিল TimescaleDB এর ক্ষমতা পরীক্ষা করা। ফলাফলটি নিম্নলিখিত চিত্রটি ছিল: প্রতি সেকেন্ডে 120 হাজার মান।

সম্প্রদায়ে উদাহরণও রয়েছে:

এছাড়াও ব্যক্তি TimescaleDB চালু করেছে এবং io.weight ব্যবহার করার লোড প্রসেসরে নেমে গেছে; এবং TimescaleDB অন্তর্ভুক্তির কারণে অভ্যন্তরীণ প্রক্রিয়া উপাদানগুলির ব্যবহারও হ্রাস পেয়েছে। তদুপরি, এগুলি সাধারণ প্যানকেক ডিস্ক, অর্থাৎ, সাধারণ ডিস্কগুলিতে একটি সাধারণ ভার্চুয়াল মেশিন (এসএসডি নয়)!

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

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

শ্রোতা প্রশ্ন

শ্রোতাদের কাছ থেকে প্রশ্ন (এর পরে - A): - যদি TimescaleDB কনফিগার করা এত সহজ হয়, এবং এটি এমন একটি পারফরম্যান্স বুস্ট দেয়, তাহলে সম্ভবত পোস্টগ্রেসের সাথে Zabbix কনফিগার করার জন্য এটি একটি সেরা অনুশীলন হিসাবে ব্যবহার করা উচিত? এবং এই সমাধানটির কোন অসুবিধা এবং অসুবিধা আছে, বা সর্বোপরি, আমি যদি নিজের জন্য Zabbix তৈরি করার সিদ্ধান্ত নিয়ে থাকি, আমি সহজেই Postgres নিতে পারি, সেখানে টাইমস্কেল ইনস্টল করতে পারি, এটি ব্যবহার করতে পারি এবং কোনো সমস্যা নিয়ে ভাবতে পারি না?

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

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

উত্তর: - সম্প্রদায়ের শেষ গ্রাফগুলিতে, "গৃহকর্মী" সহ একটি গ্রাফ ছিল:

তিনি কাজ চালিয়ে যান। টাইমস্কেলডিবি দিয়ে হাউসকিপার কি করে?

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

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

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

উত্তর: - আমরা ইতিমধ্যেই নন-এসকিউএল বিষয়ে স্পর্শ করেছি। যতদূর আমি বুঝতে পারি, Zabbix এর আসলে ডেটা পরিবর্তন করার দরকার নেই, এবং এই সব একটি লগের মত কিছু। বিশেষায়িত ডেটাবেসগুলি ব্যবহার করা কি সম্ভব যেগুলি তাদের ডেটা পরিবর্তন করতে পারে না, কিন্তু একই সময়ে সংরক্ষণ, জমা এবং অনেক দ্রুত বিতরণ করতে পারে - ক্লিকহাউস, উদাহরণস্বরূপ, কাফকার মতো কিছু?... কাফকাও একটি লগ! এটা কোনোভাবে তাদের একত্রিত করা সম্ভব?

এজি: - আনলোড করা যাবে। সংস্করণ 3.4 থেকে আমাদের একটি নির্দিষ্ট "বৈশিষ্ট্য" রয়েছে: আপনি ফাইলগুলিতে সমস্ত ঐতিহাসিক ফাইল, ঘটনা, সবকিছু লিখতে পারেন; এবং তারপর কিছু হ্যান্ডলার ব্যবহার করে অন্য কোনো ডাটাবেসে পাঠান। আসলে, অনেকে আবার কাজ করে এবং ডাটাবেসে সরাসরি লেখে। ফ্লাইতে, হিস্ট্রি সিঙ্কাররা এই সব ফাইলগুলিতে লেখে, এই ফাইলগুলি ঘোরান এবং আরও অনেক কিছু, এবং আপনি এটি ক্লিকহাউসে স্থানান্তর করতে পারেন। আমি পরিকল্পনা সম্পর্কে বলতে পারি না, তবে সম্ভবত NoSQL সমাধানগুলির জন্য আরও সমর্থন (যেমন ক্লিকহাউস) অব্যাহত থাকবে।

উত্তর: - সাধারণভাবে, দেখা যাচ্ছে যে আপনি পোস্টগ্রেস থেকে সম্পূর্ণরূপে পরিত্রাণ পেতে পারেন?

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

উত্তর: - আপনি কি অনুমান করতে পারেন যে আপনি ক্লিকহাউসে স্যুইচ করলে সবকিছু কত দ্রুত কাজ করবে, উদাহরণস্বরূপ?

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

উত্তর: - তাই আমরা একটি সমান লড়াই সম্পর্কে কথা বলছি, এবং এই দ্রুত ডাটাবেসের মহান সুবিধা সম্পর্কে না?

এজি: - আমি মনে করি আমরা যখন সংহত করব, তখন আরও সঠিক পরীক্ষা হবে।

উত্তর: - ভাল পুরনো আরআরডি কোথায় গেল? কি আপনাকে SQL ডাটাবেসে স্যুইচ করেছে? প্রাথমিকভাবে, সমস্ত মেট্রিক্স RRD তে সংগ্রহ করা হয়েছিল।

এজি: - Zabbix এর RRD ছিল, সম্ভবত একটি খুব প্রাচীন সংস্করণে। সর্বদা SQL ডাটাবেস আছে - একটি ক্লাসিক পদ্ধতি। ক্লাসিক পদ্ধতি হল MySQL, PostgreSQL (এগুলি অনেক দীর্ঘ সময়ের জন্য বিদ্যমান)। আমরা প্রায় কখনই SQL এবং RRD ডাটাবেসের জন্য একটি সাধারণ ইন্টারফেস ব্যবহার করিনি।

কিছু বিজ্ঞাপন 🙂

আমাদের সাথে থাকার জন্য আপনাকে ধন্যবাদ. আপনি আমাদের নিবন্ধ পছন্দ করেন? আরো আকর্ষণীয় বিষয়বস্তু দেখতে চান? অর্ডার দিয়ে বা বন্ধুদের সুপারিশ করে আমাদের সমর্থন করুন, $4.99 থেকে বিকাশকারীদের জন্য ক্লাউড ভিপিএস, এন্ট্রি-লেভেল সার্ভারগুলির একটি অনন্য অ্যানালগ, যা আমাদের দ্বারা আপনার জন্য উদ্ভাবিত হয়েছে: VPS (KVM) E5-2697 v3 (6 কোর) 10GB DDR4 480GB SSD 1Gbps থেকে $19 বা কিভাবে একটি সার্ভার শেয়ার করবেন সম্পর্কে সম্পূর্ণ সত্য? (RAID1 এবং RAID10 এর সাথে উপলব্ধ, 24 কোর পর্যন্ত এবং 40GB DDR4 পর্যন্ত)।

আমস্টারডামের ইকুইনিক্স টায়ার IV ডেটা সেন্টারে ডেল R730xd 2x সস্তা? শুধু এখানে 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 টিভি $199 থেকে নেদারল্যান্ডে! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 থেকে! সম্পর্কে পড়ুন কিভাবে ইনফ্রাস্ট্রাকচার কর্পোরেশন তৈরি করা যায়। এক পয়সার জন্য 730 ইউরো মূল্যের Dell R5xd E2650-4 v9000 সার্ভার ব্যবহার করে ক্লাস?

উত্স: www.habr.com