আপনার অ্যাপ্লিকেশনটিতে বর্গ বনাম গণনা সম্পাদনের পক্ষে কি কি?


154

shopkeeper টেবিলের নিম্নলিখিত ক্ষেত্র রয়েছে:

id (bigint),amount (numeric(19,2)),createddate (timestamp)

ধরা যাক, আমার উপরের টেবিলটি আছে। আমি গতকালের জন্য রেকর্ড পেতে এবং সেন্টে মুদ্রিত পরিমাণটি রেখে একটি প্রতিবেদন তৈরি করতে চাই।

করার এক উপায় হ'ল আমার জাভা অ্যাপ্লিকেশনে গণনা সম্পাদন করা এবং একটি সাধারণ ক্যোয়ারী চালানো

Date previousDate ;// $1 calculate in application

Date todayDate;// $2 calculate in application

select amount where createddate between $1 and $2 

এবং তারপরে রেকর্ডগুলির মধ্য দিয়ে লুপ করুন এবং আমার জাভা অ্যাপ্লিকেশনে সেন্টগুলিতে পরিমাণ রূপান্তর করুন এবং প্রতিবেদন তৈরি করুন

অন্য উপায়টি স্কেল ক্যোয়ারিতে নিজেই গণনা সম্পাদনের মতো:

select cast(amount * 100 as int) as "Cents"
from shopkeeper  where createddate  between date_trunc('day', now()) - interval '1 day'  and  date_trunc('day', now())

এবং তারপরে রেকর্ডগুলি লুপ করে প্রতিবেদন তৈরি করুন gene

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

উপরের ব্যবহারের ক্ষেত্রে কেবল উদাহরণ, একটি বাস্তব দৃশ্যে একটি টেবিলের অনেকগুলি কলাম থাকতে পারে যার জন্য একই ধরণের প্রক্রিয়াজাতকরণ প্রয়োজন।

পারফরম্যান্স এবং অন্যান্য দিকগুলির ক্ষেত্রে কোন পদ্ধতির ভাল এবং আপনি কেন দয়া করে আমাকে বলতে পারেন?


2
তারিখ গণনাগুলি তেমন কোনও প্রভাব ফেলবে না - ধরে নেওয়া আপনার এসকিএল ইঞ্জিন প্রকৃতপক্ষে কেবল একবার আপনার তারিখ গণনা করবে। আপনার অ্যাপ্লিকেশন এ সেগুলি সংজ্ঞায়িত করা নিখুঁত ধারণা তৈরি করে, যেহেতু সেগুলি যে কোনও উপায়ে সেখানে সংজ্ঞায়িত করা হবে, তা প্রতিবেদনের শিরোনাম বা অন্য বিষয়গুলির জন্য হোক। এক্ষেত্রে মানকে ১০০ দিয়ে গুণ করা যে কোনও স্তরের উপর করা যেতে পারে, যেহেতু আপনি যে কোনওভাবেই এই সারিগুলি রেন্ডারিংয়ের জন্য লুপিং করে যাবেন এবং * 100 সামনের দিকের প্রান্ত ব্যতীত কোনও স্তরের ধীরে ধীরে কম হওয়ার সম্ভাবনা নেই। উভয় ক্ষেত্রেই আপনার গণনাগুলি পার্শ্ববর্তী অপারেশনগুলির দ্বারা ন্যূনতম এবং বামনযুক্ত, কোনও পারফরম্যান্স উদ্বেগ নয়।
মর্গ

উত্তর:


206

এটি অনেকগুলি বিষয়ের উপর নির্ভর করে - তবে সবচেয়ে গুরুত্বপূর্ণ:

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

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

আপনার নোট পুনরায়:

এবং তারপরে রেকর্ডগুলির মধ্য দিয়ে লুপ করুন

রেকর্ডগুলির মাধ্যমে লুপিং প্রায়শই বেকায়দায় করা ভুল জিনিস - একটি সেট-ভিত্তিক ক্রিয়াকলাপ লেখার পক্ষে পছন্দ করা হয়।

একটি সাধারণ নিয়ম হিসাবে , আমি ডাটাবেসের কাজকে সর্বনিম্ন "এই ডেটা সঞ্চয় করে রাখুন, এই ডেটাটি আনুন" - তে রাখা পছন্দ করি - তবে সর্বদা এমন পরিস্থিতিতে রয়েছে যেখানে সার্ভারে একটি মার্জিত ক্যোয়ারী প্রচুর পরিমাণে ব্যান্ডউইথকে বাঁচাতে পারে scen

