অতি-দ্রুত ডাটাবেসে এক বিলিয়ন সারি স্ক্যান করা হচ্ছে


9

পটভূমি

একটি স্থানীয় ডাটাবেসে প্রায় 1.3 বিলিয়ন স্বতন্ত্র সারি রয়েছে। প্রতিটি সারি অপ্রত্যক্ষভাবে একটি নির্দিষ্ট অক্ষাংশ এবং দ্রাঘিমাংশ (অবস্থান) এর সাথে যুক্ত। প্রতিটি সারিতে একটি তারিখ স্ট্যাম্প থাকে।

ব্যবহারের ক্ষেত্রে

নিম্নরূপ সমস্যা হয়:

  1. ব্যবহারকারী একটি শুরুর / শেষের তারিখ এবং মানগুলির একটি ব্যাপ্তি সেট করে (যেমন, 100 থেকে 105))
  2. সিস্টেমটি সমস্ত সারি সংগ্রহ করে যা প্রদত্ত তারিখটির সাথে মিলিত হয়, অবস্থান অনুসারে গ্রুপ করা হয়েছে।
  3. সিস্টেমগুলি সেই তারিখগুলির মধ্যে অবস্থানগুলির নির্ধারণ করে যে মানগুলির প্রদত্ত পরিসরে পড়ে যাওয়ার একটি পরিসংখ্যানগত সম্ভাবনা রয়েছে।
  4. সিস্টেমটি সমস্ত মিলে যাওয়া অবস্থান ব্যবহারকারীকে প্রদর্শন করে lays

এটি গতি এবং স্কেলের সমস্যা।

প্রশ্ন

আপনি কল্পনা করতে পারেন এমন সর্বনিম্ন ব্যয়বহুল সমাধান আর্কিটেকচারটি কী যা এই জাতীয় ব্যবস্থাকে পাঁচ সেকেন্ডের মধ্যে ব্যবহারকারীদের জন্য ফলাফল পুনরুদ্ধার করতে দেয়?

বর্তমান ব্যবস্থা

পরিবেশটি বর্তমানে:

  • PostgreSQL 8.4 (আপগ্রেড করা সম্ভব; ডাটাবেস স্যুইচ করা কোনও বিকল্প নয়)
  • আর এবং পিএল / আর
  • XFS দ্বারা
  • WD VelociRaptor
  • 8 জিবি র‌্যাম (কর্সার জি.স্কিল; 1.3 গিগাহার্টজ)
  • কোয়াড কোর জেনুইনইন্টেল 7 (2.8 গিগাহার্টজ)
  • উবুন্টু 10.10

হার্ডওয়্যার আপগ্রেড গ্রহণযোগ্য।

আপডেট - ডাটাবেস স্ট্রাকচার

কোটি কোটি সারি সাদৃশ্য একটি সারণীতে রয়েছে:

id | taken | location_id | category | value1 | value2 | value3
  • আইডি - প্রাথমিক কী
  • নেওয়া - সারিতে নির্ধারিত তারিখ
  • অবস্থান_আইডি - অক্ষাংশ / দ্রাঘিমাংশের উল্লেখ ference
  • বিভাগ - তথ্য বিবরণ
  • মান 1 .. 3 - অন্যান্য মানগুলি যা ব্যবহারকারী জিজ্ঞাসা করতে পারে

takenকলাম সাধারণত প্রতি পরপর তারিখ হয় location_id, কখনও কখনও প্রতিটি অবস্থানের 1800 থেকে 2010 তথ্য আছে (যেমন প্রতিটি অবস্থানে একই তারিখ সীমার মধ্যে ডেটা আছে 77,000 সম্পর্কে তারিখ, তাদের অনেকেই সদৃশ)।

এখানে সাতটি বিভাগ রয়েছে এবং টেবিলগুলি ইতিমধ্যে বিভাগ দ্বারা বিভাগ করা হয়েছে (চাইল্ড টেবিলগুলি ব্যবহার করে)। প্রতিটি বিভাগে ~ 190 মিলিয়ন সারি রয়েছে। অদূর ভবিষ্যতে, বিভাগ অনুসারে সারিগুলির সংখ্যা এক বিলিয়ন ছাড়িয়ে যাবে।

