PostgreSQL এবং JDBC সব রস বের করে দেয়। ভ্লাদিমির সিটনিকভ

আমি আপনাকে ভ্লাদিমির সিটনিকভের 2016 সালের প্রথম দিকের রিপোর্টের প্রতিলিপি পড়ার পরামর্শ দিচ্ছি "PostgreSQL এবং JDBC সব রস বের করে দিচ্ছে"

শুভ অপরাহ্ন আমার নাম ভ্লাদিমির সিটনিকভ। আমি 10 বছর ধরে NetCracker এর জন্য কাজ করছি। এবং আমি বেশিরভাগই উত্পাদনশীলতার মধ্যে আছি। জাভা সম্পর্কিত সবকিছু, SQL এর সাথে সম্পর্কিত সবকিছুই আমি পছন্দ করি।

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

আমরা কথা বলবো:

• ডেটা স্যাম্পলিং সম্পর্কে।
• তথ্য সংরক্ষণ সম্পর্কে.
• এবং পারফরম্যান্স সম্পর্কেও।
• এবং সেখানে পুঁতে থাকা আন্ডারওয়াটার রেক সম্পর্কে।

একটি সহজ প্রশ্ন দিয়ে শুরু করা যাক। আমরা প্রাথমিক কী-এর উপর ভিত্তি করে টেবিল থেকে একটি সারি নির্বাচন করি।

ডাটাবেস একই হোস্টে অবস্থিত। এবং এই সমস্ত চাষে 20 মিলিসেকেন্ড সময় লাগে।

এই 20 মিলিসেকেন্ড অনেক. যদি আপনার কাছে এই ধরনের 100টি অনুরোধ থাকে, তাহলে আপনি এই অনুরোধগুলির মাধ্যমে প্রতি সেকেন্ডে স্ক্রোল করার সময় ব্যয় করেন, অর্থাৎ আমরা সময় নষ্ট করছি।

আমরা এটি করতে পছন্দ করি না এবং এর জন্য বেস আমাদের কী অফার করে তা দেখুন। ডাটাবেস আমাদের কোয়েরি চালানোর জন্য দুটি বিকল্প অফার করে।

প্রথম বিকল্প একটি সহজ অনুরোধ. এটা সম্পর্কে ভাল কি? সত্য যে আমরা এটি গ্রহণ করি এবং এটি প্রেরণ করি, এবং এর বেশি কিছু না।

https://github.com/pgjdbc/pgjdbc/pull/478

ডাটাবেসের একটি উন্নত ক্যোয়ারীও রয়েছে, যা আরও জটিল, কিন্তু আরও কার্যকরী। আপনি আলাদাভাবে পার্সিং, এক্সিকিউশন, ভেরিয়েবল বাইন্ডিং ইত্যাদির জন্য অনুরোধ পাঠাতে পারেন।

সুপার এক্সটেন্ডেড ক্যোয়ারী এমন কিছু যা আমরা বর্তমান প্রতিবেদনে কভার করব না। আমরা, সম্ভবত, ডাটাবেস থেকে কিছু চাই এবং সেখানে একটি ইচ্ছা তালিকা তৈরি করা হয়েছে যা কিছু আকারে তৈরি করা হয়েছে, অর্থাত্ এটিই আমরা চাই, তবে এটি এখন এবং পরবর্তী বছরে অসম্ভব। তাই আমরা সবেমাত্র এটি রেকর্ড করেছি এবং আমরা প্রধান ব্যক্তিদের ঝাঁকুনি দিয়ে ঘুরে বেড়াব।

এবং আমরা যা করতে পারি তা হল সহজ প্রশ্ন এবং বর্ধিত প্রশ্ন।

প্রতিটি পদ্ধতির সম্পর্কে বিশেষ কি?

একটি সহজ ক্যোয়ারী এক-বারের মৃত্যুদন্ডের জন্য ভাল। একবার করা এবং ভুলে যাওয়া। এবং সমস্যা হল এটি বাইনারি ডেটা বিন্যাস সমর্থন করে না, অর্থাৎ এটি কিছু উচ্চ-পারফরম্যান্স সিস্টেমের জন্য উপযুক্ত নয়।

