কয়েক বিলিয়ন সারি ডেটার জন্য সেরা ডাটাবেস এবং সারণী নকশা [বন্ধ]


74

আমি একটি অ্যাপ্লিকেশন লিখছি যা বিপুল পরিমাণ বৈদ্যুতিক এবং তাপমাত্রার ডেটা সঞ্চয় এবং বিশ্লেষণ করতে হবে।

মূলত বিগত বেশ কয়েক বছর ধরে কয়েক হাজার স্থানে আসতে বেশ কয়েক বছর ধরে প্রচুর পরিমাণে ঘন্টার বিদ্যুৎ ব্যবহারের পরিমাপ সংরক্ষণ করতে হবে এবং তারপরে খুব জটিল নয় এমন উপাত্ত বিশ্লেষণ করতে হবে।

আমার এখনকার তথ্য যে তথ্য সংরক্ষণ করতে হবে তা হ'ল লোকেশন আইডি, টাইমস্ট্যাম্প (তারিখ এবং সময়), তাপমাত্রা এবং বিদ্যুতের ব্যবহার।

যে পরিমাণ তথ্য সংরক্ষণ করতে হবে তা সম্পর্কে এটি প্রায় অনুমান, তবে এই লাইনগুলির পাশাপাশি কিছু:
20 000+ অবস্থান, প্রতি মাসে 720 টি রেকর্ড (প্রতি ঘন্টার পরিমাপ, প্রতি মাসে প্রায় 720 ঘন্টা), 120 মাস (10 বছর আগে ) এবং ভবিষ্যতে অনেক বছর। সাধারণ গণনাগুলি নিম্নলিখিত ফলাফল দেয়:

20 000 অবস্থান x 720 রেকর্ডগুলি x 120 মাস (10 বছর পূর্বে) = 1 728 000 000 রেকর্ড

এগুলি অতীতের রেকর্ড, নতুন রেকর্ডগুলি মাসিক আমদানি করা হবে, সুতরাং প্রতি মাসে প্রায় 20 000 x 720 = 14 400 000 নতুন রেকর্ডগুলি

মোট অবস্থানগুলি ধীরে ধীরে পাশাপাশি বৃদ্ধি পাবে।

এই সমস্ত ডেটাতে, নিম্নলিখিত ক্রিয়াকলাপগুলি সম্পাদন করা প্রয়োজন:

  1. একটি নির্দিষ্ট তারিখ এবং সময় সময়কালের জন্য ডেটা পুনরুদ্ধার করুন: 01.01.2013 এবং 01.01.2017 তারিখ এবং 07:00 এবং 13:00 এর মধ্যে নির্দিষ্ট অবস্থান আইডির জন্য সমস্ত রেকর্ড।
  2. একটি নির্দিষ্ট তারিখ এবং সময়সীমার জন্য সাধারণ গাণিতিক ক্রিয়াকলাপগুলি, যেমন: এমআইএন, ম্যাক্স এবং এভিজি তাপমাত্রা এবং একটি নির্দিষ্ট অবস্থান আইডির জন্য বিদ্যুতের ব্যবহারের জন্য 5 বছরের জন্য 07:00 থেকে 13:00 এর মধ্যে ID

ডেটা মাসিক লিখিত হবে, তবে কয়েকশো ব্যবহারকারী (কমপক্ষে) নিয়ত পড়বেন, তাই পড়ার গতি উল্লেখযোগ্যভাবে বেশি গুরুত্ব পায়।

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

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

আমার প্রশ্নগুলি নিম্নলিখিত:

  1. এত বড় পরিমাণে ডেটার জন্য আমার কোনও নোএসকিউএল ডাটাবেস ব্যবহার করা উচিত। না পারলে কি আমি মাইএসকিউএল এ লেগে থাকতে পারি?
  2. আমার কোন ডাটাবেস ব্যবহার করা উচিত?
  3. নির্দিষ্ট সময় এবং তারিখের জন্য দ্রুত তথ্য পুনরুদ্ধার এবং প্রক্রিয়া করার জন্য আমি কি তারিখ এবং সময়কে আলাদা, সূচিযুক্ত (যদি সম্ভব) কলামগুলিতে রাখি, বা একক কলামে টাইমস্ট্যাম্প রেখে কি এটি করা যেতে পারে?
  4. এখানে কি কোনও টাইম সিরিজের ডেটা মডেলিংয়ের পদ্ধতির পক্ষে উপযুক্ত এবং যদি আপনি ভাল টেবিলে নকশার জন্য আমাকে পয়েন্টার দিতে না পারেন?