এছাড়াও বিবেচনা করুন: যদি এটি গণনামূলকভাবে ব্যয়বহুল হয় তবে এটি কোথাও ক্যাশে করা যায়?

আপনি যদি একটি সঠিক " চান যা ভাল" চান; এটিকে উভয় উপায়ে কোড করুন এবং এটি তুলনা করুন (উল্লেখযোগ্য যে কোনও একটির প্রথম খসড়া সম্ভবত 100% টিযুক্ত নয়)। তবে এর সাধারণ ব্যবহারের ফ্যাক্টর: যদি বাস্তবে, এটি একবারে 5 বার (পৃথকভাবে) বলা হয়ে থাকে, তবে অনুকরণ করুন: এইগুলির মধ্যে 1 বনাম 1 এর সাথে কেবল একটিও তুলনা করবেন না।


লুপিং কম-বেশি "সারি-সময়ে-সময়ে" প্রক্রিয়াকরণকে জড়িত। এবং এর অর্থ 2 * নেটওয়ার্কের বিলম্বিতা এবং চারটি প্রসঙ্গটি রাউন্ড ট্রিপকে স্যুইচ করে। হ্যাঁ: এটি ব্যয়বহুল। একটি "নেটিভ" ডিবিএমএস অপারেশন ডিস্ক-আই / ও এর (সিস্টেম কল) হ্রাস করতে সমস্ত কঠোর পরিশ্রম করে তবে সিস্টেম কল প্রতি একাধিক সারি বেশি আনতে পরিচালিত হয়। সারি একবারে কমপক্ষে চারটি সিস্টেম কল নেয় ।
ওয়াইল্ডপ্লাজার

@ উইল্ডপ্লাজার প্রয়োজন নেই; সার্ভারটি সারিগুলি প্রবাহিত করতে পারে যা তারা আসার সাথে সাথে গ্রাস করে - একটি "পাঠক" রূপকটি অস্বাভাবিক নয়।
মার্ক Gravell

1
@ মার্ক ক্যাভেল: আচ্ছা, এটি নির্ভর করে। যে ক্ষেত্রে কোনও অ্যাপ্লিকেশন প্রোগ্রামের পায়ের ছাপ শুধুমাত্র একটি লজিকাল রেকর্ড, এটি কম-বেশি ঠিক আছে। তবে আমি জানি যে "ফ্রেমওয়ার্কগুলি" বেশিরভাগই প্রারম্ভকালে সমস্ত রেকর্ড স্তন্যপান করে এবং একে একে একে জ্বালিয়ে দেয়। লক করা আরেকটি সমস্যা।
ওয়াইল্ডপ্লাজার

আমি মনে করি যে থাম্বের একটি ভাল নিয়ম হ'ল: এসকিউএল সার্ভারের সারিগুলি থেকে ডেটা ফিরিয়ে আনবেন না যা আপনার চূড়ান্তভাবে প্রয়োজন হয় না। উদাহরণস্বরূপ, আপনার যদি সামগ্রিক ক্রিয়াকলাপ করতে হয় তবে তারা সম্ভবত এসকিউএলে অন্তর্ভুক্ত। টেবিল বা subquery মধ্যে যোগ দেয়? এসকিউএল। আমরা ব্যাজগুলির সাথেও এটি ব্যবহার করি এবং এ পর্যন্ত আমরা স্কেল সহ মোকাবেলা করছি :-)
Sklivvz

1
@ জিংকিং এটি একটি সেট-ভিত্তিক অপারেশন হবে। সেই পরিস্থিতিতে আপনি লুপ কোডটি লিখবেন না - এটি একটি বাস্তবায়ন বিশদ। একটি "লুপিং" আমি স্পষ্ট লুপ বলতে চাচ্ছি, উদাহরণস্বরূপ দ্বারা কার্সার
মার্ক Gravell

86

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

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

সবচেয়ে খারাপ পরিস্থিতিটি হ'ল বৃহত্তর সেটের প্রতিটি একক সারির জন্য বারবার সার্ভারে যেতে হবে। (এটি একবারে এক টন আকরিক পাঠানোর মতো হবে))

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

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

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


12
অন্যান্য বিকাশকারীদের সাথে অর্থপূর্ণভাবে নকশার সিদ্ধান্ত নেওয়ার জন্য আমি এই সাদৃশ্যটি ব্যবহার সম্পর্কে সতর্ক থাকব। অ্যানালগিগুলি যৌক্তিকের চেয়ে অনেকগুলি বক্তৃতাযুক্ত ডিভাইস। অন্যান্য কারণগুলির মধ্যে একটি স্বর্ণকারকে সোনার আকরিক পাঠানোর চেয়ে কোনও অ্যাপ সার্ভারে ডেটা প্রেরণ করা অনেক সস্তা che
ডগ 18

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

