Graph, search আর time-series ডেটাবেস

১ · এক ডেটাবেস সব কাজে নয় — তিনটি বিশেষ পরিবার

পর্ব ৫৬-এ NoSQL-এর চারটি বড় পরিবার দেখেছেন। Relational ডেটাবেস যেন হাসপাতালের সাধারণ চিকিৎসক — বেশিরভাগ কাজ সে-ই সবচেয়ে ভালো করে; কিন্তু তিন ধরনের প্রশ্নে বিশেষজ্ঞ লাগে:

প্রতিটি পরিবারের জন্য এই পর্বে একই পাঁচটি প্রশ্নের উত্তর খুঁজবেন: কোন সমস্যা মেটায়, ডেটা মডেল কী, কোয়েরির ভাষা কেমন, SQLite দিয়ে কাছাকাছি কী করা যায় (আর কোথায় থামতে হয়), আর কখন সত্যিই বিশেষ সিস্টেম আনবেন। বাস্তবের বড় অ্যাপ প্রায়ই কয়েকটি একসাথে ব্যবহার করে — একে বলে polyglot persistence. একটি ই-কমার্স সাইটে অর্ডার আর টাকা থাকে relational ডেটাবেসে, পণ্য খোঁজা চলে search engine-এ, সার্ভারের CPU ও latency মাপা হয় time-series সিস্টেমে, আর “যারা এটা কিনেছেন তারা আরও কিনেছেন” আসতে পারে graph থেকে।

২ · Graph ডেটাবেস — property graph আর index-free adjacency

Facebook-এর “People you may know”, ব্যাংকের জালিয়াতি ধরার দল, কিংবা Google Maps-এর পথ — সবখানে ডেটা আসলে একটি graph: কিছু বিন্দু আর তাদের সংযোগ। Relational ডেটাবেসে আমরা সংযোগ রাখি foreign key বা junction টেবিলে, আর প্রতিটি ধাপ পেরোতে একটি JOIN লিখি। ধাপ যদি দুটি হয়, দুটি JOIN; কিন্তু “যত ধাপ লাগে” হলে কয়টি? এই প্রশ্নের জন্যই graph database.

আজকের সবচেয়ে প্রচলিত মডেল property graph. এর চারটি উপাদান:

• Node — একটি বস্তু: একজন মানুষ, একটি অ্যাকাউন্ট, একটি শহর।
• Label — node-এর ধরন: :Person, :Account, :Device. একটি node-এর একাধিক label থাকতে পারে।
• Relationship — দুই node-এর মধ্যে নাম দেওয়া, দিকওয়ালা সংযোগ: (Rahim)-[:FRIEND]->(Karima). ER মডেলের relationship-এর মতো, তবে এখানে প্রতিটি সংযোগ নিজেই একটি সংরক্ষিত বস্তু।
• Property — node বা relationship-এর গায়ে key-value: name: 'Rahim', since: 2019.

এই “আঙুল ধরে চলা”-র কারিগরি নাম index-free adjacency. Neo4j-এর মতো native graph ডেটাবেসে প্রতিটি node-এর record সরাসরি তার relationship-গুলোর ঠিকানা (pointer) রাখে, আর প্রতিটি relationship রাখে দুই প্রান্তের node-এর ঠিকানা। ফলে একটি node থেকে পাশের node-এ যেতে কোনো index খুঁজতে হয় না — খরচ প্রতি relationship-এ মোটামুটি ধ্রুবক, O(1). Relational ডেটাবেসে একই ধাপ মানে friend(src)-এর B+ tree index-এ একটি খোঁজ: গাছের উচ্চতা h হলে প্রায় h-টি page পড়া, অর্থাৎ O(log E), যেখানে E = মোট সংযোগ।

খরচটা সৎভাবে মাপা দরকার। গাছের উচ্চতা সাধারণত ৩–৪, আর ওপরের page-গুলো buffer pool-এ থাকে (পর্ব ৩৯), তাই একটি ধাপে পার্থক্য সামান্য। পার্থক্য বড় হয় গভীর, বহু ধাপের traversal-এ: প্রতিটি node-এর গড়ে d জন প্রতিবেশী হলে k ধাপে পথের সংখ্যা প্রায় d^k, আর প্রতিটি পথে log-গুণক খরচ জমতে থাকে। তবে “graph ডেটাবেস সবসময় দ্রুত” — এমন দাবি ঠিক নয়: “সব অ্যাকাউন্টের মোট লেনদেন” ধরনের বিশাল aggregate-এ relational বা column store প্রায়ই ভালো।

Graph-এর আরেকটি পুরোনো ধারা RDF (Resource Description Framework) — W3C-র মানদণ্ড, যেখানে সব তথ্য তিন অংশের বাক্য বা triple: subject – predicate – object, যেমন “Rahim — friend — Karima”. প্রতিটি জিনিসের নাম একটি URI, তাই বিভিন্ন প্রতিষ্ঠানের ডেটা জোড়া লাগানো সহজ। এর কোয়েরি ভাষা SPARQL; Property graph অ্যাপ বানানোর জন্য বেশি জনপ্রিয়, আর RDF জ্ঞান-আদান-প্রদান ও ontology-র জন্য।

PREFIX ex: <http://example.org/>
# triple:  ex:rahim  ex:friend  ex:karima .
SELECT DISTINCT ?name WHERE {
  ex:rahim ex:friend/ex:friend ?p .     # দুই ধাপের property path
  ?p ex:name ?name .
  FILTER (?p != ex:rahim)
}

৩ · Cypher — প্যাটার্ন এঁকে প্রশ্ন, variable-length path আর shortestPath

Neo4j সবচেয়ে পরিচিত graph ডেটাবেস, আর তার ভাষা Cypher. Cypher-এর মূল চিন্তা: প্রশ্নটা ছবির মতো আঁকা। গোল বন্ধনী ( ) = node, তীর -[ ]-> = relationship. আপনি একটি প্যাটার্ন আঁকেন, আর ডেটাবেস graph-এ সেই আকারের সব টুকরো খুঁজে আনে। নিচের উদাহরণগুলো এই পাতায় চলবে না — শুধু পড়ার জন্য; graph-টি পরের অংশের SQL এডিটরের মতোই (৮ জন মানুষ, ৯টি বন্ধুত্ব)।

// node, label, property আর relationship বানানো
CREATE (r:Person {name: 'Rahim', city: 'Dhaka'}),
       (k:Person {name: 'Karima', city: 'Chattogram'}),
       (r)-[:FRIEND {since: 2019}]->(k);

