10种不可以使用关系数据库的场景

1.搜索: 即使Oralce商店自己也不使用Oracle Text, 但是你会看到很多人使用复杂的like之类查询语句,这是非常丑陋的,兼容性相当差,Oracle数据库获得数据的过程是艰难的,除了Oralce以外,其他数据库几乎没有真正的搜索扩展。推荐使用类似Hibernate Search, Apache Solr, or even Autonomy.能有更好地性能。

系统主要使用类似模糊查询的功能

2. 推荐: 这是很多电子商务产品最丑陋的地方,他们获取关于用户的许多数据,然后试图进行推荐。考虑一个社交网络场景下,如果你的朋友买了袜子,我也推荐袜子给你,这是从RDBMS中获得的数据,我们会使用Join表等SQL语句多层次查询,这在Neo4J之类图库中只需要两行即可。你可以在社交系统中使用关系数据库,但是会失去天然的实时性。

Neo4J是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎,但是它将结构化数据存储在网络上而不是表中,Neo看作是一个高性能的图引擎,该引擎具有成熟和健壮的数据库的所有特性。程序员工作在一个面向对象的、灵活的网络结构下而不是严格、静态的表中——但是他们可以享受到具备完全的事务特性、企业级的数据库的所有好处。

3. 高频交易:我们大多数人都认为交易系统必须RDBMS,因为它能保证事务性,对吗?错了. 高频交易者往往是采用NoSQL的第一批人,对于HFT低延迟为王(低延迟意味快速响应,特别是大访问量情况下快速完成用户交易),当然,你可以进行高难度篮球投篮,你也能使用关系数据库完成低延迟,但是关系数据库真的不是为这个目标设计的。.

nosql的优势:高性能
4.商品分类编目: 使用SQL来映射商品不是一件令人愉快的事情,当我为一家移动电话商家服务,商品是手机,除了标准模型以外还有几种不同性质的手机,在不同市场下都不同的名称,同样的模型可以有完全不同的部件。管理这些扁平化数据很方便的工具我比较喜欢图库类如:Neo4j.

在一个化工企业我还有类似的经验,我们对产品进行了非常吃力愚蠢的字符串映射,但是将产品信息保存在图库中就非常简单方便,即使使用文本数据库如CouchBase 2.0 or MongoDB也还可以。

Couchbase产品包含了CouchDB的一个副本。Couchbase产品向CouchDB添加了缓存、集群等功能,CouchDB是个文档数据库,提供了端到端的复制方法

CouchBase与MongoDB都是面向文档

5. 用户/用户组和权限ACL: 在某个程度上讲, LDAP是最原始的NoSQL数据库,LDAP是为用户权限设计的。可惜当技术发展LDAP成为过去时,开发人员只好使用创建数据表的方式来欺骗蒙混过关。在企业软件中,User表和Role表方式不能再这样走下去了。

个人认为用户角色的关联也可以用Neo4j.

6. 日志分析: Hadoop 或是和小型集群的 RHQ/JBossON 是一个好的选择,将除了错误以外日志截获到这两个系统中,做一件很复杂的事情,生活将变得更糟糕,非结构化数据正是 MapReduce强项,可以使用PIG之类方便操作,但是主流系统监控工具大部分是基于RDBMS,实际上日志分析真的不需要事务,低延迟才是第一追求。

hadoop=分布式文件系统(保存日志)+mapreduce(非结构化数据分析+并发(效率))

7. 媒体库: 使用关系数据库存储元数据也许还可以(其实最好还是使用文本数据库Couchbase 2.0 or MongoDB), 但是BLOBs类型数据已经维持痛苦经历很长时间,你最好使用分布式存储或集群式的文件系统来保存图片和其他二进制数据,很不幸,很多CMS内容管理系统工程师还是将它们保存到RDBMS.

8. Email: 电子邮件是带有元数据的现代非结构化数据,我们尽可能优化 RDBMS,使用 BLOBs字段做很疯狂的事情, email是关于元数据 搜索 内容,这其中没有任何关系代数,也不需要事务,文件系统就很好,而元数据可以保存在文本数据库。

对于blob和clob的处理不是关系型数据库的强项,最好选用针对文档的nosql数据库

9. 分类广告: 一个高伸缩 大批用户展示,短小内容,使用文本数据库MongoDB. 最终一致性足够了。

10. 时间系列time-series 有关预测等(大数据分析): 这是最普遍的10个,但它有多种形式,从商品到金融工程师和太阳黑子的天气。有关时间方面的应用对于关系数据库只是一个传说。如果时间是你主要关心的业务核心,那么使用MapReduce-friendly列族比如Cassandra 也许是一个好的解决方案,Datastax 已经针对Cassandra 发布了其时间系列的数据。

Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra 的一个写操作,会被复制到其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了

 

关系数据库和分布式数据库都是常见的数据库类型,它们在不同的场景下具有不同的使用场景和优缺点。 关系数据库(RDBMS)是基于关系模型的数据库使用表格来组织和管理数据。它适用于需要保持数据一致性和完整性的应用场景,例如银行系统、人力资源管理系统等。以下是关系数据库的优缺点: 优点: 1. 数据一致性:关系数据库使用事务处理来确保数据的一致性,可以保证数据的完整性和准确性。 2. 查询灵活性:关系数据库使用结构化查询语言(SQL)进行数据查询和操作,具有强大的查询功能。 3. 数据完整性:关系数据库支持主键、外键等约束,可以保证数据的完整性。 4. 数据安全性:关系数据库具备较好的安全性能,可以进行用户认证、权限控制等操作。 缺点: 1. 扩展性局限:关系数据库对于大规模数据的扩展性有限,当数据量增大时,性能可能下降。 2. 单点故障:关系数据库通常部署在单个服务器上,存在单点故障的风险。 3. 高成本:商业关系数据库通常需要付费,成本较高。 分布式数据库是将数据分散存储在多个节点上的数据库系统,可以提供更高的性能和可扩展性。以下是分布式数据库的优缺点: 优点: 1. 高性能:分布式数据库可以将数据分散存储在多个节点上,提供更高的读写性能。 2. 可扩展性:分布式数据库可以通过增加节点来扩展数据容量和处理能力。 3. 容错性:分布式数据库具备容错机制,当部分节点发生故障时,仍然可以提供服务。 4. 高可用性:分布式数据库可以通过数据的冗余存储来提供高可用性。 缺点: 1. 复杂性:分布式数据库的设计和管理相对复杂,需要考虑数据分布、一致性等因素。 2. 数据一致性:分布式数据库需要解决数据一致性的问题,例如使用分布式事务或一致性协议。 3. 配置和维护成本:分布式数据库的配置和维护相对复杂,需要投入较多的人力和资源。 总结而言,关系数据库适用于对数据一致性和完整性要求较高的应用场景,而分布式数据库则适用于需要高性能和可扩展性的大规模数据存储和处理场景
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值