কয়েক মিলিয়ন সারি দিয়ে কোনও সংকীর্ণ টেবিলের উপর ক্যোয়ারীর কার্যকারিতা বাড়ানো কি সম্ভব?


14

আমার একটি ক্যোয়ারী রয়েছে যা বর্তমানে সম্পূর্ণ করতে গড়ে 2500 মিমি নিচ্ছে। আমার টেবিলটি খুব সংকীর্ণ, তবে এখানে ৪৪ মিলিয়ন সারি রয়েছে। পারফরম্যান্স উন্নত করার জন্য আমার কাছে কী বিকল্প রয়েছে, বা এটি যতটা তা পায় ততই ভাল?

প্রশ্ন

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; 

টেবিল

CREATE TABLE [dbo].[Heartbeats](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DeviceID] [int] NOT NULL,
    [IsPUp] [bit] NOT NULL,
    [IsWebUp] [bit] NOT NULL,
    [IsPingUp] [bit] NOT NULL,
    [DateEntered] [datetime] NOT NULL,
 CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

সূচক

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

অতিরিক্ত সূচিপত্র যুক্ত করতে সাহায্য করবে? যদি তা হয় তবে তাদের দেখতে কেমন হবে? বর্তমান পারফরম্যান্সটি গ্রহণযোগ্য, কারণ কোয়েরিটি কেবল মাঝে মধ্যেই চালিত হয় তবে আমি শিখার অনুশীলন হিসাবে ভাবছি, এটি দ্রুত করার জন্য আমি কি কিছু করতে পারি?

হালনাগাদ

যখন আমি একটি বলের সূচক ইঙ্গিতটি ব্যবহার করতে কোয়েরিটি পরিবর্তন করি, তখন কোয়েরি 50 মিমিতে সম্পাদিত হয়:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WITH(INDEX(CommonQueryIndex))
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 

একটি সঠিকভাবে নির্বাচনী ডিভাইসআইডিএস ধারাটি যোগ করা 50 মিমি ব্যাপ্তিতেও আঘাত করে:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' AND DeviceID = 4;

যদি আমি ORDER BY [DateEntered], [DeviceID]মূল ক্যোয়ারিতে যুক্ত করি তবে আমি 50 মিমির মধ্যে থাকি:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

এই সমস্তগুলি সূচকটি আমি ব্যবহার করছিলাম (কমনকিউয়ারআইডেক্স) তাই, আমি মনে করি আমার প্রশ্নটি এখন, এই সূচকটি এই জাতীয় প্রশ্নের জন্য ব্যবহার করতে বাধ্য করার কোনও উপায় আছে কি? বা আমার টেবিলের আকারটি অপটিমাইজারটি খুব বেশি ছুঁড়ে ফেলেছে এবং আমাকে অবশ্যই একটি ORDER BYবা একটি ইঙ্গিত ব্যবহার করতে হবে ?


আমার ধারণা আপনি "ডেটইন্টারড" -এ আরও একটি নন ক্লাস্টারড ইনডেক্স যুক্ত করতে পারবেন যা পারফরম্যান্সকে আরও কিছুটা বাড়িয়ে তুলবে
প্রবীণ

@ প্রবীণ এটি কি মূলত আমার বিদ্যমান সূচকের সমান হবে? একই মাঠে দুটি সূচক থাকবে বলে আমার কি বিশেষ কিছু করার দরকার আছে?
Nate

@ ন্যাটে, যেহেতু টেবিলটিকে হার্টবিট বলা হয় এবং সেখানে ৪৪ মিলিয়ন রেকর্ড জড়িত আমি ধরে নিই যে এই টেবিলে আপনার ভারী সন্নিবেশ রয়েছে? ইনডেক্সিংয়ের সাহায্যে আপনি গতি বাড়ানোর জন্য কেবল একটি কভারিং সূচক যুক্ত করতে পারেন। তবে আপনি যেমন উল্লেখ করেছেন যে আপনি কেবল কখনও কখনও এই ক্যোয়ারীটি ব্যবহার করেন যদি আপনি ভারী সন্নিবেশগুলি করেন তবে আমি তার বিরুদ্ধে দৃ strongly়ভাবে পরামর্শ দেব। এটি মূলত আপনার sertোকানো বোঝা দ্বিগুণ করে। আপনি কি এন্টারপ্রাইজ সংস্করণে চলছে?
এডওয়ার্ড ডর্টল্যান্ড

আমি লক্ষ্য করেছি যে আপনার এনসি ইনডেক্সে আপনার ডিভাইসআইডি রয়েছে। আপনার যেখানে এই ধারাটিতে এটি অন্তর্ভুক্ত করা সম্ভব? এবং এটি কি ফলাফলকে প্রান্তিকের নীচে নামিয়ে আনবে? <35 কে রেকর্ডস (শীর্ষস্থানীয় 1000 টি ধারা ছাড়াই)।
এডওয়ার্ড ডর্টল্যান্ড

1
শেষ প্রশ্ন, আপনি সর্বদা প্রবেশের তারিখ অনুসারে সন্নিবেশ করান? বা এগুলি বিন্যস্ত হতে পারে যেহেতু ডিভাইসগুলি একে অপর থেকে অ্যাসিঙ্ক .োকাতে পারে। আপনি ক্লাস্টারড সূচিটি ডেটএন্টারড কলামে পরিবর্তন করার চেষ্টা করতে পারেন। আপনার ক্লাস্টারড সূচকের ছুটির পৃষ্ঠাগুলি এখন 445 পৃষ্ঠাগুলি। এটি দ্বিগুণ হবে, যদি আপনি কোনও int থেকে তারিখের সময় যেতে চান। তবে এই ক্ষেত্রে, এটি খারাপ হতে পারে না।
এডওয়ার্ড ডর্টল্যান্ড

উত্তর:


13

কেন অপটিমাইজার আপনার প্রথম সূচকটির জন্য যায় না:

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

[তারিখ-তালিকাভুক্ত] কলামের নির্বাচনের বিষয়।

আপনি আমাদের জানিয়েছিলেন যে আপনার টেবিলে ৪৪ মিলিয়ন সারি রয়েছে। সারির আকারটি হ'ল:

আইডিটির জন্য 4 বাইট, ডিভাইস আইডির জন্য 4 বাইট, তারিখের জন্য 8 বাইট এবং 4 বিট কলামের জন্য 1 বাইট। এটির জন্য 17 বাইট + 7 বাইট ওভারহেড (ট্যাগস, নাল বিটম্যাপ, ভরাট অফসেট, কল গণনা) প্রতি সারিতে মোট 24 বাইট।

এটি রাউগলি 140k পৃষ্ঠায় অনুবাদ করবে। এই 44 মিলিয়ন সারি সঞ্চয় করতে।

এখন অপটিমাইজার দুটি জিনিস করতে পারে:

  1. এটি টেবিলটি স্ক্যান করতে পারে (ক্লাস্টারড ইনডেক্স স্ক্যান)
  2. অথবা এটি আপনার সূচকটি ব্যবহার করতে পারে। আপনার সূচকের প্রতিটি সারির জন্য, পরে এটি ক্লাস্টারড ইনডেক্সে বুকমার্ক লুক করা দরকার।

এখন একটি নির্দিষ্ট সময়ে আপনার অ ক্লাস্টারড ইনডেক্সে পাওয়া প্রতিটি সূচি প্রবেশের জন্য ক্লাস্টারড ইনডেক্সে এই সমস্ত একক দৃষ্টিকোণগুলি করা আরও ব্যয়বহুল হয়ে ওঠে। এর জন্য থ্রেশহোল্ডটি সাধারণত দেখার জন্য মোট গণনা মোট টেবিল পৃষ্ঠা গণনার 25% টোট 33% ছাড়িয়ে যায়।

সুতরাং এই ক্ষেত্রে: 140 কে / 25% = 35000 সারি 140 কে / 33% = 46666 সারি।