প্রায় 20,000 অবস্থান এবং 70,000 শহর রয়েছে। অক্ষাংশ এবং দ্রাঘিমাংশ দ্বারা অবস্থানগুলি শহর সম্পর্কিত হয় corre প্রতিটি লোকেশন একটি নির্দিষ্ট শহরে অর্পণ করার অর্থ শহরের গণ্ডি সন্ধান করা, যা তুচ্ছ কাজ নয়।

ধারনা

আমার কিছু ধারণাগুলি অন্তর্ভুক্ত রয়েছে:

  • ডাটাবেস হোস্ট করার জন্য একটি মেঘ পরিষেবা সন্ধান করুন।
  • একটি এসএসডি রাইড স্ট্রিপ তৈরি করুন (দুর্দান্ত ভিডিও)।
  • একটি টেবিল তৈরি করুন যা শহর অনুসারে সমস্ত অবস্থানকে একত্রিত করে (প্রাক-গণনা)।

ধন্যবাদ!


10
"ডাটাবেসগুলি স্যুইচ করা কোনও বিকল্প নয়" ভাল এটি বেশিরভাগ সমাধান সরিয়ে দেয়। শুভকামনা!
স্টিভেন এ। লো

1
আপনি এই রেকর্ডগুলির সাথে ঠিক কী করছেন সে সম্পর্কে আরও তথ্য ছাড়া বলা শক্ত। এছাড়াও, আপনি 5 সেকেন্ডের নিকৃষ্টতম মামলার সন্ধান করছেন (যার অর্থ সম্ভবত প্রতিটি রেকর্ড পরীক্ষা করা এবং শূন্য অবস্থানের মিল)?
গাই স্যারটন

2
@ ডেভ: বর্তমান সিস্টেমটিতে কত সময় লাগে? বর্তমান সিস্টেম কি পোস্টজিআইএস ব্যবহার করছে ? কি location_idএকটি geographyবা geometry, অথবা একটি দ্বিতীয় টেবিল বোঝায়? location_idকলামটি কি সূচিত হয়?
রোবং

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

1
@ ডেভ, প্রচুর সম্ভাবনা, তবে প্রশ্নটি আপনার সাথে কী প্রাসঙ্গিক। আপনি কি অনুসন্ধান করেছেন যে বর্তমান বাধা এখনও কোথায়?

উত্তর:


12

সর্বাধিক গুরুত্বপূর্ণ বিষয়টি হ'ল একেবারে নির্দিষ্ট হওয়া যেখানে আপনি ডাটাবেসগুলি স্যুইচ করতে পারবেন না বলেই এখন প্রদত্ত সংখ্যক প্রতিনিধিদের অনুরোধের জন্য বাধা রয়েছে।

আপনি যদি পুরো টেবিল স্ক্যান করেন তবে আপনার যথাযথ সূচীগুলি দরকার।

যদি আপনি I / O এর জন্য অপেক্ষা করেন তবে আপনার ক্যাশিংয়ের জন্য আরও মেমরি দরকার (জেফ অ্যাটউড সম্প্রতি উল্লেখ করেছেন যে 24 গিগাবাইট সিস্টেম ডেস্কটপ সিস্টেমে প্রবেশযোগ্য ছিল)।

আপনি যদি সিপিইউতে অপেক্ষা করেন তবে আপনার গণনাগুলি অপ্টিমাইজ করা যায় কিনা তা আপনাকে দেখতে হবে।

এটির জন্য একটি ডিবিএ-টুপি এবং অপারেটিং সিস্টেম-টুপি প্রয়োজন, তবে আপনি সঠিক গাছটি ঝাঁকিয়েছেন তা নিশ্চিত করার পক্ষে এটি উপযুক্ত is


আপনি কখনই এটিকে টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো করে - এমনকি যদি প্রতিটি সারিতে 100 বাইট লাগে, 1.3 বিলিয়ন সারি = 121 গিগাবাইট। আপনার সমস্ত সূচী ইত্যাদি সহ, আমি নিশ্চিত এটি আরও অনেক বেশি হবে। একটি একক বাক্সে, এসএসডি + টন ম্যামের আশেপাশে কিছু গুরুতর হার্ডওয়্যার না থাকলে আপনি ধীর হয়ে যাবেন। সস্তা উপায় বাক্সগুলি জুড়ে স্কেল করা।
সুব শঙ্করা সুব্রমনিয়ান

