৩.১ বিলিয়ন সারি ডেটা কীভাবে পরিচালনা করবেন?


14

আপাতত অপেক্ষাকৃত বিশাল পরিমাণে ডেটা সঞ্চয় করার জন্য আমার স্টোরেজ স্কিমা বাস্তবায়নের দায়িত্ব দেওয়া হয়েছে। বর্তমান data pointমান নির্ধারণের জন্য ডেটা প্রাথমিকভাবে অ্যাক্সেস করা হবে তবে ডেটা ট্রেন্ডিং / বিশ্লেষণের জন্য আমার গত ছয় মাসের ইতিহাসও ট্র্যাক করতে হবে।

গত এক ঘন্টার জন্য min/ max/ sumমানটি ট্র্যাক করতে সাম্প্রতিক প্রয়োজনীয়তা যুক্ত করা হয়েছিল ।

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

তথ্যটি

নিম্নলিখিত সারণিটি প্রাথমিক ডেটা উত্সকে উপস্থাপন করে (প্রায়শই জিজ্ঞাসা করা হয়)। টেবিলটিতে প্রায় পাঁচ মিলিয়ন সারি থাকবে। ডেটা পরিবর্তনগুলি প্রাথমিকভাবে ডেটা লোডের পরে UPDATEখুব মাঝেমধ্যে INSERTবিবৃতি সহ স্টেটমেন্ট হবে । dataPointIdআপনি সর্বদা নির্বাচন করবেন বলেই আমি ডেটা ক্লাস্টার বেছে নিয়েছি all values for a given data point

// Simplified Table
CREATE TABLE [dbo].[DataPointValue](
    [dataPointId]  [int] NOT NULL,
    [valueId]      [int] NOT NULL,
    [timestamp]    [datetime] NOT NULL,
    [minimum]      [decimal](18, 0) NOT NULL,
    [hourMinimum]  [decimal](18, 0) NOT NULL,
    [current]      [decimal](18, 0) NOT NULL,
    [currentTrend] [decimal](18, 0) NOT NULL,
    [hourMaximum]  [decimal](18, 0) NOT NULL,
    [maximum]      [decimal](18, 0) NOT NULL

    CONSTRAINT [PK_MeterDataPointValue] PRIMARY KEY CLUSTERED ([dataPointId],[valueId])
)

দ্বিতীয় সারণীটি প্রায় 3.1 বিলিয়ন সারিগুলিতে উল্লেখযোগ্যভাবে বৃহত্তর (গত ছয় মাসের ডেটা উপস্থাপন করে)। ছয় মাসের পুরানো ডেটা মুছে ফেলা হবে; অন্যথায় কঠোরভাবে ডেটা INSERTস্টেটমেন্ট (~ 200 সারি / সেকেন্ড, 720,000 সারি / ঘন্টা, 17 মিলিয়ন সারি / সপ্তাহ)।

// Simplified Table
CREATE TABLE [dbo].[DataPointValueHistory](
    [dataPointId] [int]            NOT NULL,
    [valueId]     [int]            NOT NULL,
    [timestamp]   [datetime]       NOT NULL,
    [value]       [decimal](18, 0) NOT NULL,
    [delta]       [decimal](18, 0) NOT NULL

    CONSTRAINT [PK_MeterDataPointHistory] PRIMARY KEY CLUSTERED ([dataPointId], [valueId], [timestamp])

)

প্রত্যাশাটি হ'ল এই টেবিলটি আকারে দ্বিগুণ হয়ে যাবে কারণ ট্র্যাকড ডেটা পয়েন্টের মানগুলি 400 সারি / সেকেন্ডে বৃদ্ধি পায় (সুতরাং billion 10 বিলিয়ন ডলার পৌঁছানো প্রশ্নের বাইরে নয়)।

প্রশ্ন (গুলি) , আমি একের অধিক জিজ্ঞাসা করছি ... তারা নিবিড়ভাবে সম্পর্কিত।

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


1) প্রদত্ত যে আমি গনা প্রয়োজন min, maxএবং sumমধ্যে (যেমন গত ঘন্টার জন্য now - 60 minutes)। সাম্প্রতিক ডেটা ট্র্যাক করার জন্য সেরা পন্থাটি কী:

  • ডেটা পরিষেবাটির স্মৃতিতে সাম্প্রতিক ডেটা ধরে রাখুন। প্রতিটি ডেটা আপডেটের সাথে গণিত মিনিট / সর্বোচ্চ / গড় লিখুন।

  • প্রতিটি আপডেটের বিবৃতি চলাকালীন ইতিহাস সারণী থেকে সাম্প্রতিক ইতিহাসের প্রশ্নগুলি (পরবর্তী প্রশ্নের উপর প্রভাব ফেলবে?) জিজ্ঞাসা করুন। ক্যোয়ারী ডেটা পয়েন্ট মানের জন্য সর্বশেষতম ডেটা অ্যাক্সেস করবে এবং কেবলমাত্র গত মিলিয়ন রেকর্ডের মধ্যে স্ক্যান করা উচিত?

  • ইতিহাসের টেবিলের চেহারাটি এড়াতে ডেটাপয়েন্টভ্যালিউ সারিটিতে সাম্প্রতিক ইতিহাস সংরক্ষণ করুন? সম্ভবত একটি সীমানাযুক্ত স্ট্রিং হিসাবে সঞ্চিত এবং আপডেট আপডেটের ভিতরে প্রক্রিয়া করা হয়?

  • অন্য বিকল্প আমি বিবেচনা করা হয়নি?