ধন্যবাদ.


29
2017. ছোট না হলেও এটি যথাযথ হার্ডওয়্যারের জন্য খুব বেশি পরিমাণে ডেটা নয়। এবং আমি আপনাকে বলতে ঘৃণা করি, কিন্তু এখনও পর্যন্ত আপনার কাছে যা আছে তা সম্পর্কিত সম্পর্কের মতো শোনাচ্ছে।
টমটম

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

3
এসিকিউএল বা নোএসকিউএল-এর সাথে আলি রাজেঝি হাদুপের কোনও সম্পর্ক নেই - এটি কেবলমাত্র একটি স্টোরেজ ইঞ্জিন। হ্যাডোপ দ্বারা সমর্থিত প্রচুর এসকিউএল ইন্টারফেস রয়েছে।
mustaccio

3
আপনার সীমাবদ্ধতাগুলি কী আবার: সফ্টওয়্যার / লাইসেন্সগুলিতে ব্যয় করার অর্থ?
ব্যবহারকারী 3067860

1
যখন আপনার কাছে অসীম অর্থ থাকবে, তখন আমি একটি এসএপি হানা অ্যাপ্লায়েন্স কেনার পরামর্শ দেব। বড় ডেটাসেটে একত্রিত করার জন্য এটি দুর্দান্ত। তবে আপনার কাছে সম্ভবত অসীম অর্থ নেই।
ফিলিপ

উত্তর:


90

আমি প্রতিদিন এটিই করি, প্রতি ঘন্টার ডেটা ব্যবহার না করে আমি 5 মিনিটের ডেটা ব্যবহার করি। আমি প্রতিদিন প্রায় 200 মিলিয়ন রেকর্ড ডাউনলোড করি, সুতরাং আপনি এখানে যে পরিমাণ পরিমাণ কথা বলবেন তা কোনও সমস্যা নয়। 5 মিনিটের ডেটা প্রায় 2 টিবি আকারের এবং আমার কাছে আবহাওয়ার ডেটা 50 ঘন্টা পিছনে লোকেশন অনুসারে এক ঘন্টা হিসাবে ফিরে যায় level সুতরাং আমার অভিজ্ঞতার ভিত্তিতে আমাকে আপনার প্রশ্নের উত্তর দিন:

  1. এর জন্য NoSQL ব্যবহার করবেন না। ডেটা অত্যন্ত কাঠামোগত এবং পুরোপুরি একটি সম্পর্কিত ডেটাবেস ফিট করে।
  2. আমি ব্যক্তিগতভাবে এসকিউএল সার্ভার 2016 ব্যবহার করি এবং ডেটাটির এই পরিমাণে জুড়ে গণনা প্রয়োগ করতে আমার কোনও সমস্যা নেই। এটি আমার পোস্টগার্রেএসকিউএল উদাহরণে মূলত ছিল যখন আমি আমার কাজ শুরু করি এবং এটি কোনও ছোট এডাব্লুএস দৃষ্টান্তের সাথে ডেটা ভলিউমটি পরিচালনা করতে পারে না।
  3. আমি চাই অত্যন্ত পুরনো ঘন্টা অংশ আহরণের এবং সংরক্ষণকারী এটা তারিখ নিজেই থেকে আলাদা সুপারিশ। বিশ্বাস করুন, আমার ভুল থেকে শিখুন!
  4. আমি বেশিরভাগ ডেটা তালিকা-ভিত্তিক (DATE, TIME, DATAPOINT_ID, VALUE) সঞ্চয় করি তবে লোকেরা কীভাবে ডেটা ব্যাখ্যা করতে চাইবে তা নয়। ডেটা এবং বিপুল পরিমাণে পাইভোটিংয়ের বিরুদ্ধে কিছু ভয়ঙ্কর প্রশ্নের জন্য প্রস্তুত থাকুন। রেজাল্ট সেটের জন্য একটি ডি-নরমালাইজড টেবিল তৈরি করতে ভয় পাবেন না যা ফ্লাইতে গণনা করার জন্য খুব বড়।

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

আমি কেন তারিখ থেকে পৃথক ঘন্টা সঞ্চয় করার পরামর্শ দিচ্ছি তার বিশদটি জানাতে, আমি কেন সেভাবে এটি করি তার কয়েকটি কারণ এখানে রয়েছে:

  1. বৈদ্যুতিক ডেটা যেভাবে উপস্থাপন করা হয়েছে তা হ'ল আওয়ার এন্ডিং- অতএব, 01:00 আসলে পূর্ববর্তী ঘন্টাটির বৈদ্যুতিক শক্তির গড় এবং 00:00 আওয়ার এন্ডিং 24 হয় ((এটি গুরুত্বপূর্ণ কারণ আপনাকে অবশ্যই 24 ঘন্টা মান অন্তর্ভুক্ত করার জন্য দুটি তারিখ সন্ধান করতে হবে - যে দিন আপনি নিম্নলিখিত দিনের প্রথম চিহ্নটি আরও সন্ধান করছে)) তবে আবহাওয়ার তথ্যগুলি প্রকৃতপক্ষে একটি সামনের পদ্ধতিতে উপস্থাপন করা হয়েছে (পরবর্তী ঘন্টাটির জন্য আসল এবং পূর্বাভাস)। এই ডেটা নিয়ে আমার অভিজ্ঞতায় গ্রাহকরা বিদ্যুতের দাম / চাহিদার উপরে আবহাওয়ার প্রভাবটি বিশ্লেষণ করতে চান। আপনি যদি সরাসরি স্টেট-আপ তারিখ তুলনা ব্যবহার করেন, তবে সময় স্ট্যাম্পগুলি একই থাকলেও আপনি প্রকৃতপক্ষে আগের ঘন্টাটির গড় তাপমাত্রা বনাম নিম্নলিখিত ঘন্টাটির জন্য তুলনা করছেন।DATETIME কলাম।
  2. কর্মক্ষমতা. আমি বলব যে আমি যে প্রতিবেদনগুলি উত্পন্ন করি তার মধ্যে কমপক্ষে 90% প্রতিবেদনগুলি গ্রাফগুলি হয়, সাধারণত একক তারিখের জন্য বা একাধিক তারিখের জন্য ঘন্টার বিপরীতে দামের পরিকল্পনা করে। তারিখ থেকে সময় বিচ্ছিন্ন করার পরে আপনি যে তারিখের সীমাটি দেখতে চান তার উপর নির্ভর করে প্রতিবেদন তৈরি করতে ব্যবহৃত ক্যোয়ারীর গতি কমিয়ে আনতে পারে। গ্রাহকগণ গত 30 বছরের একক তারিখ দেখতে চান, এটি এক্ষেত্রে অস্বাভাবিক কিছু নয় (বাস্তবে আবহাওয়ার জন্য এটি 30 বছরের নরমাল উত্পন্ন করা প্রয়োজন) - এটি ধীর হতে পারে। অবশ্যই আপনি আপনার ক্যোয়ারীটি অপ্টিমাইজ করতে পারেন এবং সূচিগুলি যুক্ত করতে পারেন এবং আমার উপর বিশ্বাস রাখুন আমার কাছে এমন কিছু উন্মাদ সূচক রয়েছে যা আমার কাছে নয় বরং এটি সিস্টেমটিকে দ্রুত চালিত করে তোলে।
  3. প্রমোদ. আমি একাধিকবার একই টুকরো কোড লিখতে পছন্দ করি না। আমি একই কলামে তারিখ এবং সময় সংরক্ষণ করতাম, যতক্ষণ না সময়ের অংশটি বের করতে আমাকে বারবার একই প্রশ্নটি লিখতে হত। কিছুক্ষণ পরে আমি এটি করতে অসুস্থ হয়ে পড়েছিলাম এবং এটি নিজের কলামে বের করেছি। আপনার যত কম কোড লিখতে হবে তার মধ্যে ত্রুটি রয়েছে। এছাড়াও, কম কোড লেখার অর্থ এই যে আপনি নিজের প্রতিবেদনগুলি দ্রুত বের করতে পারবেন, কেউই সারাদিন প্রতিবেদনের জন্য অপেক্ষা করতে চায় না।
  4. শেষ ব্যবহারকারীরা। সমস্ত শেষ ব্যবহারকারী শক্তি ব্যবহারকারী নয় (যেমন এসকিউএল লিখতে জানেন)। ইতিমধ্যে কোনও ফর্ম্যাটে ডেটা সংরক্ষণ করা হয়েছে যা তারা এক্সেল (বা অন্যান্য অনুরূপ সরঞ্জাম) ন্যূনতম প্রচেষ্টা দিয়ে আনতে পারে তা আপনাকে অফিসে নায়ক করে তুলবে। যদি ব্যবহারকারীরা সহজেই ডেটা অ্যাক্সেস বা পরিচালনা করতে না পারে তবে তারা আপনার সিস্টেম ব্যবহার করবে না। বিশ্বাস করুন, আমি কয়েক বছর আগে নিখুঁত সিস্টেমটি ডিজাইন করেছি এবং এই কারণে কেউ এটি ব্যবহার করেনি। ডাটাবেস ডিজাইন কেবল নিয়ম / নির্দেশিকাগুলির একটি পূর্বনির্ধারিত সেটকে মেনে চলা নয়, এটি সিস্টেমকে ব্যবহারযোগ্য করে তোলার বিষয়ে।

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