// বন্ধুর বন্ধু, যিনি এখনো সরাসরি বন্ধু নন — "আপনি হয়তো চেনেন"
MATCH (me:Person {name: 'Rahim'})-[:FRIEND]-(f)-[:FRIEND]-(fof)
WHERE fof <> me AND NOT EXISTS { (me)-[:FRIEND]-(fof) }
RETURN fof.name AS suggestion, count(*) AS mutual
ORDER BY mutual DESC;
// suggestion: Nusrat (mutual 2), Tanvir (mutual 1)

লক্ষ করুন, -[:FRIEND]--এ তীরের মাথা নেই — মানে দিক যা-ই হোক। বন্ধুত্ব দুই দিকের, তাই ডেটায় একবার -> রাখলেই চলে, কোয়েরিতে দিক উপেক্ষা করা যায়। এবার আসল শক্তি: variable-length path. [:FRIEND*1..3] মানে “১ থেকে ৩টি FRIEND সম্পর্কের শিকল”। SQL-এ এর জন্য recursive CTE লাগে (পর্ব ২৫), Cypher-এ শুধু একটি তারকাচিহ্ন। আর shortestPath দুই node-এর মধ্যে সবচেয়ে কম ধাপের পথ দেয়:

// Rahim থেকে ৩ ধাপের মধ্যে কারা আছেন
MATCH (me:Person {name: 'Rahim'})-[:FRIEND*1..3]-(x)
WHERE x <> me
RETURN DISTINCT x.name;

// Rahim থেকে Mitu — সবচেয়ে কম ধাপের পথ (৬ ধাপের সীমা)
MATCH p = shortestPath(
  (a:Person {name: 'Rahim'})-[:FRIEND*..6]-(b:Person {name: 'Mitu'}))
RETURN [n IN nodes(p) | n.name] AS route, length(p) AS hops;
// route: ["Rahim","Sabbir","Tanvir","Imran","Mitu"], hops: 4

Variable-length প্যাটার্নটি ভেতরে কীভাবে ছড়ায়, ধাপে ধাপে দেখুন। একটি নিয়ম মনে রাখবেন: একটি MATCH-এর ভেতরে Cypher একই relationship দুবার ব্যবহার করে না (relationship uniqueness), তবে একই node-এ আবার পৌঁছানো নিষেধ নয়।

দূরত্ব বা খরচসহ পথ (যেমন কিলোমিটারে সবচেয়ে ছোট রাস্তা) চাইলে hop গোনা যথেষ্ট নয় — Dijkstra-র মতো অ্যালগরিদম লাগে। Neo4j-এ এর জন্য আলাদা Graph Data Science library আছে। Neo4j-এর নতুন সংস্করণগুলোতে GQL-ধাঁচের SHORTEST আর quantified path pattern-এর মতো নতুন সিনট্যাক্সও যোগ হয়েছে — নিজের সংস্করণের ডকুমেন্টেশন দেখে নিন।

মানদণ্ড — GQL আর SQL/PGQ

বহু বছর graph-এর কোনো ISO মানদণ্ড ছিল না: Neo4j-এর Cypher (পরে openCypher নামে উন্মুক্ত), Apache TinkerPop-এর Gremlin, Oracle-এর PGQL — প্রত্যেকের নিজের ভাষা। এখন দুটি মানদণ্ড এসেছে। SQL:2023-এর নতুন অংশ SQL/PGQ সাধারণ টেবিলকেই একটি property graph হিসেবে ঘোষণা করে, আর GRAPH_TABLE-এর ভেতরে Cypher-ধাঁচের MATCH লিখতে দেয়। আর ২০২৪ সালে প্রকাশিত হয় GQL (ISO/IEC 39075) — SQL-এর পর ISO-র দ্বিতীয় ডেটাবেস কোয়েরি ভাষা, যার বড় অংশ Cypher থেকে অনুপ্রাণিত। কোন ডেটাবেস কতটুকু সমর্থন করে, তা দ্রুত বদলাচ্ছে; ব্যবহারের আগে নিজের সিস্টেমের সংস্করণ যাচাই করুন। নিচের সিনট্যাক্সও সিস্টেমভেদে সামান্য আলাদা হতে পারে।

CREATE PROPERTY GRAPH social
  VERTEX TABLES (person KEY (id) LABEL person PROPERTIES (id, name))
  EDGE TABLES (friend KEY (src, dst)
    SOURCE KEY (src) REFERENCES person (id)
    DESTINATION KEY (dst) REFERENCES person (id)
    LABEL friend);

SELECT DISTINCT fof
FROM GRAPH_TABLE (social
  MATCH (a IS person WHERE a.name = 'Rahim')
        -[IS friend]-> (b IS person) -[IS friend]-> (c IS person)
  COLUMNS (c.name AS fof));

৪ · SQLite-এ graph — edges টেবিল, recursive CTE আর তার দাম

Graph রাখার জন্য আলাদা ডেটাবেস না থাকলেও চলে: দুটি টেবিলই যথেষ্ট — node-এর টেবিল আর সংযোগের টেবিল, অর্থাৎ একটি adjacency list. প্রথম তিনটি এডিটরে আছে person (id, name) — আটজন: 1 Rahim, 2 Karima, 3 Sabbir, 4 Nusrat, 5 Tanvir, 6 Farhana, 7 Imran, 8 Mitu — আর friend (src, dst, since), যেখানে প্রতিটি বন্ধুত্ব দুই দিকেই একটি করে সারি (৯টি বন্ধুত্ব, ১৮টি সারি), যাতে “src-এর বন্ধু” খুঁজতে শুধু src কলাম দেখলেই হয়। Primary key (src, dst)-এর index-ই প্রতিটি ধাপের খোঁজ দ্রুত করে।

প্রথম প্রশ্ন দুই ধাপের, তাই recursion লাগে না — একটি self join যথেষ্ট। “Rahim হয়তো চেনেন” — বন্ধুর বন্ধু, যিনি নিজে Rahim নন এবং এখনো সরাসরি বন্ধু নন, কতজন পারস্পরিক বন্ধুসহ:

SELECT p.name AS suggestion, COUNT(*) AS mutual_friends,
       group_concat(m.name, ', ') AS via
FROM friend f1
JOIN friend f2 ON f2.src = f1.dst          -- বন্ধুর বন্ধু
JOIN person p  ON p.id = f2.dst
JOIN person m  ON m.id = f1.dst            -- মাঝের বন্ধু
WHERE f1.src = 1                           -- Rahim
  AND f2.dst <> 1
  AND f2.dst NOT IN (SELECT dst FROM friend WHERE src = 1)
