08:04:35 右军
NewSQL 的出现就是为了解决扩展性和一致性之间的矛盾，我所理解的 NewSQL 主要还是面向 OLTP 业务和轻量级的OLAP业务，大型复杂的OLAP 数据库暂时不在本文讨论的范围。对于 NewSQL 来说，我觉得应该需要明确一下必备的性质，什么样的数据库才能称之为NewSQL，在我看来，应该有以下几点必备的特性： 1. SQL 2. ACID Transaction, 支持跨行事务 3. Auto-scale 4. Auto-failover
08:04:36 右军
09:05:45 李雄峰
发个广告哈。
09:05:46 李雄峰
09:08:31 一峰-csii-项目负责人-北京
有一个疑问想咨询下大家:查询库里存在的门店信息和当前位置相比较，计算出离我小于3km的门店展示。如果门店信息很多，还要逐条计算。会造成慢查询。有啥好建议没？
09:10:34 李雄峰
你可以考虑，把常规的按圆来计算直线距离，变成一个 矩形区域
09:11:10 李雄峰
这就转换成 b > x > a, c>y>d的方式了，数据库妥妥的快速算出来。
09:11:49 李雄峰
@北京-tonny 好奇问下，你们怎么解决火星坐标问题
09:12:15 沪上十三少
当年有个车联网公司问过这问题
09:13:02 李雄峰
有啥更好的算法？
09:13:57 沪上十三少
我没有[偷笑]
09:14:08 一峰-csii-项目负责人-北京
目前还没考虑呢[捂脸]
09:14:09 Daniel-快钱-架构
es有个坐标索引
09:14:14 鹏
火星坐标数值不是能识别么，给以提示火星太危险快回到地球去
09:15:40 hobbit-技术总监
@北京-tonny?有两种，geohash算法和运用kdtree建模，两种都可以
09:15:55 Daniel-快钱-架构
可以试试现成的es geo坐标索引，可以算距离的
09:19:05 一峰-csii-项目负责人-北京
计算可以计算，主要是轮询数据库现存千条或者万条数据门店，算出每一条，然后再排序，很慢的啊[捂脸]
09:19:40 一峰-csii-项目负责人-北京
业务早期还行
09:19:55 一峰-csii-项目负责人-北京
业务量大就完蛋了
09:23:48 李雄峰
不会哪， 数据库里存放的是经纬度x，y。 计算距离x,y 为r的区域，把 r转换成横坐标距离a, 纵坐标距离b， 就变成 在数据库中过滤 x-a < lat < x+a， y-b < gat < y+b的数据了，SQL妥妥搞定。
09:24:25 李雄峰
需要更精细的结果，可以在这个过滤结果中再逐个计算距离。
09:25:16 一峰-csii-项目负责人-北京
嗯嗯，
09:25:31 kent–研发
这思路就是先缩小范围 再计算嘛
09:26:21 kent–研发
好奇 现在通过百度或者高德SDK获取坐标都是火星坐标系吗？ 一般存储需要转换一下还是直接使用火星坐标系
09:28:19 李雄峰
@kent-研发 同好奇。
09:28:53 李雄峰
高德的火星坐标，和手机实时拿到的gps坐标，是不一致的。
09:29:08 杨连峰
个人的经验是，Redis, Mongo, ES都有相应的GEO支持，使用这些最好，如果要是性能要求更高，可以考虑使用地图块18级包含的位置做为key再加一层缓存。关于火星坐标系，如果都用同一SDK，应该就不存在问题了。
09:29:09 李雄峰
记得如果是和高德有合作，高德会给API来解码火星坐标。
09:39:21 一峰-csii-项目负责人-北京
腾讯地图呢
09:44:46 一峰-csii-项目负责人-北京
微信小程序调用腾讯地图api精度应该可以保证
09:52:29 syu
@北京-tonny?solr直接支持
09:53:37 syu
lucene系的都行
20:16:53 鱼丸-卓易信-JAVA开发
es好像也是支持的