MongoDB数据存储-深入了解-低调大师

MongoDB数据存储-深入了解

2017-12-12 575

 
           "xprev" 
           : 
           "null"
           ,  
          
           "nsdiag" 
           : 
           "test.sample"
           ,  
          
           "size" 
           : 8192,  
          
           "firstRecord" 
           : 
           "0:50b0"
           ,  
          
           "lastRecord" 
           : 
           "0:6cb0" 
          
           },  
          
           ...  
          
           ]  
          
           ...  
          
           } 
          
           可以看到extents在逻辑上是链表形式，以及每个extent的数据量、以及所在data 
           file
           的offset位置. 
          
           从上面介绍中已经得知，删除document会导致磁盘碎片，有些update也会导致磁盘碎片，比如update导致文档尺寸变大，进而超过原来分配的空间；当有新的insert操作时，
          
           mongodb会检测现有的extents中是否合适的碎片空间可以被重用，如果有，则重用这些fragment，否则分配新的存储空间。磁盘碎片，对write操作有一定的性能影响，而且
          
           会导致磁盘空间浪费；如果你需要删除某个collection中大部分数据，则可以考虑将有效数据先转存到新的collection，然后直接drop()原有的collection。或者使用
          
           db.runCommand({compact: 
           '<collection>'
           })。 
          
           如果你的database已经运行一段时间，数据已经有很大的磁盘碎片（storageSize与dataSize比较），可以通过mongodump将指定database的所有数据导出，然后将原有的db删除，
          
           再通过mongorestore指令将数据重新导入。（同compact，这种操作需要停机维护）
          
           mongod中还有2个默认的database，系统级的，
           "admin"
           和
           "local"
           ；它们的存储原理同上，其中
           "admin"
           用于存储
           "用户授权信息"
           ，比如每个database中用户的role、权限等； 
          
           "local"
           即为本地数据库，我们常说的oplog（replication架构中使用，类似与binlog）即保存在此数据库中。 
          
           2）Namespace文件
          
           对于namespace文件，比如
           "test.ns"
           文件，默认大小为16M，此文件中主要用于保存
           "collection"
           、index的命名信息，比如collection的
           "属性"
           信息、每个索引的属性类型等， 
          
           如果你的database中需要存储大量的collection（比如每一小时生成一个collection，在数据分析应用中），那么我们可以通过配置文件
           "nsSize"
           选项来指定。 
          
           3）journal文件
          
           journal日志为mongodb提供了数据保障能力，它本质上与mysql binlog没有太大区别，用于当mongodb异常crash后，重启时进行数据恢复；这归结于mongodb的数据持久写入
          
           磁盘是滞后的。默认情况下，
           "journal"
           特性是开启的，特别在production环境中，我们没有理由来关闭它。（除非，数据丢失对应用而言，是无关紧要的） 
          
           一个mongodb实例中所有的databases共享journal文件。
          
           对于write操作而言，首先写入journal日志，然后将数据在内存中修改（mmap），此后后台线程间歇性的将内存中变更的数据flush到底层的data files中，时间间隔为60秒；
          
           write操作在journal文件中是有序的，为了提升性能，write将会首先写入journal日志的内存buffer中，当buffer数据达到100M或者每隔100毫秒，buffer中的数据将会flush
          
           到磁盘中的journal文件中；如果mongodb异常退出，将可能导致最多100M数据或者最近100ms内的数据丢失，flush磁盘的时间间隔有配置项
           "commitIntervalMs"
           决定，默认为 
          
           100毫秒。mongodb之所以不能对每个write都将journal同步磁盘，这也是对性能的考虑，mysql的binlog也采用了类似的权衡方式。开启journal日志功能，将会导致write性能
          
           有所降低，可能降低5~30%，因为它直接加剧了磁盘的写入负载，我们可以将journal日志单独放置在其他磁盘驱动器中来提高写入并发能力（与data files分别使用不同的
          
           磁盘驱动器）。
          
           如果希望数据尽可能的不丢失，可以考虑：
          
           1）减小commitIntervalMs的值
          
           2）每个write指定
           "write concern"
           中指定
           "j"
           参数为
           true 
          
           3）最佳手段就是采用
           "replica set"
           架构模式，通过数据备份方式解决，同时还需要在
           "write concern"
           中指定
           "w"
           选项，且保障级别不低于
           "majority"
           。 
          
           最终需要在
           "写入性能"
           和
           "数据一致性"
           两个方面权衡，即CAP理论。 
          
           根据write并发量，journal日志文件为1G，如果指定了smallFiles配置项，则最大为128M，和data files一样journal文件也采用了
           "preallocated"
           方式，journal日志保存在 
          
           dbpath下
           "journal"
           子目录中，一般会有三个journal文件，每个journal文件格式类似于
           "j._<序列数字>"
           。并不是每次buffer flush都生成一个新的journal日志，而是当前 
          
           journal文件即将满时会预创建一个新的文件，journal文件中保存了write操作的记录，每条记录中包含write操作内容之外，还包含一个
           "lsn"
           （last sequence number）， 
          
           表示此记录的ID；此外我们会发现在journal目录下，还有一个
           "lsn"
           文件，这个文件非常小，只保存了一个数字，当write变更的数据被flush到磁盘中的data files后，也 
          
           意味着这些数据已经持久化了，那么它们在
           "异常恢复"
           时也不需要了，那么其对应的journal日志将可以删除，
           "lsn"
           文件中记录的就是write持久化的最后一个journal记录的ID， 
          
           此ID之前的write操作已经被持久写入data files，此ID之前的journal在
           "异常恢复"
           时则不需要关注；如果某个journal文件中最大 ID小于
           "lsn"
           ，则此journal可以被删除或者重用。

