谁能解释伏地魔项目或类似键值存储有用的场景？答案

【问题标题】：Can anyone explain scenarios where Project Voldermort or similar key value stores are useful?谁能解释伏地魔项目或类似键值存储有用的场景？
【发布时间】：2010-12-08 09:49:34
【问题描述】：

我可以看到自己使用Project Voldermort 来缓存来自传统 RDBMS 查询的结果。但是在这种情况下，它几乎没有提供比其他（Java）缓存系统（例如 EHcache Jcache 等）的主要优势。

我还能在哪里使用 Project Voldermort 或类似的 Key Value 商店？您如何在业务应用程序中使用它？

【问题讨论】：

标签： nosql key-value voldemort

【解决方案1】：

伏地魔计划是NoSQL 运动的一部分。计算机体系结构的趋势正在将数据库推向需要水平可扩展性的方向。 NOSQL 试图解决这个要求。

此类键/值存储所声称的好处之一是能够在没有传统 RDBMS 开销的情况下处理大量数据。

http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_

【讨论】：

我知道这是一项很酷的技术。我想知道普通企业如何使用它。我所说的普通企业，是指一直在使用传统关系数据库的非谷歌和非 Facebook 类型的公司。我正在寻找人们将这项技术用于“正常”业务的用例或场景。
另见 Bigtable：jetfar.com/bigtable-and-why-it-changes-everything 和 labs.google.com/papers/bigtable.html

【解决方案2】：

提高数据库速度的一种方法是非规范化。以这个 MySQL 为例：

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，您可能会发现它对您有所帮助。

【讨论】：