选择合适的分布式主键方案
发表于|更新于
|浏览量:
数据库自增长序列或字段
UUID
使用 UUID to Int64 的方法
Redis 生成 ID
Twitter 的 snowflake 算法
利用 zookeeper 生成唯一 ID
MongoDB 的 ObjectId
文章作者: 烦恼多一点
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站!
相关推荐

2022-07-28
自己如何实现消息队列
大体上的设计是由一条线程 1 执行从等待列表中获取任务插入任务队列再由线程池中的线程从任务队列中取出任务去执行. 添加一条线程 1 主要是防止在执行耗时的任务时阻塞主线程.当执行耗时任务时,添加的任务的操作快于取出任务的操作, 当任务队列长度达到最大值时,线程 1 将被阻塞,等待线程 2,3… 从任务队列取出任务执行。

2022-07-02
分库与分表带来的分布式困境与应对之策
数据迁移与扩容问题前面介绍到水平分表策略归纳总结为随机分表和连续分表两种情况。连续分表有可能存在数据热点的问题,有些表可能会被频繁地查询从而造成较大压力,热数据的表就成为了整个库的瓶颈,而有些表可能存的是历史数据,很少需要被查询到。连续分表的另外一个好处在于比较容易,不需要考虑迁移旧的数据,只需要添加分表就可以自动扩容。随机分表的数据相对比较均匀,不容易出现热点和并发访问的瓶颈。但是,分表扩展需要迁移旧的数据。 针对于水平分表的设计至关重要,需要评估中短期内业务的增长速度,对当前的数据量进行容量规划,综合成本因素,推算出大概需要多少分片。对于数据迁移的问题,一般做法是通过程序先读出数据,然后按照指定的分表策略再将数据写入到各个分表中。 表关联问题在单库单表的情况下,联合查询是非常容易的。但是,随着分库与分表的演变,联合查询就遇到跨库关联和跨表关系问题。在设计之初就应该尽量避免联合查询,可以通过程序中进行拼装,或者通过反范式化设计进行规避。 分页与排序问题一般情况下,列表分页时需要按照指定字段进行排序。在单库单表的情况下,分页和排序也是非常容易的。但是,随着分库与分表的演变,也会遇...

2022-07-10
limit 20000 加载很慢怎么解决
MySQL 的性能低是因为数据库要去扫描 N + M 条记录,然后又要放弃之前 N 条记录,开销很大 解决思路: 前端加缓存,或者其他方式,减少落到库的查询操作,例如某些系统中数据在搜索引擎中有备份的,可以用 es 等进行搜索 使用延迟关联,即先通用 limit 得到需要数据的索引字段,然后再通过原表和索引字段关联获得需要数据 select a.* from a,(select id from table_1 where is_deleted='N' limit 100000,20) b where a.id = b.id 从业务上实现,不分页如此多,例如只能分页前 100 页,后面的不允许再查了 不使用 limit N,M, 而是使用 limit N,即将 offset 转化为 where 条件。

2022-07-13
聊聊 MongoDB 使用场景
高伸缩性的场景MongoDB 非常适合高伸缩性的场景,它是可扩展性的表结构。基于这点,可以将预期范围内,表结构可能会不断扩展的 MySQL 表结构,通过 MongoDB 来存储,这就可以保证表结构的扩展性。 日志系统的场景日志系统数据量特别大,如果用 MongoDB 数据库存储这些数据,利用分片集群支持海量数据,同时使用聚集分析和 MapReduce 的能力,是个很好的选择。 分布式文件存储MongoDB 还适合存储大尺寸的数据,之前介绍的 GridFS 存储方案,就是基于 MongoDB 的分布式文件存储系统。

2022-07-07
数据库索引的原理
数据库索引,是数据库管理系统中一个排序的数据结构,以协助快速查询、更新数据库表中数据。索引的实现通常使用 BTree 及其变种 B+Tree。

2022-07-03
说说 SQL 优化之道
一些常见的 SQL 实践 负向条件查询不能使用索引 select from order where status!=0 and status!=1 not in/not exists # 都不是好习惯 可以优化为 in 查询: select from order where status in(2,3) 前导模糊查询不能使用索引 select from order where desc like '%XX' 而非前导模糊查询则可以: select from order where desc like 'XX%' 数据区分度不大的字段不宜使用索引 select from user where sex=1 原因:性别只有男,女,每次过滤掉的数据很少,不宜使用索引。 经验上,能过滤80%数据时就可以使用索引。对于订单状态,如果状态值很少,不宜使用索引,如果状态值很多,能够过滤大量数据,则应该建立索引。 在属性上进行计算不能命中索引 select from order where YEAR(date) < = ...
评论
WalineDisqus
公告
This is my Blog






