enjoy coding …
MySQL-convention MySQL-convention orient version 1.0.1, 2022-01-04 12:37 Table of Contents 基础规范 命名规范 库表设计规范 列/字段设计规范 索引规范 SQL规范 操作规范 参考 基础规范 表存储引擎必须使用InnoDB 表字符集默认utf8mb4, 而不是utf8或其它 utf8mb4: A UTF-8 encoding of the Unicode character set using one to four bytes per character. utf8mb3: A UTF-8 encoding of the Unicode character set using one to three bytes per character. utf8:…
mongodb-convention mongodb-convention orient version 0.0.1 Table of Contents 基础规范 命名规范 库设计规范 连接规范 集合设计规范 文档/列/字段设计规范 索引规范 API/SQL规范 操作规范 参考 基础规范 【强制】禁止在线上环境做数据库压力测试 【强制】测试，开发，线上数据库环境必须隔离 【强制】设计前, 应该了解mongodb的一些限制, 参考https://docs.mongodb.com/manual/reference/limits/ 解读: 例如: 文档大小限制为16M; 例如: In the $lookup stage, the from collection cannot be sharded 参考: https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/index.html#sharded-collection-restrictions 命名规范 【强制】数据库名db_xxxx, 全部小写，禁止使用任何”_”(即下划线)以外的特殊字符，禁止使用数字打头的库名 【强制】数据库名最多为64个字符 【强制】集合名全部小写，禁止使用任何”_”(即下划线)以外的特殊字符，禁止使用数字/system打头的集合名 【强制】集合名称最多为64字符 【强制】集合中的key禁止使用任何”_”(即下划线)以外的特殊字符 【强制】文档中的字段名等均应尽量保持短小 库设计规范 【强制】在创建新的库前应尽量评估该库的体积、QPS等，提前与DBA讨论是应该新建一个库还是专门为该库创建一个新的集群 连接规范 【强制】正确连接副本集，副本集提供了数据的保护、高可用和灾难恢复的机制。如果主节点宕机，其中一个从节点会自动提升为从节点。 【建议】合理控制连接池的大小，限制连接数资源，可通过Connection String URL中的…
说明 规范与建议以Google代码规范为基础, 以Effective系列等作为补充(去掉了重合的, 过时的, 基本可以省略的内容) Google代码规范的注释及格式等部分考虑使用cpplint工具来完成 版本: 1.0.0 最后更新: 2021-09-01 13:01 作者: orient 主页: http://orientye.com github: https://github.com/orientye 微信公众号: 深入理解计算机系统 Google代码规范 https://google.github.io/styleguide/cppguide.html 中文版: https://google-styleguide.readthedocs.io/zh_CN/latest/google-cpp-styleguide/contents.html (注意:有些并不准确) Effective C++ 3rd Item 04. 确定对象被使用前已被初始化 Item 07. 为多态基类声明virtual析构函数 Item 09. 绝不在构造函数和析构函数中调用virtual函数 Item 11. operator=处理好自我赋值 Item 12. 复制对象时勿忘其每一个成分 Item 16. 成对使用new和delete要采取相同形式 Item 21. 绝不返回局部变量(local stack)的指针或引用 Item 26. 尽可能延后变量定义的出现时间 Item 28. 避免返回handles(包括引用指针迭代器)指向对象内部…
Beautiful Code — go sort sort: optimize average calculation in symMerge and doPivot. Change code of the form `i + (j-i)/2` to `int(uint(i+j) >> 1)`. The optimized average calculation uses fewer instructions to calculate the average without overflowing at the addition. Analogous to https://golang.org/cl/36332. name old time/op new time/op delta StableString1K-4 49.6µs ± 3% 49.1µs…
ARC（Adaptive Replacement Cache）是一种适应性Cache算法, 它结合了LRU与LFU。 LRU(Least recently used) 其核心思想是:假设刚visit的item,很有可能在未来被revisit 丢弃最近最少访问的items 通常用双链表实现 tips: redis并没有这样做，因为这样每个key至少会多出两个指针。 redis采用的是一种近似LRU，基本思想是随机取出一些key,形成一个小的POOL，然后在pool中采用LRU策略(相关源码:redis/src/evict.c) 缺点:忽略了frequency, 不适合大规模扫描等情况 LRU有一系列变种，比如LRU2, 2Q, LIRS等。 LFU(Least-frequently used) 其核心思想是:假设visit次数越多的item,很有可能在未来被revisit 适应大规模扫描 对热点友好 缺点:忽略了recency, 可能会积累不再使用的数据 tips: redis4.0开始支持了LFU,例如volatile-lfu, allkeys-lfu配置选项 ARC 整个Cache分成两部分，起始LRU和LFU各占一半，后续会动态适应调整partion的位置（记为p） 除此，LRU和LFU各自有一个ghost list(因此，一共4个list) 每次，被淘汰的item放到对应的ghost list中（ghost list只存key）, 例如：如果被evicted的item来自LRU的部分， 则该item对应的key会被放入LRU对应的ghost list 第一次cache miss, 则会放入LRU 如果cache hit, 如果LFU中没有，则放入LFU 如果cache miss, 但在ghost list中命中，这说明对应的cache如果再大一丁点儿就好了： 如果存在于LRU ghost list, 则p=p+1；否则存在于LFU ghost list, p=p-1….