বিলিয়ন-সারি-সারণী // সূচীতে ব্যবহৃত ধীর প্রশ্নগুলি


10

যেহেতু আমি একজন তরুণ বিকাশকারী এবং ডেটাবেসগুলি ব্যবহার করার ক্ষেত্রে সত্যই দক্ষ নই (পোস্টগ্রিসকিউএল ৯.৩) আমি এমন একটি প্রকল্প নিয়ে কিছু সমস্যার মুখোমুখি হয়েছি, যেখানে আমার সত্যিই সহায়তা প্রয়োজন।

আমার প্রকল্পটি ডিভাইসগুলি (1000 বা আরও বেশি ডিভাইস পর্যন্ত) থেকে ডেটা সংগ্রহ করার বিষয়ে, যেখানে প্রতিটি ডিভাইস প্রতি সেকেন্ডে একটি করে ডেটা ব্লক পাঠাচ্ছে, যা প্রতি ঘন্টা 3 মিলিয়ন সারি করে।

বর্তমানে আমি একটি বড় টেবিল পেয়েছি যেখানে আমি প্রতিটি ডিভাইসের আগত ডেটা সঞ্চয় করি:

CREATE TABLE data_block(
    id bigserial
    timestamp timestamp
    mac bigint
)

যেহেতু একাধিক প্রকারের ডেটা একটি ডেটা ব্লক অন্তর্ভুক্ত করতে পারে (বা করতে পারে না), অন্য সারণী রয়েছে যা সারণিকে উল্লেখ করে data_block

CREATE TABLE dataA(
    data_block_id bigserial
    data

    CONSTRAINT fkey FOREIGN KEY (data_block_id) REFERENCES data_block(id);
);
CREATE TABLE dataB(...);
CREATE TABLE dataC(...);
CREATE INDEX index_dataA_block_id ON dataA (data_block_id DESC);
...

এটি সম্ভব যে একটি ডাটা_ব্লকটিতে 3x ডেটাএ, 1 এক্স ডেটাবি, তবে কোনও ডেটাসি নেই।

ডেটা কয়েক সপ্তাহের জন্য রাখা হবে, তাই আমি এই টেবিলটিতে 5 বিলিয়ন ডলার সারি রাখব। এই মুহুর্তে, আমার টেবিলে ~ 600 মিলিয়ন সারি রয়েছে এবং আমার প্রশ্নগুলি সত্যই দীর্ঘ সময় নেয়। তাই আমি সিদ্ধান্ত নিয়েছিলাম একটি সূচক তৈরি করব timestampএবংmac কারণ আমার নির্বাচিত বিবৃতিগুলি সর্বদা সময়ের সাথে এবং প্রায়শই সময় + ম্যাকের সাথেও অনুসন্ধান করে।

CREATE INDEX index_ts_mac ON data_block (timestamp DESC, mac);

... তবে আমার প্রশ্নগুলি এখনও যুগে যুগে গ্রহণ করে। উদাহরণস্বরূপ, আমি একদিন এবং একটি ম্যাকের জন্য ডেটা জিজ্ঞাসা করেছি:

SELECT * FROM data_block 
WHERE timestamp>'2014-09-15' 
AND timestamp<'2014-09-17' 
AND mac=123456789
Index Scan using index_ts_mac on data_block  (cost=0.57..957307.24 rows=315409 width=32) (actual time=39.849..334534.972 rows=285857 loops=1)
  Index Cond: ((timestamp > '2014-09-14 00:00:00'::timestamp without time zone) AND (timestamp < '2014-09-16 00:00:00'::timestamp without time zone) AND (mac = 123456789))
Total runtime: 334642.078 ms

ক্যোয়ারী চালানোর আগে আমি একটি পূর্ণ শূন্যতা করেছি। একটি কোয়েরি <10 সিসি করার জন্য বড় টেবিলগুলির সাথে এই জাতীয় সমস্যা সমাধানের জন্য কি একটি দুর্দান্ত উপায় আছে?

আমি বিভাজন সম্পর্কে পড়েছি, তবে এটি আমার ডেটাএ, ডেটাবি, ডাটাসি রেফারেন্স দিয়ে ডেটা_ব্লক_আইডি নিয়ে কাজ করবে না? যদি এটি কোনওভাবে কাজ করে তবে আমি কি সময় বা ম্যাকের সাথে পার্টিশন তৈরি করব?

আমি আমার সূচকটি অন্য দিকে বদলেছি। প্রথম ম্যাক, তারপরে টাইমস্ট্যাম্প এবং এটি প্রচুর পারফরম্যান্স লাভ করে।

CREATE INDEX index_mac_ts ON data_block (mac, timestamp DESC);

তবে এখনও, অনুসন্ধানগুলি> 30 সেকেন্ড নেয়। বিশেষত যখন আমি LEFT JOINআমার ডেটা টেবিলগুলি দিয়ে একটি করি। এখানে EXPLAIN ANALYZEনতুন সূচকের প্রশ্নগুলির একটি:

EXPLAIN ANALYZE SELECT * FROM data_block WHERE mac = 123456789 AND timestamp < '2014-10-05 00:00:00' AND timestamp > '2014-10-04 00:00:00'
Bitmap Heap Scan on data_block  (cost=1514.57..89137.07 rows=58667 width=28) (actual time=2420.842..32353.678 rows=51342 loops=1)
  Recheck Cond: ((mac = 123456789) AND (timestamp < '2014-10-05 00:00:00'::timestamp without time zone) AND (timestamp > '2014-10-04 00:00:00'::timestamp without time zone))
  ->  Bitmap Index Scan on index_mac_ts  (cost=0.00..1499.90 rows=58667 width=0) (actual time=2399.291..2399.291 rows=51342 loops=1)
        Index Cond: ((mac = 123456789) AND (timestamp < '2014-10-05 00:00:00'::timestamp without time zone) AND (timestamp > '2014-10-04 00:00:00'::timestamp without time zone))
Total runtime: 32360.620 ms 

দুর্ভাগ্যক্রমে আমার হার্ডওয়্যার কঠোরভাবে সীমাবদ্ধ। আমি একটি ইন্টেল i3-2100 @ 3.10Ghz, 4 জিবি র‌্যাম ব্যবহার করছি। আমার বর্তমান সেটিংস নিম্নলিখিত হিসাবে রয়েছে:

default_statistics_target = 100
maintenance_work_mem = 512MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 4GB
work_mem = 512MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 2GB
max_connections = 20
random_page_cost = 2

উত্তর:


1

এটি আমার এমএস এসকিউএল পক্ষপাত প্রতিবিম্বিত করতে পারে তবে আমি টেবিলটি গুচ্ছিয়ে দিয়ে দেখতে চাই timestamp । আপনি যদি নির্দিষ্ট সময়ের জন্য ঘন ঘন ডেটা টানেন তবে এটি সাহায্য করবে কারণ তথ্য শারীরিকভাবে স্বচ্ছভাবে সংরক্ষণ করা হবে। সিস্টেমটি সূচনা পয়েন্টে সন্ধান করতে পারে, সীমার শেষে স্ক্যান করতে পারে এবং হয়ে যায়। যদি আপনি একটি নির্দিষ্ট ঘন্টা জিজ্ঞাসা করেন তবে এটি কেবল 3,600,000 রেকর্ডস।

যদি আপনার ক্যোয়ারী (যা ...?) নির্দিষ্ট মেশিনের জন্য হয় তবে পোস্টগ্রিসের সেই 3.6 এম রেকর্ডগুলির 99.9% ফিল্টার করতে হবে। যদি এই ওয়ান-ইন-এ-হাজার ফিল্টারটি সাধারণ তারিখের পরিসীমা ফিটারের চেয়ে বেশি নির্বাচনী macহয় তবে আপনার সূচকের প্রথম উপাদান হিসাবে আপনাকে আরও নির্বাচনী ক্ষেত্রটি ব্যবহার করা উচিত । এটি এখনও ক্লাস্টারিংয়ের জন্য মূল্যবান হতে পারে।

যদি তা এখনও না করে, আমি একই ক্ষেত্রের দ্বারা ভাগ করে নিচ্ছি যা আপনি সূচী করছেন, হয় timestampবা হয়mac

আপনি ডেটা প্রকারটি দেন নি। তারা কি ডেটা উপযুক্ত? পাঠ্য হিসাবে তারিখগুলি সংরক্ষণ করা অযথা আপনার টেবিলটি ফুলে উঠবে, উদাহরণস্বরূপ।


2
পোস্টগ্র্রেসের ক্লাস্টার ইনডেক্স নেই (যদিও এটি একটি সূচী বরাবর একটি টেবিল ক্লাস্টার করতে পারে - তবে এটি ম্যানুয়ালি করা প্রয়োজন এবং "থাকবেন না")
a_horse_with_no_name

পরামর্শের জন্য আপনাকে ধন্যবাদ. এখন এটি আগের তুলনায় দ্রুত চলে, তবে এখনও খুব কম পারফরম্যান্সে> 30 কোয়েরি প্রতি সিকিউর। আমি ক্লাস্টারিংও করেছি, তবে @ অ_হর্স_বিহীন_নো_নাম হিসাবে বলেছেন: পোস্টগ্রয়েসে এটি একটি শট। আমার ডাটা টাইপগুলি সঠিক বলে আমি মনে করি। আমি তাদের প্রশ্নটিতে যুক্ত করেছি
manman

ক্লাস্টারযুক্ত টেবিলগুলি ছাড়াই, পরিসীমা অনুসন্ধানের জন্য আমার পরবর্তী প্রস্তাবনাটি পার্টিশন করা হবে।
সমস্ত ট্রেডের জন 14

-2