বর্ধিত ক্যোয়ারী - আপনাকে পার্সিংয়ের সময় বাঁচাতে দেয়। এই আমরা কি করেছি এবং ব্যবহার শুরু. এই সত্যিই, সত্যিই আমাদের সাহায্য করেছে. পার্সিং উপর শুধুমাত্র সঞ্চয় আছে. ডেটা ট্রান্সফারে সঞ্চয় রয়েছে। বাইনারি বিন্যাসে ডেটা স্থানান্তর করা অনেক বেশি কার্যকর।

চলুন অনুশীলনে এগিয়ে যাই। এটি একটি সাধারণ অ্যাপ্লিকেশন মত দেখায় কি. এটা জাভা হতে পারে, ইত্যাদি

আমরা বিবৃতি তৈরি করেছি। আদেশ কার্যকর করেছেন। কাছাকাছি তৈরি করা হয়েছে। এখানে ভুল কোথায়? সমস্যাটা কি? সমস্যা নেই. সব বইয়ে এটাই বলা আছে। এভাবেই লিখতে হবে। আপনি সর্বোচ্চ কর্মক্ষমতা চান, এই মত লিখুন.

কিন্তু অনুশীলন দেখিয়েছে যে এটি কাজ করে না। কেন? কারণ আমাদের একটা ‘ক্লোজ’ পদ্ধতি আছে। এবং যখন আমরা এটি করি, ডাটাবেসের দৃষ্টিকোণ থেকে এটি দেখা যাচ্ছে যে এটি একটি ডাটাবেসের সাথে কাজ করা একজন ধূমপানের মতো। আমরা বলেছিলাম "পার্স এক্সিকিউটি ডিএললোকেট"।

কেন এই সব বাড়তি সৃষ্টি এবং বিবৃতি আনলোড? তাদের কারো প্রয়োজন নেই। কিন্তু প্রিপেয়ারড স্টেটমেন্টে সাধারণত যা ঘটে তা হল যখন আমরা সেগুলি বন্ধ করি, তারা ডাটাবেসের সবকিছু বন্ধ করে দেয়। এই আমরা কি চাই না.

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

কিভাবে আমরা এই অর্জন করতে পারেন?

এটা খুবই সহজ - বিবৃতি বন্ধ করার প্রয়োজন নেই। আমরা এটি এভাবে লিখি: "প্রস্তুত করুন" "চালনা করুন"।

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

এটা স্পষ্ট যে এই ধরনের ত্রুটিগুলি সহজেই সংশোধন করা হয়। আমি তাদের সম্পর্কে কথা বলব না। তবে আমি বলব যে নতুন সংস্করণটি অনেক দ্রুত কাজ করে। পদ্ধতি মূঢ়, কিন্তু এখনও.

কিভাবে সঠিকভাবে কাজ করতে? এর জন্য আমাদের কি করতে হবে?

বাস্তবে, অ্যাপ্লিকেশন সবসময় বিবৃতি বন্ধ. সব বইয়ে তারা বলে বন্ধ করতে, নইলে স্মৃতি ফুটো হয়ে যাবে।

এবং পোস্টগ্রেএসকিউএল কীভাবে প্রশ্নগুলি ক্যাশে করতে হয় তা জানে না। এটি প্রয়োজনীয় যে প্রতিটি সেশন নিজের জন্য এই ক্যাশে তৈরি করে।

এবং আমরা পার্সিংয়ে সময় নষ্ট করতে চাই না।

এবং যথারীতি আমাদের কাছে দুটি বিকল্প রয়েছে।

প্রথম বিকল্পটি হ'ল আমরা এটি গ্রহণ করি এবং বলি যে আসুন PgSQL-এ সবকিছু মোড়ানো যাক। সেখানে একটি ক্যাশে আছে। এটা সবকিছু ক্যাশে. এটা মহান চালু হবে. আমরা এটা দেখেছি। আমরা 100500 অনুরোধ আছে. কাজ করে না. আমরা অনুরোধগুলিকে ম্যানুয়ালি পদ্ধতিতে পরিণত করতে রাজি নই। না না.

আমাদের কাছে দ্বিতীয় বিকল্প রয়েছে - এটি নিন এবং নিজেরাই কেটে নিন। আমরা উত্স খুলি এবং কাটা শুরু করি। আমরা দেখেছি এবং দেখেছি। দেখা গেল যে এটি করা এত কঠিন নয়।

