9. SQL vs. NoSQL

在数据库领域,有两种主要类型的解决方案:SQL和NoSQL - 或关系数据库和非关系数据库。 它们的构建方式,存储的信息类型以及存储方式各不相同。

关系数据库是结构化的,具有预定义的SCHEMA,如存储电话号码和地址的电话簿。 非关系数据库是非结构化的,分布式的并且具有动态SCHEMA,例如文件夹,其包含从人的地址和电话号码到他们的Facebook“喜欢”和在线购物偏好的所有内容。

SQL

关系数据库以行和列的形式存储数据。 每行包含有关一个实体的所有信息,列是所有单独的数据点。 一些最流行的关系数据库是MySQL,Oracle,MS SQL Server,SQLite,Postgres,MariaDB等。

NoSQL

键值存储:数据存储在键值对数组中。 'key'是属性名称,链接到'value'。包括Redis,Voldemort和Dynamo。

文档数据库:在这些数据库中,数据存储在文档中,而不是表中的行和列,并且这些文档在集合中组合在一起。每个文档可以具有完全不同的结构。文档数据库包括CouchDB和MongoDB。

列族数据库:在列式数据库中,我们有列族,而不是“表”,它们是行的容器。与关系数据库不同,我们不需要预先知道所有列,并且每行不必具有相同数量的列。列族数据库最适合分析大型数据集 - 如Cassandra和HBase。

图形数据库:这些数据库用于存储关系最佳表示。数据以图形结构保存,包括节点(实体),属性(有关实体的信息)和线(实体之间的连接)。图数据库的示例包括Neo4J和InfiniteGraph。

SQL 和 NOSQL 的区别

存储:

SQL将数据存储在表中,其中每行代表一个实体,每列代表一个关于该实体的数据点;例如,如果我们将汽车实体存储在表格中,则不同的列可以是“颜色”,“制作”,“模型”等。

NoSQL数据库具有不同的数据存储模型。主要是键值,文档,图形和列。

SCHEMA:

在SQL中,每条记录都符合固定SCHEMA,这意味着必须在数据输入之前决定和选择列,并且每行必须包含每列的数据。模式可以在以后更改,但它涉及修改整个数据库并脱机一段时间。

而在NoSQL中,SCHEMA是动态的。可以动态添加列,每个“行”(或等效的)不必包含每个“列”的数据。

查询:

SQL数据库使用SQL(结构化查询语言)来定义和操作数据,这非常强大。在NoSQL数据库中,查询专注于文档集合。有时它也称为UnQL(非结构化查询语言)。不同的数据库使用UnQL有不同的语法。

可伸缩性:

在大多数常见情况下,SQL数据库是可垂直扩展的,即通过增加硬件的马力(更高的内存,CPU等),这可能变得非常昂贵。可以跨多个服务器扩展关系数据库,但这是一个具有挑战性且耗时的过程。通常要程序员自己实现。

另一方面,NoSQL数据库可以横向扩展,这意味着我们可以在NoSQL数据库基础架构中轻松添加更多服务器来处理大量流量。任何便宜的商品硬件或云实例都可以托管NoSQL数据库,从而使其比垂直扩展更具成本效益。许多NoSQL技术也会自动在服务器之间分配数据。

可靠性或ACID合规性(原子性,一致性,隔离性,持久性):

绝大多数关系数据库都符合ACID。因此,在数据可靠性和执行事务的安全保证方面,SQL数据库仍然是更好的选择。

大多数NoSQL解决方案都牺牲了ACID合规性以实现性能和可扩展性。

如何选择

在数据库技术方面,没有一个通用的解决方案。这就是为什么许多企业依赖于关系数据库和非关系数据库来满足不同需求的原因。即使NoSQL数据库因其速度和可扩展性而越来越受欢迎,但仍然存在高度结构化的SQL数据库可能表现更好的情况;选择合适的技术取决于用例。

使用SQL数据库的原因
以下是选择SQL数据库的几个原因:

我们需要确保遵守ACID。 ACID合规性通过准确规定事务如何与数据库交互来减少异常并保护数据库的完整性。通常,NoSQL数据库牺牲了ACID合规性以实现可扩展性和处理速度,但对于许多电子商务和金融应用程序而言,符合ACID标准的数据库仍然是首选。

您的数据结构合理且不变。如果您的业务没有经历需要更多服务器的大规模增长,并且如果您只处理一致的数据,则可能没有理由使用旨在支持各种数据类型和高流量的系统。

总结,需要TRANSCATION,QPS不高,SCHEMA明确,支持使用关系型数据库。

使用NoSQL数据库的原因
当我们的系统的所有其他组件快速运转时,NoSQL数据库会阻止数据成为系统的瓶颈。大数据有助于NoSQL数据库取得巨大成功,主要是因为它处理的数据与传统的关系数据库不同。一些流行的NoSQL数据库例子是MongoDB,CouchDB,Cassandra和HBase。

存储大量通常几乎没有结构的数据。 NoSQL数据库对我们可以存储在一起的数据类型没有限制,并允许我们根据需要更改添加不同的新类型。使用基于文档的数据库,您可以将数据存储在一个位置,而无需事先定义数据的“类型”。
充分利用云计算和存储。基于云的存储是一种极好的节省成本的解决方案,但需要将数据轻松分布在多个服务器上以进行扩展。在现场或在云中使用商用(价格合理,体积更小)的硬件可以省去额外软件的麻烦,而像Cassandra这样的NoSQL数据库可以在多个数据中心开箱即用,而不会有太多麻烦。
快速开发。 NoSQL对快速开发非常有用,因为它不需要提前准备好。如果您正在进行系统的快速迭代,这需要频繁更新数据结构,而不会在版本之间造成大量停机,那么关系数据库会降低您的速度。

总结,QPS高,易于水平扩展(可利用云资源),数据SCHEMA弱。海量数据。选择NOSQL。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,616评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,020评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,078评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,040评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,154评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,265评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,298评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,072评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,491评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,795评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,970评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,654评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,272评论 3 318
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,985评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,223评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,815评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,852评论 2 351

推荐阅读更多精彩内容