(@ আরবেরি ইয়ং, ৩৫ কে মোট সারির 0.08% এবং 46666 হ'ল 0.10%, সুতরাং আমি মনে করি সেখানেই বিভ্রান্তি ছিল)

সুতরাং যদি আপনার যেখানে ক্লজটি 35000 থেকে 46666 সারিগুলির মধ্যে কোথাও তৈরি হয় this (এটি শীর্ষ ধারাটির নীচে)

এটির পরিবর্তনের একমাত্র দুটি উপায়:

  1. আপনার যেখানে ক্লজটি আরও নির্বাচনী করুন। (যদি সম্ভব হয়)
  2. * ড্রপ করুন এবং কেবলমাত্র কয়েকটি কলাম নির্বাচন করুন যাতে আপনি একটি আচ্ছাদন সূচক ব্যবহার করতে পারেন।

এখন নিশ্চিত হয়ে নিন যে আপনি একটি সিলেক্ট * ব্যবহার করার পরেও একটি কভারিং সূচক তৈরি করতে পারেন। হোভার যা কেবলমাত্র আপনার সন্নিবেশ / আপডেট / মুছে ফেলার জন্য একটি বিশাল ওভারহেড তৈরি করে। এটি সর্বোত্তম সমাধান কিনা তা নিশ্চিত করতে আমাদের আপনার কাজের চাপ (পড়ুন বনাম লিখুন) সম্পর্কে আরও জানতে হবে।

ডেটটাইম থেকে স্মার্ট ডেটটাইমে পরিবর্তন করা ক্লাস্টারড ইনডেক্সে আকারে 16% হ্রাস এবং আপনার নন ক্লাস্টারড ইনডেক্সে আকারে 24% হ্রাস।


স্ক্যান প্রান্তিকতা সাধারণত (10% বা তার থেকেও কম) এর চেয়ে অনেক কম থাকে তবে একবছর আগে যেহেতু পরিসরটি একক দিন তাই এটি এমনকি প্রান্তিক হওয়া উচিত নয়। এবং একটি ক্লাস্টার্ড সূচক স্ক্যান দেওয়া হয় না, কারণ একটি আচ্ছাদন সূচক যুক্ত করা হয়েছিল। যেহেতু সেই সূচকটি WHERE ধারাটি সারগ-সক্ষম করে তোলে, তাই এটি পছন্দ করা উচিত।
আরবেরি ইয়ং

@ আরবেরি ইয়ং আমি ব্যাখ্যা করার চেষ্টা করছিলাম কেন [এনটেটারডেট], [ডিভাইসআইডি] এর নন ক্লাস্টার ইনডেক্স প্রথমে ব্যবহার হচ্ছে না? থ্রেশহোল্ড সম্পর্কে আমি মনে করি আমরা উভয়ই একমত, আমি কেবল পৃষ্ঠার দৃষ্টিকোণ থেকে কথা বলছি। আমি আমার উত্তরটি আরও পরিষ্কার করার জন্য পরিবর্তন করব।
এডওয়ার্ড ডোর্টল্যান্ড

আমি কী উত্তর দিচ্ছি তা আরও পরিষ্কার করার জন্য উত্তরটি পরিবর্তন করে। @RBarry Young এর প্রস্তাবিত প্রচ্ছদ সূচকটি কেন ব্যবহার করা হচ্ছে তা আমি ব্যাখ্যা করতে পারি না। আমি এটিকে এখানে মিলিয়ন সারিতে পরীক্ষা করেছি এবং এটি কভারিং সূচকটি ব্যবহার করে অপটিমাইজার।
এডওয়ার্ড ডর্টল্যান্ড

একটি বিস্তৃত প্রতিক্রিয়ার জন্য ধন্যবাদ, প্রচুর পরিমাণে উপলব্ধি করে। কাজের চাপের প্রতি শ্রদ্ধা সহ, টেবিলে প্রতি 5 মিনিটের সময়কালে 150-300 টি সন্নিবেশ থাকে এবং প্রতিবেদনের প্রয়োজনে প্রতিদিন কয়েকটি পাঠ হয়।
নট

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

8

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

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

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

তো এখন কি করা?

আমার পরামর্শ হ'ল এনসি ইনডেক্স বাদ দেওয়া, ক্লাস্টার করা পিকে পরিবর্তনহীন ও ক্লাস্টারড ইনডেক্স তৈরি করতে হবে [ডেটএন্টার্ডড]। সরল আরও ভাল, যতক্ষণ না এটি অন্যথায় প্রমাণিত হয়।


সারিগুলি ক্রমবর্ধমান ক্রমে সন্নিবেশ করানো ধরে নেওয়া এটি সহজ উত্তর - তবে অ-রৈখিক ক্রম সন্নিবেশ করায় খণ্ডন ঘটবে।
কर्क ব্রডহર્স্ট

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

4

যতক্ষণ আপনি সেখানে "*" পেয়েছেন, ততক্ষণ কেবলমাত্র আমি কল্পনা করতে পারি যে এটির চেয়ে বেশি পার্থক্য হবে তা হ'ল আপনার সূচী সংজ্ঞাটি এটিতে পরিবর্তন করা:

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)INCLUDE (ID, IsWebUp, IsPingUp, IsPUp)
 WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

আমি মন্তব্যগুলিতে যেমন উল্লেখ করেছি, এটি সেই সূচিটি ব্যবহার করা উচিত, তবে এটি যদি না হয় তবে আপনি এটি অর্ডার বা কোনও সূচক ইঙ্গিত দিয়ে রাজি করতে পারেন।


আমি এটি চেষ্টা করেছি এবং এখনও আমি একই জায়গায় রয়েছি, 2500ms সার্ভারের প্রতিক্রিয়া এবং 10 মাইল ক্লায়েন্ট প্রক্রিয়া সময়ের জন্য অপেক্ষা করে।
Nate

ক্যোয়ারী পরিকল্পনা পোস্ট করুন।
আরবেরি ইয়ং

দেখে মনে হচ্ছে এটি ক্লাস্টার্ড সূচকটি ব্যবহার করছে। (নির্বাচন খরচ: 0% <- শীর্ষ খরচ: 20% <- ক্লাস্টার ইনডেক্স স্ক্যান PK_Heartbeats খরচ: 80%)
Nate

হ্যাঁ, এটি ঠিক নয়, কিছুটা স্ট্যাটস / অপ্টিমাইজার বন্ধ করে দিচ্ছে। নতুন সূচকটি ব্যবহার করতে বাধ্য করার জন্য একটি ইঙ্গিত যুক্ত করুন।
আরবেরি ইয়ং

@ ম্যাক্স ভার্নন: সম্ভবত, তবে এটি ক্যোয়ারী প্ল্যানে ফ্ল্যাগ করা উচিত ছিল।
আরবেরি ইয়ং

3

আমি এটাকে একটু অন্যভাবে দেখতে চাই।

  • হ্যাঁ, আমি জানি এটি একটি পুরানো থ্রেড তবে আমি আগ্রহী।

আমি ডেটটাইম কলামটি ডাম্প করব - এটিকে একটি ইন্টিতে পরিবর্তন করব। আপনার সন্ধানের জন্য একটি সারণী আছে বা আপনার তারিখের জন্য রূপান্তর করুন।

ক্লাস্টার্ড সূচকটি ডাম্প করুন - এটি একটি গাদা হিসাবে ছেড়ে দিন এবং নতুন INT কলামে একটি ক্লাস্টারযুক্ত সূচক তৈরি করুন যা তারিখটি উপস্থাপন করে। অর্থাত আজ 20121015 হবে That আদেশটি গুরুত্বপূর্ণ। আপনি কত ঘন ঘন টেবিলটি লোড করেন তার উপর নির্ভর করে DESC ক্রমে সেই সূচকটি তৈরি করে দেখুন। মূল ব্যয় বেশি হবে এবং আপনি একটি ফিল ফ্যাক্টর বা বিভাজন প্রবর্তন করতে চাইবেন। বিভাজন আপনার রান সময়কে হ্রাস করতে সহায়তা করবে।

শেষ পর্যন্ত, যদি আপনি এসকিউএল 2012 ব্যবহার করতে পারেন তবে SEQUENCE ব্যবহার করে দেখুন - এটি সন্নিবেশকারীদের জন্য পরিচয় () ছাড়িয়ে যাবে।


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

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

1
আমি নিশ্চিত না কেন আমি এটি কেন আগে হারিয়েছি তবে ক্লাস্টারড ইনডেক্স এবং নন-ক্লাস্টারড ইনডেক্সেও সারি সংক্ষেপণ ব্যবহার করি। আমি কেবল আপনার টেবিলটি দিয়ে একটি দ্রুত পরীক্ষা করেছি এবং আমি যা পেয়েছি তা এখানে: উপরের সংজ্ঞায়িত সারণীতে আমি ডেটার একটি সেট তৈরি করেছি (5.8 মিলিয়ন সারি)। ক্লাস্টার্ড এবং ননক্র্লাস্টারড ইনডেক্স আমি সংকুচিত (সারি) করেছি। লজিকাল রিডস, আপনার সঠিক ক্যোয়ারির উপর ভিত্তি করে, 2,074 থেকে কমিয়ে 1,433 হয়েছে। এটি একটি উল্লেখযোগ্য হ্রাস এবং আমি আত্মবিশ্বাসী যে একা আপনাকে সাহায্য করবে - এবং এটি খুব কম ঝুঁকিপূর্ণ।
জেরেমি লোয়েল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.