Interactive Visualization of Terascale Data in the Browser ...
System Architecture and Wire Frames. Rider/Drive r Major Modules Cloud Google Maps Personal Data...
-
Upload
adelia-thornton -
Category
Documents
-
view
215 -
download
1
Transcript of System Architecture and Wire Frames. Rider/Drive r Major Modules Cloud Google Maps Personal Data...
System Architectureand Wire Frames
Rider/Driver
Major Modules Cloud
Google Maps
Personal Data
Routing Data
Phone Interfaces
Browser Interface
• Drivers and Riders use a common interface that can run on either a phone (iPhone, Android, SMS) or a browser (Firefox, Explorer, Chrome). We can start with just a browser, usable on smart phones.• Requests for service and profile modification are recorded in the personal data base which is kept synchronized
between the interface device and the cloud.• The Trip Manager is communicates with all active users, receiving location information and coordinating real-
time communication.• Matches are performed in the Routing Data module which uses Google Maps for basic services but maintains a
large graph of all trips planned or requested.• Google Maps is also used to create presentations for the interfaces.• Italics designates outsourced modules.• Not all connections are shown.
Billing System
SMS Service
Mail Service
Trip Manager Traffic
Monitor
BoE Data Requirements
• Each user requires a negligible amount of data, easily held on a smart phone: contact information, current co-ordinates, social network, preferences, current plans, past trips
• The Routing Data base might be big.– For every existing street segment or planned traverse of a street
segment, 103 bytes– Manhattan has over 125 cross streets and 12 avenues, so it has over
2*125*12 = 3,000 street segments– Suppose 10% of our N customers have 20-block trips in the data base
at any time. 2*N planned segment traverses.– 103*(3000+2*N) = 3*106+2*103*N = 3*106+2*106*(N/103)
= 3 + 2*n MB for n thousand users. – For 1 million users, about 2GB—still not much.
BoE Processing Requirements
• We’d like instantaneous response for active users, but network delays will probably dominate, so programming convenience is probably the more important consideration. Dedicate a virtual processor to each one.
• Suppose .01% of 106 users are active at a time. Requires 100 processes = 100 Heroku Dynos and 100 Heroku Workers. About $6,000 per month.
Start time: (now)
Date: (today)
End place:
Start place: (here)
Return start time:*
Repeat* Daily
MTWTF
Weekly
Ride Offer
Make Offer
Specify Route
Ask per trip: $
Date: <rider’s date>Time: <rider’s time>Start:<rider’s place>End: <rider’s destination>Offer: $ <rider’s offer>Name:<rider’s name>*Cell: <rider’s cell>*Email: <rider’s email>*
Send
My email
Ride Request for You
My Name
My cell
Yes
Maybe
Message
No
Start time: (now)
Date: (today)
End place:
Start place: (here)
Return start time:*
Repeat* Daily
MTWTF
Weekly
Ride Request
Request
Offer per trip: $
Xxx: (preset)
Xxx: (preset)
Xxx:*
Xxx: (preset)
Xxx
Xxx
Title
Xxx
Xxx
XXX
Details:
Confirm Ride
Send
The ride was…
bad
aborted
good
<day><time><start><end><people….>
Email:
Name:
Birthday:*
Cell Phone:
Profile
(X)
Use for real-timecommunication
I would drive*
if it took less than
Gender*
(10)extra minutes.
I would charge the rider $ (1.00)
plus $ (0.00) per mile
I would ride*
if it took less than (10)extra minutes.
I would pay the driver $ (1.00)
plus $ (0.00) per mile
FemaleMale
Prefer Female RidersMale Riders
Prefer Female DriversMale Drivers
Submit
Password:
Set Billing Information
Link to Facebook