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 tb_lbs_user where GeoHash  like  “abcd%”;

优点:利用geohash优化关系型数据库,查询效率,而且还比较直观;

缺点:慢,数据量大和并发量大的情况下可以把数据库拖死;

方案3:

思路:

将地球划分为n个方格,geohash值为6个位,每个方格为(宽一平方千米,以人口均值取值)

数据结构:

1)用户群圈定:

以geohash值为key,在用户更新地理位置的时候更新或插入;

userGeoList:List< M{userid :{lat,lan,gender, free }}>

示例:

key                     value

5cfr5x                 {{12322:{11,11,1}},{1234:{0.5,0.2,1}},{ 4567:{0.2,0.3,1}},….}

5cfr5f                 {{12322:{11,11,1}},{1234:{0.5,0.2,1}},{4567:{0.2,0.3,1}},….}

.                 .

.                 .

.                 .

2)用户信息:

一个用户信息;纬度、经度、GeoHash值

userInfo ={lan,lat ,geo}

例如:

key                     value

12322                {5661,1234, 5cfr5x }

344                            {344,333, 5cfr5x }

.                 .

.                 .

.                 .

算法实现:

1)更新:

定义:

user_new_geohash:新的geohash值

userid:用户ID

getUserInfo:根据userid获取用户信息

updateGeohash:更新用户的geohash

removeUserid:根据userid,移除集合中的某个用户

getuserGeoList:根据geohash获取用户群

addUserid:往用户群中添加userid

UserGeoListNew:创建用户群对象

实现:

user_new_geohash = “5cfr5f”

userid = 12322;

userInfo  =  getUserInfo(userid);

user_old_geohash = userInfo. geo

if user_new_geohash  !=  user_old_geohash

userInfo.updateGeohash (userid, user_old_geohash, userInfo. geo)

userGeoListOld  =  getuserGeoList(user_old_geohash);

userGeoListOld .removeUserid(userid)

userGeoListNew  =  getuserGeoList(user_new_geohash);

if userGeoListNew  !=null:

userGeoListNew.addUserid(userid, gender,free)

else:

userGeoListNew = new UserGeoListNew();

2)查询

定义:

getuserGeoHash:根据userid获取geohash

getuserGeoList:根据geohash和偏移值获取用户集合

sort:根据地理位置由近到远排序

NearbyUserListCache:用户缓存

k:查询条件

geohash = getuserGeoHash(userid);

lan = 0

userGeoList2  =  new userGeoList ()

for (int i = 3; i >= 2; i--) {

userGeoList  = getuserGeoList(geohash,lan)

for(user: userGeoList ){

if user.gender == 1 and user.free == 1://查询条件

userGeoList2.add(user);

}

lan  +=  1000;

if (userGeoList2.size() >= 1000) {

break;

}

}

userGeoList.sort();

NearbyUserListCache.add(k, userGeoList);

以NearbyUserListCache逐步分页

算法复杂度:

n*n

可能查询多次

方案4:

2)用户群数值记录:

以geohash值为key,在用户更新地理位置的时候更新或插入;

userNum : DECR/INCR

userFemaleNum : DECR/INCR

userMaleNum : DECR/INCR

2)查询

定义:

getuserGeoHash:根据userid获取geohash

getuserGeoList:根据geohash和偏移值获取用户集合

sort:根据地理位置由近到远排序

NearbyUserListCache:用户缓存

k:查询条件

geohash = getuserGeoHash(userid);

lan = 0

userGeoList = new userGeoList ()

while true:

if len >=10000

userGeoList  = getuserGeoList(geohash)

else:

len +=xxx;

break;

userGeoList2.sort();

NearbyUserListCache.add(k, userGeoList2);

以NearbyUserListCache逐步分页

只需要查询一次

时间: 2024-10-06 11:31:47

LBS优化方案探究的相关文章

针对MySQL大表优化方案

详解MySQL大表优化方案 (1).字段 (2).索引 (3).规范查询SQL (4).存储引擎 (5).mysql配置参数优化 (6).mysql读写分离 (7).分区和分表 单表优化: 当单表的数据不是一直在暴增,不建议使用拆分,拆分会带来逻辑,部署,运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量 (1).字段 l 尽量使用TINYINT.SMALLINT

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

