nosql – 任何人都可以解释Project Voldermort或类似的键值存储

CREATE TABLE `users` (
    `user_id` INT NOT NULL AUTO_INCREMENT,… -- Additional user data
    PRIMARY KEY (`user_id`)
);


CREATE TABLE `roles` (
    `role_id` INT NOT NULL AUTO_INCREMENT,`name` VARCHAR(64),PRIMARY KEY (`role_id`)
);


CREATE TABLE `users_roles` (
    `user_id` INT NOT NULL,`role_id` INT NOT NULL,PRIMARY KEY (`user_id`,`role_id`)
);

整洁,整洁,正常化.但是,如果您想获取用户及其角色,则查询很复杂：

SELECT u.*,r.*
  FROM `users` u
  LEFT JOIN `user_roles` ur ON u.`user_id` = ur.`user_id`
  JOIN `roles` r ON ur.`role_id` = r.`role_id`;

如果你对它进行非规范化,它可能看起来像：

CREATE TABLE `users` (
    `user_id` INT NOT NULL AUTO_INCREMENT,`role` VARCHAR(64),… -- Additional user data
    PRIMARY KEY (`user_id`)
);

等效的查询将是：

SELECT * FROM `users`;

这改善了查询的一些性能特征：

>因为您想要的结果已经在表中,所以您不必执行读取侧计算.例如如果您想查看具有给定角色的用户数,则需要GROUP BY和COUNT.如果它是非规范化的,您可以将其存储在另一个表中,该表用于保存角色和具有该角色的用户数.
>您想要的数据位于同一个位置,希望在磁盘上的相同位置.您可以执行一次到几次连续读取,而不需要许多随机搜索.

NoSQL DB针对这些情况进行了高度优化,您可以在这些情况下访问大多数静态的顺序数据集.那时,它只是将字节从磁盘移动到网络.减少工作量,减少开销,提高速度.尽管听起来很简单,但可以对数据和应用程序进行建模,因此感觉很自然.

这种性能的折衷是写入负载,磁盘空间和一些应用程序复杂性.对数据进行非规范化意味着更多的副本,这意味着更多的磁盘空间和写入负载.实际上,每个查询都有一个数据集.因为您将这些计算的负担转移到写入时间而不是读取时间,所以您确实需要某种异步机制来实现这一点,因此一些应用程序的复杂性.

而且因为你必须存储更多的副本,你必须执行更多的写入.这就是为什么你不能用SQL数据库实际复制这种架构的原因 – 扩展写入非常困难.

根据我的经验,这种权衡对于大规模应用来说是非常值得的.如果您想在几个月前阅读更多关于Cassandra,I wrote this piece的实际应用,您可能会发现它有用.