最新 | 最热门 | 最高评价

+0  Jame’s Reading 10-14

Tag: oracle | 经济解释;把时间当作朋友;sqlparse;monitoring;tcp scalability
jametong 发于 2013年10月14日 20:40 | 点击: 2332 | 展开摘要
技术文章阅读

http://t.cn/z8OBJG5 对于varchar2/nvarchar2类型的字段,在12c 中最大可以支撑到32k大小了, 对于很多业务来讲, 这可能是个不错的选择.

http://t.cn/agGm7R 各种不同的Replication方式对于一致性/事务支持/响应时间/吞吐量/数据丢失以及故障切换能力的支持.

http://t.cn/z81ivvF Linux TCP/IP Tuning for Scalability, 重点介绍了Lin

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

+0  SSDB 支持 Snappy 压缩了

Tag: SSDB | LevelDB | NoSQL | Snappy
ideawu 发于 2013年10月08日 23:32 | 点击: 1924 | 展开摘要
SSDB 数据库服务器从 1.6.2 版本开始, 支持 Snappy 数据压缩. Snappy 是一个由 Google 公司开发的压缩库, 在 Google 内部应用非常广泛, 同时也在很多知名开源软件中得到应用, 如 Cassandra, Hadoop 等.

LevelDB 也是可以使用 Snappy 的, 但不是强制绑定, 而是在编译 LevelDB 时自动判断使用. 但是, 在编译 LevelDB 时要添加关于 Snappy 的参数, 而且在编译使用了 LevelDB

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

+0  用SSDB快速开发一个微博(Twitter)demo

Tag: SSDB | LevelDB | NoSQL
ideawu 发于 2013年10月06日 15:02 | 点击: 1833 | 展开摘要
对于新浪微博或者 Twitter 这样的应用, 其最核心的数据结构就是排序列表. 例如, 我关注的人, 关注我的人, 我发的微博, 我收到的微博, 等等. 这些业务功能点都是排序列表数据结构, 根据时间排序.

这样的数据结构如果用关系数据库(如 MySQL)来存储的话, 需要设计一个表, 表和一个外键字段, 作为列表的名字, 还要有一个 int 型时间字段用于排序, 还有第 3 个字段就是列表的元素(如 uid, 微博 ID). 不过, 因为 MySQL 一旦表的数据量达到

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

+0  我对Lamport Logical Clock的理解

Tag: NoSQL杂谈 | Lamport Logical Clock | 算法 | 一致性 | 理论原地 | 分布式
nosqlfan 发于 2013年09月03日 23:45 | 点击: 2905 | 展开摘要
分布式环境中的一致新问题一直是最热门的话题之一,本文主要介绍了其中的一种比较简单的思路:Lamport Logical Clock。本文来自@GoAce 博客文章的投稿。感谢他的分享。

原文地址:http://www.orzace.com/lamport-logical-clock/

建议先看论文原文再来看这篇文章(原文见文章下方参考文献部分),我不会对论文中的各个点都详细说明,只是写一些我自己的想法,帮助理解。

大家都知道,分布式环境下,确定各个事件发生的顺序很重要,

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

+0  MySQL 向 Redis 快速导入数据

Tag: 知识┊技术相关 | mysql | redis
xsky 发于 2013年09月03日 11:55 | 点击: 2617 | 展开摘要
Mysql到Redis的数据协议

redis-cli命令行工具有一个批量插入模式,是专门为批量执行命令设计的。这第一步就是把Mysql查询的内容格式化成redis-cli可用的数据格式。
原理是把要插入到Redis的数据直接转成Redis协议数据流,通过pipe mode 导入到Redis.

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

+0  InnoDB碰到MySQLdb

Tag: 知识┊技术相关 | mysql | PYTHON
xsky 发于 2013年09月03日 11:52 | 点击: 1581 | 展开摘要
这两天用python中的MySQLdb想在mysql中插入数据,函数返回显示数据已经成功插入,但是在mysql中却没有这个数据,这是为什么呢?
于是:我开始进行了排错

1.我以为是MySQLdb连接mysql有问题,但是后来一想,在MySQLdb中显示已经插入了啊,而且还能看到mysql中的其他数据,说明连接是没有问题de

2.同样的SQL在MYSQL上直接执行是没有问题的。怀疑表有问题?重建表后还是不能插入。

3.在后来,建了个测试表试了下,发现可以插入,然后马上对比

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

+0  MySQL的高可用可扩展架构探讨