আমি শুধু এপোক ডেট ব্যবহার করে সৌভাগ্য পেয়েছি তবে আপনার ব্যবহারের ক্ষেত্রে আপনার সুপারিশটি আকর্ষণীয়। ভাগ করে নেওয়ার জন্য ধন্যবাদ.
আলী রাজেঘি

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

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

1
আপনার হার্ডওয়্যার কেমন?
কেনে 21

1
আপনি কতজন ব্যবহারকারীকে পরিবেশন করেন তার উপর নির্ভর করে এটি অবিশ্বাস্য হার্ডওয়্যার। যেহেতু এটি ছদ্ম-অপ্টিমাইজেশান প্রতিক্রিয়া, তাই আমি মনে করি আপনার প্রযুক্তি সহ অন্তর্ভুক্ত দরকারী। আপনি 30 সেকেন্ডের মধ্যে 2TB ক্রাচ করতে পারেন শুনে আমি সম্পূর্ণ শক হয়ে গিয়েছিলাম - এটি অবিশ্বাস্যভাবে দ্রুত। আমার নিজস্ব রায়কে বাদ দিয়ে, আমি মনে করি ভবিষ্যতের লোকেরা সময়-সিরিজের ডেটা অনুকূল করতে চেয়েছিল তাদের পক্ষে এটি কার্যকর হবে!
কেনে

57

পোস্টগ্রিসএসকিউএল এবং ব্রিন সূচী

এটি নিজের জন্য পরীক্ষা করুন। এটি একটি এসএসডি সহ 5 বছরের পুরানো ল্যাপটপে কোনও সমস্যা নয়।

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,  -- fake location ids in the range of 1-20000
    now() AS tsin,                   -- static timestmap
    97.5::numeric(5,2) AS temp,      -- static temp
    x::int AS usage                  -- usage the same as id not sure what we want here.
  FROM generate_series(1,1728000000) -- for 1.7 billion rows
    AS gs(x);

                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..15.00 rows=1000 width=4) (actual time=173119.796..750391.668 rows=1728000000 loops=1)
 Planning time: 0.099 ms
 Execution time: 1343954.446 ms
(3 rows)

সুতরাং টেবিলটি তৈরি করতে এটি 22 মিনিট সময় নিয়েছে। বড় আকারে, কারণ টেবিলটি একটি পরিমিত 97GB। এরপরে আমরা সূচকগুলি তৈরি করব,

CREATE INDEX ON electrothingy USING brin (tsin);
CREATE INDEX ON electrothingy USING brin (id);    
VACUUM ANALYZE electrothingy;

সূচকগুলি তৈরি করতে এটি বেশ ভাল সময় নিয়েছে। যদিও তারা ব্রিন হওয়ায় তারা কেবল ২-৩ এমবি এবং তারা সহজেই র‌্যামে সঞ্চয় করে। 96 গিগাবাইট পড়া তাত্ক্ষণিক নয়, তবে এটি আপনার কাজের চাপে আমার ল্যাপটপের ক্ষেত্রে আসল সমস্যা নয়।

এখন আমরা এটি জিজ্ঞাসা।

explain analyze
SELECT max(temp)
FROM electrothingy
WHERE id BETWEEN 1000000 AND 1001000;
                                                                 QUERY PLAN                                                                  