GROUP BY p.id
ORDER BY mutual_friends DESC, p.name;

suggestion │ mutual_friends │ via
Nusrat     │ 2              │ Karima, Sabbir
Tanvir     │ 1              │ Sabbir

“যত ধাপ লাগে” প্রশ্নের জন্য recursive CTE. পর্ব ২৫-এ রাস্তার মানচিত্রে যে কৌশল দেখেছেন, এখানেও তাই: প্রতিটি সারি দেখা id-গুলোর একটি স্ট্রিং (seen) বয়ে নেয়, যাতে চক্রে ঘুরপাক না খায় (cycle detection), আর সাথে নামের পথ (route). প্রতিটি মানুষের সবচেয়ে কম hop:

WITH RECURSIVE walk(id, hops, seen, route) AS (
  SELECT 1, 0, '/1/', 'Rahim'
  UNION ALL
  SELECT f.dst, w.hops + 1, w.seen || f.dst || '/', w.route || ' > ' || p.name
  FROM walk w
  JOIN friend f ON f.src = w.id
  JOIN person p ON p.id = f.dst
  WHERE instr(w.seen, '/' || f.dst || '/') = 0     -- একই মানুষ দুবার নয়
    AND w.hops < 6                                  -- নিরাপত্তার সীমা
)
SELECT p.name, MIN(w.hops) AS min_hops, w.route, COUNT(*) AS paths
FROM walk w JOIN person p ON p.id = w.id
GROUP BY p.id ORDER BY min_hops, p.name;

name    │ min_hops │ route                                  │ paths
Rahim   │ 0        │ Rahim                                  │ 1
Karima  │ 1        │ Rahim > Karima                         │ 3
Sabbir  │ 1        │ Rahim > Sabbir                         │ 3
Nusrat  │ 2        │ Rahim > Karima > Nusrat                │ 3
Tanvir  │ 2        │ Rahim > Sabbir > Tanvir                │ 4
Farhana │ 3        │ Rahim > Karima > Nusrat > Farhana      │ 4
Imran   │ 3        │ Rahim > Sabbir > Tanvir > Imran        │ 4
Mitu    │ 4        │ Rahim > Sabbir > Tanvir > Imran > Mitu │ 4

Fraud ring — একই ডিভাইস ব্যবহার করা অ্যাকাউন্টের দল

মোবাইল ফাইন্যান্সিয়াল সার্ভিসের ঝুঁকি-বিশ্লেষণ দলের একটি পরিচিত সতর্কসংকেত: অনেকগুলো “আলাদা” অ্যাকাউন্ট আসলে একই ফোন সেট বা একই ডিভাইস থেকে চলছে। এটি নিজে অপরাধের প্রমাণ নয় — পরিবারের সবাই একটি ফোন ব্যবহার করতেই পারেন — কিন্তু মানুষের হাতে যাচাইয়ের (manual review) জন্য চিহ্নিত করার মতো। অ্যাকাউন্ট আর ডিভাইস দুই ধরনের node; A101 আর A103 সরাসরি কোনো ডিভাইস ভাগ না করলেও A102-এর মাধ্যমে যুক্ত হতে পারে। প্রশ্নটা তাই graph-এর connected component খোঁজা।

এডিটরের টেবিল account_device (acc_id, device_id) — দশটি অ্যাকাউন্ট (A101–A110) আর সাতটি ডিভাইস (D1–D7)-এর ১৩টি সংযোগ, বানানো ডেটা। কৌশল: প্রতিটি অ্যাকাউন্ট থেকে অ্যাকাউন্ট → ডিভাইস → অ্যাকাউন্ট ধরে যতদূর যাওয়া যায়, আর দলের নাম হবে দলের সবচেয়ে ছোট আইডি।

WITH RECURSIVE reach(start, acc) AS (
  SELECT DISTINCT acc_id, acc_id FROM account_device
  UNION                                   -- ডুপ্লিকেট বাদ, তাই চক্রেও থামে
  SELECT r.start, d2.acc_id
  FROM reach r
  JOIN account_device d1 ON d1.acc_id = r.acc
  JOIN account_device d2 ON d2.device_id = d1.device_id
),
ring AS (SELECT start, MIN(acc) AS ring_id FROM reach GROUP BY start)
SELECT ring_id, COUNT(*) AS accounts, group_concat(start, ', ') AS members
FROM ring GROUP BY ring_id
HAVING COUNT(*) >= 2
ORDER BY accounts DESC, ring_id;

ring_id │ accounts │ members
A105    │ 4        │ A105, A106, A107, A110
A101    │ 3        │ A101, A102, A103
A104    │ 2        │ A104, A108

Depth বাড়লে খরচ — সংখ্যায় দেখুন

এবার একটি বড় graph: ১০০০টি node (0–999), প্রতিটি থেকে ৩টি করে সংযোগ, অর্থাৎ ৩০০০টি edge, গাণিতিক সূত্রে বানানো (edge টেবিল, src-এ index). Node 0 থেকে কোনো পাহারা ছাড়া হাঁটলে প্রতিটি depth-এ কয়টি সারি তৈরি হয়, আর তার মধ্যে আলাদা node কয়টি?

WITH RECURSIVE walk(node, depth) AS (
  SELECT 0, 0
  UNION ALL
  SELECT e.dst, w.depth + 1
  FROM walk w JOIN edge e ON e.src = w.node
  WHERE w.depth < 8
)
SELECT depth, COUNT(*) AS rows_made,
       COUNT(DISTINCT node) AS distinct_nodes
FROM walk GROUP BY depth ORDER BY depth;

depth │ rows_made │ distinct_nodes
0     │ 1         │ 1
1     │ 3         │ 3
2     │ 9         │ 9
3     │ 27        │ 25
4     │ 81        │ 73
5     │ 243       │ 193
6     │ 729       │ 388
7     │ 2187      │ 492
8     │ 6561      │ 500

একই কাজ সাধারণ প্রোগ্রামে, visited set রেখে — প্রতিটি মানুষ একবারই queue-তে ঢোকে (DSA কোর্সের BFS পর্বে বিস্তারিত):

from collections import deque
edges = [("Rahim", "Karima"), ("Rahim", "Sabbir"), ("Karima", "Nusrat"), ("Sabbir", "Nusrat"),
         ("Sabbir", "Tanvir"), ("Nusrat", "Farhana"), ("Tanvir", "Imran"), ("Farhana", "Imran"), ("Imran", "Mitu")]
adj = {}                                   # adjacency list
for a, b in edges:
    adj.setdefault(a, []).append(b); adj.setdefault(b, []).append(a)
