IT牛人博客聚合

全文译自墙外文章“NoSQL Data Modeling Techniques”，译得不好，还请见谅。这篇文章看完之后，你可能会对NoSQL的数据结构会有些感觉。我的感觉是，关系型数据库想把一致性，完整性，索引，CRUD都干好，NoSQL只干某一种事，但是牺牲了很多别的东西。总体来说，我觉得NoSQL更适合做Cache。下面是正文——

NoSQL 数据库经常被用作很多非功能性的地方，如，扩展性，性能和一致性的地方。这些NoSQL的特性在理论和实践中都正在被大众广泛地研究着，研究的热点正是那些和性能分布式相关的非功能性的东西，我们都知道 CAP 理论被很好地应用于了 NoSQL 系统中（陈皓注：CAP即，一致性(Consistenc

查看全文: http://www.udpwork.com/item/7283.html

concepts guide（11g）

By Thomas Kyte

由Tom担纲编写的11g的Concepts guide作为第一本书籍，是引领你进去Oracle世界的最基础的一本书籍，建议所有的人都对此做深入阅读，我了解的有些朋友对此文档有3-5遍以上的阅读。重点：oracle数据库的体系结构、内存架构、oracle的基本数据对象、并发控制与隔离级别相关内容，Undo与Redo的内容。

backup and recovery guide

备份与恢复是Oracle数据库也是关系数据库最关键的部件，深入阅读此文档，可以帮助你了解Oracle是如何设计redo、undo、数据格式，以及恢复过程中的一些细节内容。

Expert

查看全文: http://www.udpwork.com/item/7146.html

我找了两台硬件环境基本一样的机器（同一个刀片里面的两台），分别装了FreeBSD和Linux，来测试leveldb在这两个环境下的性能差异。

编译环境：

FreeBSD 9.0:  gcc  4.6，libunwind-1.0.1 google-perftools-1.8.3

（libunwind-0.99-beta编译不过去，google-perftools-1.9.1虽然能编译过去，但是最后和db_bench链接完后，运行会core dump）

CentOS Linux: gcc 4.4，google-perftools-1.9.1，libunwind-0.99-beta

leveldb的代码是从

查看全文: http://www.udpwork.com/item/6714.html

今天把Berkeley DB加进去，加到昨天的测试代码中。然后把client改成多线程的，其实就是为了方便启动测试。

首先，当服务器端是单线程的时候，一切都工作的很好，QPS也不低。

然后，我把服务器改成多线程，共享一个db handle。然后立马就死锁了。速度非常快。

嗯，用锁的时候必须把死锁检测打开。

dbenv->set_lk_detect(DB_LOCK_DEFAULT);

你猜怎么着？

第一次测试，很OK，插入20万条数据(key是用java.util.Random.nextLong生的），花了23秒。

第二次，卡死了。我以为又是死锁，但是用pstack打开一看，不是。好多线程在等锁，还有好多线程停留在

查看全文: http://www.udpwork.com/item/6589.html

最近，想做一个data store，存储一些用户数据。我想越简单越好，不要搞什么分布式，尽力单机解决所有问题，然后找一个机器做replication。但是呢，这个机器所处位置很重要，很容易成为整个网站的瓶颈，所以我还是想尽可能的提高效率。

我要一个什么东西呢？ 简单点说，就是一个可持久化的、高效的KV存储。例如腾讯的CMEM服务，或者，mysqld+memcached。我只是举个例子，不一定非要走memcache的接口。每个item都有一个过期时间，超过那个时间之后，应当被删除，否则硬盘会炸掉的。据同事估计，数据量大概是1-2T左右。我觉得我通过压缩手段，能降低到100GB的规模。请求的频率呢，大概是每秒2-3万次读写，而且写入比

查看全文: http://www.udpwork.com/item/6578.html

某人发了一篇Don’t use MongoDB的血泪控诉，我把原文翻译如下，你可以看看。不过，我想我们还要去看看10gen CTO的对此事的回复，我们还要去在Reddit上看看大家的说法，10gen CTO的对此事的回复后面也有一堆人在讨论这个事，还有一些程序员开始去读MongoDB的源码了，呵呵。看样子，说MongoDB的这些事并不是真的。

10gen CTO 对此事的并不完全知道，其在回复，对些文中的每一条都做了回复。我把其回复的大体意思也放在原文中。不过，很有意思的是那些程序员的讨论。建议大家看看。

正文

因为各种政治原因，我这段时间没有说什么，但是现在我觉得因为要对社会负责，所以我要阻止大家不要把你们的业务

查看全文: http://www.udpwork.com/item/6256.html

目前NoSQL产品最被人诟病的就是其稳定性，不得不承认，目前HBase离做到数据库那样的高稳定还有距离（丢数据、不能读写、DDL失败等严重问题），这篇blog将用来记录我们在运维HBase时碰到的问题（会不断更新），希望能给使用HBase的同学有一些帮助。

1、单台regionserver的region数很多后写速度疯狂下降

具体请见：http://koven2049.iteye.com/blog/1144526

2、region server OOM

碰到过两种造成region server OOM的状况：

* rowKey设计的问题，写的一直是同一行，version配置的又比较大，无法split，从而

查看全文: http://www.udpwork.com/item/6109.html

根据最近生产环境使用的经验，更多的项目的采用，以及采用了更加自动的测试平台，对HBase做了更多的场景的测试，在这篇blog中来分享下纯粹的随机写和随机读的性能数据，同时也分享下我们调整过后的参数。

测试环境说明：

1、Region Server： 5台，12块1T SATA盘(7200 RPM)，No Raid，物理内存24G，CPU型号为E5620；

启动参数为：-Xms16g -Xmx16g -Xmn2g -XX:SurvivorRatio=2 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=

查看全文: http://www.udpwork.com/item/5647.html

这是根据最近HBase项目的一些经验，还有NB的Advanced HBase的slide重写的一份关于HBase的介绍，熟手可基本忽略此slide，:)

Hbase简介与实践分享
View more presentations from BlueDavy

查看全文: http://www.udpwork.com/item/5442.html

SSD应该是近几年来硬件技术最nb的革命，困扰计算机性能的最短木板－－磁盘IO终于有了巨大的突破。而且SSD在未来的几年中会快速普及（我还琢磨着给我笔记本换SSD）。

前一段cm同学也想做一个MVCC支持的k-v数据库 ，现有的数据库都是根据几年前的硬件水平（小内存、无NUMA、机械磁盘）进行的设计的，不可能针对SSD专门优化，SSD上的MySQL性能提升应该是只用了SSD IOPS超高这一个特性。在SSD未来几年应该能广泛普及的前提下，针对SSD的数据库优化是必须的。集中查了查资料，聊聊想法，有不对的地方欢迎各位补充。

先简要的介绍一下SSD的特点。SSD没有传统机械硬盘的机械寻道时间而带来的延迟，所以IOPS性能可以达到10

查看全文: http://www.udpwork.com/item/5840.html

最近开始看HBase，幸运的是，现在HBase社区已经非常的活跃，网络上可以找到大量的参考资料。但对于大集群的运维经验，还有待积累。上周在团队内部简单分享了一下这段时间的读书总结，现在把PPT放出来。

这个PPT只是个读书笔记，可能有些理解有误的地方，如果发现了，请一定要留下评论。

Hbase运维碎碎念
View more presentations from seaman ning

您可能也喜欢：

关于HBase的一些零碎事

OOW2009美国行:千岛湖·大瀑布·玻璃城

Oracle11g将于7月11号在New York正式发布

用Amoeba构架MySQL分布式数据库环境

淘宝网招聘Oracle&

查看全文: http://www.udpwork.com/item/5359.html

NoSQL现在风生水起，hbase的使用也越来越广，但目前几乎所有的NoSQL产品在运维上都没法和DB相提并论，在这篇blog中来总结下我们在运维hbase时的一些问题以及解决的方法，也希望得到更多hbase同行们的建议，:)