1
ঠিক আমি যা সম্মত তা আমি মনে করি না এসকিউএল @ আ_হর্স_উইথ_নো_নামে লুপ ভিত্তিক গণনা করা সবসময় খারাপ কাজ বলে মনে হয় না, এরউইনের রূপক হিসাবে নির্দেশিত তথ্যের সাহায্যে ডেটা আনার সময় আমি বরং এটি গণনা করব। অথবা ডেটা ফেরত এলে আপনাকে ব্যয় করে এটি পুনরাবৃত্তি করতে হবে।
zinking

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

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

18

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

সাধারণত সারি স্তরের গণনার জন্য খুব বেশি পার্থক্য নেই।

যেখানে এটি কোনও পার্থক্য করে:

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

12

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

  • জটিল গণনা
  • ডেটা-নিবিড় গণনা

এসকিউএল এর শক্তি এবং এক্সপ্রিভিটি ভারীভাবে হ্রাস করা হয়। উইন্ডো ফাংশনগুলির সূচনা হওয়ার পরে , অ-কঠোরভাবে সেট-ভিত্তিক গণনাগুলি খুব সহজে এবং মার্জিতভাবে ডাটাবেসে সম্পাদন করা যায়।

সামগ্রিক প্রয়োগের আর্কিটেকচার নির্বিশেষে সর্বদা থাম্বের তিনটি নিয়ম অনুসরণ করা উচিত:

  • ডাটাবেস এবং অ্যাপ্লিকেশন স্লিমের মধ্যে স্থানান্তরিত তথ্যের পরিমাণ রাখুন (ডিবিতে স্টাফ গণনা করার পক্ষে)
  • ডাটাবেস দ্বারা ডিস্ক থেকে লোড হওয়া ডেটার পরিমাণ স্লিম রাখুন (অপ্রয়োজনীয় ডেটা অ্যাক্সেস এড়ানোর জন্য ডাটাবেসটিকে স্টেটমেন্ট অনুকূলিতকরণের পক্ষে)
  • জটিল, সমবর্তী গণনাগুলির সাথে ডেটাবেসটিকে তার সিপিইউ সীমাতে ঠেলে দেবেন না (অ্যাপ্লিকেশন স্মৃতিতে ডেটা টানানোর পক্ষে এবং সেখানে গণনা সম্পাদনের পক্ষে)

আমার অভিজ্ঞতার সাথে আপনার শালীন ডাটাবেস সম্পর্কে শালীন ডিবিএ এবং কিছু জ্ঞানসম্পন্ন জ্ঞানের সাথে আপনি খুব শীঘ্রই আপনার ডিবিএস সিপিইউ সীমাতে চলে যাবেন না।

আরও কিছু পড়তে যেখানে এই বিষয়গুলি ব্যাখ্যা করা হয়েছে:


2

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

কিছু ক্ষেত্রে এটি প্রয়োগ হয় না তবে এটি যখন তা বোঝায় তখন। এছাড়াও সাধারণভাবে ডিবি বক্সে সেরা হার্ডওয়্যার এবং পারফরম্যান্স রয়েছে।


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

1

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

আসুন দুটি পদক্ষেপে এটি সম্পর্কে ভাবা যাক: (1) ওয়ালটিপি (রেকর্ডের অল্প সংখ্যক) লেনদেন। (২) ওএলএপি (বহু রেকর্ডের দীর্ঘ স্ক্যান)।

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

রি: অনুভূমিক স্কেলিং আধুনিক ডাটাবেসগুলি অনুভূমিকভাবে স্কেল করে। এই সিস্টেমগুলি ইতিমধ্যে HA এবং ফল্ট সহনশীলতা প্রয়োগ করে। এটি লাভ করুন এবং আপনার অ্যাপ্লিকেশন স্থানটিকে সহজ করার চেষ্টা করুন।

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


0

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

  1. আপনি যদি ডাটাবেস এসকিএল এর মাধ্যমে সোজা কিছু অর্জন করতে পারেন তবে ডিবি আরও ভাল সঞ্চালন করবে এবং সেখানে গণনা করবে এবং তারপরে ফলাফল আনতে হবে। তবে যদি প্রকৃত গণনার জন্য এখানে এবং সেখান থেকে স্টাফ খুব বেশি গণনার প্রয়োজন হয় তবে আপনি অ্যাপ্লিকেশন কোডটি দিয়ে যেতে পারেন। কেন? কারণ বেশিরভাগ ক্ষেত্রে দৃশ্যের মতো লুপিংটি বর্গক্ষেত্র দ্বারা সর্বোত্তমভাবে পরিচালিত হয় না যেখানে এই বিষয়গুলির জন্য সামনের প্রান্তের ভাষাগুলি আরও ভালভাবে ডিজাইন করা হয়েছে।
  2. যদি একই জায়গার অনেকগুলি স্থান থেকে প্রয়োজনীয় হয় তবে অবশ্যই গণনার কোডটি ডিবি প্রান্তে স্থাপন করা একই জিনিসগুলিকে একই জায়গায় রাখা ভাল to
  3. যদি বিভিন্ন প্রশ্নের মাধ্যমে চূড়ান্ত ফলাফল অর্জনের জন্য প্রচুর গণনা করতে হয় তবে ডিবি শেষের দিকেও যেতে পারেন কারণ আপনি ব্যাকএন্ড থেকে ফলাফল প্রাপ্তির চেয়ে আরও ভাল সম্পাদন করার জন্য একই কোডটি একটি সঞ্চিত পদ্ধতিতে রাখতে পারেন এবং তারপরে সামনের দিকে তাদের গণনা করতে পারেন শেষ.

কোডটি কোথায় রাখবেন তা সিদ্ধান্ত নেওয়ার আগে আপনি আরও অনেকগুলি বিষয় চিন্তা করতে পারেন। একটি উপলব্ধি সম্পূর্ণ ভুল - জাভা (অ্যাপ কোড) এবং / অথবা সমস্ত কিছু ডিবি (স্কুয়েল কোড) দ্বারা করা ভাল best


0

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

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


0

গুরুতরভাবে, "পারফরম্যান্স" সংজ্ঞায়িত হয়নি।

আমার কাছে যে বিষয়টি সবচেয়ে বেশি গুরুত্বপূর্ণ তা হ'ল ডেভেলপার সময়।

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


0

আমি বিশ্বাস করি না যে পারফরম্যান্সের পার্থক্যগুলি নির্দিষ্ট উদাহরণ এবং মানদণ্ড ছাড়াই যুক্তিযুক্ত হতে পারে তবে আমার আরও একটি গ্রহণযোগ্যতা রয়েছে:

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

আপনার যদি একটি সঠিক মাঝারি স্তর থাকে (প্রদত্ত উদাহরণ থেকে মনে হয়, এটি তেমনটি নয়) তবে সেই স্তরটি পরিবর্তিত হতে পারে এবং জেবস রুবি / রেলস হতে পারে।

অন্যদিকে, এটি এসকিউএল-ব্যাকএন্ডকে এমন কিছু দিয়ে প্রতিস্থাপন করবে যেটি এসকিউএলের সাথে সম্পর্কিত ডিবি নয় এবং এমনকি যদি আপনি তা করেন তবে আপনাকে প্রথম দিকের প্রান্তটি যাইহোক স্ক্র্যাচ থেকে পুনরায় লিখতে হবে, সুতরাং পয়েন্টটি মোটা হবে।

আমার ধারণা হ'ল আপনি যদি ডিবিতে গণনা করেন তবে দ্বিতীয় ফ্রন্ট-এন্ড বা মাঝারি স্তরটি পরে লেখা আরও সহজ হবে, কারণ আপনাকে সমস্ত কিছু পুনরায় প্রয়োগ করতে হবে না। তবে বাস্তবে আমি মনে করি "লোকেদের বুঝতে হবে এমন কোড দিয়ে আমি এটি কোথায় করতে পারি" সর্বাধিক গুরুত্বপূর্ণ বিষয়।


আপনি যদি jboss থেকে রুবিতে পরিবর্তন করেন তবে খুব সম্ভবত আপনি ডিবি পরিবর্তন করবেন (এবং আপনাকে যেভাবেই এই গণনাগুলি গ্রহণ করতে হবে) এবং নোসকিএলের মতো আপনি আরও আলাদা কিছুতে পরিবর্তন আনতে পারবেন এমন সম্ভাবনা কম নয়।
ডেইনিয়াস

0

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

এছাড়াও বেশিরভাগ আর্কিটেকচারে এটি এসকিউএল সার্ভার (গুলি) যা সিস্টেমের বাইরের সিস্টেম এবং বাইরের সিস্টেমে যুক্ত হয় make

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


0

