使用地图瓦片索引实现地理聚合
在处理大规模的散点数据时,有时候我们需要提供一个只读的查询 API 在地图上做可视化。 当数据量过大,比如百万这个量级,将数据一口气全部返回给前端在浏览器上处理是不太合适的。 应当在后端服务内完成一定聚合,将聚合后的搜索返回给前端。 这里介绍下在 Go 中如何使用 MongoDB + Tile 索引实现这件事。 ...
在处理大规模的散点数据时,有时候我们需要提供一个只读的查询 API 在地图上做可视化。 当数据量过大,比如百万这个量级,将数据一口气全部返回给前端在浏览器上处理是不太合适的。 应当在后端服务内完成一定聚合,将聚合后的搜索返回给前端。 这里介绍下在 Go 中如何使用 MongoDB + Tile 索引实现这件事。 ...
tzfpy 是 tzf 的 Python binding。 如果只是本地可用,Go 代码加上 CGO 扩展编译成 .so 文件就能用了。 不过要做成发布到 PyPI 上在其他地方能直接安装的 wheel 是有些曲折的,看 CI 失败的记录就挺明显的。 ...
上回 说到在 Go 里弄出了一个 tzf 的库,可以非常快速得到经纬度所在的时区信息。 当时的想法是用 Rust 实现出来然后用 maturin 制作 Python 扩展。 经过一段时间的摸索发现 Rust 的坑有点大,于是 2022-07-23 转换了方向,在 Python 里调用 Go 编译出来的 .so 文件。 验证 demo 还算简单 ringsaturn/tzf#11。 ...
2022-05-29 01:04 +0800 立了个年度 Flag:在 Go 里用多边形搜索实现经纬度转时区 2022-05-29 20:47 +0800 搞出来了 https://github.com/ringsaturn/tzf 基本数据处理流程: 挺想用 Rust 实现一遍,然后用 pyo3 封装下,看看能不能比 Numba 加速的 timezonefinder 更快。 ...
由于过往的各种条件限制,如数据库性能不够、PaaS 平台功能不足、对特定领域的问题理解不充分,线上的服务一定会有很多妥协解决方案。这些问题不会让服务彻底不可用,但一定会困扰团队,容易让人担忧系统的可靠性。特别是提供 toB 服务而言可靠性与准确性是一样重要的。 ...
看的书不多,在了解到的中国历史有两段我觉得称得上典型的时期,一个乱世,一个在某些人看来「有点乱」。 第一个是北宋末年的汴京之围 《汴京之围》: 在北宋的朝廷内,随着勤王军队的到来,那些求和的大臣也在加紧行动。如果金军最终被勤王军击溃,就意味着他们主持的求和工作是错误的,这些大臣很可能被愤怒的群众撕成碎片。只有让金军尽早离开,才能证明他们的求和是正确的,不需要承担责任。因此,北宋君臣也越来越配合金军的赔款移交工作。 ...
在 Go 里定义 struct 及其序列化&反序列化的方式都是通过 Tag 的方式做的, 但是在我开始使用 Apollo 的时候没有找到社区的解决方案,所以翻了下 BSON/JSON/YAML 的反序列化实现方式, 觉得用反射机制好像是可以做的,于是就开搞了,项目在 https://github.com/caiyunapp/oap。 ...
简而言之,写了个工具包
提示 ...