https://github.com/pgjdbc/pgjdbc/pull/319

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

তদনুসারে, প্রতিটি এককালীন অনুরোধে ডাটাবেসের মেমরি নষ্ট না করার জন্য সার্ভার-প্রস্তুত বিবৃতিগুলি 5 তম সম্পাদনে সক্রিয় করা হয়।

আপনি জিজ্ঞাসা করতে পারেন - সংখ্যাগুলি কোথায়? আপনি কি পাচ্ছেন? এবং এখানে আমি নম্বর দেব না, কারণ প্রতিটি অনুরোধের নিজস্ব আছে।

আমাদের প্রশ্নগুলি এমন ছিল যে আমরা OLTP প্রশ্নগুলি পার্স করতে প্রায় 20 মিলিসেকেন্ড ব্যয় করেছি৷ এক্সিকিউশনের জন্য 0,5 মিলিসেকেন্ড, পার্সিংয়ের জন্য 20 মিলিসেকেন্ড ছিল। অনুরোধ - 10 KiB পাঠ্য, 170 লাইনের পরিকল্পনা। এটি একটি OLTP অনুরোধ। এটি 1, 5, 10 লাইনের অনুরোধ করে, কখনও কখনও আরও।

কিন্তু আমরা মোটেও 20 মিলিসেকেন্ড নষ্ট করতে চাইনি। আমরা এটি 0 এ কমিয়েছি। সবকিছুই দারুণ।

এখান থেকে কি নিয়ে যেতে পারবেন? আপনার যদি জাভা থাকে, তাহলে আপনি ড্রাইভারের আধুনিক সংস্করণ নিন এবং আনন্দ করুন।

আপনি যদি একটি ভিন্ন ভাষায় কথা বলেন, তাহলে চিন্তা করুন - সম্ভবত আপনার এটিরও প্রয়োজন? কারণ চূড়ান্ত ভাষার দৃষ্টিকোণ থেকে, উদাহরণস্বরূপ, যদি PL 8 বা আপনার কাছে LibPQ থাকে, তবে এটি আপনার কাছে স্পষ্ট নয় যে আপনি সম্পাদনে নয়, পার্সিংয়ের জন্য সময় ব্যয় করছেন এবং এটি পরীক্ষা করার মতো। কিভাবে? সবকিছুই বিনামূল্যে।

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

যদি অনুরোধটি গতিশীলভাবে তৈরি হয়। এটা ঘটে। কেউ স্ট্রিংগুলিকে একত্রে আঠালো করে, যার ফলে একটি SQL ক্যোয়ারী হয়।

সে খারাপ কেন? এটা খারাপ কারণ প্রতিবার আমরা একটি ভিন্ন স্ট্রিং দিয়ে শেষ করি।

এবং এই ভিন্ন স্ট্রিং এর হ্যাশকোড আবার পড়তে হবে। এটি সত্যিই একটি CPU টাস্ক - এমনকি একটি বিদ্যমান হ্যাশে একটি দীর্ঘ অনুরোধ পাঠ্য খুঁজে পাওয়া এত সহজ নয়। অতএব, উপসংহারটি সহজ - অনুরোধগুলি তৈরি করবেন না। একটি পরিবর্তনশীল তাদের সংরক্ষণ করুন. এবং আনন্দ করুন।

পরবর্তী সমস্যা। ডেটা প্রকারগুলি গুরুত্বপূর্ণ। এমন ওআরএম আছে যেগুলো বলে যে কোন ধরনের NULL আছে তাতে কিছু যায় আসে না, কিছু ধরনের হতে দিন। যদি Int, তারপর আমরা setInt বলতে. এবং যদি NULL, তাহলে এটি সর্বদা VARCHAR হতে দিন। এবং কি পার্থক্য এটা শেষ করতে কি NULL আছে? ডাটাবেস নিজেই সবকিছু বুঝতে পারবে। এবং এই ছবি কাজ করে না.

অনুশীলনে, ডাটাবেস মোটেই যত্ন করে না। আপনি যদি প্রথমবার বলেন যে এটি একটি সংখ্যা, এবং দ্বিতীয়বার আপনি বলেছেন যে এটি একটি VARCHAR, তাহলে সার্ভার-প্রস্তুত বিবৃতি পুনরায় ব্যবহার করা অসম্ভব। এবং এই ক্ষেত্রে, আমাদের বিবৃতি পুনরায় তৈরি করতে হবে।

