🧑‍💻 धडा 17 — Code मधून database

📍 तुम्ही इथे आहात: 18 पैकी धडा 17 · मागील: lesson-16-replication-failover · पुढील: lesson-18-oltp-olap

भाग 3 — अधिक खोलात. धडे 01–12 नी रेकॉर्ड रूम बांधली आणि चालवली. धडे 13–18 हे interviews आणि incidents मध्ये विचारले जाणारे विषय आहेत — प्रत्येक त्याच school.db वर प्रत्यक्ष चालतो.

📦 या ब्रँचमध्ये काय आहे

धडे 01–17, आणि db/demo.py मधले appcode(): 2,000 inserts एकेक करून commit विरुद्ध एकाच transaction मध्ये, आणि database is locked ला भेटणारा आणि exponential backoff सह तिसऱ्या प्रयत्नात यशस्वी होणारा एक write.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

एक मदतनीस वर्गातून रेकॉर्ड रूमकडे forms घेऊन जाते. ती खोलीपर्यंत चालत गेली, एक form दिला, शिक्क्याची वाट पाहिली, आणि परत आली — 2,000 वेळा — तर दिवस संपतो. जर ती 2,000 forms चा एक खोका घेऊन गेली आणि एक शिक्का घेतला, तर क्षणभर लागतो. प्रत्येक COMMIT म्हणजे खोलीपर्यंतची एक फेरी.

कधी कधी दुसरा कारकून आत असल्यामुळे खोलीचे दार क्षणभर बंद असते. शहाणी मदतनीस थोडी थांबते, पुन्हा प्रयत्न करते, आणखी थोडी थांबते, पुन्हा प्रयत्न करते — आणि कायम दार ठोठावत राहण्याऐवजी काही प्रयत्नांनंतर नम्रपणे थांबते.

🗺️ आकृती

flowchart LR
    req["🌐 request"] --> pool["🚰 pool: borrow a connection"]
    pool --> tx["with conn:  BEGIN … COMMIT<br/>parameters (?) only"]
    tx --> ok["✅ return the connection"]
    tx -. "database is locked" .-> retry["⏳ retry: 50 → 100 → 200 ms, then give up"]
    retry --> tx

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/database/lesson-diagrams.html#l17

❓ काय

Connection pool — प्रत्येक request साठी नवे connection उघडण्याऐवजी connections उसने घ्या आणि परत करा (धडा 10). ते नेहमी परत करा — गळलेले (leaked) connection pool रिकामा करते.
कामाच्या प्रत्येक एककासाठी एक छोटे transaction — Python मधले with conn: शेवटी commit करते आणि कोणत्याही exception वर rollback करते (धडा 04). User किंवा network call ची वाट पाहत असताना transaction कधीच उघडे ठेवू नका.
Parameters, नेहमी (धडा 13).
Batching — एकाच transaction मध्ये executemany; मोठ्या imports साठी bulk loaders (Postgres मध्ये COPY).
Backoff सह retries — फक्त तात्पुरत्या errors वर retry करा (locked, deadlock victim, connection reset), फक्त संपूर्ण transactions किंवा idempotent writes, आणि एका मर्यादेसह.
ORMs (SQLAlchemy, Django, ActiveRecord, Prisma) — objects ना rows शी जोडतात आणि तुमच्यासाठी SQL आणि parameters लिहितात. त्यांच्यामुळे N+1 सोपे होते (धडा 12): query count log करा.

🤔 का

बहुतेक "database हळू आहे" tickets म्हणजे खरेतर "app database शी वाईट पद्धतीने बोलते": खूप commits, खूप connections, खूप round trips, आणि lock साठी कोणतीच योजना नाही.

🔧 कसे (या repo मध्ये)

db/demo.py मधले appcode() — ते दुसऱ्या connection मधून write lock धरून ठेवते, त्यामुळे retry loop ला खरा database is locked भेटतो, मग ते lock सोडते.

🧪 करून पाहा

python3 db/demo.py appcode
python3 - <<'EOF'
import sqlite3, time
c = sqlite3.connect(":memory:"); c.execute("CREATE TABLE t (x)")
for n in (100, 1000, 5000):
    t = time.perf_counter()
    with c: c.executemany("INSERT INTO t VALUES (?)", ((i,) for i in range(n)))
    print(n, "rows in one transaction:", round((time.perf_counter() - t) * 1000, 2), "ms")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

काहीसे असे commit per row 513 ms · one transaction 1 ms (तुमचे आकडे वेगळे असतील; गुणोत्तर हाच धडा आहे), मग attempt 1 … locked, attempt 2 … locked, attempt 3: done.

🏁 तुम्ही आत्ताच काय सिद्ध केले