2) এর জন্য DataPointValueHistory, ডেটাবলের বিরুদ্ধে অনুসন্ধানগুলি সর্বদা dataPointIdএবং এক বা একাধিক valueIdএর হতে হবে। অনুসন্ধান করা ডেটা সাধারণত শেষ দিন, সপ্তাহ বা মাসের জন্য হতে পারে তবে কিছু ক্ষেত্রে পুরো ছয় মাসের জন্য হতে পারে।

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

  • DataPointValueHistoryডেটাপয়েন্টআইডি -> মান আইডি -> টাইমস্ট্যাম্প দ্বারা ক্লাস্টার

  • DataPointValueHistoryটাইমস্ট্যাম্প -> ডেটাপয়েন্টআইডি -> মান আইডি দ্বারা ক্লাস্টার


3) পরিশেষে, উপরে উল্লিখিত হিসাবে, আমি মনে করি এটি DataPointValueHistoryটেবিল বিভক্ত করার অর্থ হবে । ইতিহাসের ডেটা কীভাবে সেরাভাবে ভাগ করা যায় সে সম্পর্কে কোনও পরামর্শ প্রশংসিত হবে।

  • যদি প্রথম টাইমস্ট্যাম্প দ্বারা ক্লাস্টার করা হয় তবে আমি ভাবছি যে সপ্তাহে ডেটা ভাগ করা উচিত (মোট 27 টি পার্টিশন)। সর্বাধিক প্রাচীন পার্টিশনটি সাপ্তাহিক 27 পরে মুছে ফেলা হবে।

  • যদি ডেটাপয়েন্টআইড দ্বারা প্রথমে ক্লাস্টার করা হয়, তবে আমি ভাবছি যে আইডিটির কোনও মডুলাস দ্বারা ডেটা ভাগ করা উচিত?

টেবিল বিভাজন নিয়ে আমার যেমন সীমিত অভিজ্ঞতা আছে, আপনার দক্ষতার প্রশংসা করা হবে।


আপনি কি স্ট্যাকওভারফ্লোতে এই প্রশ্নের সংস্করণটি মুছলেন?
টেরিন

@ ব্লুয়েফিট - হ্যাঁ, এটি অফ-টপিক হিসাবে পতাকাঙ্কিত করা হয়েছিল ... সুতরাং আমি এসও প্রশ্নটি মুছে ফেলে এখানে পুনরায় তৈরি করেছি (এটি সম্ভবত স্থানান্তরিত হওয়ার জন্য আমার অপেক্ষা করা উচিত ছিল)।
ক্যালগারি কোডার

কোনও সমস্যা নেই, আমি কেবল নিশ্চিত করেছিলাম যে আমাদের ক্রস পোস্টের কোনও প্রশ্ন নেই।
তারিন

স্ট্যান্ডার্ড সংস্করণে, আপনি এখনও পার্টিশনযুক্ত ভিউ এবং একাধিক বেস টেবিলগুলি ব্যবহার করে ডেটা ভাগ করতে পারেন। নিশ্চিত যে আপনি তা বিবেচনা করে কিনা।
জন সেগেল

@ জন - হ্যাঁ, আমি ম্যানুয়াল টেবিল পার্টিশনগুলি বিবেচনা করেছি (সেই বিশেষ পছন্দটি কোনও এন্টারপ্রাইজ লাইসেন্স পাওয়া যায় কিনা তার উপর ভিত্তি করে হবে ... যদি হ্যাঁ, তবে কেন আমার নিজের ভূমিকা থাকবে)।
ক্যালগারি কোডার

উত্তর:


4

আমি যখন এই বিশ্লেষণ সমাধান তৈরির বিষয়ে গবেষণা করছিলাম যেখানে এক সারণীতে কয়েক বিলিয়ন সারি থাকবে তখন আমি এই বিশ্লেষণটি খুব দরকারী বলে মনে করি।

http://leiliweb.wordpress.com/2012/12/11/partitioned-table-and-index-strategies-using-sql-server-2008/


ধন্যবাদ লিঙ্কটির জন্য, অবশ্যই কার্যকরভাবে ... পয়েন্ট 1 বা 2 তে কোনও চিন্তা?
ক্যালগারি কোডার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.