做个有用之人,随着年龄的增长,对这一点越来越渴望。 ​​​​
一大早听说知乎的库挂了,为了可控的RTO,我自己一直的准则是使用团队可控的数据库技术来承接核心服务。 ​​​​
基于B Tree的数据库的Write Amplification至少没有基于LSM Tree研发数据库的人说的那么大,很多时侯是精心优化的LSM Tree数据库和无优化的B Tree数据库对比的结果。 ​​​​
重新思考了一下以前做的一些东东,三个地方有两个地方想法上了一个台阶(找到了更完善更全面的实现方式),还有一个地方没有任何突破(待继续努力)。 ​​​​
只有官爷、小秘、资本家、民工四工种了。 ​​​​
经过测试,增加UNDO表空间个数,对Purge有一点提升作用。 ​​​​
去年设计了一个On Demand Flush的机制来避免MySQL进到最坏的Single Page Flush的状态,感觉这个概念也可以用在RocksDB的Compaction中,在自己的研究性项目OneValue中也有所体现,当小范围查询响应时间超出一定的幅度后,手工触发一次这个范围内的Compaction操作。 ​​​​
目前的分布式数据库还都是有Worst Case的,都还是讲场景的,要关注它们的多少、发现的速度以及处理的速度。
搜了一天分布式数据库可能会遇到的问题,由突发流量引起的版本堆积与Compaction之间的不协调是一类,还有一类是分布算法引起的不均衡或沉重的Metadata负担,因热点的不确性这个问题也难完全杜绝。这个造成了系统中最坏的情况不可预测及不可控,和现在分布式底层所用的KV系统的设计有关,如何在业务感知 ​​​​...展开全文c
搜了一天分布式数据库可能会遇到的问题,由突发流量引起的版本堆积与Compaction之间的不协调是一类,还有一类是分布算法引起的不均衡或沉重的Metadata负担,因热点的不确性这个问题也难完全杜绝。这个造成了系统中最坏的情况不可预测及不可控,和现在分布式底层所用的KV系统的设计有关,如何在业务感知 ​​​​...展开全文c
这两天在想MySQL Apply Binlog的理论峰值是多少?然后真实路径与理论路径之间有多少差别,将这些差别的地方解一下,要是能提升个3-5倍,是不是会非常好? ​​​​
守正出奇,很多时侯守正的人会过得很难,出奇的人会觉得奇能解一切问题。 ​​​​
看了一下最近宣传的几个去O案例,觉得到今天为了替换个Oracle数据库,还得用一大堆组件的复杂方案,更坚定了进一步去提升单节点Scaleup能力的信心(刚好找到了突破口),实现一对一的替换能力,才能追求和落实系统运行的简洁髙效。当然我也看好分布式的未来,在数据膨胀超远摩尔定律的今天,狠不得一个 ​​​​...展开全文c
分析了一下数据库相关的开源项目,可以分为四类:一是新业务带来的新数据库模型需求,比如图数据库、时序数据库、文档数据库等;二是Scale Up的需求,很多公司开源了以MySQL/PG为基础的增强版,但在这个点上都极不理想;三是Scale Out的需求,也是Scale Up争扎无效的结果,从最早的客户端动态库到基于 ​​​​...展开全文c
这个问题的解决对基于Binlog的复制也很有帮助,备库的读流量不会影响Apply的速度了。
解决了MySQL的多核Scale Up问题后,一个Oracle数据库(不算RAC)终于可以用一个精心优化过定制的MySQL实例替换了。 ​​​​
解决了MySQL的多核Scale Up问题后,一个Oracle数据库(不算RAC)终于可以用一个精心优化过定制的MySQL实例替换了。 ​​​​

正在加载中,请稍候...