Real-Time Spatiotemporal Data Utilization For Future Mobility Services: Atsushi Isomura

0 1 10 .. 2 2 1
Real-time spatiotemporal data utilization
for future mobility services
Atsushi ISOMURA
NTT(Nippon Telegraph and Telephone) Corp., Researcher

0 1 10 .. 2 2 1
About me
- Atsushi Isomura (call me SUSHI)
- Tokyo, Japan
- Work
- NTT Software Innovation Center
- OSS, in-memory, data storage, distribution, etc.
- “Spatio-Temporal data processing”
- Free time
- Develop smart-phone apps
- Nintendo Switch (Splatoon2 : rank X, SSB Ultimate : Elite)
- Baseball
- Drive cars (Desire : Drive without traffic jam)

01 2. 021 . 3 3 2
1. Motivation
2. Spatio-temporal data utilization in redis
3. Proposal
4. Performance
5. ST-code generation tips / Sample codes
#Links of codes and slides at the end.
INDEX

01 2. 4 021 . 4 2
1. Motivation

34951 0 354 22 1 0 6 .6.5 .
1-1. Background
These IoT devices keep INCREASING!
ref1 : 2016 estimation of Fuji Keizai Marketing Research & Consulting Group
ref2 : 2016 estimation of Yano Research Institute
[hundred million]
‘16 ‘20
2.6
5.4
[hundred million]
‘16 ‘20
1.1
3.2

0162. 021 . 2
1-1. Background
IoT sensorsIoT devices
What’s the difference?

01 2. 7 021 . 2
1-1. Background
1. They MOVE every moment!
Latitude Longitude Time Value
37.800 -122.402 2019/4/2 12:30:15 ID:1234, 30km/h
37.798 -122.400 2019/4/2 12:30:16 ID:1234, 31km/h
… … … …
ST(Spatio-Temporal) Data

01 2. 021 . 2
1-1. Background
2. The density CHANGES by location & time
Metropolis
Suburb
Metropolis
Suburb
High
Low
Low
High

0 1 10 .. 2 2 1
1-2. Future mobility services
Example1 : Nearby car crash alert
car
crash
alert
Broken car
on abc Street
real-time
view
Alert !
Crash!

0 1 10 .. 2 2 1
redisconf19 ended
train arrived
Example2 : Optimal routing for taxis
taxi
waiting
events
party closed Input
- location of waiting people
- event information
- traffic jam
- etc.
Calculate optimal
route automatically

0 1 10 .. 2 2 1
I need to send this
package NOW!
Nearest drone available
Example3 : Drone package delivery
drone
package

0 1 10 .. 2 2 1
1-1. Background
IoT devices Important Features
1. MOVE
2. Density CHANGES
Future mobility services
- real-time response
- ST-data insert
- ST-data search

01 2. 021 . 3 3 2
1-3. Requirements and current technology
1. Insert bunch of ST-data in real-time (<10ms)
2. Search by ST-range query in real-time (<100ms)
3. Distribute data equally regardless of density changes
- All requirements must be satisfied
Data store AppsCars
1. over 20M rec/s[1]
[1] : Fuji Keizai Marketing Research “Connected car related markets and telematics strategy 2017”
(Estimation only in Japan)
2. lng:x1~x2 lat:y1~y2 time:t1~t2
Value
No matured technology that could satisfy all requirements.
ST-range query
3.

01 2. 4 021 . 4 2
1-4. Which data store to use?
Of course we selected “redis”
We searched for…
- blazingly fast performance
- geo features
- secondary indexing
- data distribution
We studied from RedisConf…
redisconf17
Using “Geohash-encoding” & “Sorted-set”
enable ST-data management in redis

01 2. 021 . 25
2. ST-data utilization in redis

0162. 021 . 2
2-1. Related commands
https://redis.io/commands
Geo related commands Sorted-set related commands
Utilize “Geohash[1]”
encoding algorithm
[1] : http://geohash.org/

