[什么时候有人将键值存储（Redis，内存缓存等）用于Web开发？实际用例将是最有帮助的。
我的困惑是，简单的数据库似乎功能更多，因为据我所知，它可以完成键值存储可以做的所有事情，此外，它还允许您进行过滤/查询。意思是，据我所知，您不能像这样进行过滤：
select * homes where price > 100000
带有键值存储。
假装StackOverflow使用键值存储（内存缓存，redis等）。
键值存储将如何帮助满足Stackoverflow托管需求？
我无法回答何时使用键值（此处为kv）数据存储的问题，但我可以向您展示一些示例，并回答您的stackoverflow示例。
通过数据库访问，您最需要的是kv商店。例如，用户使用用户名“ joe”登录。因此，您在数据库中查找“ user：joe”并检索其密码（当然是哈希值）。或者，也许您在“ user：pass：joe”下输入了他的密码，这真的没有关系。如果它是堆栈溢出，并且您正在渲染页面http://stackoverflow.com/questions/6935566/when-to-use-a-key-value-store-for-web-development，则将查找“ question：6935566”并使用它。很容易看到kv商店如何解决您的大多数问题。
我想说的是，kv存储是传统RDMS提供的功能的子集。这是因为传统RDMS的设计会带来许多缩放问题，并且通常会在缩放时失去功能。 kv商店不具备这些功能，因此它们不会限制您。但是，这些功能通常可以以任何方式创建，可以从核心设计为可扩展的（因为如果没有，它们将立即变得显而易见）。
然而，这并不意味着有些事情你做不到。例如，您提到查询。这是许多kv商店的陷阱，因为它们通常不知道该值（并非总是如此，例如，redis等），并且无法找到您要查找的内容。更糟糕的是，它们并非旨在快速地做到这一点，它们只是通过按键来快速查找。
解决此问题的一种方法是按字母顺序对密钥进行排序，并允许范围查询。这实质上是“给我在问题1和问题5之间的一切”。现在该示例已经毫无用处，但是范围查询有很多用途。
[您说过，您希望所有房屋的价格都超过$ 100,000。如果您希望能够这样做，则可以按价格创建房屋指数。假设您有以下房屋。
house:0 -> {"color":"blue","sold":false,"city":"Stackoverville","price":500000}
house:1 -> {"color":"red","sold":true,"city":"Toronto","price":150000}
house:2 -> {"color":"beige","sold":false,"city":"Toronto","price":40000}
house:3 -> {"color":"blue","sold":false,"city":"The Blogosphere","price":110000}
在SQL中，您将每个字段存储在列中，而不是将所有字段都存储在一个（在本例中为JSON）文档中。并且可以SELECT * FROM houses WHERE price > 100000。这似乎很好，但如果没有建立索引，则需要查看表中的每栋房屋并检查其价格，如果您有数百万栋房屋，这可能会很慢。因此，对于kv商店，您还需要一个索引。主要区别在于，SQL数据库将无声地执行慢速操作，而kv存储将无法执行此操作。
如果没有范围查询，则需要将索引粘贴在单个文档中，这使安全更新索引变得很麻烦，这意味着您必须为每个查询下载整个索引，这再次限制了可伸缩性。] >
house:index:price -> [{"price":500000,"id":"0"},{"price":150000,"id":"1"},{"price":110000,"id":"3"},{"price":40000,"id":"2"}]但是，如果您有范围查询（通常称为键扫描），则可以创建如下所示的索引：
house:index:price:040000 -> 2 house:index:price:110000 -> 3 house:index:price:150000 -> 1 house:index:price:500000 -> 0然后您可以要求输入
house:index:price:100000和house:index:price::之间的键（'：'字符是'9'之后的字符，您将得到[3,1,0]，这是所有房价都超过$ 100,000的房屋（它们也很有帮助）。与此相关的另一件好事是，它们很可能位于群集的一个“分区”上，因此此查询将与单次获取（加上微小的额外传输开销）大约花费相同的时间，或者如果您的范围恰好超过两次，则花费两次服务器边界（但是这些可以并行完成！）。
这样显示了如何在kv商店中执行查询。您可以查询可以作为字符串订购的任何内容（几乎所有内容）并非常快速地查找它。如果没有范围查询，则需要将整个索引存储在一个很烂的键下，但是，如果您有范围查询，那将非常好而且非常快。这是一个更复杂的示例。
我希望多伦多的未售出房屋的价格低于$ 100,000。我只需要设计索引。 （我添加了几套房子，以使其更有意义）。起初，您可能只是为每个属性建立另一个索引，但是您很快就会意识到，这意味着您必须选择每个未售出的房子并从数据库中下载。 （这就是我所说的缩放问题显而易见时的意思。）解决方案是使用多索引。构建完成后，您可以精确选择所需的值。
house:index:sold:city:price:f~Fooville~000010:5 -> "" house:index:sold:city:price:f~Toronto~040000:2 -> "" house:index:sold:city:price:f~Toronto~140000:4 -> "" house:index:sold:city:price:t~Stackoverville~500000:0 -> "" house:index:sold:city:price:t~The Blogosphere~110000:3 -> "" house:index:sold:city:price:t~Toronto~150000:1 -> ""现在，与上一个示例不同，我将id放在密钥中。这允许两个房屋具有相同的属性。我本可以将它们合并为值，但是添加移除索引变得更加困难。我还选择了用
~分隔数据。这是因为按字母顺序在所有字母之后，以确保全名将被排序，而且我不必在每个城市都使用相同的长度。在生产系统中，我可能会使用字节255或0。
现在范围house:index:sold:city:price:f~Toronto~100000-house:index:sold:city:price:f~Toronto~~将选择所有与查询匹配的房屋。需要注意的重要一点是，查询与结果数量成线性比例关系。这确实意味着您必须为要建立索引的每组属性都建立一个索引（尽管本例中的索引也适用于已售出和已售城市查询）。这似乎是一项艰巨的工作，但最终您意识到这只是您在做，而不是您的数据库。我敢肯定，我们很快就会开始看到此类库：D
稍微扩展了主题之后，我显示了：
我认为您会发现kv存储足以满足许多应用程序的需求，并且通常可以提供比传统RDMS更好的性能和可用性。话虽如此，每个应用程序都是不同的，因此不可能回答原始问题。
不要将NoSQL类型的数据库与memcached之类的东西混淆（后者不打算永久存储数据）。
noSQL有两个通用可行的用例：
键值存储通常非常快，因此最好将它们用作高速访问数据的缓存，并且很少进行更新以减少数据库负载。
只是bstrawson的答案的补充，“ mem-cache
Stack Overflow确实确实广泛使用Redis。 @Mark Gravell在a couple of nice blog posts中以堆栈溢出为例，对问题的详细解答。 Mark是出色的Booksleeve完全异步.NET Redis绑定库的作者。