আপনি যদি একই ক্যোয়ারী চালাচ্ছেন, নিশ্চিত করুন যে আপনার কলামের ডেটা প্রকারগুলি বিভ্রান্ত নয়৷ আপনাকে NULL এর জন্য সতর্ক থাকতে হবে। আমরা PreparedStatements ব্যবহার শুরু করার পরে এটি একটি সাধারণ ত্রুটি ছিল

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

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

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

বিন্দু হল যে আমাদের দুটি কলাম রয়েছে, যার প্রতিটি সূচীযুক্ত। একটি NULL কলামে এক মিলিয়ন সারি রয়েছে। এবং দ্বিতীয় কলামে মাত্র 20টি লাইন রয়েছে। যখন আমরা আবদ্ধ ভেরিয়েবল ছাড়াই এক্সিকিউট করি, সবকিছু ঠিকঠাক কাজ করে।

যদি আমরা বাউন্ড ভেরিয়েবল দিয়ে এক্সিকিউট করা শুরু করি, অর্থাৎ আমরা "?" অথবা "$1" আমাদের অনুরোধের জন্য, আমরা শেষ পর্যন্ত কী পাব?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

প্রথম মৃত্যুদন্ড প্রত্যাশিত হিসাবে. দ্বিতীয়টি একটু দ্রুত। কিছু ক্যাশে ছিল. তৃতীয়, চতুর্থ, পঞ্চম। তারপর ঠুং শব্দ - এবং যে মত কিছু. এবং সবচেয়ে খারাপ বিষয় হল যে এটি ষষ্ঠ মৃত্যুদণ্ডে ঘটে। কে জানত যে প্রকৃত মৃত্যুদণ্ডের পরিকল্পনা কী তা বোঝার জন্য ঠিক ছয়টি মৃত্যুদণ্ড কার্যকর করা দরকার?

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

এ ব্যাপারে আপনি কি করতে পারেন? এখানে, অবশ্যই, কিছু অনুমান করা আরও কঠিন। একটি সহজ সমাধান আছে যা আমরা ব্যবহার করি। এটি হল +0, অফসেট 0। নিশ্চয় আপনি এই ধরনের সমাধান জানেন। আমরা শুধু এটি গ্রহণ করি এবং অনুরোধে "+0" যোগ করি এবং সবকিছু ঠিক আছে। আমি পরে দেখাব.

এবং আরেকটি বিকল্প আছে - পরিকল্পনাগুলি আরও সাবধানে দেখুন। বিকাশকারীকে শুধুমাত্র একটি অনুরোধ লিখতে হবে না, 6 বার "ব্যাখ্যা বিশ্লেষণ" বলতে হবে। যদি এটি 5 হয়, এটি কাজ করবে না।

এবং একটি তৃতীয় বিকল্প আছে - pgsql-হ্যাকারদের একটি চিঠি লিখুন। আমি লিখেছিলাম, যাইহোক, এটি একটি বাগ বা বৈশিষ্ট্য কিনা তা এখনও পরিষ্কার নয়।

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

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

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

মনে হবে, কতটা সম্ভব? এখানে একটি বাগ, সেখানে একটি বাগ. আসলে, বাগ সর্বত্র আছে.

এর একটি ঘনিষ্ঠ কটাক্ষপাত করা যাক. উদাহরণস্বরূপ, আমাদের দুটি স্কিমা আছে। টেবিল S সহ স্কিম A এবং টেবিল S সহ চিত্র B। প্রশ্ন - একটি টেবিল থেকে ডেটা নির্বাচন করুন। এ ক্ষেত্রে আমাদের কী হবে? আমরা একটি ত্রুটি হবে. আমরা উপরের সব থাকবে. নিয়ম হল - একটি বাগ সর্বত্র আছে, আমাদের উপরের সবগুলো থাকবে।

এখন প্রশ্ন হল: "কেন?" মনে হবে যে ডকুমেন্টেশন আছে যে যদি আমাদের একটি স্কিমা থাকে, তাহলে একটি "সার্চ_পথ" ভেরিয়েবল আছে যা আমাদের বলে যে টেবিলটি কোথায় দেখতে হবে। এটি একটি পরিবর্তনশীল আছে বলে মনে হবে.

সমস্যাটা কি? সমস্যা হল যে সার্ভার-প্রস্তুত বিবৃতি সন্দেহ করে না যে search_path কেউ পরিবর্তন করতে পারে। এই মানটি ডাটাবেসের জন্য ধ্রুবক হিসাবে রয়ে গেছে। এবং কিছু অংশ নতুন অর্থ নাও নিতে পারে।

অবশ্যই, এটি আপনি যে সংস্করণটি পরীক্ষা করছেন তার উপর নির্ভর করে। আপনার টেবিলগুলি কতটা গুরুত্ব সহকারে আলাদা তার উপর নির্ভর করে। এবং সংস্করণ 9.1 কেবল পুরানো অনুরোধগুলি কার্যকর করবে। নতুন সংস্করণ বাগ ধরতে পারে এবং আপনাকে বলে যে আপনার একটি বাগ আছে।

অনুসন্ধান_পথ + সার্ভার-প্রস্তুত বিবৃতি = সেট করুন
ক্যাশড প্ল্যান অবশ্যই ফলাফলের ধরণ পরিবর্তন করবে না

কিভাবে এটি চিকিত্সা? একটি সহজ রেসিপি আছে - এটা করবেন না। অ্যাপ্লিকেশনটি চলাকালীন অনুসন্ধান_পথ পরিবর্তন করার দরকার নেই। আপনি যদি পরিবর্তন করেন তবে একটি নতুন সংযোগ তৈরি করা ভাল।

আপনি আলোচনা করতে পারেন, যেমন খুলুন, আলোচনা করুন, যোগ করুন। হয়তো আমরা ডাটাবেস ডেভেলপারদের বোঝাতে পারি যে যখন কেউ একটি মান পরিবর্তন করে, তখন ডাটাবেসের উচিত ক্লায়েন্টকে এই বিষয়ে বলা: “দেখুন, আপনার মান এখানে আপডেট করা হয়েছে। হতে পারে আপনাকে বিবৃতিগুলি পুনরায় সেট করতে হবে এবং সেগুলি পুনরায় তৈরি করতে হবে?" এখন ডাটাবেস গোপনে আচরণ করে এবং কোনোভাবেই রিপোর্ট করে না যে বিবৃতিগুলি ভিতরে কোথাও পরিবর্তিত হয়েছে।

এবং আমি আবার জোর দেব - এটি এমন কিছু যা জাভার জন্য সাধারণ নয়। আমরা PL/pgSQL এক থেকে এক একই জিনিস দেখতে হবে. তবে এটি সেখানে পুনরুত্পাদন করা হবে।

আসুন আরও কিছু ডেটা নির্বাচন করার চেষ্টা করি। আমরা নির্বাচন করি এবং নির্বাচন করি। আমরা একটি মিলিয়ন সারি সঙ্গে একটি টেবিল আছে. প্রতিটি লাইন একটি কিলোবাইট। আনুমানিক এক গিগাবাইট ডেটা। এবং আমাদের জাভা মেশিনে 128 মেগাবাইটের একটি ওয়ার্কিং মেমরি রয়েছে।

আমরা, সমস্ত বইতে প্রস্তাবিত হিসাবে, স্ট্রিম প্রক্রিয়াকরণ ব্যবহার করি। অর্থাৎ, আমরা ফলাফল সেট খুলি এবং সেখান থেকে ধীরে ধীরে ডেটা পড়ি। এটা কি কাজ করবে? এটা কি স্মৃতি থেকে পড়ে যাবে? একটু পড়বেন? আসুন ডাটাবেসে বিশ্বাস করি, পোস্টগ্রেসে বিশ্বাস করি। আমরা এটা বিশ্বাস করি না। আমরা কি OutOFMemory পড়ে যাবে? কে OutOfMemory অভিজ্ঞ? কে এর পরে এটি ঠিক করতে পরিচালিত? কেউ এটা ঠিক করতে পরিচালিত.

আপনার যদি এক মিলিয়ন সারি থাকে তবে আপনি কেবল বাছাই এবং চয়ন করতে পারবেন না। অফসেট/সীমা প্রয়োজন। এই বিকল্পের জন্য কে? আর অটোকমিট নিয়ে খেলার পক্ষে কে?

