সেন্সর অ্যারে থেকে প্রচুর পরিমাণে ডেটা সঞ্চয় করা


14

বিশাল সেন্সর অ্যারে থেকে ডেটা নমুনাগুলি সংরক্ষণ করার জন্য আমাকে একটি সমাধান (অ্যাপ্লিকেশন এবং ডিবি) বাস্তবায়নের দায়িত্ব দেওয়া হয়েছে। অ্যারেটিতে প্রায় 20,000 সেন্সর রয়েছে, তবে শীঘ্রই এটি 100,000 সেন্সর পর্যন্ত বাড়তে চলেছে। প্রতিটি সেন্সর প্রতি 10 সেকেন্ডে ডেটা নমুনা প্রেরণ করে এবং প্রতিটি নমুনা আকারে 28 বাইট।

এই পরিমাণে করতে গিয়ে বাড়ে:

  • প্রতিদিন সেন্সর প্রতি 8640 নমুনা
  • প্রতিদিন সেন্সরটিতে 242 কেবি ডেটা
  • প্রতিদিন 864 মিলিয়ন নমুনা

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

আমার মাথার বর্তমান সমাধানটি হ'ল ডেটা নমুনাগুলি সঞ্চয় করতে দুটি টেবিল সহ একটি ডিবি তৈরি করা। প্রথমটি দ্বিতীয়টিতে একটি সূচকের সাজানোর কাজ করে যা প্রতি সেন্সর ভিত্তিতে প্রতিদিন বাইনারি ক্ষেত্রের মধ্যে জমে থাকা নমুনাগুলি সঞ্চয় করে:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

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

এইভাবে আমি 864 মিলিয়ন এন্ট্রির পরিবর্তে প্রতিদিনের টেবিলে কেবল 100,000 এন্ট্রি দিয়ে শেষ করি। ল্যান বা উচ্চ গতির WAN- তে ডেটা উপলব্ধ থাকতে হবে, তাই পুরো দিন ভিত্তিতে সেন্সরের ডেটা পুনরুদ্ধার গ্রহণযোগ্য হবে।

যদিও সমস্ত ডেটা সংরক্ষণ করতে হয়, তবে এর বেশিরভাগটি সম্ভবত কখনও পড়তে হবে না। সুতরাং টেবিলে পাঠের পরিমাণ লেখার চেয়ে বিশাল পরিমাণে হবে না।

আমি জানি যে আমি কেবল ডেটা ফাইলের পাথ সংরক্ষণ করে ফাইল সিস্টেমটি ব্যবহার করে কিছু বাস্তবায়ন করতে পেরেছিলাম, তবে আমি পড়েছি যে এসকিউএল সার্ভার এনটিএফএসকে ছাড়িয়ে গেছে যখন আপনার বাইনারি ক্ষেত্রগুলি 256 কেবি ধন্যবাদ জানায়। (256kB এবং 1MB এর মধ্যে একটি ধূসর অঞ্চল বিদ্যমান, যখন এনটিএফএস বাইনারি আকারের> 1 মেগাবাইটের জন্য এসকিউএল সার্ভারকে ছাড়িয়ে যায়)।

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

  1. উপরের বিষয়ে কেউ আমাকে কিছু ব্যবহারিক পরামর্শ / মন্তব্য দিতে পারেন?

  2. আমি যে পড়তে চলেছি সেখানে কি স্পষ্ট সমস্যা আছে?

  3. নমুনা তথ্য বেশ সুন্দরভাবে সংকুচিত করে। একটি 242 কেবি ফাইল প্রায় 85 কেবিতে কমপ্রেস করে। আমি কি ডাটাবেস স্তরে এমন কিছু সংকোচনের প্রয়োগ করতে পারি যাতে নমুনা ডেটা (কলাম) স্বয়ংক্রিয়ভাবে সংকুচিত হয়?

  4. এসকিউএল সার্ভারটি কি এই প্রকল্পের জন্য স্পষ্টতই ভুল পছন্দ?

  5. দুটি টেবিলের আমার নকশাটি কি বুদ্ধিমান, বা আমি ঠিক পাশাপাশি এটি একটি একক টেবিলের সাথে সংযুক্ত করতে পারি যা এখনও দুটি টেবিলের মতো "পারফরম্যান্ট" হবে?