***************当你发现自己的才华撑不起野心时，就请安静下来学习吧***************

本文转自散尽浮华博客园博客，原文链接：http://www.cnblogs.com/kevingrace/p/7909947.html，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/346702

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

分布式Session共享解决方案

image.png Session是服务器用来保存用户操作的一系列会话信息，由Web容器进行管理。单机情况下，不存在Session共享的情况，分布式情况下，如果不进行Session共享会出现请求落到不同机器要重复登录的情况，一般来说解决Session共享有以下几种方案。 1、session复制 session复制是早期的企业级的使用比较多的一种服务器集群session管理机制。应用服务器开启web容器的session复制功能，在集群中的几台服务器之间同步session对象，使得每台服务器上都保存所有的session信息，这样任何一台宕机都不会导致session的数据丢失，服务器使用session时，直接从本地获取。这种方式在应用集群达到数千台的时候，就会出现瓶颈，每台都需要备份session，出现内存不够用的情况。 2、session绑定利用hash算法，比如nginx的ip_hash,使得同一个Ip的请求分发到同一台服务器上。这种方式不符合对系统的高可用要求，因为一旦某台服务器宕机，那么该机器上的session也就不复存在了，用户请求切换到其他机器后么有session，无法完成...

2017-12-13

619

分布式实时日志分析解决方案ELK部署架构

一、概述 ELK已经成为目前最流行的集中式日志解决方案，它主要是由Beats、Logstash、Elasticsearch、Kibana等组件组成，来共同完成实时日志的收集，存储，展示等一站式的解决方案。本文将会介绍ELK常见的架构以及相关问题解决。 Filebeat：Filebeat是一款轻量级，占用服务资源非常少的数据收集引擎，它是ELK家族的新成员，可以代替Logstash作为在应用服务器端的日志收集引擎，支持将收集到的数据输出到Kafka，Redis等队列。 Logstash：数据收集引擎，相较于Filebeat比较重量级，但它集成了大量的插件，支持丰富的数据源收集，对收集的数据可以过滤，分析，格式化日志格式。 Elasticsearch：分布式数据搜索引擎，基于Apache Lucene实现，可集群，提供数据的集中式存储，分析，以及强大的数据搜索和聚合功能。 Kibana：数据的可视化平台，通过该web平台可以实时的查看Elasticsearch中的相关数据，并提供了丰富的图表统计功能。二、ELK常见部署架构 2.1、Logstash作为日志收集器这种架构是比较原始的部署...

2017-12-13

511

发表评论

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。