nosql.txt

// NoSql
1、NoSQL 可以水平扩展的原因有？
    (tips：NoSQL数据模型简单，没有事务支持，没有Join操作)

2、数据库的索引数据结构在选型时，面临三方面的问题，即RUM(Read Optimization / Update Optimization / Memory space)，
    这三个方面分别对应着不同的索引算法实现。
    (1)读优化的数据结构有，hash，trie等
    (2)写优化的数据结构有，lsm，partitioned-B-Tree等
    (3)空间优化的数据结构有，bloom filter等
    不同的应用应该根据自己的特点进行选择
    上述细节可以参考RUM的论文

// Redis

1、Redis中渐进式rehash实现？
    (tips：避免了集中式rehash导致系统繁忙，将整个rehash过程均摊到每一次的GET PUT
     操作中，一步步完成)

2、Redis实现分布式lock的问题在于，如果某个持有锁的client因为GC或者IO操作suspend，
    在恢复后，没办法确认当前的锁状态，当然，在恢复执行后可以再次执行加锁操作，以
    确认是否持有锁，但是这没有完全避免GC和sleep的可能，还是会有可能持有一个过期的
    锁，然后写入非预期的数据。
    一种解决方案就是锁中带有一个单调递增的token，server只允许比当前记录的token大的client的
    写操作，之前因为sleep而过期的锁会被拒绝写入数据。
    当前redlock算法依赖于集群中的大多数返回加锁成功，但是当出现网络分区等异常场景时，
    算法没法保证加锁的正确性。

3、redis中如果某个key出现热点，怎么解决呢？思路可能有如下几点
    (1)QoS限流，当前也是这么做的
    (2)本地缓存，减少访问redis量
    (3)热点key添加其他信息，如timestamp，这样人为区分开访问节点

4、Redis基于LRU实现了一套VM管理机制，原因有如下几个点
    (tips：
     1、Redis管理的数据结构比较复杂，不适合直接用操作系统的page管理
     2、操作系统的page是4KB大小固定的，但是像Redis中的list结构，有可能包含了很多的node，
        需要由Redis自己来将整个结构进行写回
     3、Redis如果依赖操作系统的page，由于本身实现是单线程的，前一个请求访问到了在磁盘中的key，
        那么会阻塞后续的所有client访问
    为了绕过page cache，很多数据库的实现都是自己管理VM，自己实现flush，然后以 O_DIRECT 的模式
    将数据写回，避免数据的二次拷贝
    )

// LevelDB
1、BloomFilter有什么缺点？
    (tips：
     1、如果判断一个key不在，那就真的不在，但是如果判断在，那有可能不在
     2、BloomFilter结构不支持delete操作，不过这个在LevelDB中还好，因为levelDB在SSTable中
     使用BloomFilter，且SSTable结构是不变的，避开了这一问题，有其他结构提出了改进的操作)


// Memcached



// Riak



// HBase