在运维hbase时，目前我们最为关注的主要是三大方面的状况：

1. Cluster load；

2. 读写；

3. 磁盘空间。

1. Cluster load

集群的load状况直接反映了集群的健康程度，load状况的获取非常容易，直接部署ganglia即可得到，由于hbase以优秀的可伸缩性著称，因此多数情况下load超出接受范围时加机器是一个不错的解决方法，当然，这还和系统的设计和使用hbas

查看全文: http://www.udpwork.com/item/5342.html

随着Facebook使用HBase来构建实时消息系统，基于Hadoop的面向列存储的HBase持续升温。

目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本，暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2（或者0.203.0）缺少一个重要的特性，HDFS不支持sync模式的持久，这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase，有两个选择，一是使用Cloudera的CDH3版本，Cloudera就类似MySQL的Percona，对官方版本的Hadoop做了很多改进工作，而且经典的《Hadoop：The Definitive Guide》一书的作者Tom White就是

查看全文: http://www.udpwork.com/item/5294.html

文章来源：Best “must know” open sources to build the new Web。个人感觉这个收集贴收集成相当的全。

学习HTML 5编程和设计

★ HTML5 Rocks : Major Feature Groups  的学习 HTML5 的资源 (HTML5 演示, 教程 ). 源码

很不错的 HTML5 Dashboard – Mozilla，效果很炫。

WhatWG Developers, 一个清楚的 HTML5 技术规格说明书。

★ StackOverflow : 大名鼎鼎的技术问答式论坛。

★ Addyosmani, jQuery 和 JavaScript 文章教程

查看全文: http://www.udpwork.com/item/5208.html

昨天下午的技术讨论会上说到了数据库的按时间点的进行实时备份和归档，当时的讨论都是基于日志如何来做。

这个问题需要做到以下几点：

因备份而引起的中断数据库服务的时间尽可能短;

能够迅速的让数据库使用备份的数据rollback;

归档的备份数据能在专门的备份机统一保存，方便本机失效后的处理;

如果可能，归档备份的数据能做到增量备份，以节省备份机的磁盘空间，同时方便快速传输。

从数据库本身解决这个问题，可能受困于已有的数据库设计和代码，不非常容易。换个思路，可以基于fs的snapshot来做。

在*nix系统下功能最强的snapshot首推zfs，本身支持文件系统快照，支持增量备份，并内置了zfs send工具能直接把备份快

查看全文: http://www.udpwork.com/item/5842.html

Facebook在谈到其选择HBase作为新的message体系的存储时，提到了一点是hbase的高性能写，那hbase的写性能状况到底如何了，还是需要靠测试来说明，在这篇blog中就以我们目前做的一些测试来看看hbase的写速度，以及分享下我们对于测试中体现出来的数据的分析和测试时碰到的一些问题，还希望对hbase有研究或实践的同学多加指正。

测试环境：

1、4个client，每client 25个写线程，每个client写入1kw数据，其他还有一些更长时间的测试，例如连续写7个小时等；

2、12台region server（8 core 超线程 => 16 core, Intel Xeon E5620, 12块1T的Sat

查看全文: http://www.udpwork.com/item/5017.html