def bfs(start, goal):
    parent, queue, popped = {start: None}, deque([start]), 0   # parent = visited + কোথা থেকে এলাম
    while queue:
        node = queue.popleft(); popped += 1
        if node == goal: break
        for nb in adj[node]:
            if nb not in parent:           # প্রতিটি মানুষ একবারই queue-তে
                parent[nb] = node; queue.append(nb)
    route = []
    while node is not None:
        route.append(node); node = parent[node]
    return route[::-1], popped, len(parent)
route, popped, seen = bfs("Rahim", "Mitu")
print(" > ".join(route), "| hops:", len(route) - 1)
print("dequeued:", popped, "| visited:", seen, "of", len(adj))

Rahim > Sabbir > Tanvir > Imran > Mitu | hops: 4
dequeued: 8 | visited: 8 of 8

৫ · Search engine — Lucene, analyzer, BM25, shard আর replica

পর্ব ৩০-এ inverted index দেখেছেন: শব্দ → কোন কোন ডকুমেন্টে আছে তার তালিকা (posting list). একটি search engine এই ধারণাকে বিশাল মাপে নিয়ে যায়। আজকের সবচেয়ে প্রচলিত দুটি — Elasticsearch আর তার ২০২১ সালের open-source শাখা OpenSearch — দুটিই Lucene নামের Java library-র ওপর তৈরি। ডেটা মডেল সহজ: প্রতিটি রেকর্ড একটি JSON ডকুমেন্ট, ডকুমেন্টের সংগ্রহের নাম index (relational-এর টেবিলের কাছাকাছি), আর mapping বলে কোন ঘর কোন টাইপের।

লেখা index-এ ঢোকার আগে যায় একটি analyzer-এর ভেতর দিয়ে, যার তিনটি ধাপ: (১) character filter — যেমন HTML ট্যাগ মোছা; (২) tokenizer — লেখাকে শব্দে ভাঙা; (৩) token filter — ছোট হাতের অক্ষর, stop word বাদ, stemming. ইংরেজি analyzer-এ “Fast charging supported” হয়ে যায় fast, charg, support. খোঁজার শব্দও একই analyzer দিয়ে যায় — না হলে “Charging” আর “charg” কখনো মিলত না।

মিলে যাওয়া ডকুমেন্ট সাজানো হয় প্রাসঙ্গিকতার স্কোরে (relevance ranking). Lucene-এর ডিফল্ট সূত্র BM25 (Elasticsearch ৫.০ থেকে ডিফল্ট; তার আগে ছিল TF-IDF-ভিত্তিক সূত্র)। একটি শব্দ q আর ডকুমেন্ট D-এর জন্য:

score(q, D) = IDF(q) × tf × (k1 + 1) / (tf + k1 × (1 − b + b × |D| / avgdl))
IDF(q)      = ln(1 + (N − n + 0.5) / (n + 0.5))

এখানে tf = D-তে শব্দটি কতবার, |D| = D-তে মোট শব্দ, avgdl = গড় ডকুমেন্ট-দৈর্ঘ্য, N = মোট ডকুমেন্ট, n = কতগুলো ডকুমেন্টে শব্দটি আছে; সাধারণ মান k1 = 1.2, b = 0.75. তিনটি চিন্তা: বিরল শব্দের ওজন বেশি (IDF); বারবার থাকলে স্কোর বাড়ে, কিন্তু একটি সীমার দিকে থেমে যায় (k1-এর saturation); আর লম্বা ডকুমেন্টে একবার থাকা কম অর্থবহ (b-এর length normalization). পাঁচটি ছোট পণ্য-বিবরণে খোঁজ “battery charging” (stemming ছাড়া):

d1: fast charging phone with a big battery                    (৭ শব্দ)
d2: power bank with fast charging                             (৫)
d3: wireless headphone with long battery life                 (৬)
d4: smart watch battery saver keeps the battery going for days (১০)
d5: red silk saree                                            (৩)

এই হিসাবটি একটি ছোট Python প্রোগ্রামে — inverted index বানানো থেকে স্কোর পর্যন্ত (stdlib ছাড়া কিছু লাগে না):

import math, re
from collections import Counter
docs = {"d1": "fast charging phone with a big battery",
        "d2": "power bank with fast charging",
        "d3": "wireless headphone with long battery life",
        "d4": "smart watch battery saver keeps the battery going for days",
        "d5": "red silk saree"}
tok = {d: re.findall(r"[a-z0-9]+", t.lower()) for d, t in docs.items()}
N, avgdl, k1, b = len(tok), sum(map(len, tok.values())) / len(tok), 1.2, 0.75
index = {}                                   # inverted index: term -> {doc: tf}
for d, words in tok.items():
    for w, tf in Counter(words).items():
        index.setdefault(w, {})[d] = tf
scores = Counter()
for q in "battery charging".split():
    post = index.get(q, {})
    idf = math.log(1 + (N - len(post) + 0.5) / (len(post) + 0.5))
    print(f"{q:9} n={len(post)} idf={idf:.3f} postings={post}")
    for d, tf in post.items():
        norm = 1 - b + b * len(tok[d]) / avgdl   # লম্বা ডকুমেন্টে বড়
        scores[d] += idf * tf * (k1 + 1) / (tf + k1 * norm)
for d, s in scores.most_common(): print(f"  {d}  {s:.3f}  {docs[d]}")

battery   n=3 idf=0.539 postings={'d1': 1, 'd3': 1, 'd4': 2}
charging  n=2 idf=0.875 postings={'d1': 1, 'd2': 1}
  d1  1.344  fast charging phone with a big battery
  d2  0.951  power bank with fast charging
  d4  0.632  smart watch battery saver keeps the battery going for days
  d3  0.546  wireless headphone with long battery life

ছড়ানো গঠন — shard, replica আর near-real-time

একটি index কয়েকটি shard-এ ভাগ হয় — প্রতিটি shard নিজেই একটি সম্পূর্ণ Lucene index, আর বিভিন্ন সার্ভারে (node) ছড়ানো থাকে, ঠিক পর্ব ৫৪-এর sharding-এর মতো। প্রতিটি primary shard-এর এক বা একাধিক replica অন্য node-এ থাকে: একটি সার্ভার নষ্ট হলে replica primary হয়ে যায়, আর খোঁজের চাপও replica-রা ভাগ করে নেয়। একটি খোঁজ সব shard-এ একসাথে যায়, প্রতিটি নিজের সেরা ফল ফেরত দেয়, আর সমন্বয়কারী node সেগুলো মিলিয়ে চূড়ান্ত ক্রম বানায় — scatter-gather. Primary shard-এর সংখ্যা index বানানোর সময়ই ঠিক করতে হয়; পরে বদলাতে reindex বা split/shrink-এর মতো বিশেষ অপারেশন লাগে।