01 2. 7 021 . 2
2-2. What’s “Geohash”?
2-dimensional
longitude(x), latitude(y)
1-dimensional (Geohash)
x1y1x2y2x3y3 … xnyn
length : short=wide long=narrow
0
00
01
0
10
101100
010
011
10
1
1
11
San Francisco(x, y)
lv.1 0 1
lv.1 lv.2 0 1 0 1
0
0
1
1
0
1
Morton-curve[1]
level-1 level-2
n : length of each dimension
01 10 …

01 2. 021 . 2
2-2. What’s “Geohash”?
Useful feature
Prefix match = Range query of longitude & latitude
0
00
01
0
10
101100
010
011
1
1
11
10…
1001…
100110…

0 1 10 .. 2 2 1
2-3. Insert/Search requirements
- Insert : longitude(x), latitude(y), time(t), and value
- Search : range query of location and time
x y t value
37.798° -122.402° April 2nd 2019 14:10:15 30 km/h
… … … …
Query : Search all values of…
- GEOHASH with prefix of ‘x1y1…xqyq ’
- TIMESTAMP between t1 and t2
q : length of each dimension for prefix search

0 1 10 .. 2 2 1
>ZADD time_a geohash_a “ID, …”
(integer) 1
>GEOADD time_a geohash_a “ID, …”
(integer) 1
2-4. Possible Key-Value design
-Key
Timestamp
(string)
-Score
Geohash
(int)
-Value
time_a
geohash_a ID, …
… …
time_b
… …
… …
… … …
-Key
Geohash
(string)
-Score
Timestamp
(int)
-Value
geohash_a
time_a ID, …
… …
geohash_b
… …
… …
…
Pattern 1. Time key sorted by Geohash Pattern 2. Geohash key sorted by Time
Either of them works fine
>ZADD geohash_a time_a “ID, …”
(integer) 1

0 1 10 .. 2 2 1
2-5. How to search by range
>ZRANGEBYSCORE t1 x1y1…xqyq…00 x1y1…xqyq…11
>ZRANGEBYSCORE t1+1 x1y1…xqyq…00 x1y1…xqyq…11
…
>KEYS x1y1…xqyq*
(return list[i] of all keys that start with x1y1…xqyq )
>ZRANGEBYSCORE list[0] t1 t2
…
>ZRANGEBYSCORE list[i] t1 t2
query by circle : GEORADIUS instead of ZRANGEBYSCORE
-Key
Timestamp
(string)
-Score
Geohash
(int)
-Value
time_a
geohash_a ID, …
… …
-Key
Geohash
(string)
-Score
Timestamp
(int)
-Value
geohash_a
time_a ID, …
… …
Pattern 1 Pattern 2
(q : length of each dimension for query)

0 1 10 .. 2 2 1
>KEYS x1y1…xqyq*
(return list[i] of all keys that start with x1y1…xqyq )
…
>ZRANGEBYSCORE list[i] t1 t2
…
2-6. Range query takes time
Pattern 1 Pattern 2
Turn around time/Query 1.3 s 535 s
Simple test by using 5 redis-servers
(concurrent connections : 256, number of values : 10 million, search only)
Pattern 1 Pattern 2
[1] : https://redis.io/commands/KEYS
Search too many Keys.
Slow!
Danger![1] Too slow!

01 2. 021 . 3 3 2
…
Pattern 1
Turn around time/Query 1.3 s
Pattern 1
Slow!
It takes more than 1s.
Let’s reduce the Keys

01 2. 4 021 . 4 2
…
Pattern 1
Turn around time/Query 1.3 s
Pattern 1
Slow!
It takes more than 1s.
Let’s reduce the Keys
Wait!
Problem is left!

01 2. 021 . 25
2-8. Another problem?
Suppose that…
- Tons of cars send data continuously
- Applications require current data
- Multiple Redis-servers are available
AppsCars
redis1
redis2
redis3…
redisN
What will happen?
-Key
Timestamp
(string)
-Score
Geohash
(int)
-Value
time_a
geohash_a ID, …
… …
Pattern 1

0162. 021 . 2
redis1
redis2
redis3…
redisN
2-8. Load concentration (intensive access)
current timestamp key
Idle
busy
We send
current data!
We need
current data!
AppsCars

01 2. 7 021 . 2
redis1
redis2
redis3…
redisN
2-8. Load concentration (intensive access)
current timestamp key
Idle
busy
We send
current data!
We need
current data!
AppsCars

