Skip to main content

Home/ Larvata/ Group items tagged ack

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
crazylion lee

UniversalCodeGrep by gvansickle - 1 views

gvansickle.github.io/ucg

ack grep ag

shared by crazylion lee on 22 Oct 16 - No Cached
  • crazylion lee on 22 Oct 16
     
    "Easy as Ack, Faster than grep" -- 這套好像是王者......
張 旭

单表60亿记录等大数据场景的MySQL优化和运维之道 - 快课网 - 0 views

www.cricode.com/3981.html

mysql system performance HA database

shared by 張 旭 on 18 Nov 15 - No Cached
  • 存储引擎使用InnoDB
  • 变长字符串尽量使用varchar varbinary
  • 不在数据库中存储图片、文件等
  • ...34 more annotations...
  • 库名、表名、字段名、索引名使用小写字母，以下划线分割 ，需要见名知意
  • 所有字段均定义为NOT NULL ，除非你真的想存Null
  • 使用TIMESTAMP存储时间
  • 使用DECIMAL存储精确浮点数，用float有的时候会有问题
  • 单个索引字段数不超过5，单表索引数量不超过5，索引设计遵循B+ Tree索引最左前缀匹配原则
  • 建立的索引能覆盖80%主要的查询，不求全，解决问题的主要矛盾
  • 避免冗余索引
  • 索引这个东西是一把双刃剑，在加速读的同时也引入了很多额外的写入和锁，降低写入能力
  • 字段定义为varchar，但传入的值是个int，就会导致全表扫描，要求程序端要做好类型检查
  • 避免使用大表的JOIN，MySQL优化器对join优化策略过于简单
  • UPDATE、DELETE语句不使用LIMIT ，容易造成主从不一致
  • 高危操作检查，Drop前做好数据备份
  • 日志分析，主要是指的MySQL慢日志和错误日志
  • Percona公司根据Facebook OSC思路，用perl重写了一版，就是我们现在用得很多的pt-online-schema-change，软件本身非常成熟，支持目前主流版本
  • 原生主从同步肯定存在着性能和安全性问题
  • Sharding is very complex, so itʼs best not to shard until itʼs obvious that you will actually need to!
  • 有中间层控制拆分逻辑最好，否则拆分过细管理成本会很高
  • 全量binlog备份
  • xtrabackup热备
  • 采用分布式文件系统存储备份
  • 基于库级别的复制，所以如果你只有一个库，使用这个意义不大
  • 半同步复制，从5.5开始支持
  • 半同步通过从库返回ACK这种方式确认从库收到数据
  • Secondsbehindmaster来判断延时不可靠，在网络抖动或者一些特殊参数配置情况下，会造成这个值是0但其实延时很大了。通过heartbeat表插入时间戳这种机制判断延时是更靠谱的
  • Binlog格式，建议都采用row格式，数据一致性更好
  • 成熟开源事务存储引擎，支持ACID，支持事务四个隔离级别，更好的数据安全性，高性能高并发，MVCC，细粒度锁，支持O_DIRECT
  • 数据安全性至关重要，InnoDB完胜
  • 主流使用TokuDB主要是看中了它的高压缩比
  • TokuDB在测试过程中写入稳定性是非常好的
  • 单表容量在InnoDB下1TB+，使用Tokudb的lzma压缩到80GB
  • 独立写程序好一些，与程序解耦方便后期维护
  • 追踪字段值变化可以通过分析row格式binlog好一些
  • 解决了单表过大恢复时间问题，也支持online DDL
  • 物理备份采用xtrabackup热备方案比较好
1 - 2 of 2
Showing 20▼ items per page