এই প্রশ্নের অন্যান্য উত্তর আকর্ষণীয়। আশ্চর্যের বিষয়, আপনার প্রশ্নের উত্তর কেউ দেয়নি। আপনি ভাবছেন:

  1. ক্যোয়ারীতে সেন্টগুলিতে কাস্ট করা ভাল? আমি মনে করি না কন্টেন্টে কাস্ট আপনার ক্যোয়ারীতে কিছু যোগ করেছে।
  2. কোয়েরিতে এখন () ব্যবহার করা কি ভাল? আমি ক্যোয়ারিতে তারিখগুলি ক্যোয়ারীতে গণনা করার পরিবর্তে পাস করতে পছন্দ করব।

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

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


0

এই প্রশ্নটির সমাধান করার জন্য আসল উদাহরণটি ধরুন take

আমার আমার ওএলসি ডেটাতে ওজনযুক্ত চলমান গড় গণনা করা দরকার, আমার কাছে প্রায় 134000 মোমবাতি রয়েছে যার জন্য প্রতিটি প্রতীক রয়েছে

  1. বিকল্প 1 পাইথন / নোড ইত্যাদিতে এটি করুন
  2. বিকল্প 2 এসকিউএল নিজেই এটি করুন!

কোনটা ভালো?

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

আবশ্যকতা

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

আপনাকে কিছুটা উত্সাহ দেওয়ার জন্য, ওয়েট মুভিং এভারেজ করতে এটি পাইথন সংস্করণ

ডাব্লুএমএ কোডের মাধ্যমে সম্পন্ন

import psycopg2
import psycopg2.extras
from talib import func
import timeit
import numpy as np
with psycopg2.connect('dbname=xyz user=xyz') as conn:
with conn.cursor() as cur:
t0 = timeit.default_timer()
cur.execute('select distinct symbol from ohlc_900 order by symbol')
for symbol in cur.fetchall():
cur.execute('select c from ohlc_900 where symbol = %s order by ts', symbol)
ohlc = np.array(cur.fetchall(), dtype = ([('c', 'f8')]))
wma = func.WMA(ohlc['c'], 10)
# print(*symbol, wma[-1])
print(timeit.default_timer() - t0)
conn.close()

এসকিউএল মাধ্যমে ডাব্লুএমএ

"""
if the period is 10
then we need 9 previous candles or 15 x 9 = 135 mins on the interval department
we also need to start counting at row number - (count in that group - 10)
For example if AAPL had 134 coins and current row number was 125
weight at that row will be weight = 125 - (134 - 10) = 1
10 period WMA calculations
Row no Weight c
125 1
126 2
127 3
128 4
129 5
130 6
131 7
132 8
133 9
134 10
"""
query2 = """
WITH
condition(sym, maxts, cnt) as (
select symbol, max(ts), count(symbol) from ohlc_900 group by symbol
),
cte as (
select symbol, ts,
case when cnt >= 10 and ts >= maxts - interval '135 mins'
then (row_number() over (partition by symbol order by ts) - (cnt - 10)) * c
else null
end as weighted_close
from ohlc_900
INNER JOIN condition
ON symbol = sym
WINDOW
w as (partition by symbol order by ts rows between 9 preceding and current row)
)
select symbol, sum(weighted_close)/55 as wma
from cte
WHERE weighted_close is NOT NULL
GROUP by symbol ORDER BY symbol
"""
with psycopg2.connect('dbname=xyz user=xyz') as conn:
with conn.cursor() as cur:
t0 = timeit.default_timer()
cur.execute(query2)
# for i in cur.fetchall():
# print(*i)
print(timeit.default_timer() - t0)
conn.close()

বিশ্বাস করুন বা না করুন, ক্যোয়ারী ওয়েট মুভিং অ্যাভারেজ করার খাঁটি পাইথন সংস্করণের চেয়ে দ্রুত চলে runs আমি এই ক্যোয়ারীটি লেখার জন্য ধাপে ধাপে গিয়েছিলাম তাই সেখানে থাকুন এবং আপনি ঠিকঠাক করবেন

গতি

0.42141127300055814 সেকেন্ড পাইথন

0.23801879299935536 সেকেন্ড এসকিউএল

আমার ডাটাবেসে আমার 134000 জাল ওএইচএলসি রেকর্ড রয়েছে যাতে এটি 1000 স্টকের মধ্যে বিভক্ত যাতে এসকিউএল যেখানে আপনার অ্যাপ্লিকেশন সার্ভারকে ছাড়িয়ে যায় তার উদাহরণ


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