01 2. 021 . 2
2-8. Load concentration
1 2 3 4
24
24 redis-servers
( concurrent connections : 256 (data insertion only) )
Cannot use CPU resource efficiently
CPU usage (%)
User/System
usage(%)Idle(%)
0
100
spike
0
50

0 1 10 .. 2 2 1
2-9. Problems we need to solve
Problem 1.
- ST-range query is slow due to
- searching too many Keys
- using the “KEYS” command
Problem 2.
- ST-data insert is inefficient due to
- load concentration

01 2. 021 . 3 3 2
3-1. Applying “ST-code”
0
00
01
0
10
101100
010
011
1
1
11
Morton-curve transform for longitude, latitude, and time
timestamp
[1] Jan Jezek, “STCode : The Text Encoding Algorithm for Laitute/Longitude/Time”,
Springer International Publishing Switzerland 2014
ST-code[1] : x1y1t1 x2y2t2 x3y3t3 … xnyntn
prefix match = range query
timestamp
Min.
timestamp
Max.
current time
0 1
1110
100 101

01 2. 021 . 3 3 2
-Key -Score -Value
PRE-code_a
SUF-code_a ID, …
… …
… … …
ST-code : x1y1t1 x2y2t2 x3y3t3 … xnyntn
split
PRE-code : x1y1t1 … xsysts
(express WIDE st-range)
SUF-code : xs+1ys+1ts+1 … xnyntn
(express NARROW st-range)
>ZADD PRE-code_a SUF-code_a “ID5, …”
(integer) 1
s : where you split
Don’t make me use the
KEYS command!

01 2. 021 . 3 3 2
-Key -Score -Value
PRE-code_a
SUF-code_a ID5, …
… …
… …
>ZRANGEBYSCORE PRE-code_a
xs+1ys+1ts+1…xqyqtq…000 xs+1ys+1ts+1…xqyqtq…111
Very Fast! Problem solved!?
(restriction : s < q)
s : where you split
q : length of each dimension for prefix search
ST-range query only in one command!

12 3 . 132 00 . 4 4 3
Don’t forget about this…

12 3 .5 132 00 .5 3
Problems we need to solve
Problem 1. (Solved by ST-code!)
Problem 2. (not yet)
search only 1 key
“ZRANGEBYSCORE”

12 3 . 132 00 . 36
3-2. Limited node distribution
insert
• Select multiple nodes based on the hashed value of ST-code(PRE-code).
• Insert to “one” of the selected nodes.
• Search from “all” of the selected nodes.
San Francisco, 7:00
7:03
…
7:00
7:01
7:02
search
7:00～7:01
San Francisco,
ST-range query
avoid load concentration efficient search
#works as above when applying ST-code(PRE-code) as Key
time
selected nodes

1273 . 132 00 . 3
Problems we need to solve
Problem 1. (Solved by ST-code!)
Problem 2. (Solved by Limited node distribution)
search only 1 key
“ZRANGEBYSCORE”
load distribution

12 3 . 8 132 00 . 3
3-3. Architecture Overview
(A)ST-code & (B)Limited node distribution are applied.
calculate ST-code
split ST-code into PRE-code & SUF-code
calculate hashed value of PRE-code
calculate insert/search node number
1 2 3 4 5
PRE-code ⇒ “Key”
SUF-code ⇒ “Score”
PRE-code ⇒ “Key”
SUF-code ⇒ range query of “Score”
Cars (insert) Application (search)
time lat lng value
Redis
(B)
ST-code value ST-code
PRE-code
valuenode num
valuetime lat lng
(A)
SUF-code
PRE-code SUF-code node num PRE-code SUF-code

01 2. 021 . 3 3 2
4. Performance

01 2. 4 021 . 4 2
4-1. Compared methods
-Key -Score -Value
PRE-code_a
SUF-code_a …
… …
… … …
1. ST-key method (ST-code & Limited node distribution)
2. Time-key method
-Key -Score -Value
time_a
geohash_a …
… …
… … …

