🥇 InfluxDB এর সাথে কাজ করার সময় রাগ, দর কষাকষি এবং হতাশা প্রোহোস্টার

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

দায়িত্ব অস্বীকার: তালিকাভুক্ত সমস্যাগুলি InfluxDB সংস্করণ 1.7.4 এ প্রযোজ্য।

কেন সময় সিরিজ?

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

লেনদেন বিশ্লেষণ করার সময়, একটি ধারণা এসেছিল: InfluxDB টাইম সিরিজ ডাটাবেসকে প্রধান স্টোরেজ হিসাবে ব্যবহার করার জন্য। লেনদেনগুলি সময়ের মধ্যে পয়েন্ট এবং তারা টাইম সিরিজ মডেলের সাথে ভালভাবে ফিট করে৷

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

এটা একটু বিভ্রান্তিকর ছিল যে এই ধরনের ডাটাবেস সাধারণত মেট্রিক্স সংগ্রহের উদ্দেশ্যে ব্যবহার করা হয়। সার্ভারের নিরীক্ষণ, আইওটি ডিভাইস, যা থেকে লক্ষ লক্ষ পয়েন্ট ফর্ম “ফ্লো”: [ - ]। কিন্তু যদি ডাটাবেস একটি বড় ডেটা প্রবাহের সাথে ভাল কাজ করে, তাহলে কেন একটি ছোট ভলিউম সমস্যা সৃষ্টি করবে? এটি মাথায় রেখে, আমরা InfluxDB কে কাজ করতে নিয়েছি।

InfluxDB তে আর কি সুবিধাজনক

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

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

অন্য টেবিলে ডেটা একত্রিত করার জন্য একটি ক্রমাগত ক্যোয়ারী তৈরি করুন;
প্রথম টেবিলের জন্য, সেই একই সপ্তাহের চেয়ে পুরনো মেট্রিকগুলি মুছে ফেলার জন্য একটি নীতি নির্ধারণ করুন৷

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

সংরক্ষিত তথ্য সম্পর্কে

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

সমস্যার

পরিষেবার বিকাশ এবং পরবর্তী পরীক্ষার সময়, ইনফ্লাক্সডিবি-র অপারেশনে আরও বেশি জটিল সমস্যা দেখা দিয়েছে।

1. ডেটা মুছে ফেলা হচ্ছে

লেনদেনের সাথে ডেটার একটি সিরিজ রয়েছে:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

ফলাফল:

আমি ডেটা মুছে ফেলার জন্য একটি কমান্ড পাঠাচ্ছি:

DELETE FROM transactions WHERE symbol=’USDT’

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

আমি সম্পূর্ণ টেবিল মুছে ফেলার চেষ্টা করছি:

DROP MEASUREMENT transactions

আমি টেবিল মুছে ফেলার পরীক্ষা করি:

SHOW MEASUREMENTS

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

সমস্যাটি আমার কাছে একবারই ঘটেছে, যেহেতু মুছে ফেলার কেসটি একটি বিচ্ছিন্ন কেস ছিল। কিন্তু ডাটাবেসের এই আচরণটি স্পষ্টতই "সঠিক" অপারেশনের কাঠামোর সাথে খাপ খায় না। পরে আমি এটি গিথুবে খোলা পেয়েছি টিকিট প্রায় এক বছর আগে এই বিষয়ে।

ফলস্বরূপ, সম্পূর্ণ ডাটাবেস মুছে ফেলা এবং পুনরুদ্ধার করা সাহায্য করেছে।

2. ফ্লোটিং পয়েন্ট সংখ্যা

InfluxDB-তে অন্তর্নির্মিত ফাংশন ব্যবহার করার সময় গণিত গণনার সঠিকতা ত্রুটি রয়েছে। এটি অস্বাভাবিক কিছু নয়, তবে এটি অপ্রীতিকর।

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

3. ক্রমাগত প্রশ্নগুলি বিভিন্ন সময় অঞ্চলের সাথে খাপ খাইয়ে নেওয়া যায় না

