亢奋猫 发布的文章

CSS 垂直居中的最简单写法:容器元素设为 flex 布局,子元素只要写 margin: auto 即可。

<header>
    <h1>A secret weapon…</h1>
</header>
header {
  display: flex;
  height: 100px;
}

h1 {
  margin: auto;
}

在 Messenger 应用中打开网页后,如果用户点击分享,那么分享出的链接和内容如何控制呢?

可以通过 Open Graph 来实现:

carbon.png

查看demo:

在Messenger应用中打开此链接并分享:
https://cdn.ijustplay.cn/files/5bc3c1d52024c150581c7651627304b7.html

实际情况下我们注意到如果没有og信息,Messenger 应用依然会抓取用户网站信息。但是这些信息不一定是我们需要的,因此只需要在网站 meta 信息中加入 og 内容即可控制了。如果遇到问题可留言讨论。

messenger-share.jpg

基于远程仓库创建新分支
git branch branch_name remote_name/branch

基于远程仓库创建新分支并且切换到新分支
git checkout -b branch_name remote_name/branch

获取上次提交hash
git rev-parse HEAD --short

与关系型数据库相比,MongoDB的优点:

1. 弱一致性(最终一致),保证用户的访问速度:

举例来说,在传统的关系型数据库中,一个 COUNT 类型的操作会锁定数据集,这样可以保证得到“当前”情况下的精确值。

这在某些情况下,例如:通过 ATM 查看账户信息的时候很重要,但对于 Wordnik 来说,数据是不断更新和增长的,这种精确的保证几乎没有任何意义,反而会产生很大的延迟。他们需要的是一个大约的数字以及更快的处理速度。

但某些情况下 MongoDB 会锁住数据库。如果此时正有数百个请求,则它们会堆积起来,造成许多问题。我们使用了下面的优化方式来避免锁定:

2. 每次更新前,我们会先查询记录。

查询操作会将对象放入内存,于是更新则会尽可能的迅速。在主/从部署方案中,从节点可以使用“-pretouch”参数运行,这也可以得到相同的效果。

使用多个 mongod 进程。我们根据访问模式将数据库拆分成多个进程。

文档结构的存储方式,能够更便捷的获取数据。

对于一个层级式的数据结构来说,如果要将这样的数据使用扁平式的,表状的结构来保存数据,这无论是在查询还是获取数据时都十分困难。

举例1:

就拿一个“字典项”来说,虽然并不十分复杂,但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库
中的主键和外键表现出来,但把它看作一个“文档”而不是“一系列有关系的表”岂不更好?使用
“dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂(往往代价也很高)的连接查询方便
且快速。

举例2:

在一个关系型数据库中,一篇博客(包含文章内容、评论、评论的投票)会被打散在多张数据表中。在 MongoDB 中,能用一个文档来表示一篇博客,
评论与投票作为文档数组,放在正文主文档中。这样数据更易于管理,消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操作。

db.blogposts.save({
  title : "My First Post", author: {name : "Jane", id :1},
  comments : [
    { by: "Abe", text: "First" },
    { by : "Ada", text : "Good post" }
  ]
})
db.blogposts.find({ "author.name" : "Jane" })
db.blogposts.findOne({
  title : "My First Post",
  "author.name": "Jane",
  comments : [
    { by: "Abe", text: "First" },
    { by : "Ada", text : "Good post" }
  ]
})
db.blogposts.find({ "comments.by" : "Ada" })
db.blogposts.ensureIndex({ "comments.by" : 1 });

举例3:

MongoDB 是一个面向文档的数据库,目前由 10gen 开发并维护,它的功能丰富,齐全,完全可以替代 MySQL。在使用 MongoDB 做产品原型的过程中,我们总结了 MonogDB 的一些亮点:

1、使用 JSON 风格语法,易于掌握和理解

MongoDB 使用 JSON 的变种 BSON 作为内部存储的格式和语法。针对 MongoDB 的操作都使用 JSON 风格语法,客户端提交或接收的数据都使用 JSON 形式来展现。相对于 SQL 来说,更加直观,容易理解和掌握。

2、Schema-less,支持嵌入子文档:MongoDB 是一个 Schema-free 的文档数据库。

一个数据库可以有多个 Collection,每个 Collection 是 Documents 的集合。Collection 和 Document 和传统数据库的 Table 和 Row 并不对等。无需事先定义 Collection,随时可以创建。

3、Collection 中可以包含具有不同 schema 的文档记录。

这意味着,你上一条记录中的文档有3个属性,而下一条记录的文档可以有10个属性,属性的类型既可以是基本的数据类型(如数字、字符串、日期等),也可以是数组或者散列,甚至还可以是一个子文档(embed document)。这样,可以实现逆规范化(denormalizing)的数据模型,提高查询的速度。