আমি এমন একটি অ্যাপ্লিকেশনটিতে কাজ করেছি যার বৈদ্যুতিক মিটার থেকে কয়েক বিলিয়ন রিডিং ছিল এবং 10 সেকেন্ডের মধ্যে বেশিরভাগ কোয়েরি কার্যকর করা হয়েছিল।

আমাদের পরিবেশ ছিল অন্যরকম। একটি সার্ভার ক্লাস মেশিনে মাইক্রোসফ্ট এসকিউএল সার্ভার (৪ টি কোর, ২৪ জিবি মেমরি)। কোনও সার্ভারে আপগ্রেড করার কোনও সুযোগ?

একটি বড় সমস্যা হ'ল একবারে পাঠাগুলি সঞ্চার করার ফলে ডাটাবেসের উপর একটি বড় পারফরম্যান্স প্রভাব পড়ে। প্রয়োজনীয় ডেটা এবং লকগুলি লেখার জন্য অপেক্ষা করা হবে। আপনি কি ব্যাচগুলিতে সন্নিবেশ করতে পারেন?

আপনার স্কিমা দিয়ে আপনার 4 টি খুব বড় টেবিল থাকবে। এটি গুরুত্বপূর্ণ হবে যে আপনার সমস্ত যোগদানকারী উভয় টেবিলের সূচকগুলি ব্যবহার করুন। একটি টেবিল স্ক্যান চিরতরে নিবে। নাল সক্ষম ক্ষেত্রগুলির সাথে তাদের 1 টি টেবিলের সাথে একীভূত করা কি সম্ভব?


ব্যাচগুলিতে সন্নিবেশ: আমি বাল্ক-সন্নিবেশগুলি করতে পারতাম তবে এই মুহুর্তে আমি একটি পরীক্ষামূলক ডাটাবেসে কাজ করছি, যেখানে কোনও অনুসন্ধান চলাকালীন কোনও সন্নিবেশ তৈরি করা হয় না। তবে আপনাকে ধন্যবাদ আমি পরে এটি সূচকগুলি সম্পর্কে ভাবব: প্রতিটি টেবিলে আমার সূচি রয়েছে। আইডি তে সূচি ডেটা টেবিলগুলিতে (ম্যাক, টাইমস্ট্যাম্প) ডাটা_ব্লক টেবিলের উপর। সমস্যাটি তখনও থাকে যখন আমি বাম-যোগে প্রতি ডেটাএর জন্য অনুসন্ধান করি তবে সেখানে কোনও হয় না। এমনকি সূচক সহ এটি ডেটা টেবিল অনুসন্ধান করে। অযোগ্য ক্ষেত্র: সম্ভব নয় কারণ একটি ডেটাব্লক এক ধরণের একাধিক ডেটা থাকতে পারে। 1xdata_ block -> 4xdataA যেমন
ম্যানম্যান

আপনার ডিবি সরঞ্জাম আপনাকে একটি কোয়েরি বিশ্লেষক দেয়? আইডি এর উপর ভিত্তি করে আপনার ডাটা_ব্লকটিতে একটি সূচক প্রয়োজন হতে পারে।
কেসি-এনএইচ

আমি চেষ্টা করব, তবে কেন এটি সাহায্য করতে পারে বুঝতে পারি না !?
ম্যানম্যান

-2

আপনি পোস্টগ্রিসের (বা অন্য কোনও আরডিবিএমএস) সহজাত স্কেলেবিলিটি সীমাতে আঘাত করছেন।

মনে রাখবেন যে একটি আরডিবিএমএস সূচক একটি বি-ট্রি is গড় এবং খারাপ উভয় ক্ষেত্রে একটি বি-ট্রি হ'ল (লগ এন)। এটি এটিকে এন এর যুক্তিসঙ্গত মানের জন্য একটি দুর্দান্ত, নিরাপদ, অনুমানযোগ্য পছন্দ করে তোলে এন খুব বড় হয়ে গেলে এটি ভেঙে যায়।

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

অতিরিক্তভাবে, একটি হ্যাশ টেবিল সমান্তরাল করা সহজ এবং একটি বি-ট্রি নয়। এটি বিতরণকৃত কম্পিউটিং আর্কিটেকচারের জন্য হ্যাশ টেবিলকে আরও উপযুক্ত করে তোলে।

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


2
বি-ট্রি ইনডেক্স (হ্যাশ, বিটম্যাপ এবং অন্যান্য) এর চেয়ে প্রচুর আরডিবিএমএসের কাছে আরও অনেক বিকল্প রয়েছে। কিছু ডিবিএমএস সারি সঞ্চয় করছে এবং কিছু কলাম সংরক্ষণ করছে। এবং ও (লগন) খারাপ নয়, এমনকি কয়েক বিলিয়ন সারিও। এবং 4 জিবি মেমরির মেশিন ব্যবহার করার সময় তারা সম্ভবত কোনও সীমা ছাড়তে পারে না।
ypercubeᵀᴹ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.