Section 2 of 3 · 18 lessons

NoSQL

A technician wants the whole inspection on one screen. A sensor needs to send readings quickly, while the dashboard keeps asking for the latest one. Should all of those jobs store their records in the same way? Work through keys and documents with Botie, then follow what happens when we divide the records among machines or keep several copies. Each choice changes the questions we can answer easily and the failures we need to handle.

0 of 18 finished

Choosing the Shape of the Records

The team looks up a pump by its ID many times a day. Other jobs need an entire inspection or a summary across sites. Begin with those questions and see why a useful way to store one answer can be awkward for another.

  1. 01Which Records Does the Technician Need Together?A pump screen, a recent-reading lookup and a site report ask different questions of the same records. Start with those requests before choosing how to store the data.
    Build with Botie →Read the lesson
  2. 02Which P1 Did the Lookup Mean?Two sites use the same short asset ID. Build keys that preserve the full identity, and distinguish a missing entry from a stored zero.
    Build with Botie →Read the lesson
  3. 03How Long Should Botie Trust the Saved Reading?A cache can answer quickly while showing an old reading. Follow its expiry boundary and the load a cold cache sends back to the source.
    Build with Botie →Read the lesson

Working Inside Documents

A nested record is convenient to save, but we still need to find particular measurements and change the intended field. Follow each path into the document and account for values that are missing.

  1. 06Did the High Value Belong to the Temperature Sensor?An array contains several readings. Keep the sensor kind and its value attached to the same member while filtering documents.
    Build with Botie →Read the lesson
  2. 07Can Botie Save a Change Without Erasing Somebody Else’s?A technician saves an old copy after another editor has changed the pump. Keep unrelated fields intact and bind the write to the version that was actually reviewed.
    Build with Botie →Read the lesson

Finding and Summarising Documents

The collection grows beyond what we want to read for every question. Organise a route to likely matches, then follow the selected documents through the operations that produce a useful summary.

  1. 08Can We Find North’s Hot Pumps Without Reading Every Document?Use a site index to narrow the candidates, then keep the temperature condition. Inspect what an index saves and which work it leaves behind.
    Build with Botie →Read the lesson
  2. 09How Much Urgent Work Was Hidden Inside the Pump Documents?Follow documents through filtering, array expansion and grouping. Keep track of what one row represents so the site total counts visits exactly once.
    Build with Botie →Read the lesson

Partitioning for the Questions We Ask

One site sends far more readings than the others. Work out where those records go and which records a query must visit before choosing how to divide the data.

  1. 10Why Is One Storage Key Doing All the Work?The maintenance service has plenty of records but most requests land on one tenant. Choose a key from the work the service actually performs, then inspect the traffic it concentrates.
    Build with Botie →Read the lesson
  2. 11Keep One Asset’s History Together Without Growing ForeverA technician wants a time range for one pump. Give that request a bounded partition and an ordering that makes the required records reachable.
    Build with Botie →Read the lesson

Reading and Writing Replicated Records

Two technicians can see different versions of the same work order. Follow the copies and the updates to understand which answers a read can promise and how a competing write should be handled.

  1. 12Why Did the Repair Disappear When Botie Read It Back?Copies can disagree while an update is travelling. Define what a particular read must guarantee before deciding which replica may answer it.
    Build with Botie →Read the lesson
  2. 13Two Technicians Cannot Both Reserve the Last KitA successful read does not reserve the stock it showed. Put the expected version and remaining-stock rule inside the actual write.
    Build with Botie →Read the lesson
  3. 14How Can Two Offline Teams Keep Both Inspection Counts?Choosing the last arriving total can lose someone’s work. Give each replica an owned contribution and derive a merge whose repeated delivery does not inflate the count.
    Build with Botie →Read the lesson

Keeping Derived Data Repairable

A summary can fall behind its source, an old document can have a different shape, and a backup can omit recent work. Keep enough information to detect those gaps and rebuild a trustworthy result.

  1. 15Why Does the Dashboard Still Count a Job That Was Closed?A source record changes while a dashboard keeps its own count. Build a projection from versioned job images and make repeats, moves and deletions visible.
    Build with Botie →Read the lesson
  2. 16The New Sensor Sends a Different DocumentSome readers still expect temp_c while a new device sends a value and a unit. Introduce an explicit representation version and a reader that can explain both.
    Build with Botie →Read the lesson
  3. 17The Bad Update Reached Every Replica. What Can We Restore?Replication faithfully copies a mistake too. Recover a known snapshot through a complete log interval, then verify the recovered service before switching readers.
    Build with Botie →Read the lesson

Serving Model Data

A fast lookup still gives a model the wrong input if it returns a stale value or information from the future. Bring the storage decisions back to the inspection the model is helping us make.

  1. 18A Fast Feature Lookup Still Has to Mean the Right ThingA model needs the right entity, feature definition and available measurements in a fixed order. Use a serving document for that contract while keeping historical training evidence separately.
    Build with Botie →Read the lesson