---------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=5245.22..5245.23 rows=1 width=7) (actual time=42.317..42.317 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=1282.17..5242.73 rows=993 width=7) (actual time=40.619..42.158 rows=1001 loops=1)
         Recheck Cond: ((id >= 1000000) AND (id <= 1001000))
         Rows Removed by Index Recheck: 16407
         Heap Blocks: lossy=128
         ->  Bitmap Index Scan on electrothingy_id_idx  (cost=0.00..1281.93 rows=993 width=0) (actual time=39.769..39.769 rows=1280 loops=1)
               Index Cond: ((id >= 1000000) AND (id <= 1001000))
 Planning time: 0.238 ms
 Execution time: 42.373 ms
(9 rows)

টাইমস্ট্যাম্পগুলি সহ আপডেট করুন

সূচকের অনুরোধটি সন্তুষ্ট করতে এবং টাইমস্ট্যাম্প কলামে অনুসন্ধানের জন্য আমরা এখানে বিভিন্ন টাইমস্ট্যাম্প সহ একটি টেবিল তৈরি করি, সৃষ্টি কিছুটা সময় নেয় কারণ to_timestamp(int)যথেষ্ট পরিমাণে ধীর now()(যা লেনদেনের জন্য ক্যাশে থাকে)

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,
    -- here we use to_timestamp rather than now(), we
    -- this calculates seconds since epoch using the gs(x) as the offset
    to_timestamp(x::int) AS tsin,
    97.5::numeric(5,2) AS temp,
    x::int AS usage
  FROM generate_series(1,1728000000)
    AS gs(x);

                                                               QUERY PLAN                                                                
-----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..17.50 rows=1000 width=4) (actual time=176163.107..5891430.759 rows=1728000000 loops=1)
 Planning time: 0.607 ms
 Execution time: 7147449.908 ms
(3 rows)

এখন আমরা পরিবর্তে টাইমস্ট্যাম্প মানটিতে একটি ক্যোয়ারী চালাতে পারি,

explain analyze
SELECT count(*), min(temp), max(temp)
FROM electrothingy WHERE tsin BETWEEN '1974-01-01' AND '1974-01-02';
                                                                        QUERY PLAN                                                                         
-----------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=296073.83..296073.84 rows=1 width=7) (actual time=83.243..83.243 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=2460.86..295490.76 rows=77743 width=7) (actual time=41.466..59.442 rows=86401 loops=1)
         Recheck Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
         Rows Removed by Index Recheck: 18047
         Heap Blocks: lossy=768
         ->  Bitmap Index Scan on electrothingy_tsin_idx  (cost=0.00..2441.43 rows=77743 width=0) (actual time=40.217..40.217 rows=7680 loops=1)
               Index Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
 Planning time: 0.140 ms
 Execution time: 83.321 ms
(9 rows)

ফলাফল:

 count |  min  |  max  
-------+-------+-------
 86401 | 97.50 | 97.50
(1 row)

সুতরাং 83.321 এমএসে আমরা 1.7 বিলিয়ন সারি সহ একটি টেবিলের মধ্যে 86,401 রেকর্ডকে একত্রিত করতে পারি। এটা যুক্তিযুক্ত হওয়া উচিত।

ঘন্টা শেষ

ঘন্টা শেষ হওয়ার গণনা করা খুব সহজ, টাইমস্ট্যাম্পগুলি কেটে ফেলুন এবং তারপরে কেবল একটি ঘন্টা যুক্ত করুন।

SELECT date_trunc('hour', tsin) + '1 hour' AS tsin,
  count(*),
  min(temp),
  max(temp)
FROM electrothingy
WHERE tsin >= '1974-01-01'
  AND tsin < '1974-01-02'
GROUP BY date_trunc('hour', tsin)
ORDER BY 1;
          tsin          | count |  min  |  max  
------------------------+-------+-------+-------
 1974-01-01 01:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 02:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 03:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 04:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 05:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 06:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 07:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 08:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 09:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 10:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 11:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 12:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 13:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 14:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 15:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 16:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 17:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 18:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 19:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 20:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 21:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 22:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 23:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-02 00:00:00-06 |  3600 | 97.50 | 97.50
(24 rows)

Time: 116.695 ms

এটি লক্ষণীয় গুরুত্বপূর্ণ, এটি সমষ্টিতে কোনও সূচক ব্যবহার করছে না, যদিও তা পারে। যদি এটি আপনার সাধারণভাবে জিজ্ঞাসিত হয় তবে আপনি সম্ভবত date_trunc('hour', tsin)এতে একটি ব্রিন চান তবে এটির মধ্যে একটি ছোট সমস্যা রয়েছে যা date_truncঅপরিবর্তনীয় নয় তাই আপনাকে এটি তৈরির জন্য প্রথমে এটি আবৃত করতে হবে।

