合理规划:如何为APP选择正确的数据库

网友投稿 701 2023-05-27

合理规划:如何为APP选择正确的数据库?

合理规划:如何为APP选择正确的数据库?

从事新项目总是令人极度兴奋——可以自由地以自己喜欢的方式设计和构建项目。但如果规划得不合理,就会给未来带来麻烦。需要作出的最关键的决定之一就是选择APP数据库,而此文的目的就是介绍数据库的选择方案——并列举其优势和弊端以帮你明智地选择数据库。

键值

数据库的结构像JSON对象,每个键都是唯一的,每个键都指向某个值。

它把数据保存在内存中,运行速度快,但有容量限制,所以难以存储大量数据。由于没用到硬盘,因而运行非常的快。因为不涉及查询或连接,因此不需要担心数据建模。由于没有模式,开发人员总是可以灵活地根据自己的喜好更改数据。

使用条件:

这种技术主要用作缓存机制,频繁获取和观察数据的某些部分时使用。因此,键值技术作为缓存机制,普遍与其他数据库结合使用。

宽立柱

宽立柱像注射了类固醇的键值。值被修改为存储一组列,而不仅仅是普通数据。

引入一组列之后,现在可以给相关数据分组,但仍没有标准的模式。因此,每个键可以指向不同分组的数据。

由于没有模式,它可以处理非结构化数据,并附带一种名为CQL的查询语言,类似于SQL,但功能要弱得多。数据以连续的流形式出现,比如来自物联网设备、股票市场、金融交易或Netflix观看历史。

使用条件:

写频不经常更新或读取

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

文档型数据库

它是我们使用的最流行的数据库技术之一。很明显,它包括文档,每个文档是一组键值对。它们是非结构化的、不需要模式。

文档被分组到集合中,这些集合可以被构造成逻辑层次结构。逻辑数据集合以更有逻辑性的方式分组相关数据,它似乎与关系数据库相似。

数据库不能运行join查询,怎么立刻获得所有相关的数据呢?把它们全部储存。鼓励非规范化数据库,已经做好会出现数据复制/不一致的准备。

读取数据非常快,但编写和更新数据的同时要保证一致性却是一项挑战。文档数据库非常适合通用应用程序,也可能非常适合大多数应用程序、游戏和物联网。

若对数据库模式不甚了解,则记录数据库是最佳启动方式。

流行文档型数据库

数据量很多,而且数据之间有着直接或间接的关系时,文档型数据库无法容纳。在这种情况下,必须运行多个复杂的查询,然后在前端应用程序中合并所有接收到的数据,或者可以使用关系数据库,其中这些复杂的查询由数据库管理

关系数据库

这类数据库中,著名的一些包括MySQL, Postgres, and ***。他们出现很长时间了,对于很对应用程序来说都是不错的选择。

想象一个汽车工厂,它有不同的轮毂来生产汽车部件。假设门是在一个地方制造的,而轮子、车身和内部零件都是在各自不同的地方制造的。

假设的车厂蓝图

每个制造的部件都有一个唯一的ID。所以一旦汽车组装完毕,就可以从不同的地方取来所有的零件,然后组装汽车。

建造这样一个工厂需要制定蓝图,以确保整个生产过程非常高效和优化。这个蓝图在使用在数据库中时称为模式。因此,需要为数据库规划模式,以确保数据库也有效性高,能满足应用程序的数据需求。

缺点:

久而久之,改变车厂的布局就像改变要求一样,会浪费汽车公司的时间和金钱。大型应用程序也面临相似的情况。确保在要求清晰的情况下使用关系数据库。而且,一旦建立一个每月能制造30辆车的工厂,那么就很难把产量提升到90。同理,关系数据库很难扩大规模,但也有例外,如Cockroach DB 和 ***,在设计时添加了扩大规模的功能。

优点:

SQL数据库符合ACID标准,这意味着即使读写操作之间可能会失败,数据有效性和完整性也不会受到损害-这使其非常适合与银行/金融相关的数据。一旦有了合适的模式,就可以确保存储的数据将始终存储在一组验证之后的固定结构中,这些验证先模式中得以定义。

哪个最适合你?

若要求清晰,不需要大幅改变要求,选择这个。若对需求不是很确定,并且处于某种试验阶段,那么最好使用NoSQL数据库。

要是不需要建立模式,直接把关系存成数据,该用哪个呢?

图表数据库

数据存储在节点中,关系被定义为边。一起来看看怎么做。

要想在SQL数据库里查找所有学习计算机科学的学生,则需要一个查找/中间人表,该表单独存储所有学习计算机科学的学生的记录。

图表更加简单明了,因为不必分别存储数据中的关系部分,而自动带有新式数据。

关系更易于记录和保持在图表里

有了这个直接显示两个节点间的关系的新方式,复杂的联接查询变得更简单,与SQL相比,极大地提高了数据的性能。因此,因依赖大量联接操作而降低数据的性能时,可以使用这种数据库。

可搜索数据库

如果你正在构建一个像谷歌这样的应用程序,在小字符串查询搜索中,你必须快速返回所有匹配的记录,那么这就是一个全文搜索引擎。这些数据库基于始于1999年的Apache Lucene项目。

Algolia和MeiliSearch是全文搜索引擎。它们看起来类似于文档类型的数据库。有一个索引,并向它添加数据对象。搜索数据库引擎将分析文档中的所有文本,并创建称为倒排索引的东西。

当你查询某项内容时,数据库只会检查反向索引,这使得整个过程看起来异常迅速,即使对于大型数据库也是如此。

多模式数据库

可供选择的数据库有很多,但最流行的似乎是Fauna。作为应用开发者,我们通常只关心JSON,我们可以在应用前端使用它。有了Fauna,不必担心数据建模、模式、缩放、复制或规范化过程,只需获取JSON数据即可。使用GraphQL定义访问数据的方式。

以一个类似instagram的应用程序的场景为例。将使用JSON为用户、发布和查询定义规则。

我们刚刚上传了GraphQL模式,它会自动创建一个集合来存储数据和查询数据的索引。在幕后,它将考虑如何利用基于您提供的GraphQL模式的不同范例,如关系、图表和文档。只是简单地以与在文档数据库中相同的方式添加数据,而且不会受到数据建模的限制。

优点:

它符合ACID标准、运行速度极快。不必担心基础设施。只需定义对数据的需求,云端会解决其余的问题。

缺点:

价格明显是个缺点。好的东西不是免费的,但是对于想要学习的开发人员以及小型创业公司,它们确实提供了慷慨的计划/开源选项。

以下是Fauna列出的值得注意的重要特点:

这些并不是全部!要学习的不同的数据库还有很多,但我希望本文的介绍能帮你在设计应用程序时思路清晰有方向。

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

上一篇:大厂Redis热点key解决之道
下一篇:数据从哪里找?手把手教你构建数据集
相关文章