01 2. 4 021 . 4 2
4-2. Experimental conditions
Concurrency
(max)
Data size
(KB)
Redis server nodes
“selected nodes”
for proposed method
insert 640
10 24 8
search 320
Data inserted (10 million data) Data searched (100,000 query)
time range : 15min
area : 3km2
(1) : http://www.nyc.gov/html/tlc/html/about/trip_record_data.shtml
dense/sparse
depending on area(2)
time Current timestamp
longitude
NY Taxi open data(1)
latitude
value ID, speed, etc.
(2) : referred from https://toddwschneider.com/posts/analyzing-1-1-billion-nyc-taxi-and-uber-trips-with-a-vengeance/

42 .. 42 9 191 10
4-3. System configuration
8 : ) 2) : ) 2) 4
# Software version
1
Client
Jedis 2.9.0
2 Test Program(TP) -
2 MW Java 1.8.0
3 Server redis 5.0.3
4 OS Ubuntu 16.04.1 LTS
# Specification
1 server all in common
Intel Xeon E5-2618Lv4 10 core 2.2GHz 25M cash x1
256GB DDR4 1.2v ECC REG DIMM 32GBx8
SSD : 2.5inch 480GB SATA3 2
HDD : 2.5inch 1TB 7200rpm SATA3 2
3 NW Infiniband SW
AMellanox IB Switch
MSB7800-ES2F Switch-IB™-2 based EDR InfiniBand
1U Switch, 36 QSFP28ports
1049
.
) (
1049
.
1049
.
#
1049
.
…
…

12 3 . 132 00 . 4 4 3
4-4. Insert performance
• ST-key method is 13 times better in throughput, 12 times better in turn around time(TAT).
Throughput (rec/s)
0
20000
40000
60000
80000
ST-key Time-key
Average TAT (ms/rec)
0
10
20
30
40
ST-key Time-key
12
(concurrency : 256)
1376000
5000 3
40

01 2. 4 021 . 4 2
4-4. Insert performance (CPU resource)
ST-key Time-key
Average CPU usage of all servers 81% 5%
• ST-key method can fully use CPU resource of servers.
• ST-key method distributed processing load to servers equally.
ST-key Time-key
fully used spike
User/System
usage(%)
Idle(%)
User/System
usage(%)Idle(%)
0
100
0
70
0
100
0
50

12 .5 1 2 00 .54 4
4-5. Search performance
• ST-key method is 5 times better in throughput and TAT.
(concurrency : 256)
0
1000
2000
3000
4000
ST-key Time-key
0
100
200
300
400
ST-key Time-key
Throughput (query/s) Average TAT (ms/query)
553500
680 70
360

12 . 1 2 00 . 4 4 6
4-5. Search performance (CPU resource)
• ST-key method enables better performance with less CPU usage.
ST-key Time-key
ST-key Time-key
Average CPU usage of all servers 51% 65%
40
User/System
usage(%)
Idle(%)
User/System
usage(%)
Idle(%)
100
0
0
50
less CPU
0
100
0

127 . 1 2 00 . 4 4
4-6. Results in summary
Both requirements are satisfied
1. Insert bunch of ST-data in real-time (<10ms)
2. Search by ST-range query in real-time (<100ms)
ST-key method
AppsCars
Value
ST-range query
redis
1. 3.3ms/insert 2. 70ms/query

12 . 8 1 2 00 . 4 4
5. ST-code generation tips /
Demo(console)

01 2. 021 . 25
5-1. ST-code generation ( stencode/stencode_naive.py)
def st_encode(lon_input, lat_input, time_input, precision=96):
lon_interval, lat_interval, time_interval = (-90.0, 90.0), (-180.0, 180.0), (0.0, 2018304000.0)
st_code = ‘’
loop = 0
while len(st_code) < precision:
if loop%3 ==0:
mid = (lon_interval[0] + lon_interval[1]) / 2
if lon_input > mid:
lon_interval = (mid, lon_interval[1])
st_code += '1'
else:
lon_interval = (lon_interval[0], mid)
st_code += '0'
elif loop%3 == 1:
mid = (lat_interval[0] + lat_interval[1]) / 2
if lat_input > mid:
lat_interval = (mid, lat_interval[1])
st_code += '1'
else:
lat_interval = (lat_interval[0], mid)
st_code += '0'
else :
mid = (time_interval[0] + time_interval[1]) / 2
if time_input > mid:
time_interval = (mid, time_interval[1])
st_code += '1'
else:
time_interval = (time_interval[0], mid)
st_code += '0'
loop += 1
return st_code
Too naïve!!!
Too slow!!!

01 2. 021 . 25
input = [lon_input, lat_input, time_input]
maxmin = [(-90.0, 90.0), (-180.0, 180.0), (0.0, 2018304000.0)]
def st_encode_FAST(input, maxmin, precision=96):
bins=[]
precision = int(precision/3)
for (i, m) in zip (input, maxmin):
tmp = (i-m[0])/(m[1]-m[0])*(2**precision)
tmp = format(int(tmp),'b')
n_lost = precision-len(tmp)
bins.append('0' * n_lost + tmp)
st_code = ''.join(b1+b2+b3 for b1,b2,b3 in zip(bins[0],bins[1],bins[2]))
return st_code
5-1. ST-code generation ( stencode/stencode_fast.py)
Much faster

01 2. 021 . 25
5-2. Demo (console)
- Data insert (st_insert.py)
- Data search (st_search.py)
redis client
PyPIredis
MW
OS
st_insert.py st_search.py
redis server
redis
OS
- key : PRE CODE
- score : SUF CODE
- value : ID, lat, lng, time
- key : PRE CODE
- score : SUF CODE
- value : ID, lat, lng, time

12 3 .5 132 00 .5 3
Contact me anytime
E-mail : atsushi.isomura.bt@hco.ntt.co.jp
SlideShare : sushi boy
(Today’s ppt : https://www.slideshare.net/secret/DTlOu6Wzg4bGHz )
Github : sushi-boy
(Today’s repository : https://github.com/sushi-boy/stcode-redisconf19 )
FaceBook : Atsushi Isomura
NSW Friend code : 0092-0570-5252
Any questions?

12 .5 1 2 00 .5 6
Limited Node Distribution

127 .5 1 2 00 .5
Limited node distribution (insert)
-Insert
1. Calculate multiple nodes according to PRE-code
2. Insert to one of the nodes selected randomly
N(number of nodes) = 5 D(number of distribution) = 3
# node1 node2 node3
1 redis1 redis2 redis3
… … … …
NCD redis3 redis4 redis5
combination_table
Longitude(x), Latitude(y), Time(t)
i = hash(ST-code.PRE) mod NCD
3d_morton(x, y, t, precision=max_length)
combination_table(i)
ST-code
redis1 redis2 redis3 redis4 redis5
random.choose(candidates)
Define “max_length” beforehand
- 63bit : 20m 10m 20s
- 96bit : 20cm 10cm 0.2s

12 .58 1 2 00 .5
Limited node distribution (search)
-Search
1. Calculate multiple nodes according to pre-code
2. Search to multiple nodes
range of Longitude(x), Latitude(y), Time(t)
i = hash(ST-code.PRE) mod NCD
3d_morton(x, y, t, precision=search_length)
combination_table(i)
ST-code
N(number of nodes) = 5 D(number of distribution) = 3
# node1 node2 node3
… … … …
NCD redis3 redis4 redis5
combination_table
“search_length” is calculated
depending on the range width

01 2. 021 . 25
Research background
Related Technology

0162. 021 . 2
2-1. Research Background
• ,A/ A D C <D < < A < AD
• AD AD D < A ./ . <A / AD <
L < AD AD 1 1 D <
1 < < D< AD D< D< D <
DA < AD < A < DA
(- 1 - 1-
. < ( A L
. < < ( < L
. < < ( L
-
< 1 < < D<
D -
), / <
DA <
) D A < D
A < D
) D A
D <
, AD <A
I DA
AD D < D < A < <
(- 1
2 3 /
A < A
2
3

0162. 021 . 2
2-2. Research Positioning
I D
KBE
K A
BJ A - BK
, GJ KB D L IB J NBKA A - BK
A
, G1 J
IC K
T
GJK,-
R GJK I S
-E EGMB IG JJB
B JB K J J
II O
K J
T
-E EGMB J JB K A GDG O
R-G , 3( K S
-G J JGI K E B3 DB
3 DB
G
DGL
- ( - ) (
• )G JB IB J KBG K E GI D E B K A GDG O GI GKA
PJKIL KLI K DG J JKIB J M DL J K Q
P G JKIL KLI K EGMB J JGL J K Q
J KBG K E GI D E B -)
-E EGMB JKI E IG JJB
-) G LJB K A GDG O
T 3I D B D Rasdaman SciDB, TileDB
( 2) , G IC KB D IC
T , G. 32R1G G ( D JKB I A
2G
T
Geo databases
KIL KLI K 2G JKIL KLI K

0162. 021 . 2
2-3. Geospatial Database
( /
+:C G F:P
Client Client
C ( F
+
E E
Server AP
OS/MW
+
E E
:EI:E
/
+
E E
+:C
• E B L G CB C +:C B CEA G CB
) )
) ) ) ) (
- CDC C G:OM AD : : G E:F D: G CB CE JE GG:B B - I
+) M AD : : G E:F D: G CB CE JE GG:B B
• :E: E: F GJC G D:F C F FG:A F B + E E :F
G B CB: G D: F FG:AO DD + E E BF : F:EI:E
+:C G F: G D: F FG:A F B G F: G G DECI :F + E E

9 3 A 9 66 3 2 2 21
2-4. JTS Topology Suite
• CHGL
O1, 3 AD GH F 3D G CB C 32 J GG B B / I
• 133 G G D CI F /43
D B G L B A AC G D CI , , B C D
CA F L G F G G B F D C FF B G C - F ,CC G
, C3 I L3 I FC GJ C G B B F B , C G
9
2. 3
96 39
6 9
6 2. 3
6 96 39
29 2 96620 9
A G C G CI GCH F FG B
CHG
G G C
CB DC CB
G G DC BGF
BF CB
DC CB
G G B
B DC CB
CBG G
H G G
A B AHA
FG B
F DC CB DC CB DC BGF DC CB B
GH B 4 H F 4 H F FG B
A
polygon1
polygon face
face
distance
Calculation examples for polygons
[1] https://github.com/locationtech/jts
[2] https://www.gridgain.com/technology/apache-ignite
[3] http://www.geomesa.org/
[4] http://geoserver.org/
polygon
line
O, CA G 4 D C F

12 . 1 2 00 . 4 4 6
2-5. Geospatial Index
//
1
)/ 2 2 /- 1 / )/ 2/A 2/A 1
/
-/
/
/ / 1 /A //
2 12
// 1 /A //
/ -2
/
/ - / /A 1 //
2 12
/ / / -2 -/
( /A
/ /
2 12
/ / A / /- -2 /
• / / -2/ / - - / )/ /A /-2 1 /
//C -2 1 /- 1 // /A 1
/ 1C -2 1 -/ 1 - /
• 2 / / / 2/ / /

