貌似最大的问题不是设计结构而是数据库选择，建议直接一个mongodb搞定，不用两个数据库。
这样只要两个collections就可以搞定，mongo的更新和插入还支持批量插入。
建个2d的索引，将来如果做z坐标索也有一定扩展能力。
表1：元数据

phone  type "gps":{lat , long} updated

表2：轨迹数据

phone  "gps":{lat , long} updated

mongo的一些特性肯定让你未来的操作更简便
比如：
找某点最近的phone：

db.phone.find({"gps":{"$near":[x.y]}}).limit(1)
将来如果到1000个终端，每次都刷新一遍可能效率不高，可以根据时间戳做条件或者只显示某个点{x,y}直径R范围内的机器，而不用查所有的机器的话：
db.phone.find({"gps":{'$within':{'$center':[[x,y],R]}}})

1. 方式2是对的。终端自身的数据是持久性的，终端位置是非持久的。这两类数据分开绝对是个好主意。
2. 数据库用mysql估计300多个终端还能顶得住。但还是早做准备为好。终端多了迟早需要mysql+redis。
3. 看不出有什么需要事务的地方。这个应用的策略绝对是牺牲整批数据完整，来给响应速度让路的。
4. 高并发时保证表2的写入性能，表1的读取可以次要保证，而表1的写入就用异步的手段去拖延。当然这种时候就不光需要分表了，而是必须分库甚至分服务器。
5. nodejs做后台没有致命的问题，值得一用。