পরিষেবাটিতে দৈনিক লেনদেনের পরিসংখ্যান সহ একটি টেবিল রয়েছে। প্রতিটি দিনের জন্য, আপনাকে সেই দিনের জন্য সমস্ত লেনদেন গ্রুপ করতে হবে। কিন্তু প্রতিটি ব্যবহারকারীর দিন ভিন্ন সময়ে শুরু হবে, এবং তাই লেনদেনের সেট ভিন্ন হবে। UTC দ্বারা হ্যাঁ 37 টি রূপ স্থানান্তর যার জন্য আপনাকে ডেটা একত্রিত করতে হবে।

InfluxDB-তে, সময় অনুসারে গোষ্ঠীবদ্ধ করার সময়, আপনি অতিরিক্তভাবে একটি স্থানান্তর নির্দিষ্ট করতে পারেন, উদাহরণস্বরূপ মস্কো সময়ের জন্য (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

কিন্তু ক্যোয়ারী ফলাফল ভুল হবে. কিছু কারণে, দিনের ভিত্তিতে গোষ্ঠীবদ্ধ ডেটা 1677-এ শুরু হবে (InfluxDB আনুষ্ঠানিকভাবে এই বছর থেকে একটি সময়কাল সমর্থন করে):

এই সমস্যাটি সমাধান করার জন্য, আমরা সাময়িকভাবে UTC+0 এ পরিষেবাটি স্যুইচ করেছি।

4. কর্মক্ষমতা

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

আমি তোমাকে আমার ঘটনা বলব।

পরিষেবাটি একটি API পদ্ধতি প্রদান করে যা শেষ দিনের পরিসংখ্যান প্রদান করে। গণনা সম্পাদন করার সময়, পদ্ধতিটি নিম্নলিখিত প্রশ্নগুলির সাথে ডাটাবেসকে তিনবার জিজ্ঞাসা করে:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

ব্যাখ্যা:

প্রথম অনুরোধে, আমরা বাজারের ডেটা সহ প্রতিটি মুদ্রার জন্য শেষ পয়েন্টগুলি পাই৷ আমার ক্ষেত্রে আট মুদ্রার জন্য আট পয়েন্ট।
দ্বিতীয় অনুরোধটি নতুন পয়েন্টগুলির মধ্যে একটি পায়।
তৃতীয়টি গত XNUMX ঘন্টার লেনদেনের একটি তালিকার অনুরোধ করে; সেগুলির মধ্যে কয়েকশত থাকতে পারে।

আমাকে স্পষ্ট করতে দিন যে InfluxDB স্বয়ংক্রিয়ভাবে ট্যাগ এবং সময়ের উপর ভিত্তি করে একটি সূচক তৈরি করে, যা প্রশ্নের গতি বাড়ায়। প্রথম অনুরোধে প্রতীক একটি ট্যাগ।

আমি এই API পদ্ধতিতে একটি স্ট্রেস পরীক্ষা চালিয়েছি। 25 RPS-এর জন্য, সার্ভারটি ছয়টি CPU-এর সম্পূর্ণ লোড প্রদর্শন করেছে:

একই সময়ে, নোডজেস প্রক্রিয়াটি কোনও লোড সরবরাহ করেনি।

কার্যকর করার গতি ইতিমধ্যে 7-10 RPS দ্বারা হ্রাস পেয়েছে: যদি একজন ক্লায়েন্ট 200 ms এর মধ্যে একটি প্রতিক্রিয়া পেতে পারে, তাহলে 10 ক্লায়েন্টকে এক সেকেন্ড অপেক্ষা করতে হবে। 25 RPS হল সেই সীমা যেখানে স্থিতিশীলতা ভোগ করেছে; 500টি ত্রুটি ক্লায়েন্টদের কাছে ফেরত দেওয়া হয়েছে।

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

উপসংহার

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

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

আপনি ইতিমধ্যেই প্রকল্প সংগ্রহস্থলে সংস্করণ 2.0.0-বিটা খুঁজে পেতে পারেন; আমরা কেবল আশা করতে পারি যে দ্বিতীয় সংস্করণে উল্লেখযোগ্য উন্নতি হবে। ইতিমধ্যে, আমি TimescaleDB ডকুমেন্টেশন অধ্যয়ন করতে যাব।

উত্স: www.habr.com

InfluxDB এর সাথে কাজ করার সময় রাগ, দর কষাকষি এবং হতাশা