9

I am designing a big travel market agency, where I have 170000 hotels and 3000 room types.

A simple representation of my entities is:

Hotel:
    destination: Paris
    rooms:
        room_a:
            type: single
        room_b:
            type: double
RoomType:
    name: double
    paxes(people in room): 2

The most basic search action requires from the user the destination and the number of required rooms and the paxes(people) in each room.

It seems to me a simple SQL query to get all the hotels that provide the required rooms, but I am concerned about the size of my data.

Until now, I have used only relational databases and I have no previous experience with NoSQL databases such as MongoDB and ElasticSearch and I would like to know how much faster it would be to use MongoDB or ElasticSearch vs a relational database. I have read that the typical usecase for elasticsearch is full text search but I do not know how much faster it would be for a search like this.

Thank you

iiirxs
  • 4,493
  • 2
  • 20
  • 35

2 Answers2

10

A non-relational option might give you significant search speed enhancements simply because of how slow joins can be on large datasets. With something like Mongo or Elasticsearch, you would create a single document with all of your relevant information on it and search that. That might seem counter-intuitive coming from a relational background -- but the idea is that information accessed together is stored together.

As for elasticsearch vs. mongo, here's a couple of things to consider:

  • Elasticsearch will be easier to transition into fuller featured search functionality. Full text searching for particular hotels? Search as you type? Suggestions? "Did you mean" functionality? But it's also really good at structured filtering like you describe.
  • Elasticsearch should probably not be used as your primary data source. It's less reliable than Mongo or SQL. It's not a bad product by any means, but the distributed nature of it means that if you super value the integrity of your data, just use elastic for searching.
    • The offshoot of this is, you must build your index ahead of time to search against. This adds both complexity and can delay the "real time" updating of your data. Ultimately this is part of how searching is so fast -- just like with SQL indexing, you make your reads faster by slowing down your writes.
  • While it's pretty easy to get something working with either Elasticsearch or Mongo, I think the learning curve on Elasticsearch is a little steeper. There's a lot you can do with Elasticsearch, which makes it a little harder to sift through.
  • Be cognizant of your production plans as well (if you're putting this into production). Elastic and Mongo will both be more complicated to set up than just a SQL Db. No licensing costs, but multiple boxes for replication or even going with a hosted solution can get pricey.
Tracy Moody
  • 1,089
  • 6
  • 17
3

Every Database framework has its own pros and cons, however, in my experience, Elasticsearch is good for the following reasons:

  1. Very easy to get it up and running.
  2. Scales horizontally with inbuilt cluster discovery for major cloud providers.
  3. Your data structure is a nested object and elasticsearch index mapping supports this.
  4. Highly performant and you can tweak your server RAM:Disk ratio according to your requirements.
  5. Support for various text analysers available.
  6. You have fine-grain control over what part of your document must be made searchable.
  7. APIs available for major programming languages.
  8. If you want more features like monitoring, alerting, security etc, you can subscribe to elastic's x-pack, which is pretty cool.
harishkb
  • 406
  • 3
  • 7