Py学习  »  NoSql

面向中小型应用程序的非关系数据库(nosql)

Kenny Mann • 4 年前 • 871 次点击  

非关系型数据库(如键-值对存储)在大规模数据集(google、facebook、linkedin)中的好处显而易见。您认为中小型应用程序如何从使用非关系数据库中获益?

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/41092
 
871 次点击  
文章 [ 7 ]  |  最新文章 4 年前
Ashish Pancholi
Reply   •   1 楼
Ashish Pancholi    10 年前

amazon simpledb对于那些需要非关系数据库来存储较小的、非结构化数据的人非常有用。amazon simpledb将每个域的存储大小限制为10gb。amazon simpledb提供了简单性和灵活性。simpledb自动索引所有数据。Amazon SimpleDB的定价是基于您的实际盒子使用情况。您可以在amazon simpledb中存储任何utf-8字符串数据。

Bob77
Reply   •   2 楼
Bob77    10 年前

如果您匹配一些常见的paas云服务,比如键值存储、blob存储和消息队列存储,那么您就拥有一些方便的工具,可以将小型应用程序开发人员从dba和基础设施人员的专制中解放出来。

如今,小型开发人员常常求助于jet mdb。为什么?简单、共享的访问就像将mdb文件存储在整个应用程序社区可见的文件共享上一样简单。当他们能够逃脱时(即从守门员那里获得必要的支持),他们可能会使用sql server express、mysql等。

可悲的是,在一个大型组织中,这些守门人很难对付。提到一个“数据库”,你会突然面临DBA帮派和相关的延迟、应用程序审查、优先级等。提到需要一个服务器,你就会面临另一个行刑队。

如果您不需要rdbms,那么使用nosql解决方案和相关的云服务可以消除大量这种情况。

首先,真正需要的是一个公共云提供商的帐户。这是一个相当容易的概念一旦得到批准。作为一个开发人员,一旦你被批准并分配了一个帐户,对你来说就更容易了,当然还有一些常见的簿记问题。

但我们还是把它放在一边吧。如果您的组织为这样的用途实现了私有云呢?很多外部计费的问题消失了,数据不安全的担忧消失了,等等。

这样的事情可以以半匿名的方式实现和提供,几乎和管理文件共享一样简单。匿名性的出现是因为一旦你被批准在内部云上开发,没有人需要对你使用它的活动的细节进行挑剔,就像他们需要在你可以在现有文件共享上创建文件之前检查请求一样。

显然会有存储和CPU配额需要管理。没有人能承受不确定地继续扩大规模。恶意应用程序可能会消耗大量资源。所以你需要的是某种配额制度来限制使用。无论这是由基础设施人员监控的,都是一个实现决策,还是可以像对待文件共享一样对待:用完之后,有人冲着程序员大喊大叫,程序员反过来查看它,并在适当的时候请求更多(或者修复他的bug)。

但是,您最终得到的是“实用计算”,并且通过“不使用sql”,您不会产生处理dba的成本(和问题)。当你完成一些工作时,他们仍然可以安静地坐在他们的大办公室里上网。

mythz
Reply   •   3 楼
mythz    13 年前

好吧,rdbms的一个问题是,您需要花费精力将编程语言领域模型映射到rdbms的关系模式。这项工作通常花费在配置orm层上。

使用nosql数据库,您不必将对象映射到关系模型,而且在大多数情况下,您的对象是按原样序列化的。由于缺乏中间模式, data migrations and versioning become easier .

另一个好处是可伸缩性和性能。因为大多数时候你的数据都是通过“密钥”有效地接收的,所以所有的东西都要使用和索引。通过对键执行一个%(mod)来对提供自然数据分区的可用nosql实例的数量进行简单的分片是可能的,这对于分片是至关重要的。

如果您有兴趣了解使用nosql开发与rdbms的区别,那么我有一个教程演示如何进行 designing a simple blog application using Redis .

code43
Reply   •   4 楼
code43    14 年前

这个问题可能需要更多的上下文…假设是python环境,请考虑y_serial项目的教程: http://yserial.sourceforge.net/

nosql不仅仅是为了可伸缩性而采用的。序列化(任意python对象的序列化)和持久化在任何规模上都非常方便——因此将键值系统视为一种方法。

nawroth
Reply   •   5 楼
nawroth    14 年前

当涉及到图形数据库时(比如 Neo4j -我参与的一个项目)他们擅长 scaling to complexity . 这意味着,他们提供 "better substrates for modeling business domains" (见 The State of NoSQL 也通过 Ben Scofield 也一样。在我看来,这在中小型应用程序中非常重要。

通过示例可以更好地解释这一点,因此这里有一些指向示例应用程序/域建模的链接:

Mocky
Reply   •   6 楼
Mocky    14 年前

当数据库模型(键值、文档等)与应用程序的需求很好地匹配,并且不需要高级关系功能时,在这种规模上使用nosql数据库的好处就在于。

在小范围内,性能不是问题,因为几乎所有的东西都很快。存储引擎是没有问题的,如果您不需要复杂的查询引擎,那么缺少sql支持就不是问题。

剩下的就是它的合身性和易用性。但老实说,工具确实成了一个问题。关系数据库工具是成熟的,nosql工具的特性不那么丰富,也不那么顽强。太多时候,它是滚动你自己的工具。一定要考虑一下你会放弃什么工具,以及你有多需要它们。

与产品相比,考虑nosql服务(如amazon simpledb和microsoft azure)时,小型项目还有一系列额外的优势。如果你只需要为你所使用的东西付费,而你却不怎么使用它,那么它比运行一个专用服务器要便宜得多,甚至可以免费使用simpledb免费使用层之类的东西。

您还可以避免一些服务器和数据库维护成本。如果你没有dba,或者你的dba已经工作过度,这将是一个巨大的胜利。当然,您仍有管理工作要做,但它大大减少了,而且通常更简单。

Ira Baxter
Reply   •   7 楼
Ira Baxter    14 年前

自60年代以来,ibm大型机就拥有“非关系”数据库(层次数据库,如ims+变体)。这些数据库仍在使用,因为它们速度极快,处理大规模的问题也很好。

关系数据库的目的是提供一种常规的、相对抽象的方法来存储和检索数据,在这种方法中,可以相对独立于数据模型进行调整(对于ims来说不是这样)。它们的设计是为了应对无法轻松重组hiearchical数据库的问题。好的方面是好的组织;坏的方面是中等的,而不是高绩效。

google提供可伸缩的存储和mapreduce来处理规模。这不是关系。

在过去的十年中,有一个巨大的推动将数据存储在XML中,本质上是分层的,因为XML是隐式层次结构的。这是一个巨大的错误,因为它重复了继承数据库的不便,但没有任何性能。我一点也不惊讶这场运动似乎已经几乎消亡了。

在我看来,大多数对非关系型的实际推动似乎都是针对性能和规模的。我不认为这对“小型”应用程序有多大帮助。

人们已经提出了很多基于知识的数据管理方案,但是并没有做很多实际的数据管理工作。Doug Lenat CYC 想到这里。数据库的能力 为了帮助应用程序得出不明显的结论,我对那些试图“聪明”的“小”应用程序非常感兴趣。但这些还不多。