ট্রাফিকের চাপ এলে প্রথম ইচ্ছেটা হয় ডেটাবেস বড় করা, আর সেটা প্রায়ই ভুল। জানুন কীভাবে write throughput দেখে সাইজ ঠিক করবেন, PgBouncer দিয়ে কানেকশন pool করবেন, Redis বা Valkey ভূমিকা ধরে ভাগ করবেন, আর checkout ধীর না করে pgvector search চালাবেন।
Author
Anichur Rahaman
ফ্ল্যাশ সেলের সকাল ৯:০২। এই কাল্পনিক দৃশ্যে অন-কল ইঞ্জিনিয়ার dashboard-এ দেখছেন, ১,০০০টার মধ্যে ৯৪০টা database connection ব্যবহার হচ্ছে, checkout তিন সেকেন্ডের বেশি সময় নিচ্ছে। কেউ বলল, দ্বিতীয় ঢেউ আসার আগেই database-কে পরের সাইজে তুলে ফেলা হোক।
সেটা হবে আন্দাজে কাজ। ওই ৯৪০ connection-এর বেশিরভাগই idle, দুই request-এর মাঝখানে PHP process ধরে রেখেছে, আর database-এর CPU আছে ৩৫ শতাংশের কাছাকাছি। আসল লাইনটা হলো এগারোটা worker, যারা একই কয়েকটা সারিতে write-এর জন্য অপেক্ষা করছে। connection-এর সংখ্যা লক্ষণ মাত্র, আর সাইজ বাড়ানো মানে লক্ষণের চিকিৎসা।
এর আসল রূপ আমি দেখেছি। একটা platform-এ প্রায় ১,০০০ user একই মিনিটে কাজ করবে এমন নির্ধারিত চাপের প্রস্তুতি নিয়েছিলাম; সেখানে managed database (১৬ GB RAM, ৪ vCPU, প্রায় ১,০০০ connection-এর সীমা) কখনোই বাধা ছিল না। বাধা ছিল মাত্র একটা serial worker। এই লেখায় data tier নিয়ে আমি এখন যেভাবে ভাবি সেটাই বলব: কী মাপতে হবে, কীভাবে pool করতে হবে, replica কী পারে আর কী পারে না, Redis বা Valkey-কে কীভাবে পরিষ্কার দায়িত্ব দিতে হবে, আর transactional database-এ vector query না চাপিয়ে কীভাবে AI search যোগ করা যায়।
এটি "হাই-ভলিউম system-এর ইঞ্জিনিয়ারিং" সিরিজের তৃতীয় পর্ব। প্রথম পর্বে আছে edge ও web tier, দ্বিতীয় পর্বে queue ও worker। এবার আমরা এক স্তর নিচে, data-র কাছে নামছি।
"১,০০০ max connections" লেখা দেখলে বোঝা যায় কতজন ক্লায়েন্ট কানেক্ট করতে পারবে, server কতটা কাজ করতে পারবে তা বোঝা যায় না। চার vCPU একই মুহূর্তে মাত্র কয়েকটা query চালাতে পারে। বাকিরা কানেক্টেড থাকুক বা না থাকুক, অপেক্ষাই করে।
তাই রিলেশনাল database-কে আসলে যা আটকে দেয় সেগুলো মাপুন: write throughput (প্রতি সেকেন্ডে commit আর WAL-এর পরিমাণ), CPU, ডিস্কের latency আর lock-এর অপেক্ষা। connection-এর সংখ্যা শুধু অন্য সমস্যার লক্ষণ — যেমন ধীর query connection আটকে রাখছে।
আমার নিয়ম সোজা: load test প্রমাণ না করা পর্যন্ত database আপগ্রেড করবেন না। ওই সেটআপে সমাধান ছিল web আর worker node আলাদা করা এবং প্রায় ১২টা worker process চালানো। database বাড়তি চাপ অনায়াসে সামলেছে। প্রায় ২০টা worker ছাড়ালে job শুধু database write-এর লাইনে দাঁড়িয়ে থাকত — আসল সীমা ওটাই, connection নয়। এই সংখ্যাগুলো একটা নির্দিষ্ট সেটআপের, সর্বজনীন benchmark নয়; নিজের test নিজে চালান।
PHP অনেক ছোট ছোট connection খোলে: প্রতিটা request, এমনকি প্রতিটা queue job-ও কানেক্ট করে আবার ছেড়ে দেয়। PostgreSQL প্রতি connection-এর জন্য আলাদা process চালায়, তাই এক হাজার ক্লায়েন্ট কাজের একটা query চালানোর আগেই অনেক মেমরি খেয়ে ফেলতে পারে। PgBouncer-এর মতো pooler অ্যাপ্লিকেশন আর database-এর মাঝখানে বসে। শত শত ক্লায়েন্ট connection ভাগ করে ব্যবহার করে কয়েক ডজন আসল server connection।
একটা কাল্পনিক হিসাব। দুটো web node-এ প্রতিটায় ৬০টা PHP-FPM child থাকলে ১২০টা connection খুলতে পারে, ১২টা worker process যোগ করে আরও ১২, আর scheduler ও কয়েকটা admin session মিলিয়ে প্রায় ৮। মোট প্রায় ১৪০ connection, অর্থাৎ ৪ vCPU-র জন্য ১৪০টা PostgreSQL process-এর কাড়াকাড়ি। PgBouncer-কে transaction mode-এ বসিয়ে ২০টা server connection-এর pool দিলে একই ১৪০ ক্লায়েন্ট ভাগ করে নেয় ওই ২০টা। গড়ে একটা transaction যদি ৫ ms connection ধরে রাখে, ২০টা connection সর্বোচ্চ ২০ ÷ ০.০০৫ = ৪,০০০ transaction প্রতি সেকেন্ডে টানতে পারে। CPU আপনাকে এর অনেক নিচেই আটকে দেবে, আর ঠিক সেটাই লক্ষ্য: pool আসল সীমাটাকে connection-এর ওঠানামার নিচে লুকিয়ে না রেখে সামনে এনে দেয়।
PgBouncer-এর তিনটা pool mode আছে, আর কোনটা বেছে নিচ্ছেন তার ওপর নির্ভর করে app কী করতে পারবে।
| Pool mode | server connection আটকে থাকে | কোথায় সেরা | সতর্কতা |
|---|---|---|---|
| Session | ক্লায়েন্ট connection-এর পুরো সময় | দীর্ঘস্থায়ী listener, session state লাগে এমন টুল | সবচেয়ে কম সাশ্রয়; idle ক্লায়েন্টও server connection ধরে রাখে |
| Transaction | একটা transaction-এর জন্য | web request ও queue job; high volume-এ সাধারণ পছন্দ | session state-নির্ভর যেকোনো কিছু ভেঙে যায় |
| Statement | একটা statement-এর জন্য | সরল, শুধু autocommit-ভিত্তিক কাজ | একাধিক statement-এর transaction চলে না |
লোডের মুখে থাকা web app-এর জন্য transaction mode-ই সবচেয়ে বড় লাভ দেয়। তবে সুইচ করার আগে এর কয়েকটা সীমাবদ্ধতা জেনে নেওয়া ভালো।
একই ক্লায়েন্টের পরের transaction অন্য server connection-এ চলে যেতে পারে, তাই session-এ রাখা state ভরসাযোগ্য নয়:
বাস্তব সমাধান হলো দুটো connection পথ: app-এর জন্য pooled পথ, আর migration, schema টুল ও listener-এর জন্য direct পথ। pool size ও timeout-সহ সব অপশন আছে PgBouncer configuration reference-এ।
Read replica হলো primary-র একটা কপি, যেটা সামান্য দেরিতে primary-কে অনুসরণ করে। যে কাজ একটু পিছিয়ে থাকলেও চলে, সেখানে এটা চমৎকার: report, export, search listing, dashboard আর analytics query, যেগুলো না হলে checkout-এর সঙ্গে পাল্লা দিত।
তবে এটা সব ক্ষেত্রে গতি বাড়ানোর জাদু নয়। Replication lag স্বাভাবিক, আর write বেশি হলে তা বাড়ে। এগুলো primary-তেই রাখুন:
বাস্তবে এটা একটা routing নিয়ম, যা এক পাতায় লিখে ফেলা যায়।
হার্ডওয়্যার বাড়ানোর আগে খুঁজে বের করুন কোন query সবচেয়ে বেশি সময় খায়। PostgreSQL-এর pg_stat_statements এক্সটেনশন মোট সময় ধরে query-র র্যাংকিং দেয়, আর ANALYZE ও BUFFERS অপশনসহ EXPLAIN দেখায় একটা query কয়েকটা পেজ পড়ছে, না দশ লাখ।
অপচয়ের বেশিরভাগ আসে দুটো সমস্যা থেকে:
নাম নিয়ে দু-কথা। ২০২৪ সালের মার্চে Redis source-available লাইসেন্সে চলে যায়, আর Linux Foundation চালু করে Valkey — Redis 7.2.4 থেকে নেওয়া একটা fork, যেটা অনুমতিমূলক BSD লাইসেন্সেই আছে। Valkey একই protocol বোঝে, তাই নিচের সবকিছু দুটোর ক্ষেত্রেই খাটে।
সবচেয়ে সাধারণ ভুল হলো cache, session, API token আর queue একই keyspace-এ রাখা। তখন একটা flush বা একবার মেমরির চাপ সবগুলোকে নষ্ট করে। প্রতিটা ভূমিকাকে আলাদা logical database বা আলাদা instance দিন, সঙ্গে আলাদা key prefix। Cache নিরাপদে খালি করা যায়। Queue যায় না।
| ভূমিকা | হারালে কী হয় | Eviction policy | নিয়ম |
|---|---|---|---|
| Cache | কিছুক্ষণ ধীর; data আবার তৈরি হয় | allkeys-lru | সবকিছুর TTL থাকে; evict হলে সমস্যা নেই |
| Session ও API token | মানুষ logout হয়ে যায় | volatile-ttl বা volatile-lru | এমন size রাখুন যেন eviction কখনো না ঘটে |
| Queue | job হারিয়ে যায় | noeviction | কাজ চুপচাপ ফেলে দেওয়ার বদলে write সশব্দে ব্যর্থ হয়; মেমরিতে alert রাখুন |
প্রতিটা policy-র বিবরণ আছে Redis eviction ডকুমেন্টেশনে। দুটো কথা সবচেয়ে জরুরি। allkeys-lru হলে Redis মেমরির সীমা ধরে রাখতে যেকোনো key সরিয়ে দিতে পারে — cache-এর জন্য ঠিক এটাই চাই, queue-এর জন্য ঠিক এটাই চাই না। noeviction হলে server ভরে গেলে data মুছে ফেলার বদলে নতুন write ফিরিয়ে দেয়; ফলে queue ঠিক থাকে, আর আপনি জানতে পারেন error ও alert থেকে।
আপনার runbook আর app — দুই জায়গাতেই FLUSHDB ও FLUSHALL নিষিদ্ধ করুন। Cache পরিষ্কার করতে হলে prefix ধরে মুছুন। তাহলে ভুল করে, সবচেয়ে খারাপ মুহূর্তেও, cache flush কখনো queue-র job মুছতে পারবে না।
ওই একই platform-এ managed Valkey instance ছিল ১৬ GB, ব্যবহার হচ্ছিল প্রায় ৬২ MB। বাস্তব লোডে আসল মেমরির ব্যবহার দেখুন, burst-এর সময় queue-র জন্য উদার headroom রাখুন, আর সেই মাপে নামিয়ে আনুন।
আপনার স্টোর বা ERP-তে যদি AI search, recommendation বা ডকুমেন্ট খুঁজে আনা অ্যাসিস্ট্যান্ট থাকে, তাহলে আপনি embedding রাখছেন: অর্থ বোঝানো লম্বা সংখ্যার সারি। pgvector এক্সটেনশন PostgreSQL-এ vector টাইপ আর nearest-neighbour search যোগ করে, তাই শুরুতে আলাদা vector product লাগে না।
আমার ডিজাইনের নিয়ম হলো এটা চালানো আলাদা একটা PostgreSQL database-এ, নিজস্ব connection আর নিজস্ব migration পথ দিয়ে। সর্বশেষ যে সেটআপ বানিয়েছি তাতে ছিল PostgreSQL 18-এ pgvector 0.8; PostgreSQL 18 প্রকাশিত হয় ২০২৫ সালের সেপ্টেম্বরে। Vector query CPU আর মেমরিতে ভারী, আর index তৈরি আরও ভারী। আলাদা database-এ AI-র কাজ checkout-কে ধীর করতে পারে না, আর আপনি নিজের সময়সূচিতে সেটার size, backup ও আপগ্রেড ঠিক করতে পারেন।
Embedding বানানো মানে একটা model-কে ডাকা, যেটা ধীর এবং ব্যর্থ হতে পারে। কাজটা করুন database commit-এর পরে চালু হওয়া queue job দিয়ে, web request-এ নয়। Job-কে idempotent রাখুন: মূল লেখার একটা hash রাখুন এবং কিছু না বদলালে কাজ বাদ দিন; প্রতিটা সারির সঙ্গে model-এর ভার্সন রাখুন, যাতে পরে ব্যাকগ্রাউন্ডে আবার embed করা যায়। এটা দ্বিতীয় পর্বের সেই একই worker-শৃঙ্খলা।
pgvector দুই ধরনের approximate index দেয়, আর দুটোই সামান্য নির্ভুলতার বিনিময়ে অনেক গতি আনে।
| HNSW | IVFFlat | |
|---|---|---|
| গতি ও recall | সাধারণত ভালো ভারসাম্য | ভালো, কতগুলো list probe করছেন তার ওপর নির্ভর করে |
| তৈরির সময় ও মেমরি | তৈরি ধীর, মেমরি বেশি লাগে | তৈরি দ্রুত, মেমরি কম লাগে |
| আগে data লাগে কি | না, খালি table-এও শুরু করা যায় | হ্যাঁ, প্রতিনিধিত্বমূলক data লোড করার পরে বানান |
| সাধারণ ব্যবহার | বেশিরভাগ live search-এর ডিফল্ট | খুব বড়, কম বদলানো সেট, যেখানে তৈরির খরচ গুরুত্বপূর্ণ |
বেশিরভাগ কমার্স ও ERP কাজে আমি শুরু করি HNSW দিয়ে। দুটোর টিউনিং অপশন আছে pgvector প্রজেক্টের ডকুমেন্টেশনে।
বাস্তব query কখনো শুধু "এই লেখার সবচেয়ে কাছেরটা" হয় না। হয় "সবচেয়ে কাছের, stock-এ আছে, এই স্টোরের, এই ভাষার"। Approximate index-এ filter প্রয়োগ হয় index scan হয়ে যাওয়ার পরে। কোনো filter যদি ১০% সারির সঙ্গে মেলে আর hnsw.ef_search-এর ডিফল্ট ৪০ হয়, তাহলে গড়ে মাত্র চারটা মিলে-যাওয়া সারি পাবেন — দশটা চাইলেও।
২০২৪-এর শেষে প্রকাশিত pgvector 0.8.0 ঠিক এই সমস্যার জন্য iterative index scan এনেছে। Filter পেরিয়ে খুব কম সারি টিকলে scan চলতে থাকে, যতক্ষণ না যথেষ্ট সারি মেলে বা একটা সীমায় পৌঁছায়।
| Setting | কী করে |
|---|---|
| hnsw.iterative_scan | HNSW-এর জন্য iterative scan চালু করে: strict_order দূরত্বের সঠিক ক্রম রাখে, relaxed_order সামান্য অক্রম মেনে ভালো recall দেয় |
| hnsw.max_scan_tuples | iterative scan সর্বোচ্চ কতগুলো index entry দেখতে পারবে তার সীমা |
| ivfflat.iterative_scan | IVFFlat-এর জন্য একই ধারণা, relaxed ordering সহ |
| ivfflat.max_probes | iterative scan-এ সর্বোচ্চ কতগুলো list probe হবে তার সীমা |
ফাইলও state। product-এর ছবি, invoice আর export থাকবে S3-compatible object storage-এ, web node-এর ডিস্কে নয়; নইলে load balancer-এর পেছনে দুটো node চালানো যায় না।
Bucket রাখুন server-এর একই region-এ। একটা load test-এ ভিন্ন region-এর bucket প্রতিটা তৈরি-হওয়া ফাইলের upload-এ আনুমানিক ৫০ থেকে ৮০ ms যোগ করেছিল। ফাইল আগে লোকাল ডিস্কে নামানোর বদলে সরাসরি storage থেকে stream করায় একটা job-এর সর্বোচ্চ মেমরিও প্রায় ২৮৮ MB থেকে প্রায় ১২৮ MB-তে নেমেছিল।
আবার ৯:০২-এ ফিরি। Pooler transaction mode-এ থাকলে ৯৪০ ক্লায়েন্ট connection নেমে আসে ২০টা server connection-এ, আর dashboard-এ ভয়ধরানো সংখ্যাটা আর দেখা যায় না। সেলস report চলে replica-তে, cache আর queue থাকে আলাদা keyspace-এ, আর অন-কল ইঞ্জিনিয়ার জিজ্ঞেস করেন "কোনটা saturated?", "পরের সাইজ কত?" নয়। Load test আগেই উত্তর দিয়ে রেখেছে: write, আর database আছে স্বস্তিদায়ক margin-এ।
Data tier ঠিকঠাক হলেও event-এর দিন সে কী করছে তা দেখতে পাওয়া চাই। চতুর্থ পর্বে সেটাই: কাজে লাগার মতো log, metric আর trace।
আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।
About the Author
Anichur Rahaman
Continue Reading
