Home/ Questions/Q 6836723
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T23:23:24+00:00

I am currently designing a small project and wanted some advice on how best

  • 0

I am currently designing a small project and wanted some advice on how best to make it more future proof.

I have a basic object Activity and extenstions for it. In a straight database world I might have a table for activity a table for each extension and an activity-extension join table.

I would then do a join on the appropriate tables to do a search for information.

My plan is to use CXF to open it as a web service, java middle tier for business logic and elasticsearch at the back to store and query data.

My question then is am I thinking of elasticsearch in the right way or is the approach (different tables and join) totally wrong. If it is correct what would be the best way to represent different “tables” in ElasticSearch terminology.

Also for elasticsearch what is the best way to deal with identity information in objects. Is it best to map _id to an id field in each object or store my own id field?

Cheers,
Rob

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve seen comparisons that say in ElasticSearch an Index is comparable to a database, and a table is comparable to a type.

    I think you could go about it a basically two different ways.

    Option 1: One Index and One Type. Each subtype of Activity is indexed into one type in ES, and some documents have missing fields.
    This would give you,

    • One type mapping to support, if the defaults aren’t sufficient, you’d have all the fields of all your subtypes.
    • Common fields must be analyzed the same.
    • Documents all have only subset of fields per type (not really a problem, just weird)

    Option 2: One Index and multiple types. Each extension of Activity is a type in ElasticSearch.

    • Many Type Mappings to support.
    • Common fields can be analyzed differently.
    • Each document, in theory, has all fields of mappings.

    In either approach, you can search all subtypes. I think the complexity of the search requests would depend on the application.

    For most applications, I think I would prefer option 2. Each subtype of should be its own “type” in ElasticSearch. You can use Facets across types if you wanted. If your subtypes are relatively simple, I think you could make a case option 1 though.

    When you implement it, I’d love to hear how it worked out.

    • 0