5
এসকিউএল সার্ভার এ জাতীয় জিনিসের জন্য সারি-স্তর এবং টেবিল-স্তরের সংক্ষেপণ সমর্থন করে।
জেএনকে

2
যেহেতু কেবলমাত্র 1 টি প্রবেশ / সেন্সর / দিন রয়েছে, আপনার কি টেবিল 1 দরকার?
গ্যালাকটিক

2
এই ডেটাবেসে একবার আসার পরে আপনি কী করবেন? আমি বাইনারি ফর্ম্যাটে সেন্সর ডেটা একত্রিত করতে সক্ষম হয়ে ভাবতে পারি না, কমপক্ষে সহজেই বা তত দ্রুত এই স্তরে নয়।
ডেটাগোড

1
100,000 সেন্সর এক্স 10 নমুনা প্রতি সেকেন্ডে এক্স 28 বাইট প্রতি স্যাম্পল x 24 ঘন্টা = প্রতিদিন 2.2TB। এটি দুটি টেবিলের মধ্যে রাখা অনেক।
ডেটাগোড

2
@ অ্যালেক্সকুজনেসভ: আমি নিজেই এসকিউএল সার্ভারের পছন্দটি সম্পর্কে ভাবছিলাম, তবে তারা মাইক্রোসফ্ট সোনার অংশীদার, সুতরাং আমার ধারণা এটির মূল কারণ।
অলিভার

উত্তর:


12

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

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

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

আশাকরি এটা সাহায্য করবে. পার্টিশন এবং বিভাজন স্কিমগুলি সম্পর্কিত আপনার কাছে যথেষ্ট পরিমাণ গবেষণা রয়েছে তবে আশা করি এখন আপনি যে দিকটি খুঁজছেন তা আপনারা জানেন।

PS: ওহ, এবং আমি আপনার বুলেটযুক্ত প্রশ্নের তালিকা ভুলে গেছি ... উত্তর 1, 2, এবং 5 উপরে দেখুন See উত্তর 3: এসকিউএল সার্ভারে, আপনি পার্টিশন ভিত্তিতে একটি পার্টিশনের উপর সংকোচন করতে পারেন, সুতরাং আপনার পূর্ববর্তী পার্টিশনগুলি আক্রমণাত্মকভাবে সংক্ষেপণ করুন PAGE সংক্ষেপণ ব্যবহার করে। তবে আমি বিশ্বাস করি যে আপনার অ-সারি বড় ডেটা প্রকারগুলি সংমিত করা হবে না যদি আপনি এটি করেন তবে - আবার, আপনি সেন্সরের মানগুলি স্বাভাবিক করেই এই সমস্যাটি দূর করতে চাইতে পারেন। উত্তর 4: অবশ্যই না, তবে আপনি যদি যা করতে চান তা হ'ল দিনের বেলা স্থিতিশীল ডেটা সংরক্ষণ করা এবং এটির অন্য কোনও উপায়ে কখনই অনুসন্ধান না করা, সঙ্কুচিত ফ্ল্যাট ফাইলগুলি যেতে আরও সহজ উপায় হতে পারে।

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


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

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

0

একটি হডুপ সমাধান বিবেচনা করুন। 2 টিবি / দিন দ্রুত যোগ হয়। এছাড়াও কেবল ডেল্টা রেকর্ডগুলি লগিং বিবেচনা করুন, অর্থাত্ একটি অন্তর্নিহিত মান এবং তারপরেই কোনও পরিবর্তন ঘটে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.