পার্টিশন নির্মাণ প্রক্রিয়ার

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

CREATE TABLE electrothingy_y2016 PARTITION OF electrothingy
    FOR VALUES FROM ('2016-01-01') TO ('2017-01-01');

বা যাই হোক না কেন.


13

এটি আমাকে অবাক করে দেয় যে এখানে কেউ বেঞ্চমার্কিংয়ের কথা উল্লেখ করেনি - এটি অবধি @ ইভানক্রোল তার দুর্দান্ত অবদানের সাথে আগত!

আমি যদি আপনি হয়ে থাকি তবে আমি কিছুটা সময় ব্যয় করতাম (এবং হ্যাঁ, আমি জানি এটি একটি মূল্যবান পণ্য!) আপনার সিস্টেমটি স্থাপন করে, যা আপনার মনে হয় তা চালিয়ে যাবেন (এখানে শেষ-ব্যবহারকারী ইনপুট পান!), বলুন, আপনার 10 সবচেয়ে সাধারণ প্রশ্ন।

আমার নিজের চিন্তা:

NoSQL সমাধান নির্দিষ্ট ব্যবহারের ক্ষেত্রে খুব ভাল কাজ করতে পারে তবে অ্যাড-হকের প্রশ্নের জন্য প্রায়শই জটিল নয়। মাইএসকিউএলের প্রাক্তন প্রধান স্থপতি, ব্রায়ান আকারের মজাদার নোসকিউএল-এর জন্য এখানে দেখুন !

আমি @ মিঃ ব্রাউনস্টোন এর সাথে একমত যে আপনার ডেটা একটি সম্পর্কযুক্ত সমাধানের জন্য বিশিষ্টভাবে উপযুক্ত (এবং এই মতামত ইভান ক্যারল নিশ্চিত করেছেন )!

আমি যদি কোনও ব্যয়ের প্রতিশ্রুতিবদ্ধ হই তবে তা আমার ডিস্ক প্রযুক্তির হয়ে উঠবে! আমি নাসা বা সান বা আমার এসএসডি ডিস্কগুলিতে আমার খুব কমই লিখিত সামগ্রিক ডেটা ধরে রাখতে আমার যে কোনও অর্থ ব্যয় করবো!

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

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

এই জাতীয় প্রকল্পের জন্য আমার নিজের ব্যক্তিগত প্রথম পোর্ট পোস্টগ্র্রেএসকিউএল হবে। তার মানে এই নয় যে আমি মালিকানাধীন সমাধানটি বাতিল করব, তবে পদার্থবিজ্ঞান এবং ডিস্কগুলির আইন সবার জন্য একই the "ইয়ে কান্না আইন আইনবিদদের 'জিম' জিট" :-)


6

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


1
টাইম সিরিজ ডিবিএমএসের উদাহরণ কী?
বিশপ

2
এখানে দেখুন ।
ভোরেস

4

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

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

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

চূড়ান্ত পরামর্শ হিসাবে, জনপ্রিয় একীভূত ডেটাগুলির জন্য পৃথক সারণী ব্যবহার করুন এবং ব্যাচ জবগুলি ব্যবহারের জন্য তাদের ব্যবহার করুন, এইভাবে আপনাকে প্রতিটি প্রতিবেদনের জন্য অনুশীলনটির পুনরাবৃত্তি করতে হবে না যা একীভূত মান ব্যবহার করে এবং এমন অনুসন্ধানগুলি তৈরি করে যা বর্তমানের সাথে compareতিহাসিক বা তুলনামূলক তুলনা করে historicalতিহাসিক থেকে historicalতিহাসিক অনেক সহজ এবং অনেক বেশি দ্রুত।


আপনি গ্রীনপ্লমকে কলামার স্টোর হিসাবে বিবেচনা করতে পারেন যদি আপনি সেগুলি দেখেন ! "বোনাস" হিসাবে - এটি পোস্টগ্র্যাস এসকিউএল ভিত্তিক!
ভ্যারেস

এইচপি ভার্টিকার সাথে আমার ভাল অভিজ্ঞতা হয়েছে। আমাদের কাছে 9 টি কলাম সহ একক টেবিল ছিল যার মধ্যে 130 টি টি সারি ছিল, অনেকগুলি টিউনিং ছাড়াই। এটা ঠিক কাজ করে।
থ্যাডটাটাগুই
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.