石碣镇网站建设,国外网络推广哪家公司好,教育类网站 前置审批,网站建设活动策划方案目录什么是行存储和列存储#xff1f;什么是MongoDB#xff08;NoSQL#xff09;?OLTP和OLAP什么是CAP定理#xff1f;使用场景行存储的适用场景#xff1a;列存储的适用场景#xff1a;MongoDB相对于MySQL的优点更适用MySQL的场景更适用MongoDB的场景个人理解扩展参考什…
目录什么是行存储和列存储什么是MongoDBNoSQL?OLTP和OLAP什么是CAP定理使用场景行存储的适用场景列存储的适用场景MongoDB相对于MySQL的优点更适用MySQL的场景更适用MongoDB的场景个人理解扩展参考什么是行存储和列存储
行存储传统的关系型数据库如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based基于行)在基于行式存储的数据库中 数据是按照行数据为基础逻辑存储单元进行存储的一行中的数据在存储介质中以连续存储形式存在。列存储(Column-based,基于列)是相对于行存储来说的新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中数据是按照列为基础逻辑存储单元进行存储的一列中的数据在存储介质中以连续存储形式存在。
什么是MongoDBNoSQL?
MongoDB是面向文档的NoSQL数据库用于大量数据存储。 MongoDB是一个基于文档的存储在其之上还具有一个基于图形的存储。MongoDB实际上并不存储JSON它存储BSON(二进制JSON)BSON扩展了JSON表示(字符串)以包括其他类型例如intlongdate浮点decimal128和地理空间坐标。
OLTP和OLAP
在数据库中数据处理可分为两类联机事务处理OLTPon-line transaction processing) 和 联机分析处理OLAPOn-Line Analytical Processing
OLTP是传统关系型数据库的主要应用用来执行一些基本的、日常的事务处理比如数据库增、删、改、查等等OLAP则是分布式数据库的主要应用它对实时性要求不高但处理的数据量大通常应用于复杂的动态报表系统上。
什么是CAP定理
CAP定理也称为Brewer定理。它指出分布式数据存储不可能同时满足CAP只能满足CAP其中的两部分。 一致性 即在执行操作之后数据也应保持一致。这意味着一旦写入数据以后的任何读取请求都应包含该数据。例如更新订单状态后所有客户端都应该能够看到相同的数据。 可用性 该数据库应始终可用且响应迅速。它不应有任何宕机时间。 分区容错性 分区容限意味着即使服务器之间的通信不稳定系统也应继续运行。例如可以将服务器划分为可能无法相互通信的多个组。在此如果数据库的一部分不可用则其他部分始终不受影响。
使用场景
行存储的适用场景
适合随机的增、删、改、查操作需要在行中选取所有属性的查询操作需要频繁插入或更新的操作其操作与索引和行的大小更为相关。
列存储的适用场景
查询过程中可针对各列的运算并发执行在内存中聚合完整记录集降低查询响应时间在数据中高效查找数据无需维护索引任何列都能作为索引查询过程中能够尽量减少无关IO避免全表扫描因为各列独立存储且数据类型已知可以针对该列的数据类型、数据量大小等因素动态选择压缩算法以提高物理存储利用率如果某一行的某一列没有数据在列存储时就可以不存储该列的值这将比行式存储更节省空间。 实际应用中我们会发现行式数据库在读取数据时存在一个固有的缺陷比如所选择查询的目标即是只涉及少数几个字段但由于这些目标数据埋藏在各行数据单元中而行单元往往又特别大应用程序必须读取每一条完整的行记录从而使得读取效率大大较低对此行式数据库给出的优化方案是加索引在OLTP类型的应用中通过索引机制或给表分区等手段可以简化查询操作步骤并提升查询效率。 针对海量数据背景的OLAP应用例如分布式数据库、数据仓库等行存储的数据库就有些力不从心了行式数据库建立索引和物化视图需要花费大量时间和资源因此还是不划算的无法从根本上解决查询性能和维护成本的问题也不适用于数据仓库等应用场景所以后来出现了基于列式存储的数据库。 对于数据仓库和分布式数据库来说大部分情况下它会从各个数据源汇总数据然后进行分析和反馈其大多数操作是围绕同一个字段属性进行的而当查询某属性的数据记录时列式数据库只需返回与列属性相关的值。在大数据量查询场景中列式数据库可在内存中高效组装各列的值最终形成关系记录集因此可以显著减少IO消耗并降低查询响应时间非常适合数据仓库和分布式的应用。 MongoDB相对于MySQL的优点
MongoDB文档自然映射到现代的面向对象编程语言。使用MongoDB可以避免将代码中的对象转换为关系表的复杂对象关系映射ORM层MongoDB的灵活数据模型也意味着您的数据库模式可以随业务需求而发展。例如在天气频道的MySQL数据库中花费数周时间的模式更改可能会在短短几个小时内由MongoDB完成。MongoDB还可以在多个分布式数据中心之间进行扩展提供以前MySQL等关系数据库无法实现的新的可用性和可扩展性。随着在数据量和吞吐量方面的增长MongoDB可轻松扩展无需停机无需更改应用程序。
更适用MySQL的场景
需要复杂的多行事务的应用程序 一个具体的例子是旅行预订系统背后的预订引擎通常还涉及复杂的事务。虽然核心预订引擎可能在MySQL上运行但是与用户互动的应用程序部分 – 提供内容与社交网络集成管理会话 – 将更好地放在MongoDB中 许多电子商务应用程序使用MongoDB和MySQL的组合。产品目录包括具有不同属性的多个产品非常适合MongoDB的灵活数据模型。另一方面需要复杂事务的结帐系统可能建立在MySQL或其他关系数据库技术上。 更适用MongoDB的场景 更高的写入负载 默认情况下MongoDB更侧重高数据写入性能而非事务安全MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB除非能从架构设计上保证事务安全。 高可用性 MongoDB的复副集(Master-Slave)配置非常简洁方便此外MongoDB可以快速响应的处理单节点故障自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定如云主机的环境中保持高可用性。 数据量很大或者未来会变得很大 依赖数据库(MySQL)自身的特性完成数据的扩展是较困难的事在MySQL中当一个单达表到5-10GB时会出现明显的性能降级此时需要通过数据的水平和垂直拆分、库的拆分完成扩展使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性可以很好的适应大数据量的需求。 基于位置的数据查询 MongoDB支持二维空间索引因此可以快速及精确的从指定位置获取数据。 表结构不明确且数据在不断变大 在一些传统RDBMS中增加一个字段会锁住整个数据库/表或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候当大于1TB时更甚。 因MongoDB是文档型数据库为非结构货的文档增加一个新字段是很快速的操作并且不会影响到已有数据另外一个好处当业务数据发生变化时是将不在需要由DBA修改表结构。 没有DBA(数据库管理员)支持 如果没有专职的DBA并且准备不使用标准的关系型思想结构化、连接等来处理数据那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便类可以直接序列化成JSON存储到MongoDB中。 但是需要先了解一些最佳实践避免当数据变大后由于文档设计问题而造成的性能缺陷。
个人理解
MySQL提供更强的事务保证即更好的一致性对一致性要求较高的场景如支付订单等MySQL更能胜任。但依赖数据库(MySQL)自身的特性完成数据的扩展是较困难的事难以实现水平扩展同时规范化的数据模型导致更多表关联降低性能从而需要更多键和索引占用内存。随着数据库的增长性能可能开始成为问题。MongoDB数据具有灵活的架构集合不会强制执行文档结构同时很容易依赖其自带的特性内建了多种数据分片的特性实现水平扩展适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB。
扩展
垂直扩展提升单机处理能力。水平扩展只要增加服务器数量就能线性扩充系统性能。
参考
基于行存储和列存储的数据库MongoDB和MySQL对比(译)NoSQL教程了解NoSQL的功能类型含义优势对比mysql,什么场景更适用Mongodb
