#community-help

Advice on Best Method to Store Event Records

TLDR Matthew requests advice on how to store event records with multiple attendees. Jason suggests storing these records at the event level.

2mo

Join the chat

Jul 26, 2023 (2 months ago)

Photo of md5-ac3436827bebcd62308d83f3823df584

Matthew

05:29 PM

Question about a large number smaller records vs a small number of larger records.
We have a case where we search events but filter by attendees. We have traditionally stored these as attendee records with some event data on each record since the services we used limited the record size. However there is not many events, the collection would be less than 10,000 event records. Most events have a few hundred attendees, but can get up to a few thousand. Would it be better to store events and then attach a list of attendees to each event or continue storing them as attendees with event data on each? We'd prefer to store larger event records with attendees since it's much easier for use to manage and sync the data that way.

Photo of md5-8813087cccc512313602b6d9f9ece19f

Jason

05:39 PM

The answer to this would depend on how you’ll be searching through the data.

I’m guessing you’ll be searching for attendee names, given an event ID?

05:40

Jason

05:40 PM

Do you also search on event details across all events?

Matthew

05:41 PM

Generally we are searching by event names and details(description, speakers, location, etc) and filter out events that the user isn't invited to(no attendee record)

Jason

05:43 PM

Would this be a good simplified version of a potential record:

{
  "event_name": "xyz",
  "event_location": "abc",
  "event_starts_at": 123,
  "event_ends_at": 234,
  "attendee_user_ids": [6, 7, 8, 9]
}

Matthew

05:43 PM

Yes

Jason

05:44 PM

Great, so yeah, you should be good to store events as top level records… especially if the only attendee-level query you’re doing is whether an attendee is part of an event or not

Matthew

05:45 PM

Awesome, thanks for the help

Typesense

Lightning-fast, open source search engine for everyone | Knowledge Base powered by Struct.AI

Indexed 2776 threads (79% resolved)

Join Our Community Manage subscription

Similar Threads

Improving Record Retrieval Speed from Typesense

Yoshi sought ways to accelerate Typesense record retrieval. Jason advised upgrading to high availability and using the documents/export endpoint. They also noted a high volume of writes consuming significant CPU capacity as a possible performance factor.

Discussions on Typesense, Collections, and Dynamic Fields

Tugay shares plans to use Typesense for their SaaS platform and asks about collection sizes and sharding. Jason clarifies Typesense's capabilities and shares a beta feature. They discuss using unique collections per customer and new improvements. Kishore Nallan and Gabe comment on threading and data protection respectively.

33mo

Discussing Typesense Cloud's SSDs, NVMe, and Resources Needed

A asked about Typesense's storage type and configuration possibilities. Jason shared that they use SSDs and suggested NVMe SSDs for high-availability instances. They discussed server resources needed for specific user cases and briefly touched on DDoS protection via Cloudflare.

28mo

Structuring Database for Different Data Types in a Travel App

Robert asked for advice on structuring database for a travel app. Jason suggested separate collections for each element type with multi-search, then use a popularity metric to determine the top result.

30mo

Discussing Data Retrieval in Typesense Cloud Tool

Ricardo inquired about the impact of using non-searched fields in data records with Typesense. Jason explained that all fields are fetched from the disk, even if unindexed, pointing out it might not affect performance, with the benefit of reducing separate database API calls.

31mo