然后我就去网上搜索“如何写网站SEO优化方案

这段时间属于网站的策划阶段,网站的定位.网站的布局以及关键词的选定 首先,需要确定自己建设一个什么样的网站.,我们当然是企业网站,然后,确定网站的关键词,确定关键词可以参考自己的竞争对手,也可以通过关键词挖掘工具选择合适的关键词,选出的关键词一定符合用户的搜索习惯,并且有一定的搜索量.最好是能够有明确转化意向的关键词. 关键词确定后,需要设计网站的整体布局,比如说首页应该放置哪些板块,你的客户最关心的是哪些内容?最想了解的是哪些信息?,这时就需要对你的客户进行分析了,比如我们做的是工业品,客户比

百度没出新算法之前这种最好的的优化方案

百度没出新算法之前这种最好的的优化方案:看到这个标题我相信大家很多人都会呲之以鼻的因为都自己心里感觉这人太装B了吧,谁敢说他的优化方案是最厉害的,首先这只是我感觉的. 自从绿萝算法更新以后咱们这个时候再去更新一篇文章,百度就不会去再从他原先有的数据库里面寻找了,因为这样的话太麻烦太坑爹了,就像一个我们的汶川大地震后的拯救工作太浩大了,就和研究中心里面说的一样,对一篇文章中,抓住10个中心重点就可以判断文章的原创性,伪原创需要的就是知道文章中心重点词,打个比方就像真猴子和假猴子一样万变不离其宗,伪

[转] 钉钉的H5性能优化方案

对于一个H5的产品,功能无疑很重要,但是性能同样是用户体验中不可或缺的一环.原本H5的渲染性能就不及native的app,如果不把性能优化做起来,将极大地影响用户使用产品的积极性. 用户感受 当用户能够在1-2秒内打开H5页面,看到信息的展示,或者能够开始进行下一步的操作,用户会感觉速度还好,可以接受:而页面如果在2-5秒后才进入可用的状态,用户的耐心会逐渐丧失:而如果一个界面超过5秒甚至更久才能显示出来,这对用户来说基本是无法忍受的,也许有一部分用户会退出重新进入,但更多的用户会直接放弃使用.

if-else嵌套过多时的优化方案

//if-else嵌套过多时的优化方案 在垒代码的时候经常会遇到 if-else 的嵌套判断,就是下一个判断依赖于上一个判断的结果,其基本的表现形式为if(){//first judge if(){//second //do something }else{ if(){//third //do something }else{ //do something } }}else{ //do something} 当嵌套的个数不是太多的时候,看上去也不是太乱,顺着每个判断写下来也不会太困难,但是当嵌套

MySQL大表优化方案总结

今天看了一篇mysql大表优化方案的文章( https://mp.weixin.qq.com/s/qM6MAd_ZcrHEapz0D4nSrA ),应该说是属于科普级别的,但是技术肯定是要先大概理解了才能再深入的,深入的话推荐看 MySQL技术内幕:InnoDB存储引擎(第2版) 总结一下大表的优化方案就是: 分库分表加分区 各个层级加缓存(mysql层是缓存调参) 字段索引要优化 SQL语句别复杂 读写分离大法好 升级硬件是王道

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.

分享详细网站SEO优化方案

下面分享详细网站SEO优化方案: 一.网站上线前准备阶段 1.域名选择 2.服务器及空间选择 3.网站类型选择:内容资讯型.商铺型.论坛型.文档分享下载型. 4.竞争对手调研分析 5.网站针对用户分析 6.程序选择 二.网站上线后SEO运营阶段 站内结构优化 合理规划站点结构(1.扁平化结构 2.辅助导航.面包屑导航.次导航) 内容页结构设置(最新文章.推荐文章.热门文章.增加相关性.方便自助根据链接抓取更多内容) 较快的加载速度 简洁的页面结构 1.站内SEO优化 ①关键词分析选择 ②网站框架