পটভূমি
আমার প্রায় 2000 সেন্সরগুলির একটি নেটওয়ার্ক রয়েছে যার প্রত্যেকটিরই প্রায় 100 ডেটা পয়েন্ট রয়েছে যা আমরা 10 মিনিটের ব্যবধানে সংগ্রহ করি। এই ডেটা পয়েন্টগুলি সাধারণত ইন-মান হয় তবে কিছু স্ট্রিং এবং ফ্লোট হয়। এই ডেটা 90 দিনের জন্য সংরক্ষণ করা উচিত, যদি সম্ভব হয় এবং এখনও দক্ষ হয়।
ডাটাবেস ডিজাইন
এই প্রকল্পটির মূল কাজটি যখন অর্পণ করা হয়েছিল, তখন আমি একটি সি # অ্যাপ লিখেছিলাম যা প্রতিটি সেন্সরের জন্য কমা দ্বারা পৃথক করা ফাইল লিখেছিল। সেই সময় তেমন কিছু ছিল না, যখন কেউ প্রবণতাগুলি দেখতে চেয়েছিল তখন আমরা এক্সেলের সিএসভি খুলতাম এবং এটি প্রয়োজনীয়ভাবে গ্রাফ করতাম।
জিনিসগুলি বৃদ্ধি পেয়েছে এবং আমরা একটি মাইএসকিউএল ডাটাবেসে স্যুইচ করেছি। আমি প্রতিটি সেন্সরের জন্য একটি টেবিল তৈরি করেছি (হ্যাঁ আমি জানি, প্রচুর টেবিল!); এটি ভালভাবে কাজ করছে, তবে এর কিছু সীমাবদ্ধতা রয়েছে। অনেকগুলি সারণী সহ, কোনও কোয়েরি লেখা স্পষ্টত অসম্ভব যা কোনও নির্দিষ্ট মান সন্ধানের সময় সমস্ত সেন্সরগুলির মধ্যে ডেটা খুঁজে বের করে।
পরবর্তী সংস্করণের জন্য, আমি মাইক্রোসফ্ট এসকিউএল সার্ভার এক্সপ্রেসে স্যুইচ করেছি এবং সমস্ত সেন্সর ডেটা একটি বড় টেবিলের মধ্যে রেখেছি। এটিও কাজ করে এবং আগ্রহী এমন সমস্ত সেন্সরগুলির মধ্যে মান খুঁজে পেতে আমাদের জিজ্ঞাসা করতে দিন। যাইহোক, আমি এক্সপ্রেস সংস্করণটির জন্য 10 গিগাবাইটের সীমাতে চলে এসেছি এবং এসকিউএল সার্ভার স্ট্যান্ডার্ডে বিনিয়োগ না করে মাইএসকিউএলে ফিরে যাওয়ার সিদ্ধান্ত নিয়েছি।
প্রশ্নটি
আমি মাইএসকিউএল পারফরম্যান্স এবং স্কেলাবিলিটিতে খুশি, তবে সমস্ত-ডেটা-ইন-ওয়ান-টেবিল পদ্ধতির সাথে লেগে থাকলে অনিশ্চিত। একক টেবিলের মধ্যে 10 গিগাবাইট অন্যরকম ডিজাইনের জন্য জিজ্ঞাসা করছে। আমার উল্লেখ করা উচিত যে গ্রাফিংয়ের জন্য ডেটা অনুসন্ধানের প্রয়োজনীয়তা এখনও রয়েছে এবং আমি উদ্বিগ্ন যে কোনও প্রশ্নের জন্য পারফরম্যান্সের সমস্যা থাকবে যা গ্রাফগুলি উদাহরণস্বরূপ, পুরো 90 দিনের মধ্যে এক সেন্সরের তাপমাত্রার ডেটা। (অন্য কথায়, গ্রাফটি এমন কিছু হওয়া উচিত যা দ্রুত তৈরি হওয়া উচিত, এসকিউএলকে কেবল আগ্রহের সংবেদককে আলাদা করার জন্য ডেটা পাইলগুলির মাধ্যমে বাছাই করার জন্য অপেক্ষা না করে))
পারফরম্যান্স বাড়ানোর জন্য কি আমার এই টেবিলটি আলাদা করা উচিত? নাকি এত বড় টেবিল থাকা অস্বাভাবিক নয়?
সেন্সর আইডি এবং টাইমস্ট্যাম্প কলামগুলিতে আমার সূচি রয়েছে, যা কোনও প্রশ্নের জন্য নির্ধারিত সীমানা। (উদাহরণস্বরূপ এক থেকে সময়ে সময়ে বি সেন্সর এক্স এর ডেটা পান)।
আমি শারডিং এবং বিভাজন সম্পর্কে কিছুটা পড়েছি, তবে মনে হয় না যে এগুলি ক্ষেত্রে উপযুক্ত।
সম্পাদনা:
এখনও অবধি মন্তব্য এবং উত্তরের ভিত্তিতে কিছু অতিরিক্ত তথ্য সহায়ক হতে পারে:
অনির্দিষ্ট স্টোরেজ নয়: বর্তমানে আমি 90 দিনের অতীতে ডেটা সঞ্চয় করি না। প্রতিদিন, আমি একটি কোয়েরি চালিত করি যা 90 দিনের চেয়ে পুরানো ডেটা সরিয়ে দেয়। যদি এটি ভবিষ্যতে গুরুত্বপূর্ণ হয়ে ওঠে তবে আমি আরও সঞ্চয় করব, তবে আপাতত এটি যথেষ্ট। এটি চেক এবং পারফরম্যান্সে উচ্চ (ইর) আকার রাখতে সহায়তা করে।
ইঞ্জিনের ধরণ: মাইএসএএমকিউলে বাস্তব মাইএসকিউএল প্রয়োগ করা হয়েছে। নতুন বাস্তবায়নের জন্য এবার সারণী তৈরি করার সময় (অনেকের পরিবর্তে একটি ডেটা টেবিল) তারা ইনোডিবিতে ডিফল্ট হয়েছে। আমি বিশ্বাস করি না যে আমার একটি বা অন্যটির প্রয়োজন আছে।
সাধারণকরণ: তথ্য সংগ্রহের টেবিলের পাশাপাশি অবশ্যই অন্যান্য সারণী রয়েছে। এই সমর্থন সারণীগুলি সেন্সরগুলির জন্য নেটওয়ার্ক তথ্য, ব্যবহারকারীদের জন্য লগইন তথ্য ইত্যাদির মতো জিনিসগুলি সঞ্চয় করে normal স্বাভাবিক করার মতো কিছুই নেই (যতদূর আমি জানি)। ডেটা টেবিলটিতে এতগুলি কলাম থাকার কারণটি হ'ল প্রতিটি সেন্সর থেকে অনেকগুলি ভেরিয়েবল রয়েছে। (একাধিক তাপমাত্রা, হালকা মাত্রা, বায়ুচাপ, ইত্যাদি) আমার কাছে স্বাভাবিককরণের অর্থ হ'ল কোনও অতিরিক্ত কাজ বা পুনরাবৃত্তি গোষ্ঠী নেই। (কমপক্ষে 1NF এর জন্য)) প্রদত্ত সংবেদকের জন্য, একটি নির্দিষ্ট সময়ে সমস্ত মান সংরক্ষণ করার জন্য এক সারি ডেটা প্রয়োজন এবং সেখানে কোনও 1 নেই: এন সম্পর্কের সাথে জড়িত নেই (যা আমি দেখি)।
আমি টেবিলটি কার্যত পৃথকভাবে ভেঙে ফেলতে পারি, উদাহরণস্বরূপ: এক টেবিলের সমস্ত তাপমাত্রা-সম্পর্কিত মান এবং অন্যটিতে বায়ুচাপ-সম্পর্কিত মানগুলি তৈরি করে। যদিও এটি কেবলমাত্র কোনও তাপমাত্রা-ক্যোরি তৈরির দক্ষতার উন্নতি করতে পারে, তবুও আমাকে একবারে সমস্ত ডেটা .োকাতে হবে। তারপরেও, দক্ষতা অর্জনগুলি SELECT অপারেশনগুলির জন্য উপযুক্ত হতে পারে। স্পষ্টতই আমি ব্যবহারকারীদের প্রায়শই ডেটার জন্য অনুরোধ করে তার ভিত্তিতে টেবিলটি উল্লম্বভাবে ভেঙে ফেলা ভাল। সম্ভবত এটিই আমার করা উচিত। আমি মনে করি আমার প্রশ্ন জিজ্ঞাসা করার জন্য আমি নিশ্চিতকরণের সন্ধান করছি যে এটি করা সার্থক হবে।
সম্পাদনা 2:
ডেটা ব্যবহার: শেষ পর্যন্ত অনেকগুলি ডেটা কখনই প্রয়োজন হয় না বা প্রয়োজন হয় না, কারণ আমরা সাধারণত সমস্যাযুক্ত আইটেমগুলিতে ফোকাস করি। তবে সমস্যাগুলি অনুসন্ধানের চেষ্টা করার জন্য আমরা ডেটা অনুসন্ধান করতে এবং বিভিন্ন আইটেমগুলিতে জুম বাড়ানোর জন্য বিভিন্ন সরঞ্জাম ব্যবহার করি।
উদাহরণস্বরূপ, আমরা একটি স্মৃতি ব্যবহারের মান (একটি গ্রাহক-নির্দিষ্ট মালিকানাধীন সফ্টওয়্যার প্রোগ্রাম) এবং একটি রিবুট / ক্র্যাশের মধ্যে পারস্পরিক সম্পর্ক লক্ষ্য করেছি। আমি সংগ্রহ করা ডেটা পয়েন্টগুলির একটি এই মেমরির ব্যবহারের সাথে সম্পর্কিত এবং আমি নির্দিষ্ট historicalতিহাসিক ব্যবহার অতিক্রম করার পরে ডিভাইসগুলি অস্থির হয়ে যায় তা দেখানোর জন্য historicalতিহাসিক ডেটা দেখতে সক্ষম হয়েছি। আজ, এই সফ্টওয়্যারটি চলমান ডিভাইসের উপসেটের জন্য, আমি এই মানটি পরীক্ষা করে দেখি এবং এটি খুব বেশি হলে একটি রিবুট কমান্ড জারি করি। এটি আবিষ্কার না হওয়া অবধি আমার মনে হয় নি যে এই ডেটা সংগ্রহ করা কোনও মূল্যবান।
এই কারণে, আমি বজায় রেখেছি যে 100 টি তথ্য পয়েন্ট সংগ্রহ এবং সংরক্ষণ করা হবে, এমনকি যদি মান প্রশ্নবিদ্ধ হয়। তবে সাধারণ প্রতিদিনের ব্যবহারে ব্যবহারকারীরা সাধারণত এই পরামিতিগুলির কয়েক ডজন পরীক্ষা করে থাকেন। যদি কোনও ব্যবহারকারী কোনও নির্দিষ্ট ভৌগলিক অঞ্চলে আগ্রহী হন, তবে তিনি সম্ভবত কয়েক ডজন সেন্সরের জন্য গ্রাফ বা ডেটা স্প্রেডশিট তৈরি করতে পারেন (সফ্টওয়্যার ব্যবহার করে)। তাপমাত্রা, বায়ুচাপ এবং হালকা মাত্রার মতো জিনিসগুলি দেখায় এমন দুটি বা তিনটি প্লট লাইন সহ 30 দিনের গ্রাফটি দেখার পক্ষে অস্বাভাবিক কিছু নয়। এটি করার সাথে এর অনুরূপ একটি ক্যোয়ারী চালানো হবে:
SELECT sensor_id, location, data_timestamp, temp1, air1, light1
FROM data
WHERE data_timestamp >= '2012-02-01'
AND sensor_id IN (1, 2, 3);
(মূল মাইএসকিউএল সংস্করণে, যেখানে প্রতিটি সেন্সরের নিজস্ব টেবিল ছিল, সেখানে পৃথক পৃথক তিনটি ক্যোয়ারী জারি করা হবে, তবে গ্রাফ তৈরির জন্য সফ্টওয়্যারটিতে ফলাফলগুলি মিলিত হয়েছে))
কারণ dataসারণীতে অনেকগুলি সারি রয়েছে (10 মিলিয়ন ডলার), সূচকগুলি থাকা সত্ত্বেও idএবং data_timestampপারফরম্যান্সটি একাধিক সারণির দৃশ্যের চেয়ে উল্লেখযোগ্যভাবে খারাপ (4500 সারি 9 সেকেন্ডে ফিরে এসেছে যার উদাহরণের সাথে এক সেকেন্ডেরও কম নয়)। কোন সেন্সরগুলি নির্দিষ্ট মানদণ্ডগুলি পূরণ করে তা সন্ধান করার ক্ষমতাটি একাধিক-টেবিল স্কিমাতে কার্যত শূন্য এবং এইভাবে একটি একক টেবিলে যাওয়ার কারণ।
এই ধরণের কোয়েরি একাধিক ব্যবহারকারী তাত্ক্ষণিকভাবে সম্পন্ন করতে পারেন কারণ তারা বিভিন্ন গ্রুপের ডেটা নির্বাচন করে এবং প্রতিটি ফলাফল থেকে গ্রাফের তুলনা করে। গ্রাফ বা স্প্রেডশিটে প্রায় 10 সেকেন্ড অপেক্ষা করা বেশ হতাশার হতে পারে।
90 দিনের পরে ডেটা ফেলে দেওয়া হয়। এটি সংরক্ষণাগারভুক্ত করা যেতে পারে তবে এটি বর্তমানে প্রয়োজন হয় না।
আশা করি এই তথ্য সংগ্রহ এবং সঞ্চয় করার পরে ডেটা কীভাবে ব্যবহৃত হয় তা আরও সঠিকভাবে দেখাতে সহায়তা করে।