Tag: 技术┊服务器开发 | mysql | 高性能服务器
xsky 发于 2013年09月03日 11:52 | 点击: 1658 | 展开摘要
随着信息量飞涨,信息的存储成为了这个时代至关重要的一项技术。如何来保证数据存储技术能够适应信息量的增长速度和我们对信息的高度依赖,成为一个非常重要的课题。本文将从数据库架构的层面,通过以开源的数据存储软件来构建分布式数据层的思路,期望实现一个低成本的高可用可扩展的数据层架构。

  传统数据库架构

纵观各传统商业数据库软件,多以集中式架构为主,鲜有以分布式为设计理念的架构。这些传统数据库软件的最大特点就是将所有的数据都集中在一个数据库中,依靠大型高端设备来提供高处理能力和扩

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

+1  单实例支撑每天上亿个请求的SSDB

Tag: SSDB | NoSQL | Redis
ideawu 发于 2013年08月26日 23:18 | 点击: 12431 | 展开摘要
SSDB 是一个 C++ 开发的 NoSQL 存储服务器, 支持 zset, map 数据结构, 可替代 Redis, 特别适合存储集合数据. SSDB 被开发和开源出来后, 已经在生产环境经受了3个季度的考验, 一直稳定运行.

在一个支撑数千万用户的列表数据(例如用户的订单历史, 用户的好友列表, 用户的消息列表等)的实例上, SSDB 每天处理上亿个读写请求, 仍然能保持 CPU 占用在3%左右, 内存占用为 1G. 这种数据规模是我们原来使用的 Redis 所无法满足

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

+0  初窥InnoDB的Memcached插件

Tag: Technical | Memcached | MySQL
老王 发于 2013年08月20日 17:32 | 点击: 2045 | 展开摘要
前些年,HandlerSocket的横空出世让人们眼前一亮,当时我还写了一篇文章介绍了其用法梗概,时至今日,由于种种原因,HandlerSocket并没有真正流行起来,不过庆幸的是MySQL官方受其启发,研发了基于InnoDB的Memcached插件,总算是在MySQL中延续了NoSQL的香火,以前单独架设Memcached服务器不仅浪费了内存,而且还必须自己维护数据的不一致问题,有了Memcached插件,这些问题都不存在了,而且借助MySQL本身的复制功能,我们可以说是变

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

+0  搭建测试服务器(源码编译方式)

Tag: Linux | PHP | MySQL | Nginx | 服务器 | Python | Git
youngsterxyf 发于 2013年06月18日 00:00 | 点击: 1497 | 展开摘要
目前工作中开发流程还比较初级,甚至连测试服务器都没有,代码的变更都是直接先在开发人员的本地机器上简单测试一下,然后直接部署到生产服务器上,这就相当于生产服务器同时充当了测试服务器的角色,虽然开发的是面向公司内部的系统,但作为一个有理想有追求的码农,是不允许这样粗糙混乱的开发流程的,所以申请了台服务器,自己搭建个测试服务器。

由于公司的服务器统一使用SUSE Linux Server操作系统,并且版本较老。与Ubuntu、Centos等Linux发行版不同,SUSE Linu

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

+0  MySQL优化的奇技淫巧之STRAIGHT_JOIN

Tag: Technical | MySQL
老王 发于 2013年06月04日 23:37 | 点击: 2288 | 展开摘要
最近没怎么搞SQL优化,碰巧数据库被慢查询搞挂了,于是拿来练练手。

问题

通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下:

SELECT post.*
FROM post
INNER JOIN post_tag ON post.id = post_tag.post_id
WHERE post.status = 1 AND post_tag.tag_id = 123
ORDER BY post.created DESC
LIMIT 1

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

+0  《高性能MySQL》第三版勘误表

Tag: 技术 | 高性能 | MySQL
NinGoo 发于 2013年06月03日 17:28 | 点击: 2129 | 展开摘要
《高性能MySQL》第三本勘误表,欢迎各位反馈书中的问题,我们将尽量在再次印刷的时候修正这些问题,谢谢大家。

购买链接: Amazon 京东 当当

1. 译者序vi 倒数第2段第3行

其中,我负责前、推荐序和第1、2、3章 修改为 其中,我负责前言、推荐序和第1、2、3章

注:2013年5月第二次印刷已经订正

2. P57第7行

rdnwr 修改为 rndwr

注:2013年5月第二次印刷已经订正

3. P227第4行(感谢@半个馒头大师指正)

我们希望

查看全文: http://www.udpwork.com/item/9965.html
|<<<2345678>>>| 一共21页, 249条记录