আরেকটি বৈশিষ্ট্য near-real-time: নতুন ডকুমেন্ট পাঠানোর সাথে সাথে খোঁজে আসে না। Lucene নতুন লেখা প্রথমে মেমরিতে জমায়, আর একটি refresh-এ সেগুলো থেকে নতুন, অপরিবর্তনীয় segment বানায় — তখনই খোঁজা যায়। Elasticsearch-এ ডিফল্ট refresh প্রতি ১ সেকেন্ডে। Segment কখনো বদলায় না; মুছলে শুধু “মুছে ফেলা” চিহ্ন পড়ে, আর পটভূমিতে ছোট segment জুড়ে বড় segment হয় (merge) — পর্ব ৪০ আর ৫৬-এ উল্লেখ করা LSM-tree-এর চিন্তা।

PUT /products
{
  "settings": { "number_of_shards": 3, "number_of_replicas": 1 },
  "mappings": {
    "properties": {
      "name":        { "type": "text" },
      "description": { "type": "text", "analyzer": "english" },
      "category":    { "type": "keyword" },
      "price":       { "type": "scaled_float", "scaling_factor": 100 }
    }
  }
}

GET /products/_search
{
  "query": {
    "bool": {
      "must":   [ { "multi_match": { "query": "fast charging",
                                     "fields": ["name^2", "description"] } } ],
      "filter": [ { "term":  { "category": "Electronics" } },
                  { "range": { "price": { "lte": 5000 } } } ]
    }
  },
  "highlight": { "fields": { "description": {} } }
}

ভাষাটির নাম query DSL — প্রশ্নটাই একটি JSON. দুটি জিনিস লক্ষ করুন। text ঘর analyzer দিয়ে ভাঙা হয় আর স্কোরে অংশ নেয়; keyword ঘর আস্ত একটি মান, ঠিক SQL-এর =-এর মতো মেলে। আর must-এর শর্ত স্কোর বানায়, কিন্তু filter-এর শর্ত শুধু হ্যাঁ-না বলে, স্কোর ছোঁয় না, আর তার ফল cache করা যায় — SQL-এর WHERE-এর মতো।

৬ · SQLite-এ সার্চ — FTS4, মূল ডেটাবেসের সাথে মিল রাখা আর আসল স্থাপত্য

এবার দোকানের নিজের পণ্যে সার্চ। এডিটরগুলো চলবে কোর্সের সাধারণ db-shop ডেটাবেসে — customers, categories, products (product_id, name, category_id, price, stock), orders আর order_items. সাথে একটি নতুন টেবিল product_text (product_id, description) — দশটি পণ্যের ছোট ইংরেজি বিবরণ, যেমন Mobile Phone-এর “Android phone with 8 GB RAM, 50 MP camera and a 5000 mAh battery. Fast charging supported.” পুরো ডেটা এডিটরের নিচের “নমুনা ডেটাবেস” বাক্সে।

পর্ব ৩০-এর মতো এখানেও লাইভ ইঞ্জিনে FTS5 নেই, তাই virtual table FTS4, Porter stemmer-সহ। নাম আর বিবরণ দুটি কলামই index হচ্ছে, আর docid = product_id, যাতে মূল টেবিলের সাথে জোড়া যায়:

CREATE VIRTUAL TABLE product_fts USING fts4(name, description, tokenize=porter);
INSERT INTO product_fts (docid, name, description)
  SELECT p.product_id, p.name, t.description
  FROM products p JOIN product_text t USING (product_id);

SELECT docid, name FROM product_fts WHERE product_fts MATCH 'battery';
SELECT docid, name FROM product_fts WHERE product_fts MATCH 'charging';
SELECT docid, snippet(product_fts, '[', ']', '…', 1, 6) AS hit
FROM product_fts WHERE product_fts MATCH '"fast charging"';
-- লেখার খোঁজ + কাঠামোবদ্ধ ফিল্টার একসাথে
SELECT name, price, stock FROM products
WHERE product_id IN (SELECT docid FROM product_fts WHERE product_fts MATCH 'battery')
  AND price < 5000 AND stock > 0;

docid │ name
101   │ Mobile Phone
102   │ Headphone
110   │ Smart Watch

docid │ name
101   │ Mobile Phone
103   │ Power Bank

docid │ hit
101   │ …5000 mAh battery. [Fast] [charging] supported.
103   │ …times, with a [fast] [charging] port.

name        │ price  │ stock
Headphone   │ 1200 │ 40
Smart Watch │ 3500 │ 5

Search index-কে মূল ডেটাবেসের সাথে মিলিয়ে রাখা — outbox আর CDC

Search engine সাধারণত source of truth নয়: দাম, স্টক, অর্ডার থাকে relational ডেটাবেসে, আর search index তার একটি সাজানো কপি। সমস্যা হলো কপিটাকে হালনাগাদ রাখা। সবচেয়ে সরল — অ্যাপ প্রথমে ডেটাবেসে লেখে, তারপর search engine-এ — একটি ফাঁদ (dual write): মাঝখানে অ্যাপ বন্ধ হলে বা নেটওয়ার্ক ব্যর্থ হলে দুই জায়গায় দুই রকম তথ্য, আর কেউ জানে না। দুটি প্রচলিত সমাধান:

• Outbox: মূল পরিবর্তনের একই transaction-এ একটি search_outbox টেবিলে “এই পণ্য বদলেছে” লেখা। commit হলে দুটিই থাকে, rollback হলে কোনোটিই নয়। আলাদা একটি worker outbox পড়ে search engine-এ পাঠায়, আর সফল হলে event মুছে দেয়।
• CDC: ডেটাবেসের transaction log (PostgreSQL-এর WAL, MySQL-এর binlog) পড়ে প্রতিটি commit হওয়া পরিবর্তন ধরা — অ্যাপের কোডে হাত না দিয়েই। Debezium-এর মতো টুল এই কাজে পরিচিত, প্রায়ই Kafka-র সাথে।

SQLite-এ outbox-এর একটি ছোট নকল: একটি trigger নাম বদলালে event লেখে (বাস্তবে অ্যাপ নিজেই একই transaction-এ লেখে, বা CDC লাগে)। এডিটরে product_fts আর ফাঁকা search_outbox (event_id, product_id, op) আগে থেকেই তৈরি:

CREATE TRIGGER trg_prod_upd AFTER UPDATE OF name ON products
BEGIN
  INSERT INTO search_outbox (product_id, op) VALUES (NEW.product_id, 'upsert');
END;
UPDATE products SET name = 'Smart Watch Pro' WHERE product_id = 110;
SELECT * FROM search_outbox;
SELECT docid, name FROM product_fts WHERE product_fts MATCH 'pro';   -- এখনো পুরোনো
-- worker: outbox পড়ে index হালনাগাদ, তারপর event মুছে ফেলে
DELETE FROM product_fts WHERE docid IN (SELECT product_id FROM search_outbox);
INSERT INTO product_fts (docid, name, description)
  SELECT p.product_id, p.name, t.description FROM products p
  JOIN product_text t USING (product_id)
  WHERE p.product_id IN (SELECT product_id FROM search_outbox);
DELETE FROM search_outbox;
SELECT docid, name FROM product_fts WHERE product_fts MATCH 'pro';

event_id │ product_id │ op
1        │ 110        │ upsert

(প্রথম MATCH 'pro': কোনো সারি নেই)

docid │ name
110   │ Smart Watch Pro

অ্যাপ ──লেখা──▶ PostgreSQL / MySQL  (source of truth)
                     │  একই transaction-এ outbox
                     │  বা WAL/binlog থেকে CDC
                     ▼
                 queue (যেমন Kafka)
                     ▼
              indexer / worker
                     ▼
অ্যাপ ◀──খোঁজ── Elasticsearch / OpenSearch
               (৩ shard × ১ replica)
ফলের id দিয়ে দাম-স্টক আবার মূল DB থেকে

বাংলা লেখার কথা আবার মনে করুন (পর্ব ৩০): একই অক্ষরের দুই Unicode রূপ (ড় = এক বা দুই code point) — তাই index আর খোঁজ দুই দিকেই Unicode normalization; কার-চিহ্নে শব্দ ভেঙে ফেলা tokenizer; আর শাড়ি, শাড়ির, শাড়িতে-র মতো বিভক্তি। Elasticsearch-এর ডকুমেন্টেশনে bengali নামে একটি language analyzer আছে, যা normalization আর stemming করে; ICU-ভিত্তিক analysis plugin-ও আছে। তবে কোনোটিই নিখুঁত নয় — নিজের আসল সার্চ লগ থেকে শব্দ নিয়ে _analyze API-তে token দেখে যাচাই করুন।

কখন আলাদা search engine? কয়েক লাখ পণ্য, এক-দুই ভাষা, সাধারণ খোঁজ — PostgreSQL-এর tsvector বা SQLite FTS5 প্রায়ই যথেষ্ট, আর consistency বিনা খরচে। বানান-ভুল সহনশীলতা (fuzzy), facet (ফলের মধ্যে ক্যাটাগরি-ভিত্তিক গোনা), autocomplete, বহু ভাষা, শতকোটি log লাইন বা প্রাসঙ্গিকতার সূক্ষ্ম নিয়ন্ত্রণ যখন পণ্যের কেন্দ্র, তখন Elasticsearch/OpenSearch — আর সাথে স্বীকার করে নিন, এখন থেকে একটি কপি সামলাতে হবে।

৭ · Time-series ডেটা — অবিরাম মাপ, compression, downsampling আর retention

ঢাকার কোনো মোড়ে একটি বায়ুমান সেন্সর প্রতি ১০ মিনিটে PM2.5 (বাতাসে ভাসমান সূক্ষ্ম কণা, µg/m³) মাপে। একটি পোশাক কারখানার প্রতিটি সেলাই মেশিন প্রতি সেকেন্ডে গতি আর তাপমাত্রা পাঠায়। শেয়ারবাজারের প্রতিটি লেনদেন (tick) সময়সহ জমা হয়। এগুলো সবই time-series data: প্রতিটি সারি = (কখন, কোন উৎস, কী মাপ)।

এই ডেটার আকার সাধারণ ব্যবসায়িক ডেটা থেকে আলাদা, আর সেখান থেকেই time-series database-এর নকশা আসে:

• লেখা অনেক বেশি, আর প্রায় সবই নতুন: ১০,০০০ সেন্সর × প্রতি ১০ সেকেন্ডে একটি মাপ = প্রতি সেকেন্ডে ১,০০০টি নতুন সারি, দিনে ৮ কোটি ৬৪ লাখ। পুরোনো সারি প্রায় কখনো UPDATE হয় না — append-only. তাই লেখার পথ সাজানো হয় LSM-ধাঁচে বা সময়ভিত্তিক খণ্ডে (chunk).
• প্রশ্ন সময়ের পরিসরে: “গত ৬ ঘণ্টা”, “গত মাসের প্রতিদিনের সর্বোচ্চ”। তাই ডেটা সময় অনুযায়ী ভাগ করা থাকে (partitioning), আর পুরোনো খণ্ড ছুঁতেই হয় না।
• Compression খুব কার্যকর: পরপর timestamp-এর ব্যবধান প্রায় সমান, মানও ধীরে বদলায়। তাই পুরো মান না রেখে শুধু পার্থক্য রাখা যায় (delta encoding), এমনকি পার্থক্যের পার্থক্য। Facebook-এর ২০১৫ সালের Gorilla পেপার timestamp-এ delta-of-delta আর দশমিক মানে আগের মানের সাথে XOR ব্যবহার করে প্রতিটি data point গড়ে প্রায় ১.৩৭ byte-এ নামানোর কথা জানিয়েছিল — সাধারণ ১৬ byte-এর জায়গায়।
• পুরোনো ডেটার দাম কমে: গতকালের প্রতি ১০ সেকেন্ডের CPU দরকারি, গত বছরেরটা নয় — দিনের গড়ই যথেষ্ট। তাই downsampling (সূক্ষ্ম মাপ থেকে মোটা সারাংশ) আর retention (নির্দিষ্ট বয়সের পর কাঁচা ডেটা মুছে ফেলা) এদের মূল বৈশিষ্ট্য।

নিচের stepper-এ এই পর্বের সেন্সর ডেটা নিয়েই পুরো প্রক্রিয়া: ঢাকার একটি সেন্সর dhaka-01, ১৫ জানুয়ারি ২০২৬ রাত ১২টা থেকে ভোর ৬টা পর্যন্ত প্রতি ১০ মিনিটে একটি মাপ — মোট ৩৬টি হওয়ার কথা। কিন্তু ০২:৩০ থেকে ০৩:০০ পর্যন্ত লোডশেডিংয়ে সেন্সর বন্ধ ছিল, তাই চারটি মাপ নেই (সংখ্যাগুলো শেখানোর জন্য বানানো, আসল মাপ নয়)।

