想象一下如果您正在接受系统设计面试，并且需要选择一个数据库来将与订单相关的数据存储在电子商务系统中。您的数据是结构化的，需要保持一致，但是您的查询模式与标准关系数据库不匹配。您需要隔离事务，原子性和所有事物都是酸性的……但是，天哪，它需要像Cassandra一样无限扩展。那么您将如何决定选择哪种存储数据库解决方案？

首先，我们正在处理哪种数据？它是记录还是文件系统或音频/视频内容？我们打算对该数据进行什么样的处理？我们是否需要搜索或运行复杂的分析算法？

 有哪些不同类型的存储解决方案？

根据我们的要求以及我们要如何使用或访问我们的数据，我们可能正在寻找以下存储解决方案：

· 缓存解决方案—如果我们正在设计诸如Twitter或Facebook这样的读取繁重的系统，我们可能最终会捕获大量数据，甚至是完整的时间表，以满足低延迟要求。这里的一些选项是Redis或Memcached。

· 文件系统存储-如果我们正在设计某种资产交付服务，则可能需要在其中存储图像或音频/视频文件，则可能需要使用一种称为Blob存储的方法。一个非常受欢迎的示例是Amazon S3。

· 文本搜索引擎—如果我们正在设计像Amazon这样的系统并且需要实现搜索功能，该怎么办。关于搜索功能的问题是，我们还需要考虑错别字。假设用户要搜索“ 衬衫 ”，但键入“ shrt ”。现在，如果我们不显示任何结果，那将是非常糟糕的用户体验。我们的系统必须足够聪明，才能显示“ 衬衫 ”或“ 短裤 ”的结果。这被称为模糊搜索，这是我们使用诸如Elasticsearch之类的文本搜索引擎的地方。

· 数据仓库-我知道!我们一直在讨论数据和存储，所以我们怎么不考虑大数据!有时我们只需要将所有数据转储到一个存储中，以后就可以执行各种分析。这些系统更多地用于通常是交易的脱机报告。这是我们最终使用Hadoop等数据仓库解决方案的地方。

现在，您可能已经注意到我们一直在谈论“存储解决方案”而不是“数据库”。现在让我们看看数据库 。

 SQL？NoSQL？这里发生了什么？

好了，我们有几个因素基础可以决定要使用哪种数据库，这些因素是数据的结构，查询模式和规模。

我知道有点困惑!这就是为什么我将链接添加到本文中提到的视频中的原因。

他们已经对它进行了漂亮的解释，但是我们还将在接下来的部分中对其进行遍历，因此请继续阅读。

现在，规模， 结构和 查询模式。对。如果信息是结构化的并且可以表示为表，并且如果我们需要事务是原子的，一致的，隔离的和持久的(ACID)，则可以使用关系数据库。最常用的是MySQL。

现在，如果不需要ACID属性，那么您仍然可以使用关系数据库，也可以使用NoSQL替代方法。但是，如果您的数据缺乏结构，则无法将其表示为表，现在我们需要使用NoSQL DB，例如MongoDB，Cassandra，HBase，Couchbase等。这就是查询模式成为决定因素的地方。

附注：Elasticsearch是文档数据库的一种特例。

如果我们在数据中具有各种各样的属性和各种各样的查询，则可以使用 诸如MongoDB或Couchbase之类的Document DB。但是，如果我们必须进行大规模的工作，但需要运行的查询类型很少，那么我们就选择 像Cassandra或HBase这样的列型数据库。您可能已经知道，甚至在列式数据库之间，HBase还是基于Hadoop构建的。

因此，在设置HBase时，我们首先需要设置Hadoop及其相关组件，然后在其之上设置HBase。这在设置系统时增加了一定程度的复杂性，因此，如果只是为了简单起见，我个人会选择Cassandra。在性能方面，两者都给出相似的结果。

现在，像Cassandra这样的Columnar数据库的事情是，它们主要通过分区和复制数据来工作。因此，如果您可以选择分区键，以便所有查询都使用where子句中的公共分区键，那么Cassandra就是您的最佳选择。

我碰到了这篇有关如何通过“ codekarle” 选择最佳存储解决方案的文章，它以Uber如何与他们的驾驶员和骑车人进行交互的示例很好地解释了使用列式数据库还是文档数据库的合理性。系统。让我尝试使用相同的场景对此进行解释。

假设Uber将与乘车相关的信息保存在Cassandra中，驾驶员ID为分区键。现在，当我们运行查询以每天获取特定驱动程序的所有数据时，它会基于分区键驱动程序ID来获取数据。这是Cassandra解决方案的分区方面。现在，如果我们尝试通过客户ID查询特定日期的客户游乐设施，该怎么办？现在，查询将发送到所有分区，效率得到提高。这是解决方案的复制端出现的地方。

我们可以简单地复制整个数据，现在使用客户ID作为分区键。现在，当基于客户ID的查询进入时，它将使用客户ID作为分区键定向到实例。这就是为什么Cassandra可以无限扩展的原因。还记得Cassandra的查询模式吗？我们提到只有在查询种类有限的情况下它才有用。那是因为我们只能将数据复制很多次。

 让我们开始吧，一个数据库够了吗？

现在，我们已经看到了各种存储解决方案，以及如何根据我们的需求和需要存储的信息类型在各种数据库之间进行选择。

例如，对于Amazon，订单数据需要遵循ACID属性，但它需要像Columnar DB一样可无限扩展。在这种情况下，我们将使用MySQL + Cassandra等数据库的组合。现在，所有需要遵循ACID属性的有关正在进行中的订单的信息都将存储在MySQL数据库中，一旦完成，我们就可以将它们移至Cassandra，用作永久存储。因此，只要我们需要ACID属性，数据就会保留在关系数据库中，然后被移到可以根据数据大小进行缩放的柱状数据库中。现在这个问题就解决了。

上述就是关于如何选择适合您需求的数据库全部内容介绍，想了解更多关于数据库的信息，请继续关注。