web-applications - 何时使用键值存储进行Web开发？

Question

何时有人会使用键值(Redis，内存缓存等)进行Web开发？实际用例将是最有帮助的。

我的困惑是，一个简单的数据库似乎功能更多，因为据我所知，它可以完成键值存储可以做的所有事情，此外，它还允许您进行过滤/查询。意思是，据我所知，您不能执行以下过滤:

select * homes where price > 100000

与键值存储。

例

我们假设StackOverflow使用键值存储(内存缓存，Redis等)。

键值存储将如何帮助满足Stackoverflow托管需求？

Answer 1

我无法回答何时使用键值(此处为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之间的一切”。现在，该示例已经毫无用处，但是范围查询有许多用途。
您说您希望所有房屋的价格都超过10万美元。如果您希望做到这一点，则可以按价格创建房屋指数。假设您有以下房屋。

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商店中执行查询。您可以查询可以作为字符串订购的任何内容(几乎所有内容)，并可以非常快速地查找它。如果没有范围查询，则需要将整个索引存储在一个很烂的键下，但是，如果您有范围查询，那将非常好而且非常快。这是一个更复杂的示例。
我希望多伦多的未售出房屋的价格低于10万加元。我只需要设计索引即可。 (我添加了几栋房子，以使其更有意义。)起初，您可能只是为每个属性建立另一个索引，但是您很快就会意识到，这意味着您必须选择每个未售出的房子并从数据库下载。 (这就是我所说的缩放问题显而易见时的意思。)解决方案是使用多索引。构建完成后，您可以精确选择所需的值。

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商店的某些用途。

如何在kv商店中进行查询。

我认为您会发现kv存储足以满足许多应用程序的需求，并且通常可以提供比传统RDMS更好的性能和可用性。话虽如此，每个应用程序都是不同的，因此不可能回答原始问题。