如何为应用程序选择合适的数据库

如何为应用程序选择合适的数据库

致力于新项目总是超级令人兴奋 - 我们有自由设计和建立任何我们想要的东西的东西。但是，这个规划，当没有正确完成时，将来会导致我们很多痛苦。

选择您的应用程序数据库是您必须制作的重要决策之一，并且随着本文，我打算向您介绍各种数据库选项 - 以及列出一些优点和缺点，以帮助您制作更明智的数据库决策。

内存数据库 Redis

我们的数据库的结构就像一个JSON对象-每个键都是唯一的，每个键都指向某个值。

它保留了内存中的数据，这非常快，但具有容量限制，因此您无法存储大量数据。并且由于没有涉及的磁盘，一切都快速燃烧。

无需查询或联接，因此无需担心太多数据建模。由于没有架构，因此开发人员始终可以根据自己的需要灵活地更改数据。

何时使用这种技术

该技术主要用作缓存机制，用于某些时候非常频繁地获取和观察部分数据因此，关键值技术与其他数据库一起广泛使用作为缓存机制

宽列数据库 ***

这就像钥匙值，但在类固醇上。修改该值以存储一组列，而不是简单数据。

通过引入列，您现在可以对相关数据进行分组，但是仍然没有标准架构。因此，每个键都可以指向不同的分组数据。

由于没有模式，它可以处理非结构化数据，并附上一个名为CQL的查询语言，这类似于SQL，但方法不那么强大。

数据源源不断，例如来自IoT设备，股票市场，金融交易或Netflix的观看历史记录。

何时使用此技术

经常写少更新或读取

这仍然不是通用的。因此，它可以用于存储来自我们所有不同应用程序的历史数据。

文档数据库

这是我们使用的最受欢迎的数据库技巧之一。这显然由文档组成，每个文档都是一组键值对。它们是非结构化，不需要模式。

文档将组合成集合，并且这些集合可以构造成逻辑层次结构。

这种逻辑集合允许您以更逻辑的方式对相关数据进行分组，这似乎类似于关系数据库。

由于我们的数据库无法运行联接查询，我们该如何立即获取所有相关数据?

我们将它全部存储在一起!我们鼓励数据库的非规范化，数据复制/不一致是一种折衷，我们已准备好。

读取速度确实很快，但是在确保数据一致性的同时写入和更新数据可能会有些困难。

文档数据库非常适合通用应用程序，并且可能适合大多数应用程序，游戏和IoT。

如果您真的不确定数据库架构，那么文档数据库是最佳启动方式。

流行的文档类型数据库

当您有大量数据时，文档风格的数据库就不够用了，它们可能直接或间接地相互关联。

对于这些情况，您将必须运行多个复杂查询，然后在前端应用程序中合并所有接收到的数据，或者可以使用关系数据库，其中这些复杂查询由数据库管理。

关系型数据库

我们都听说过这些数据库，最受欢迎的是MySQL，Postgres和***。他们在这里一直在这里，仍然是许多应用程序的热门选择。

我们使用结构化查询语言(SQL)。

“关系”的意义

想象一下一家汽车工厂，那里有制造汽车零件的不同轮毂。

假设门是在一个地方制造的，而轮子，车身和内饰都是在各自不同的位置制造的。

> Imaginary car-factory blueprint

每个制造的零件都有一个唯一的ID分配给它。

因此，一旦必须组装汽车，您就可以从所有这些不同的位置提取所有零件并组装汽车。

对于这样一个工厂建立建立，我们会为这样的工厂创建蓝图，这使得制造汽车的整体过程非常有效和最佳。当它在数据库中使用时，此蓝图称为模式。

因此，我们需要规划数据库的模式，以确保我们的数据库对应用程序的数据需求非常有效。

不足之处

就像如何随着时间的推移，改变汽车工厂的布局与改变要求一致，将花费汽车公司一大堆时间和金钱，这是一个类似的情况，当大规模的应用程序必须这样做时。当您的要求清晰时，请务必使用关系数据库。此外，一旦您每月建造一个具有制造30辆汽车的工厂，您就无法轻易扩展您的工厂，每月制造90辆汽车。同样，我们的关系数据库可能更加努力，但蟑螂DB和***有一些例外，旨在以比例为准。

好的方面

SQL数据库符合ACID标准，这意味着即使读写操作之间可能会失败，我们的数据有效性和完整性也不会受到损害-这使其非常适合与银行/金融相关的数据有一个模式到位后，可以放心，存储的数据将始终存储在一组验证之后的固定结构中，您将在架构中定义

最适合您的是什么?

如果您的要求很明确，并且确定您不需要对要求进行任何大的更改，请继续执行此操作如果您不太确定需求并处于实验阶段，最好使用NoSQL数据库

但是，如果我们不需要创建架构并可以将关系直接存储为数据怎么办?

图数据库

这里我们的数据存储在节点中，并且关系定义为边。非常漂亮!让我们看看如何。

如果您必须在SQL数据库中找出所有学习计算机科学的学生，您需要一个查找/中间商表，该表将所有学生的记录分开地存储了学习计算机科学的所有学生。

在图形中，这将更加简单明了，因为我们不必分别存储数据中的关系部分，而它本能地是这种新样式。

> Relationships are easier to record and maintain in graphs

通过这种直接显示两个节点之间关系的新方法，我们复杂的联接查询变得更加简单，与SQL相比，极大地提高了数据库的性能。

因此，当您依赖于大量加入操作时使用此类数据库，并且由于该依赖于性能劣化。

搜索数据库

如果您要构建Google之类的应用程序，那么在小字符串查询搜索中，您必须快速返回所有匹配的记录-您所说的是全文搜索引擎。

这些数据库基于1999年开始的Apache Lucene项目。

Algolia和Meilisearch是全文搜索引擎。

它们看起来类似于文档类型的数据库。我们有一个索引，并向其中添加了数据对象。搜索数据库引擎将分析文档中的所有文本，并创建称为反向索引的内容。

当您查询某些内容时，数据库只会去检查反向索引，这使整个过程看起来很快，即使对于大型数据库也是如此。

我把最激动人心的一个保存下来。

多模型数据库

那里有多种选择，但最受欢迎的选择似乎是动物区系。

作为应用程序开发，我们通常只关心JSON，我们可以在我们的应用程序的前端中消耗。

通过Fauna，我们不必担心数据建模，架构，缩放，复制或归一化，并且只需获取我们的JSON数据。我们定义了如何使用GraphQL访问我们的数据。

让我们拍摄类似instagram的应用程序的示例。我们将使用JSON定义我们的规则，用于用户，帖子和查询。

我们刚上传了我们的GraphQL架构 - 它会自动创建一个存储数据和索引来查询数据的集合。

在幕后，它是如何利用基于您提供的GraphQL模式的关系，图形和文档等不同的范例。

最好的部分 - 这是符合酸性的，非常快。

您无需担心基础架构。只需定义您如何需要数据，云将为您处理其余的工作。

缺点

显然，定价是不利的。伟大的事物不是免费的，但是对于想要学习的开发人员以及小型创业公司，它们确实提供了慷慨的计划/开源选项。

以下是Fauna列出的一些重要功能：

我们还没有完成!有很多东西可以学习不同的数据库，但是我希望这是对我们开发人员可以在我们的应用程序中使用的各种选项的很好的介绍。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。