এখানে, যথারীতি, সবচেয়ে অপ্রত্যাশিত বিকল্পটি সঠিক হতে দেখা যায়। এবং আপনি যদি হঠাৎ অটোকমিট বন্ধ করেন তবে এটি সাহায্য করবে। কেন এমন হল? বিজ্ঞান এ সম্পর্কে জানে না।

কিন্তু ডিফল্টরূপে, পোস্টগ্রেস ডাটাবেসের সাথে সংযোগকারী সমস্ত ক্লায়েন্ট সম্পূর্ণ ডেটা নিয়ে আসে। PgJDBC এই বিষয়ে কোন ব্যতিক্রম নয়; এটি সমস্ত সারি নির্বাচন করে।

FetchSize থিমে একটি ভিন্নতা রয়েছে, যেমন আপনি একটি পৃথক বিবৃতিতে বলতে পারেন যে এখানে, অনুগ্রহ করে 10, 50 এর মধ্যে ডেটা নির্বাচন করুন৷ কিন্তু আপনি অটোকমিট বন্ধ না করা পর্যন্ত এটি কাজ করবে না৷ অটোকমিট বন্ধ - এটি কাজ শুরু করে।

কিন্তু কোডের মধ্য দিয়ে যাওয়া এবং সেটফেচ সাইজ সব জায়গায় সেট করা অসুবিধাজনক। অতএব, আমরা একটি সেটিং তৈরি করেছি যা পুরো সংযোগের জন্য ডিফল্ট মান বলবে।

সেটাই আমরা বলেছি। পরামিতি কনফিগার করা হয়েছে. আর আমরা কি পেলাম? যদি আমরা অল্প পরিমাণ নির্বাচন করি, যদি, উদাহরণস্বরূপ, আমরা একবারে 10টি সারি নির্বাচন করি, তাহলে আমাদের ওভারহেড খরচ অনেক বেশি। অতএব, এই মান প্রায় একশ সেট করা উচিত।

আদর্শভাবে, অবশ্যই, আপনাকে এখনও এটিকে বাইটে সীমাবদ্ধ করতে শিখতে হবে, তবে রেসিপিটি হল: ডিফল্টরোফেচ সাইজ একশোর বেশি সেট করুন এবং খুশি হন।

এর তথ্য সন্নিবেশ করা যাক. সন্নিবেশ সহজ, বিভিন্ন বিকল্প আছে. উদাহরণস্বরূপ, INSERT, VALUES. এটি একটি ভাল বিকল্প। আপনি "ইনসার্ট সিলেক্ট" বলতে পারেন। অনুশীলনে এটি একই জিনিস। পারফরম্যান্সে কোনো পার্থক্য নেই।

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

আপনি যদি এটি পরিমাপ করেন তবে আপনি আবার কিছু আকর্ষণীয় আবিষ্কার করতে পারেন। আমরা কিভাবে এই কাজ করতে চান? আমরা পার্স না করতে চাই এবং অপ্রয়োজনীয় কমান্ড চালাতে চাই না।

অনুশীলনে, TCP আমাদের এটি করতে দেয় না। যদি ক্লায়েন্ট একটি অনুরোধ পাঠাতে ব্যস্ত থাকে, তাহলে ডাটাবেস আমাদের প্রতিক্রিয়া পাঠানোর প্রচেষ্টায় অনুরোধগুলি পড়ে না। শেষ ফলাফল হল ক্লায়েন্ট অনুরোধটি পড়ার জন্য ডাটাবেসের জন্য অপেক্ষা করে এবং ডাটাবেস ক্লায়েন্টের প্রতিক্রিয়া পড়ার জন্য অপেক্ষা করে।

এবং সেইজন্য ক্লায়েন্টকে পর্যায়ক্রমে একটি সিঙ্ক্রোনাইজেশন প্যাকেট পাঠাতে বাধ্য করা হয়। অতিরিক্ত নেটওয়ার্ক মিথস্ক্রিয়া, সময়ের অতিরিক্ত অপচয়।

এবং যত বেশি আমরা এগুলি যোগ করি, এটি তত খারাপ হয়। ড্রাইভার বেশ হতাশাবাদী এবং সেগুলি প্রায়শই যোগ করে, প্রায় 200 লাইনে একবার, লাইনের আকার ইত্যাদির উপর নির্ভর করে।

