geo实现方案

1、数据库内在支持GIS(地理信息系统)
MySQL: 目前只有MyISAM引擎是支持GIS的,Innodb在5.7版本中才支持空间索引。MyISAM这个引擎
不支持事务、外键,而且是表锁。适合读为主,不适合写操作。而且如果单独建一张表的话,那每次都要与
现有的表联合查询返回tag的地点,效率多少会有些影响,而且也不确定Django是否支持Innodb与myISAM
引擎联合查询。(目前用的Innodb引擎)
其它数据库:MongoDB和postgresql都是支持GIS的,前者没有仔细研究,后者在GIS方面很强大,
但目前还不考虑切换数据库。

2、第三方app或框架
GeoDjango:它是一个支持GIS存储和查询的Django衍生项目。不过这个框架太重了,内容太多,简单
熟悉了一下,它的功能还是很强大的。但在数据库层,它也是需要数据库支持GIS的。
数据库全文检索:用的比较多的是lucene和sphinx工具,熟悉这两个工具的时间成本太高了,而且从性能
上来说和自己用mysql查询差不多。

3、自己开发
考虑有两种方案,
(1) 数据库保存地点的经纬度,查找附近的地点时,用球面两点间距离公式计算并排序。
为了提高效率,还可以将其保存成存储过程。
(2)将经纬度转为一维数据geohash,这样可以在geohash上用加索引,而且用like语句
可实现查询。不过要至少调用6条like语句,而且不能实现任意距离的搜索,只能搜索几个距离
范围内的地点。

目前,公司负责开发的产品需求并不需要精确搜索,从时间成本、性能两方面考察这些方案,最好的两个方案是
比较合适的。最终选定geohash方案

时间: 2024-12-08 19:32:55

geo实现方案的相关文章

【转】微信、陌陌 架构方案分析

来源:http://www.wubiao.info/401 作者:wubiao 微信.陌陌 架构方案分析 近两年.手机应用.莫过于微信.陌陌之类最受欢迎.但实现原理,分享文章甚少. 故,提出两种方案,供分享:不正确之处.敬请留言学习. 目标 解决大型应用(微信.陌陌级别)中.用户经纬度在不断更新.用户查找频繁的问题. (每分钟1000W级) ==============================================================================

Redis百亿级Key存储方案

1 需求背景 该应用场景为AdMaster DMP缓存存储需求,DMP需要管理非常多的第三方id数据,其中包括各媒体cookie与自身cookie(以下统称admckid)的mapping关系,还包括了admckid的人口标签.移动端id(主要是idfa和imei)的人口标签,以及一些黑名单id.ip等数据. 在hdfs的帮助下离线存储千亿记录并不困难,然而DMP还需要提供毫秒级的实时查询.由于cookie这种id本身具有不稳定性,所以很多的真实用户的浏览行为会导致大量的新cookie生成,只有

LBS优化方案探究

方案1: 假设数据结构是这个样子的结构 那么找某个范围之内的用户,相当于: select * from tb_lbs_user where lat > lat_min and lat < lat_max and lng >lng_min and lng < lng_max; 优点:几乎没有,唯一能说优点的就是比较直观是个人都能够想到: 缺点:慢,数据量大和并发量大的情况下可以把数据库拖死: 方案2: 使用geohash 那么找某个范围之内的用户,相当于: select * from

geo常见需求

常见的地理位置相关需求有: 1.查找附近的人 2.显示两点距离 3.点是否在指定范围内(地理围栏) redis.MongoDB.mysql都已支持geo 几种geo方案对比 https://blog.csdn.net/varyall/article/details/80308426 需求1.2用对应的geo即可 需求3判断点是否在指定范围内实现方案(地理围栏) 一般为3中情况:1是否在指定园内,2是否在矩形内,3是否在多边形内 https://blog.csdn.net/u012898245/a

MySQL分库分表方案

1. MySQL分库分表方案 1.1. 问题: 1.2. 回答: 1.2.1. 最好的切分MySQL的方式就是:除非万不得已,否则不要去干它. 1.2.2. 你的SQL语句不再是声明式的(declarative) 1.2.3. 你招致了大量的网络延时 1.2.4. 你失去了SQL的许多强大能力 1.2.5. MySQL没有API保证异步查询返回顺序结果 1.2.6. 总结 MySQL分库分表方案 翻译一个stackoverflow上的问答,关于分库分表的缺点的,原文链接: MySQL shard

C#开发微信门户及应用(47) - 整合Web API、微信后台管理及前端微信小程序的应用方案

在微信开发中,我一直强调需要建立一个比较统一的Web API接口体系,以便实现数据的集中化,这样我们在常规的Web业务系统,Winform业务系统.微信应用.微信小程序.APP等方面,都可以直接调用基于JSON数据格式的Web API接口,在我之前的几篇随笔中,对这方面都有一定的介绍,本篇继续这个主题,细致深入的阐述如何在接口和源码的基础上整合Web API.微信后台管理及前端微信小程序的应用方案. 1.基于Web API的微信开发框架 首先我们各个业务模块,都应该围绕着Web API进行展开,

redis的单机安装与配置以及生产环境启动方案

简单介绍一下redis的单机安装与配置,方便自己记录安装步骤的同时方便他人获取知识. 首先,从官网下载最新版的(稳定版)的redis安装包.官网地址如下:https://redis.io/download 下载源码包后,redis需要编译安装.需要安装gcc和tcl,gcc用于编译tcl用于测试. 使用命令安装gcc,yum install gcc,一路选择yes,gcc就可以安装成功. 接下来安装tcl,首先获取tcl源码包(见百度云盘)或者使用命令:wget http://downloads

Linux分区方案

Linux服务器分区的方案: 分区类型 分区的实际大小 / 1G-2G (最少要150–250MB) /boot 32M-100M (启动分区,最多只要100M左右) /opt 100M-1G (附加应用程序) /tmp 40M-1000M (最大可以设为1G左右,如果加载ISO镜像文件就设为4G左右吧,一般不用那么多) /home 2G-10G (每个用户100M左右,具体自定.用户目录.) /usr 3G-10G 最少要500M左右,一般宽松的服务器要分到4-6G) /usr/local 3

Java实现多线程生产者消费模型及优化方案

生产者-消费者模型是进程间通信的重要内容之一.其原理十分简单,但自己用语言实现往往会出现很多的问题,下面我们用一系列代码来展现在编码中容易出现的问题以及最优解决方案. /* 单生产者.单消费者生产烤鸭 */class Resource { private String name; private int count = 1; //计数器,记录有多少只烤鸭被生产及消费 private boolean flag = false; //停止标记 public synchronized void set