৮ · SQLite-এ time-series — ডেটা বানানো, bucket, moving average, ফাঁক খোঁজা আর rollup

প্রথম এডিটরে সেন্সরের ডেটা নিজেই বানাবেন — একটি recursive CTE ০ থেকে ৩৫ পর্যন্ত গোনে, আর প্রতিটি i থেকে সময় হয় ০০:০০ + i × ১০ মিনিট। PM2.5-এর মান একটি সহজ সূত্রে বানানো (ধীরে বাড়ে, মাঝে ওঠানামা করে)। তারপর লোডশেডিংয়ের চারটি মাপ মুছে ফেলা হয়, আর ঘণ্টাভিত্তিক bucket. টেবিল readings (sensor, ts, pm25), primary key (sensor, ts) — time-series-এ প্রায় সবসময় এমন “উৎস + সময়” key.

CREATE TABLE readings (sensor TEXT NOT NULL, ts TEXT NOT NULL,
  pm25 REAL NOT NULL, PRIMARY KEY (sensor, ts));
INSERT INTO readings
WITH RECURSIVE t(i) AS (SELECT 0 UNION ALL SELECT i + 1 FROM t WHERE i < 35)
SELECT 'dhaka-01',
       strftime('%Y-%m-%d %H:%M', '2026-01-15 00:00', '+' || (i * 10) || ' minutes'),
       140 + (i * 37) % 50 + (i / 6) * 8
FROM t;
DELETE FROM readings WHERE ts BETWEEN '2026-01-15 02:30' AND '2026-01-15 03:00';

SELECT strftime('%H:00', ts) AS hour, COUNT(*) AS n,
       ROUND(AVG(pm25), 1) AS avg_pm25, MIN(pm25) AS min_pm25, MAX(pm25) AS max_pm25
FROM readings GROUP BY hour ORDER BY hour;

hour  │ n │ avg_pm25 │ min_pm25 │ max_pm25
00:00 │ 6 │ 165.8    │ 140    │ 188
01:00 │ 6 │ 170.8    │ 155    │ 194
02:00 │ 3 │ 187    │ 174    │ 200
03:00 │ 5 │ 181    │ 165    │ 204
04:00 │ 6 │ 202.5    │ 184    │ 221
05:00 │ 6 │ 207.5    │ 188    │ 227

এরপরের তিনটি এডিটরে একই ৩২টি সারি আগে থেকেই তৈরি। এবার moving average — বায়ুমানের সূচক প্রায়ই “শেষ এক ঘণ্টার গড়” হিসেবে দেখানো হয়। Window function-এ (পর্ব ২৬) দুই রকমভাবে লেখা যায়, আর ফাঁক থাকলে দুটির উত্তর আলাদা:

SELECT * FROM (
  SELECT ts, pm25,
    ROUND(AVG(pm25) OVER (ORDER BY ts
          ROWS BETWEEN 5 PRECEDING AND CURRENT ROW), 1) AS avg_6rows,
    ROUND(AVG(pm25) OVER (ORDER BY unixepoch(ts)
          RANGE BETWEEN 3000 PRECEDING AND CURRENT ROW), 1) AS avg_last_hour,
    COUNT(*) OVER (ORDER BY unixepoch(ts)
          RANGE BETWEEN 3000 PRECEDING AND CURRENT ROW) AS n_hour
  FROM readings)
WHERE ts BETWEEN '2026-01-15 02:00' AND '2026-01-15 04:00';

ts               │ pm25  │ avg_6rows │ avg_last_hour │ n_hour
2026-01-15 02:00 │ 200 │ 175.8     │ 175.8         │ 6
2026-01-15 02:10 │ 187 │ 180.8     │ 180.8         │ 6
2026-01-15 02:20 │ 174 │ 177.5     │ 177.5         │ 6
2026-01-15 03:10 │ 167 │ 175.2     │ 170.5         │ 2
2026-01-15 03:20 │ 204 │ 181.2     │ 185.5         │ 2
2026-01-15 03:30 │ 191 │ 187.2     │ 187.3         │ 3
2026-01-15 03:40 │ 178 │ 183.5     │ 185         │ 4
2026-01-15 03:50 │ 165 │ 179.8     │ 181         │ 5
2026-01-15 04:00 │ 210 │ 185.8     │ 185.8         │ 6

এবার ফাঁক খোঁজা (পর্ব ২৭-এর gaps-and-islands-এর আত্মীয়)। প্রতিটি মাপের আগের মাপ LAG দিয়ে এনে ব্যবধান মাপা — ১০ মিনিটের বেশি হলে ফাঁক:

SELECT prev_ts AS last_ok, ts AS back_at,
       (unixepoch(ts) - unixepoch(prev_ts)) / 60 AS gap_min,
       (unixepoch(ts) - unixepoch(prev_ts)) / 600 - 1 AS missing
FROM (SELECT ts, LAG(ts) OVER (PARTITION BY sensor ORDER BY ts) AS prev_ts
      FROM readings)
WHERE unixepoch(ts) - unixepoch(prev_ts) > 600;

-- কোন ৩০ মিনিটের bucket-এ ৩টির কম মাপ?
SELECT datetime((unixepoch(ts) / 1800) * 1800, 'unixepoch') AS bucket_30m,
       COUNT(*) AS n, ROUND(AVG(pm25), 1) AS avg_pm25
FROM readings GROUP BY bucket_30m HAVING n < 3;

last_ok          │ back_at          │ gap_min │ missing
2026-01-15 02:20 │ 2026-01-15 03:10 │ 50      │ 4

bucket_30m          │ n │ avg_pm25
2026-01-15 03:00:00 │ 2 │ 185.5

শেষে stepper-এর downsampling আর retention, সত্যিকারের SQL-এ:

CREATE TABLE readings_1h AS
SELECT sensor, strftime('%Y-%m-%d %H:00', ts) AS bucket, COUNT(*) AS n,
       ROUND(AVG(pm25), 1) AS avg_pm25, MAX(pm25) AS max_pm25
FROM readings GROUP BY sensor, bucket;

DELETE FROM readings WHERE ts < '2026-01-15 04:00';     -- retention

SELECT (SELECT COUNT(*) FROM readings)    AS raw_rows,
       (SELECT COUNT(*) FROM readings_1h) AS rollup_rows;