CID F ( DC ) 2 F 29 9D 9
2-6. Spatio-temporal Database
• 1 VVJR TF NS JQTSVFP IF FGF J FVJ VJFPN JI G] NRL MJ JHMRSPSL] SK
A : SA : A71 N [SVONRL SR 7R QJQSV] SVFLJ JHMRN J S VJFPN J VJFP NQJ
TF NS JQTSVFP IF F TVSHJ NRL QFRFLNRL
1.
L CC DF FD5A 5 F A
1.
L A C9D D 5A 9 5A 5 56 FI
-A 9 DI
F D5 9
VJFP NQJ
09D F9A 9
F D5 9
65F
D E / A V J] SK ATF NS BJQTSVFP 2F FGF J J JFVHM B L ]JR J FP 3I . /1772A , : /7 ) TT ) ,
D E A V J] SK ATF NS BJQTSVFP 2F FGF J B/ /A /0 /6/ / 2 8 6 22719 5JS7RKSVQF NHF (. -- ---
7R QJQSV] IF F LVNI
2 0A
7R QJQSV] 9J] CFP J SVJ
SA :
S LVJA : S 57A
( -
SRLS20 3PF NH AJFVHM 5JS 8A
S LVJA : 7RKP 20 TJRBA20 a
) / - LJS
NQJ
JVNJ
BFVLJ SK
A71