4
@ সুবু, আপনি বিতরণ করতে চান? এখন আপনার দুটি সমস্যা আছে ...

হেই - আমি এর সাথে একমত হয়েছি :) তবে এটি সস্তা!
সুব শঙ্করা সুব্রমনিয়ান

@ থরবজর্ন: আপনার সময় এবং আপনার সমস্ত সহায়তার জন্য আপনাকে ধন্যবাদ। আমি মনে করি আমি বিভাগ অনুযায়ী ডেটা সেটটি 25 মিলিয়ন সারিতে হ্রাস করব তারপর তারিখে সূচী প্রয়োগ করব apply এর ফলে স্ক্যানটি হ্রাস করা উচিত ~ 70000 সারি (প্রতিদিন, পরিসরের জন্য দুই সপ্তাহের সীমা সহ), যা মোটামুটি চটজলদি হওয়া উচিত।
ডেভ জার্ভিস

@ ডেভ, আপনার বাধা কোথায় রয়েছে তা এখনও আপনার জানতে হবে। এটা জানুন না যখন আছে করা।

4

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

আপনি যদি দেখেন যে তারিখের স্ট্যাম্পটি খুব বেশি পরিবর্তিত হচ্ছে, তবে আপনি অবস্থানগুলির উপর ভিত্তি করে পার্টিশন করতে পারবেন - আবার অনুভূমিকভাবে স্কেলেবল। (আশা করি তারা আরও বহু অক্ষাংশ / দ্রাঘিমাংশ যোগ করবেন না!)


ধারণাগুলি জন্য আপনাকে ধন্যবাদ। সম্ভাব্য 77 77,০66। তারিখ রয়েছে এবং নতুন তারিখগুলি এগিয়ে যাওয়ার সাথে যুক্ত করা হবে। আমার একটি একক মেশিন আছে। সেখানে ২০,০০০ টি অবস্থান রয়েছে, তবুও লোকেশন দ্বারা বিভক্ত হওয়া কোনও উপকারে আসেনি কারণ বিশ্লেষণের জন্য ডেটা সমস্ত অবস্থান স্প্যান করে।
ডেভ জার্ভিস

এবং মেঘ ব্যবহার কিভাবে উপরের সমাধান থেকে পৃথক?
চানি

এটাই আমি ভেবেছিলাম। কিছু ধরণের অনুভূমিক পার্টিশন যাতে অনুসন্ধানটি সমস্ত পার্টিশন জুড়ে সমান্তরালে ঘটতে পারে।
davidk01

দিনে বিভাজন সম্ভবত সবচেয়ে সহায়ক হবে, যার ফলস্বরূপ 2562 পৃথক সারণী (366 দিন x 7 বিভাগ)।
ডেভ জার্ভিস

4

সবচেয়ে খারাপ ক্ষেত্রে দৃশ্যের তারিখের পরিসীমাটি আপনার ডাটাবেসের সমস্ত তারিখকে কভার করে।

আপনি ১.৩ বিলিয়ন রেকর্ড পড়তে এবং প্রতিটি রেকর্ড বনাম একটি ভৌত ​​মেশিনে, 5 সেকেন্ডেরও কম সময়ে, প্রবেশ করা মানগুলিতে কিছু বিশ্লেষণ করতে চাইছেন। ফলাফলটি সমস্ত অবস্থান বা কোনওটিই হতে পারে - আপনি আগে থেকে কিছুই জানেন না।

এই পরামিতিগুলি দেওয়া আমি সম্ভবত অসম্ভব বলব।

আপনার হার্ড ড্রাইভটি দেখুন: সর্বাধিক স্থিতিশীল হার 150MB / s এর চেয়ে কম। 1.3 বিলিয়ন রেকর্ড পড়তে 5 সেকেন্ডের বেশি সময় লাগবে। সিপিইউ ভিত্তিক আপনি 5 সেকেন্ডের মধ্যে 1.3 বিলিয়ন রেকর্ডের উপর কোনও ধরণের পরিসংখ্যান বিশ্লেষণ করতে সক্ষম হবেন না।

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

