00k

Results 14 issues of 00k

旧版统一接口:void Put (RowMutation* mu); 新版同步接口:ErrorCode Put (RowMutation* mu); 新版异步接口:void Put (RowMutation* mu, CallbackFunc cb_func, void* cb_ctx); 兼容性: 因为旧版接口跟新版同步接口一样,所以用户的旧代码会调用新版的同步接口,为了保证兼容,同步接口的实现里面要判断RowMutation的GetCallback和GetContext是否非NULL,如果是的话,调用异步接口,并直接返回OK。 用户的旧代码会通过RowMutation的GetError得到错误码,因此新版同步接口也要将错误码Set到RowMutation中。

class/enhancement
module/sdk
stat/not-decide

大开脑洞的想法: **获得的好处:** 1. 彻底解决meta和master内存不一致问题 2. load/unload/split...不需要单独为meta弄一个if分支 3. 对meta的访问不会被其它表影响 4. 可以做针对meta的专门优化,例如全内存存储、利于查询的内存结构 **带来的问题:** 1. 写扩展性:写是由master发起的,如果写meta成为瓶颈,那master的处理一定先成为瓶颈。在解决这个问题之前,master需要先拆分。 2. 读扩展性:master可以指定一些ts成为meta代理,只提供读服务。 3. master不能挂:master本来也不能挂(挂了没人管load),master本来也可以挂(master有热备)。 4. 架构不够牛逼啊:如人饮水冷暖自知,牛逼不能当饭吃,如果不是遇到各种问题,我也不会有这想法了。 抛开改动成本这些问题,假如tera是从头开始,你会支持这种设计吗?请写下你的看法。

class/question
module/master
stat/will-see-later

safemode期间往往有未被kick的ts,master收到leave命令之后会很快将它们kick,这些ts的重启又会导致master重新计算tablet存活率,并因为存活率低又进入safemode

class/bug
module/master
stat/will-see-later

class/enhancement
module/sdk
stat/ready-to-do

gc代码梳理

class/enhancement
module/master
stat/not-decide

Now we use thread_pool to load/unload/split. Because of the limit of thread number, we have to control the concurrency. So when a ts restart, the load process is very slow....

class/enhancement
module/ts
stat/not-decide

1. What is the valid value range of timestamp? only positive number? positive and negative number? 2. If users have their own representation of version (which is not timestamp), is...

class/question
module/sdk
stat/will-see-later

1. 阻塞写,不阻塞读 2. 持久化,随tablet迁移 3. 随用户数据写入和读出,不产生额外的IO请求

class/newfeature
module/ts
stat/will-see-later

- [ ] mission statement - [x] roles statement - [ ] PMC guidence - [ ] committer guidence - [ ] contributer guidence

stat/will-do-later
module/other

绝大多数是误报,检测机制需要升级

class/enhancement
module/master
stat/will-see-later