HW 1 – Assigning Analytical Tasks to NoSQL DBMS and Rationale

(5 points)

Using the task list from HW 0, map each task to the most suitable NoSQL DBMS (document — MongoDB, wide-column — Cassandra, key-value — Redis, graph — Neo4j) and justify the choice. No DB-specific syntax or schema design at this stage.

For each task, fill a card (2 p.):
- Primary DBMS (MongoDB / Cassandra / Redis / Neo4j).
- Why primary (2–3 reasons) — based on analytics type and access pattern.
- Alternative 1 — how it would be solved and when to choose it.
- Alternative 2 (optional) — how it would be solved and when to choose it.
- Expected output — brief description of result shape.
- Freshness / target latency (e.g., p95) if applicable.
- Access pattern & expected selectivity (filters, time range, fan-out).

Within each card (2 p.):
- Justify the choice of DBMS: why this type of data/query fits this DBMS.
- Explain why other DBMSs are less suitable (or what the trade-offs are).

Compile a table (1 p.):

Task ID	Short name	Primary DBMS	Why primary (2–3)	Alternative 1 (how; when)	Alternative 2 (how; when)	Expected output	Freshness/latency	Access pattern

Examples:

For MongoDB:
- “Find all users from country X who performed action Y over the last month.”
- Aggregation with time filtering; counting by country/action.

For Cassandra:
- “Retrieve all actions of user X for the last 7 days.”
- Selections by key; aggregation by user and period.

For Redis:
- “Find the number of active users on a given day.”
- Counters and top lists.

For Neo4j:
- “Find all users connected to course Z through a joint project.”
- Search for connected users; compute centrality.

Submit to the BRUTE system:

HW1.docx file containing the table and per-task cards.

Deadline: Sunday 26. 10. 2025 until 23:59.

Tips for choosing a NoSQL system (access from the university account)

Example of the table (access from the university account)