মেমরির সমস্ত রেকর্ড (বা কমপক্ষে গুরুত্বপূর্ণ অংশ) ধরে রাখা সম্ভব হতে পারে। সম্ভবত 8 জিবিতে নেই। এটি কমপক্ষে ডিস্ক আই / ও অংশটি সরিয়ে ফেলবে যদিও মেমরি ব্যান্ডউইথটি 5 সেকেন্ডের মধ্যে সমস্ত কিছু স্ক্যান করতে অপর্যাপ্ত হতে পারে। যে কোনও হারে, এই ধরণের অ্যাপ্লিকেশনগুলিকে গতিযুক্ত করার জন্য এটি আমার আরেকটি কৌশল (আমার আগের পরামর্শের সাথে একত্রিত)।

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


উত্তরের জন্য ধন্যবাদ. আমার তালিকাভুক্ত ধারণাগুলি অনুসারে হার্ডওয়্যার আপগ্রেডগুলি একটি বিবেচনা। একটি উপ - 50 750 মার্কিন ডলার সমাধান আদর্শ হবে।
ডেভ জার্ভিস

2

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

যদি এই মাপদণ্ডে আপনার প্রশ্নগুলি যদি কয়েক সেকেন্ড সময় নেয়, তবে সম্ভবত এর অর্থ এমন কোনও সূচক ব্যবহার করা হচ্ছে না। আপনি কি যথাযথ হিসাবে এগুলি তদন্ত করেছেন তা নিশ্চিত করতে পারবেন?


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

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

1

পোস্টগ্রিএসএসকিউএল এবং অক্ষাংশ / দ্রাঘিমাংশের ডেটা ব্যবহার করার কারণে আপনার অবশ্যই পোস্টজিআইএস ব্যবহার করা উচিত, এইভাবে আপনি গতি বাড়িয়ে তুলতে আপনার ডাটাবেসে একটি জিআইএসটি স্পেসিয়াল ইনডেক্স যুক্ত করতে পারেন।

আমার কাছে এমন একটি টেবিল রয়েছে (350k সারি সহ) আপনার (2 কোর এবং সবে 2 জিবি র‌্যাম) এর চেয়ে অনেক কম কনফিগারেশন রয়েছে তবুও অনুসন্ধানগুলি এক সেকেন্ডেরও কম সময় নেয়।


0

Essbase যেমন ওএলএপি আর্কিটেকচার: এসবেস উইকিপিডিয়া দিয়েছিলেন তেমন একটি রিলেশনাল মডেল আপনি ভেঙে ফেলতে পারেন

আমার অর্থ হ'ল শহর প্রতি এক টেবিল তৈরি করা, এটি 1000+ টেবিলের সাথে শেষ হয়। আপনার পরামর্শ মতো একটি টেবিল নয়, তবে অনেকগুলি। তারিখ এবং অবস্থান অনুসারে প্রতিটি সারণি সূচী করুন। অনেক টেবিল, অনেক সূচী -> দ্রুত।


নোটের জন্য ধন্যবাদ। এখানে ,000০,০০০ এরও বেশি শহর রয়েছে এবং অনেকগুলি ভিন্ন দ্রাঘিমাংশ / দ্রাঘিমাংশের মান নির্দিষ্ট শহরের অঞ্চলে পড়ে।
ডেভ জার্ভিস

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

0

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


-2

আপনি মহাসড়কে সাইকেল চালানোর আশা করছেন। বর্তমানে আপনি কেবল এই সমস্যাটিকে মোকাবেলার জন্য একটি সমাধান অনুসন্ধান করছেন, আপনি যদি 2 বিলিয়ন রেকর্ড রাখেন তবে আপনি সমস্যার পূর্বাভাস দিচ্ছেন না? স্কেল্যাবিলিটির সমাধান করতে হবে। উত্তর হল সরল ব্যবহারের অবজেক্ট ডাটাবেস। যেমন আন্তঃব্যবস্থা ক্যাশে

এবং আপনি বিশ্বাস করুন আমি আন্তঃব্যবস্থা থেকে নেই ;-)

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