https://github.com/pgjdbc/pgjdbc/pull/380

এটি ঘটে যে আপনি শুধুমাত্র একটি লাইন সংশোধন করেন এবং সবকিছু 10 বার গতি বাড়াবে। এটা ঘটে। কেন? যথারীতি, এর মতো একটি ধ্রুবক ইতিমধ্যে কোথাও ব্যবহার করা হয়েছে। এবং মান "128" এর মানে ব্যাচিং ব্যবহার করা নয়।

জাভা মাইক্রোবেঞ্চমার্ক জোতা

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

এর এটা চেষ্টা করা যাক. আমরা InsertBatch সহজ পরিমাপ করি। আমরা InsertBatch একাধিকবার পরিমাপ করি, অর্থাৎ একই জিনিস, কিন্তু অনেক মান আছে। কৌশলী পদক্ষেপ। সবাই এটি করতে পারে না, তবে এটি একটি সহজ পদক্ষেপ, কপি করার চেয়ে অনেক সহজ।

আপনি কপি করতে পারেন।

এবং আপনি কাঠামোতে এটি করতে পারেন। ব্যবহারকারীর ডিফল্ট প্রকার ঘোষণা করুন, অ্যারে পাস করুন এবং সরাসরি টেবিলে ঢোকান।

আপনি যদি লিঙ্কটি খুলেন: pgjdbc/ubenchmsrk/InsertBatch.java, তাহলে এই কোডটি GitHub-এ রয়েছে। আপনি সেখানে বিশেষভাবে কি অনুরোধ তৈরি করা হয় তা দেখতে পারেন। এটা কোন ব্যাপার না.

আমরা চালু করেছি। এবং প্রথম জিনিসটি আমরা বুঝতে পেরেছিলাম যে ব্যাচ ব্যবহার না করা কেবল অসম্ভব। সমস্ত ব্যাচিং বিকল্পগুলি শূন্য, অর্থাত্ এক-কালীন সম্পাদনের তুলনায় কার্যকর করার সময় কার্যত শূন্য৷

আমরা তথ্য সন্নিবেশ. এটি একটি খুব সহজ টেবিল. তিনটি কলাম। এবং আমরা এখানে কি দেখতে পারি? আমরা দেখতে পাই যে এই তিনটি বিকল্পই মোটামুটি তুলনীয়। এবং কপি, অবশ্যই, ভাল.

এই যখন আমরা টুকরা সন্নিবেশ. যখন আমরা বলেছিলাম যে একটি VALUES মান, দুটি VALUES মান, তিনটি VALUES মান, অথবা আমরা তাদের মধ্যে 10 টি একটি কমা দ্বারা পৃথক করা নির্দেশ করেছি৷ এই এখন শুধু অনুভূমিক. 1, 2, 4, 128. এটা দেখা যায় যে ব্যাচ ইনসার্ট, যা নীল রঙে আঁকা হয়েছে, তাকে অনেক ভালো বোধ করে। অর্থাৎ, আপনি যখন একবারে একটি ঢোকান বা এমনকি যখন আপনি একবারে চারটি সন্নিবেশ করেন, তখন এটি দ্বিগুণ ভাল হয়ে যায়, কেবল কারণ আমরা VALUES-এ একটু বেশি ঢোকাই। কম EXECUTE অপারেশন।

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

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

পরবর্তিতে আমরা কি করবো? আমরা এটি চেষ্টা করেছিলাম। আমরা বুঝতে পারি যে আমাদের হয় কাঠামো বা একটি চতুর ব্যাকথ ব্যবহার করতে হবে যা বিভিন্ন অর্থকে একত্রিত করে।

আজকের প্রতিবেদন থেকে আপনার কী নেওয়া উচিত?

• PreparedStatement আমাদের সবকিছু. এটি উত্পাদনশীলতার জন্য অনেক কিছু দেয়। এটি মলম একটি বড় ফ্লপ উত্পাদন.
• এবং আপনাকে 6 বার EXPLAIN ANALYZE করতে হবে।
• এবং আমাদের সমস্যাযুক্ত প্রশ্নের অবশিষ্ট শতাংশ সংশোধন করার জন্য আমাদের অফসেট 0 এবং +0 এর মতো কৌশলগুলিকে পাতলা করতে হবে।

উত্স: www.habr.com