-- ইতিহাস: পুরোনো অংশ rollup থেকে, নতুন অংশ কাঁচা ডেটা থেকে
SELECT bucket, n, avg_pm25 FROM readings_1h WHERE bucket < '2026-01-15 04:00'
UNION ALL
SELECT strftime('%Y-%m-%d %H:00', ts), COUNT(*), ROUND(AVG(pm25), 1)
FROM readings GROUP BY 1 ORDER BY 1;

raw_rows │ rollup_rows
12       │ 6

bucket           │ n │ avg_pm25
2026-01-15 00:00 │ 6 │ 165.8
2026-01-15 01:00 │ 6 │ 170.8
2026-01-15 02:00 │ 3 │ 187
2026-01-15 03:00 │ 5 │ 181
2026-01-15 04:00 │ 6 │ 202.5
2026-01-15 05:00 │ 6 │ 207.5

বিশেষ সিস্টেম — InfluxDB, TimescaleDB আর Prometheus

তিনটির পথ তিন রকম (কোডগুলো এখানে চলবে না, শুধু পড়ার জন্য):

# line protocol: measurement,tags fields timestamp(ns, UTC)
air_quality,sensor=dhaka-01,area=Farmgate pm25=140,temp_c=18.5 1768413600000000000

-- InfluxQL (1.x, 3.x)
SELECT MEAN("pm25") FROM "air_quality"
WHERE "sensor" = 'dhaka-01' AND time >= now() - 6h
GROUP BY time(1h) fill(none)

// Flux (2.x)
from(bucket: "air")
  |> range(start: -6h)
  |> filter(fn: (r) => r._measurement == "air_quality" and r._field == "pm25")
  |> aggregateWindow(every: 1h, fn: mean, createEmpty: false)

-- SQL (InfluxDB 3)
SELECT date_bin(INTERVAL '1 hour', time) AS hour, avg(pm25) AS avg_pm25
FROM air_quality
WHERE sensor = 'dhaka-01' AND time >= now() - INTERVAL '6 hours'
GROUP BY 1 ORDER BY 1;

CREATE TABLE readings (ts TIMESTAMPTZ NOT NULL, sensor TEXT NOT NULL,
                       pm25 DOUBLE PRECISION);
SELECT create_hypertable('readings', 'ts', chunk_time_interval => INTERVAL '1 day');

SELECT time_bucket('1 hour', ts) AS bucket, sensor, avg(pm25)
FROM readings WHERE ts > now() - INTERVAL '1 day'
GROUP BY bucket, sensor ORDER BY bucket;

-- continuous aggregate: নতুন ডেটা এলে শুধু সেই অংশ আবার হিসাব
CREATE MATERIALIZED VIEW readings_1h WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', ts) AS bucket, sensor,
       avg(pm25) AS avg_pm25, max(pm25) AS max_pm25, count(*) AS n
FROM readings GROUP BY bucket, sensor;
SELECT add_continuous_aggregate_policy('readings_1h',
  start_offset => INTERVAL '3 days', end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '30 minutes');

-- compression আর retention: নীতি হিসেবে
ALTER TABLE readings SET (timescaledb.compress, timescaledb.compress_segmentby = 'sensor');
SELECT add_compression_policy('readings', INTERVAL '7 days');
SELECT add_retention_policy('readings', INTERVAL '30 days');   -- পুরো chunk ফেলে দেয়

# প্রতিটি সেন্সরের শেষ ১ ঘণ্টার গড় PM2.5
avg_over_time(pm25_ugm3{city="dhaka"}[1h])

# দোকানের API-তে শেষ ৫ মিনিটে প্রতি সেকেন্ডে অনুরোধের হার
sum by (status) (rate(http_requests_total{job="shop-api"}[5m]))

# alert-এর শর্ত: এক ঘণ্টার গড় 150-এর বেশি
avg_over_time(pm25_ugm3[1h]) > 150

কখন time-series ডেটাবেস? কয়েকশো সেন্সর, মিনিটে একটি মাপ — PostgreSQL-এ সময় ধরে partition আর একটি BRIN index (সময়ের ক্রমে আসা ডেটার জন্য ছোট index) প্রায়ই যথেষ্ট। প্রতি সেকেন্ডে হাজার হাজার লেখা, মাসের পর মাস ইতিহাস, স্বয়ংক্রিয় downsampling-retention-compression দরকার হলে TimescaleDB বা InfluxDB; আর অবকাঠামো পর্যবেক্ষণ ও alert-এর জন্য Prometheus প্রায় মানদণ্ডে পরিণত হয়েছে।

৯ · তিন পরিবার পাশাপাশি — তুলনা আর সিদ্ধান্ত

সিদ্ধান্তের একটি সৎ ক্রম: প্রথমে relational ডেটাবেসের ভেতরের সমাধান (recursive CTE, FTS, partition, BRIN) দিয়ে শুরু করুন আর মাপুন (পর্ব ৫৩-এর মতো EXPLAIN, latency, লেখার হার)। সমস্যা যখন সংখ্যায় প্রমাণিত, তখনই বিশেষ সিস্টেম — আর সেটি সাধারণত মূল ডেটাবেসের পাশে বসে, জায়গায় নয়।

১০ · AI-এর যুগে graph, search আর time-series কোয়েরি

AI টুল এই তিন জগতে দ্রুত, নিখুঁত-দেখতে উত্তর দেয়, কিন্তু এখানে সংস্করণভেদে সিনট্যাক্স বদলেছে অনেক, তাই ভুলের ধরনও নির্দিষ্ট:

AI-এর লেখা graph, search বা time-series কোয়েরি হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Recursive কোয়েরিতে চক্রের পাহারা (path বা UNION) আর depth-সীমা আছে; চক্রওয়ালা ছোট graph-এ চালিয়ে থামতে দেখেছি
• ফলের সারি হাতে গোনা উত্তরের সাথে মিলিয়েছি — ডুপ্লিকেট পথ DISTINCT বা GROUP BY দিয়ে জেনে-বুঝে সরানো
• সিস্টেম আর সংস্করণ (Neo4j 4 না 5, InfluxDB 2 না 3, Elasticsearch না OpenSearch) কোডের সাথে মিলিয়েছি
• সার্চে _analyze দিয়ে token দেখেছি; text/keyword আর must/filter ঠিক জায়গায়; বাংলা হলে দুই Unicode রূপ দিয়ে পরীক্ষা
• Time-series-এ ফাঁকওয়ালা ডেটা দিয়ে পরীক্ষা করেছি: window সময়ভিত্তিক, গড়ের গড় ভারিত, timezone UTC
• নতুন সিস্টেম প্রস্তাব করলে মূল ডেটাবেসের সাথে sync-এর পথ (outbox/CDC) আর source of truth কোনটি, তা লেখা আছে