4、内置 GridFS,支持大容量的存储。

GridFS 是一个出色的分布式文件系统,可以支持海量的数据存储。内置了 GridFS 的 MongoDB,能够满足对大数据集的快速范围查询。

5、内置Sharding。

提供基于Range的Auto Sharding机制:一个collection可按照记录的范围,分成若干个段,切分到不同的Shard上。Shards可以和复制结合,配合Replica sets能够实现Sharding+fail-over,不同的Shard之间可以负载均衡。

查询是对客户端是透明的。客户端执行查询,统计,MapReduce等操作,这些会被MongoDB自动路由到后端的数据节点。这让我们关注于自己的业务,适当的时候可以无痛的升级。

MongoDB 的 Sharding 设计能力最大可支持约 20 petabytes,足以支撑一般应用。这可以保证 MongoDB 运行在便宜的 PC 服务器集群上。PC 集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。

6、第三方支持丰富。(这是与其他的 NoSQL 相比,MongoDB 也具有的优势)

现在网络上的很多 NoSQL 开源数据库完全属于社区型的,没有官方支持,给使用者带来了很大的风险。而开源文档数据库 MongoDB 背后有商业公司 10gen 为其提供供商业培训和支持。而且MongoDB社区非常活跃,很多开发框架都迅速提供了对 MongDB 的支持。不少知名大公司和网站也在生产环境中使用MongoDB,越来越多的创新型企业转而使用 MongoDB 作为和 Django,RoR 来搭配的技术方案。

7、性能优越:
在使用场合下,千万级别的文档对象,近10G的数据,对有索引的 ID 的查询不会比 mysql 慢,而对非索引字段的查询,则是全面胜出。 mysql 实际无法胜任大数据量下任意字段的查询,而 mongodb 的查询性能实在让我惊讶。写入性能同样很令人满意,同样写入百万级别的数 据,mongodb 比我以前试用过的 couchdb 要快得多,基本10分钟以下可以解决。补上一句,观察过程中 mongodb 都远算不上是 CPU 杀手。

与关系型数据库相比,MongoDB 的缺点:

1、 mongodb 不支持事务操作。
所以事务要求严格的系统(如果银行系统)肯定不能用它。(这点和优点①是对应的)
2、 mongodb 占用空间过大。
关于其原因,在官方的FAQ中,提到有如下几个方面:

  • 空间的预分配:为避免形成过多的硬盘碎片,mongodb 每次空间不足时都会申请生成一大块的硬盘空间,而且申请的量从64M、128M、256M那 样的指数递增,直到 2G 为单个文件的最大体积。随着数据量的增加,你可以在其数据目录里看到这些整块生成容量不断递增的文件。
  • 字段名所占用的空间:为了保持每个记录内的结构信息用于查询,mongodb 需要把每个字段的key-value都以BSON的形式存储,如果 value 域相对于 key 域并不大,比如存放数值型的数据,则数据的 overhead 是最大的。一种减少空间占用的方法是把字段名尽量取短一些,这样占用空间就小了,但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个 index,每个字段名用一个字节表示,这样就不用担心字段名取多长 了。但作者的担忧也不无道理,这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换,再发送到客户端,这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。
  • 删除记录不释放空间:这很容易理解,为避免记录删除后的数据的大规模挪动,原记录空间不删除,只标记“已删除”即可,以后还可以重复利用。
  • 可以定期运行 db.repairDatabase() 来整理记录,但这个过程会比较缓慢
  • MongoDB 没有如 MySQL 那样成熟的维护工具,这对于开发和IT运营都是个值得注意的地方。

作者:李天火
链接:https://www.jianshu.com/p/7a41907a1549
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

起因

最近使用nohup创建了一个后台进程,默认日志输出到了nohup.out文件中,程序跑起来也就没再管,过了大约一周,发现硬盘空间不够了,于是查找原因,发现这个nohup.out文件已经到了70G了,导致硬盘空间不足了。

解决方案

只输出错误信息到日志文件
nohup ./program >/dev/null 2>log &
什么信息也不要
nohup ./program >/dev/null 2>&1 &

知识补充,关于Linux的重定向

Linux的3中重定向
0:表示标准输入
1:标准输出,在一般使用时,默认的是标准输出
2:标准错误信息输出
可以用来指定需要重定向的标准输入或输出。例如,将某个程序的错误信息输出到log文件中:./program 2>log。这样标准输出还是在屏幕上,但是错误信息会输出到log文件中。另外,也可以实现0,1,2之间的重定向。2>&1:将错误信息重定向到标准输出。

关于/dev/null文件
Linux下还有一个特殊的文件/dev/null,它就像一个无底洞,所有重定向到它的信息都会消失得无影无踪。这一点非常有用,当我们不需要回显程序的所有信息时,就可以将输出重定向到/dev/null。