0162. 021 . 2
Problem of current technology

127 . 1 2 00 . 6
3-1. Overview
• 7: 1 / 7 02 3 1 2 1 3 8 7 72 1 82 : 7 2 05
1 33 0 7 0 2 205 :7:4
:B I MI : M D /- D 187
:B I MI : M D K D B : B D D D B
K C D /- 187
I
DI Q
I CKB
C DI D B
I
K C D
DI D D
D
DI D CB
B : B D
K D DI Q
I D
I D Q
C B BD L B
, ,() L
, , ) ) L
,) , ( L
P P P
:B :B
/- , 4 I 752 3 752
187 , I / D C
1 8 BK
, ,() L
, , ) ) L
,) , ( L
P P
/- 187
70 KI D D
-221 2 05
02
2 320 8 05
: 7 : /72
DI
B M DI
D CBD D
7: 1 0: 02 :
77 :12 2 05

0162. 021 . 2
3-2. Spatiotemporal index
• 2 A A E A - . K A EA 7 9 EA E 9 5E E 9 5 A E 9 EA 7 95E9
5E AE9 A 5 9 3 9 9 7A 9 E EA 09 5 45 9
• ::97E
1A 99 A: 5E 9 E 99 9 56 9 6 6 1 6
2 9: 95 7 9 56 9 6 0 6 3 0 1 21 1 -
3 6 26 032 1 9 2 6
E N E N N
E 9 6 E 5E E 9 6 E A E 9 6 E
33 02 621 1 3 6
0 1 21 02 621
01211-1
A
) 0
) 0
7
7
N
N
N N
1
3 9
-
(
) (
1(
(
E E E E(E)E E N E , ( (E N E
( 95
E A: 95 E
9 E A: 95 E12
1 9 6
6 9 A 9

01 2. 7 021 . 2
3-3. Limited node distribution
• 7 . 0 0 7 0 0 7 7 .. 72 0 7 02 7
• 110. C 307 72 3 0 7 0
E 20 0 7 7 .3 07 1 0 7 0 3 .3 07 - 0
- 7 7 1 0 7 0 .3 - 0 3 .3
0 .3 . 7 . 0 7 . 7 0 3 .3 07 - 0
0
…… 720 : 0

01 2. 7 021 . 2
-+ A? ? C ?
5A C C ?C ?A 1 5?
CA 5C C I ?A ( 4 C ? 1 5?
5 5D C D ? 1 5?
5 5D C AC A5 ? D 4 A
1 2 3 4 5 6
?A ( 4 C C?A C? I.
CC A ( 4 C C C?A C? I D
5C C5 A5 K ?A ( 4 C
A A5 K CC A )) 4 C
-?1 5 AC 5 C ? A5
C C C
/ CA 4DC ?A .
(B)
1 5? C 1 5?
1 5? K (4 C
1 5? C? D 1 5?? D
CC C
(A)
3-4. Proposed Method
• /DA A? ? C ? ( ) ( ( ( ( ( (
5 D C C 4 ?

1273 . 132 00 . 3
3-5. How to apply to OSS
• : :2 2 . 2
0 - ) 0 1 0 A 11 - ) 0 - 0 A -
0 - ) 0 1 0 A 0 - ) 0 - 0 A 0
0
- 0
( -
) 0
1 0
) 0
- 0
1 0
- -
0 - - 01 - - 0
.
0
- 0
1 0
) 0
1 0
) 0
- 0
- -
0 - - 01 - - 0
1 : : 1 : :
[1] : https://apacheignite.readme.io/docs/affinity-collocation
[2] : https://redis.io/topics/data-types

127 . 1 2 00 . 4 4
4-1. Verification : Data structure
•
8CA 6 : GC 8 : G A:G C : G :6 8 : C A6 8: 8 :6 :
P 8CA 6 : GC 8 : G A:G C C6 8C 8: G 6G C GC 6 G 8 6 : : 6 C :
2 C C : 1:G C P : G 1:G C
6G6 G 8G :
:
G
: C A6
8:
8C A C 6G: 8C A C 6G:
C6
6 6 8:
: G C : 6AC A G : C : K 6G6 C 6A: 6 :6 C: GC G : 6A: C :
:6
8
: C A6
8:
G A: C :6 8 G :: G A: C :6 8 G ::
: 8 : 8 C 688: GC C : G 6G 6 : 6G6 M C 688: GC C : G 6G 6 : 6G6
0: 56 :
- G 2 A6 5
G ::
34 8C :
C A:
34 8C :
6GG:
0: 56 :
- G 2 A6 2 A6 5
G :: G ::
/:C 8C :
C A:
/:C 8C :
6GG:
G A:
4C C 1 6 C 8 G
, 4C C 1 6 C 8 G , ),(1 C A68
1 C A68
),(

-,3ST UOMNW ( BB 3SUT 1PP OMNW U J
4-2. System configuration
• 5: 1 -, ,-1 5 1 -, ,-1 5 , , - :
• 05 : 5 :,5- , 5 - ,-1 1 -, ,-1 5
ASLW GU U OSR
3PO RW USMUG PL IU GW J
( D :G G . F +
) 4GWG WSU 1TGIN 9MROW ( ( )
A CHXRWX , BA
-,: 5 0 ,
05 : 5 :,5-
fe
U U
GPP OR
IS SR
9RW P E SR 5+ (, . ISU ( (78 (+ IG N
(+,72 44 ( 533 57 49 a)(72 .b
AA4 0 ( +ORIN . 72 A1B1) _(
844 0 ( +ORIN B2 -( UT A1B1) _(
) D 7 AD
c 5B751 OWINd
EA- (B 721A5 B# A6 A GUW OWIN
05 : 5 :,5-
5:
-,: 5 0 ,
05 : 5 :,5-
05 : 5 :,5-
5:

01 2. 7 021 . 2
4-3. Conditions
• 1 4 4D 4 C C 64 6 D 4C D 5
6 CC 6 4 4 D
D C 5 D C
BC B D
D C )
D 4C6
1 0
,
1 0 )
0
4 : 4 4
, (
1 0
/2 4I
4 4
/2 4I
4 4
D C :
. D C D
N N ST
/2 4I
4 4
/2 4I
4 4
/2 4I
4 4
D C :
0 4C6 D
C4 : (
4C 4
B 6 : 6 45 C B3C 6 C 3 4 4 D

127 . 8 1 2 00 .
4-4. Results insert performance
• 1 D D 1 1 C DC 8 D C D D CD C C 5
• / C 6 D 6 C % D C 5 DD D D D C 5 DD 1 1
• / C 6 D 6 6 D 4D D 64D4 C 6 CD 5 D 6 D C C A 4
1 1 2 C3
0., I
4D 8 C D 6 64D4
%
/ C 6 , D
C
C %
C
C
C
%
1 D 2 A C3
0., Iproposed current
proposed current

4 201 4 33 201 7 7 9 .
4-5. Results search performance
• 6 %606 I B I I I AI I : B
• 4 I C AI ( , AC I : A # AC I : A 606
• 4 I C B AI AI A: I I C BB
I
I
C C
,
( )
) .
(
(
B A A I
0. 0
0. 10
[ / 1
A
532 S PT S
(
)
532 S PT S
2
2
) (
)
0.01
30
6067CI8
7 # %I8
proposed current
proposed current

01 2. 021 . 2
Many Space Filling Curves

AF .. 99 , A , C 2
A 90 A
8
8 1 2
-
1A 9
5-1. Space filling curves(SFC)
• , , , 1 C 1 A A A
2 9 A
• , , , 1 C A 1 9 1 A
1 A A A A 1 9 1 1A A 9
• , , .

Real-Time Spatiotemporal Data Utilization For Future Mobility Services: Atsushi Isomura

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Real-Time Spatiotemporal Data Utilization For Future Mobility Services: Atsushi Isomura

Similar to Real-Time Spatiotemporal Data Utilization For Future Mobility Services: Atsushi Isomura (20)

More from Redis Labs

More from Redis Labs (20)

Recently uploaded

Recently uploaded (20)

Real-Time Spatiotemporal Data Utilization For Future Mobility Services: Atsushi Isomura