MongoDB Shareding部署

几年前写过MongoDB的Sharding和replication。其实现在看起来Replication还是可以,Sharding的部分有点过于简单了。于是现在重新补充一下,至少也更新下,毕竟现在的MongoDB已经到了2.6,于当时的2.2还是有所差异的。

继续阅读“MongoDB Shareding部署”

推荐阅读:
之前写过一篇关于syslog的
MongoDB,可能是近些时间
近一年来始终专注于No-SQL

syslog-ng+mongodb构建集中日志服务

之前写过一篇关于syslog的东西,同时,对于mongodb来说,本站的介绍也不少,MongoDB一直是站长Litrin又爱又恨的no-sql数据库。

上次也说过,做一个集中化的日志系统,最为主要的优势在于它非常容易做日志分析和挖掘,而且对于松散的日志数据来说MongoDB又是一个很好的数据容器。说实话,Litrin很久之前就苦于自己写脚本将日志文件拆分后导入Mongo中进行数据分析,非常不方便。直到前些日子研究了一下syslog-ng,果然有人实现了这个插件——syslog直接写数据到MongoDB!

继续阅读“syslog-ng+mongodb构建集中日志服务”

推荐阅读:
自打从硬件方向研究性能优化起,
之前我们通过几个概念简单的介绍

吐吐MongoDB的苦水

MongoDB,可能是近些时间来比较热门的存储容器了。相对于传统的Key-value数据库,弱关系型的设置可以很方便的解决K-V模式中几乎无解的查询问题,同时相比传统的DB,MongoDB在性能上和灵活性上具有很多优势。但出于我个人的理解,我习惯上还是把它作为一个“具有索引功能的Key-value数据库”来使用。

兴许是MongoDB的还比较新(第一个版本在09年底发布),或者说开发团队10gen意图通过这种方式来卖他们的服务,在Mongo的使用过程中总是大毛病没有,小毛病不断的,很是坎坷。闲来无事,就发发牢骚,吐吐苦水吧,希望给大家在使用前有个参考。

继续阅读“吐吐MongoDB的苦水”

推荐阅读:
几年前写过MongoDB的Sh
之前写过一篇关于syslog的
近一年来始终专注于No-SQL

Key-Value式数据结构设计

近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。

之前从事的行业以企业管理和电子商务系统为主,这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项,特别是企业信息化管理系统和电子商务中的帐务结算子系统,这类系统对于数据的原子性和一致性的要求近乎苛刻,根据CAP原则,只能放弃性能作为代价。后来辗转到互联网行业,特别是SNS的开发和运维中,很多思维模式必须要打破。SNS,特别是Feed部分的数据结构,绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付,即便实现成功,也始终无法摆脱“硬撑”的嫌疑。

继续阅读“Key-Value式数据结构设计”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
碰到一个悲催的事情:一台Red

MongoDB的分发模式和部署

MongoDB是近期一直在研究的No-SQL,作为No-SQL来说,Mongo做的反而更像传统的关系型数据库,可以利用弱关系进行查询。作为网站应用来说,毫不客气地说,如果你的查询复杂程度到了MongoDB无法支持的程度,只能说明你的数据结构设计的有问题。

作为No-sql的强项,MongoDB的数据分发/同步机制相对比MySQL灵活的多,支持传统上的主从同步和趋向于高性能的ShareSet,而且对于程序端来说改动相对较小,代价几乎可以不计。现在就从这两种分发机制方式说起。

继续阅读“MongoDB的分发模式和部署”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL

从SQL到NoSQL

之前接触到的基于LAMP平台的网站,凡是稍微有一点量上去的,在数据结构的设计上总是离不开“拆库拆表”。同样,作为网站的数据结构设计,很少会出现类似ERP系统才会应用到的函数(function)、存储过程(procudce)、触发器(trigger)什么的——曾经看过有ERP系统的所有逻辑都是通过这3者保存在数据库端的。加上MySQL本身的一些因素,用之前一个朋友的话说:“Mysql在网站中的地位更多的是一个数据容器,而不是完整意义上的数据库。”

继续阅读“从SQL到NoSQL”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL