This document summarizes an OTA (Online Travel Agency) platform that uses MongoDB as its database. The platform allows one stop shopping for hotels, flights, tours and other travel products. It also facilitates B2B travel. MongoDB is used because it is fast, allows flexible schema design, and saves time on database tasks like handling dynamic data through embedded documents. Some data is stored in referenced collections to handle large amounts of data like room rates and media files.

1. OTA Platform
with MongoDB
with MongoDB
talks 19 Jan 2013

2. About Our Application
• One stop shopping OTA (Online Travel Agency)
• Regular
• Flash Deals
• Various type of products
• eg: hotels, flights, tours/activities, campaigns (flash
deals), etc
• Facilitate B2B travel

3. About Our Application

4. IS THAT IT?

5. About Our Application
Travel Ideas
• Travel News, up-to-date info all around the world
• Travel Tips
• based on places (countries, cities, areas)
• covers various aspects, such as overview, sightseeing,
eating/restaurants, shopping and events
• Travel Stories, submitted by members
• Photos and Videos
• Blog, monthly theme posts based on event calendar

6. TRAVEL BUSINESS
BREAKTHROUGH

7. SOON ON YOUR BROWSER

8. Technology Overview
These are stuff that we use behind our apps
Web Server : Apache
Application : PHP
CodeIgniter (PHP MVC Framework)
Backbone.js (Javascript Framework) with its friends
Require.js, Underscore.js, Mustache.js, jQuery
Database : MongoDB

9. Why MongoDB?
• It’s fast
• Development speed time faster
• No join, no relation
• No sql injection worries (you bet)
• Reduced database requests
• Super flexible schema design
• Fewer tables/collections used

10. What do we store in
MongoDB?
All datas are stored in MongoDB.
Including important data such as bookings,
inventory, etc.

11. Building the Apps...
We will tell you guys how
MongoDB helps us a lot

12. Saving huge amount of time
on database stuff
spreadsheet is more than enough
db structure alters and changes
straight on the code

13. With RDBMS approach, dynamic
data is pain in the a*s
Embedded documents to the rescue
This is how we handle dynamic data on our apps

14. Use Case
• Hotels may have multiple contracts
• One hotel contracts may have multiple
bank accounts
• Hotels may have multiple facilities
• Hotel facilities have several categories

15. Schema Design
MongoDB approach
RDBMS approach
more or less like this...
plus two/three tables for reference data

16. And now the query...
“get me hotels with its facilities which has BCA account in
Jakarta only”
RDBMS approach
SELECT * FROM hotels
INNER JOIN facilities ....
INNER JOIN photos ....
AND THEN JOIN the_banks ....
AND OF COURSE JOIN the_locations ....
AND JOIN the_city ....
WHERE
the_city IS “Jakarta”
AND
the_banks IS “Bank BCA”
We all know JOINs are expensive.
Use EXPLAIN on SQL to see it

17. And now the query...
“get me hotels with its facilities which has BCA account in
Jakarta only”
MongoDB approach
db.hotel.find( { “locations.city” : “Jakarta” , “contracts.banks.name” : “Bank BCA” } )
One single query to fetch all the data we need

18. Be wise when choosing which
Data Models are used
Embedded documents not applied to all data model
We use referenced model when it comes to very
large record sets / documents

19. Model Referenced One-to-Many
Relationships between Documents
http://docs.mongodb.org/manual/tutorial/model-referenced-one-to-many-relationships-between-
data-modeling-publisher-and-books
Normalize the data, just like RDBMS approach but
using “fake” relationship
Use key/id to store references between two documents

20. Use Case
• Each hotel may have multiple room types
• One room type may have up to 10
photos/videos
• Each room type have their rate/price
• Room rates based on contract period
(one or more years)
• Room rates stored daily

21. Use Case
Example :
A Hotel has 5 room types
Each Room type has 10 photos
Hotel contract period is one year
5 room types x 10 photos = 50 documents
5 room types x 365 room rates = 1825 documents
Total documents for 1 hotel :
1 + 5 + 50 + 1825 = 1881 documents

22. Use Case
Example :
Total documents for 1 hotel :
1 + 5 + 50 + 1825 = 1881 documents
If we have 1500 hotels then 1881 x 1500 = 2.821.500
What if we have more than 1500 hotels?
What if a hotel have more than 5 room types?
What if a room type has more than 15 photos?

23. And then we decided to separate the
collections that potentially has huge data
example : room_rates, hotel_media, etc

24. More to see...
• Other slides
• http://www.slideshare.net/h.ariawan/okezonecom-inline-voting-system
• http://www.slideshare.net/h.ariawan/sekilas-php-mongodb
• Codes and Articles
• https://github.com/hadiariawan/monode-crud
• http://hadiariawan.web.id/2012/06/27/simple-crud-web-using-nodejs-and-
mongodb/

25. @hadiariawan
hadi.ariawan
http://about.me/hadiariawan