एकदाच commit करून तुम्ही writes शेकडो पट जलद करू शकता, आणि थोडा वेळ कुलूपबंद असलेल्या खोलीत app अडकून न पडता किंवा तिच्यावर घाव न घालता टिकवू शकता.

⚠️ नेहमीच्या चुका

loop च्या आत प्रत्येक row वर autocommit
प्रत्येक query साठी नवे connection उघडणे
HTTP call किंवा user input दरम्यान उघडे राहिलेले transaction
प्रत्यक्षात यशस्वी झालेल्या non-idempotent write वर retry (दुहेरी charges)
ORM वर डोळे झाकून विश्वास — ते पाठवते तो SQL वाचा

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: pool sizes, transaction scope, retry policy आणि प्रत्येक request मागचे query counts हेच reviewers प्रत्येक service च्या data layer मध्ये तपासतात.

⏭️ पुढे

git checkout lesson-18-oltp-olap — मोठे reports कुठे चालवायचे.

🧑‍💻 Lesson 17 — The database from code

📍 You are here: Lesson 17 of 18 · Previous: lesson-16-replication-failover · Next: lesson-18-oltp-olap

Part 3 — going deeper. Lessons 01–12 built and ran the record room. Lessons 13–18 are the topics interviews and incidents ask about — each one runs for real on the same school.db.

📦 What's in this branch

Lessons 01–17, plus appcode() in db/demo.py: 2,000 inserts committed one by one vs in one transaction, and a write that meets database is locked and succeeds on the third attempt with exponential backoff.

🧒 Explain like I'm 5

A helper carries forms from the classroom to the record room. If she walks to the room, hands over one form, waits for the stamp, and walks back — 2,000 times — the day is gone. If she carries one box of 2,000 forms and gets one stamp, it takes a moment. Every COMMIT is a walk to the room.

Sometimes the room's door is locked for a moment because another clerk is inside. A sensible helper waits a little, tries again, waits a bit longer, tries again — and gives up politely after a few tries instead of banging on the door forever.

🗺️ Diagram

flowchart LR
    req["🌐 request"] --> pool["🚰 pool: borrow a connection"]
    pool --> tx["with conn:  BEGIN … COMMIT<br/>parameters (?) only"]
    tx --> ok["✅ return the connection"]
    tx -. "database is locked" .-> retry["⏳ retry: 50 → 100 → 200 ms, then give up"]
    retry --> tx

🗺️ Drawn version + a lab: https://school-edh.pages.dev/database/lesson-diagrams.html#l17

❓ What

Connection pool — borrow and return connections instead of opening one per request (lesson 10). Always return it — a leaked connection empties the pool.
One short transaction per unit of work — with conn: in Python commits at the end and rolls back on any exception (lesson 04). Never hold a transaction open while waiting for a user or a network call.
Parameters, always (lesson 13).
Batching — executemany inside one transaction; bulk loaders (COPY in Postgres) for big imports.
Retries with backoff — retry only transient errors (locked, deadlock victim, connection reset), only whole transactions or idempotent writes, with a cap.
ORMs (SQLAlchemy, Django, ActiveRecord, Prisma) — map objects to rows and write the SQL and parameters for you. They make N+1 easy (lesson 12): log the query count.

🤔 Why

Most "the database is slow" tickets are really "the app talks to the database badly": too many commits, too many connections, too many round trips, and no plan for a lock.

🔧 How (in this repo)

appcode() in db/demo.py — it holds the write lock from a second connection, so the retry loop meets a real database is locked, then releases it.

🧪 Try it

python3 db/demo.py appcode
python3 - <<'EOF'
import sqlite3, time
c = sqlite3.connect(":memory:"); c.execute("CREATE TABLE t (x)")
for n in (100, 1000, 5000):
    t = time.perf_counter()
    with c: c.executemany("INSERT INTO t VALUES (?)", ((i,) for i in range(n)))
    print(n, "rows in one transaction:", round((time.perf_counter() - t) * 1000, 2), "ms")
EOF

✅ Verify — what you should see

Something like commit per row 513 ms · one transaction 1 ms (your numbers differ; the ratio is the lesson), then attempt 1 … locked, attempt 2 … locked, attempt 3: done.

🏁 What you just proved

You can make writes hundreds of times faster by committing once, and make an app survive a briefly locked room without hanging or hammering it.

⚠️ Common mistakes

autocommit on every row inside a loop
opening a new connection per query
a transaction left open across an HTTP call or user input
retrying a non-idempotent write that actually succeeded (double charges)
trusting the ORM blindly — read the SQL it sends

🏭 Why this matters in production: pool sizes, transaction scope, retry policy and query counts per request are what reviewers check in the data layer of every service.

⏭️ Next

git checkout lesson-18-oltp-olap — where the big reports should run.

← Previousreplication failover Next →oltp olap

This page is the lesson's README from the lesson-17-app-code branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.