要拆用户，用户代理表 ，这让我陷入了一些思考 。不仅仅数据分片 以及查询
方案1 适用 shardingjdbc ，mycat 这类的 水平拆分 ，根据站点拆分，最终有可能会变成多租户数据隔离的情况
优点 ：1 shardingjdbc 可以有效减少开发人员的路由代码 ，不需要去关心路由表单情况
2 水平拆分后 业务其实更加清晰了
3 开发人员能够很快上手 ，技术难度低
缺点 ：
1 全局的查找 性能还是很差 比如 全局查找limit 10000 5 ， 其实是 每个分片的10005条数据 聚合 排序
2 shardingjdbc 不是完全兼容sql 规范 ，不合规范的需要开发同学改sql
3 分片后数据增长后 性能还是 变差 ，比如每个站点用户的量超过200w 时 继续分片会近一步加大开发难度
方案2 这个方案类似我之前公司的解决方案 ，将用户变更数据通过kafka （其他队列也行 性能够好就ok）聚合倒入es ，什么是聚合 ，比如说 用户添加代理了的事件 通过kafka 到了消费者 ，消费者搜索出查询数据 放入 es 中 。近一步 可以 Canal 或者otter 监听binlog 将事件 丢到kafka ，开发人员不需要管事件的投递过程 但是 运维难度会增加 。
优点 :
1 多字段 查询 完全难不倒es ，es 本身具有横向扩展能力 ，基本不需要担心数据量的问题
2 动态查询 简单
3 无全局 查找 limit 问题
缺点
1 需要熟悉kafka和es 技术 对开发人员要求更高
2 es 性能 也是和 查询语句的性能 ， 分片数量 ，索引的配置，实际硬件情况 相关的
3 对于运维的要求 显然 比shardingjdbc 更高
4 有一定延时性
方案3 基于内存数据库 ignite ， 内存数据库 本身是 可以持久化的 。不过内存中会有全部数据 （ignite 还有很多其他能力 ，服务网格，内存网格等等 ）
优点 ：
1 相当优秀的 并发读写能力 ， 写能力很强 ，具有流式写的能力
2 集群很容易
3 还有很多其他诱人的能力
缺点 ：
1 缺点非常明显 sql 兼容性 比 shardingjdbc 更差 ，适用范围比较小
2 数据全在内存中 ，你觉得 数据 贵不贵
3 需要学习 ignite运维
方案4 数据量进一步扩大 到tb 甚至pb 级别 这种级别查询 只能借助于 离线查询和在线查询的方案来做 ， 比如 kafka flink kudu ， kafka flink druid
优点
1 巨量数据量查询解决方案
2 olap 需求 可以达到亚秒级别
缺点
1 运维 和开发 要求高
还有 hbase cassandra 列式存储 我就不说了
网友评论