首先

这篇文章是株式会社Aistyle Advent Calendar第三天的文章。终于迈入第二年的入职的基础设施工程师@imaiy会以轻松的感觉分两次发布。

导入的背景

我们在IceStyle集团经营的网站，仅在@cosme上显示姐妹网站已达15个，若加上其他网站则约有20个左右。

由于网站数量众多，服务器的用途、语言和版本也各不相同，因此存在相当数量的情况。
每个网站都可能存在无组织地使用Memcached，或是与Web服务器共存，以形成Memcached集群；这导致维护性日益下降的状态。

在这里决心下定，创建一个在整个网站中可用的KVS集群！这就是事情的开始。

目前尚未确定是否要真正引入Couchbase。
由于还在验证阶段，所以可能存在错误，请事先知悉。

关于Couchbase

Couchbase官方网站(http://www.couchbase.com/)
Couchbase开发者网站(http://developer.couchbase.com/)

这是一个开源的分布式NoSQL文档数据库，可以使用无模式的JSON格式文档进行数据库操作。

文档缓存方式采用内存和硬盘的混合模式，并根据使用频率进行切换。
将所有数据存储到硬盘上可以确保永久性。

在个人看来，值得注意的是可以直接使用Memcached的客户端库。不幸的是，似乎没有适配Memcache，并且无法成功运行。

考虑导入

关于为什么选择Couchbase，主要有三个原因。

1. 1. 在構築和使用方面容易度
– 特別是在数据复制、日志输出和轮转方面
– 可以广泛获取用于运维的信息（如集群和存储桶的信息）

2. 可以在线增减集群节点而不会对系统造成重大影响
– 即使缓存处理速度稍有降低，也更好地保持命中率不下降
– 设计系统时假设命中率下降会给后端带来巨大负荷是没有意义的。

3. 开发人员容易上手
– 基本上使用命令行界面进行观察的运维并没有得到广泛推广。
– 但是将所有过程可视化起来相当麻烦。
– 一开始就可以对每个存储桶进行图形化表示或查看访问最频繁的键是很有帮助的。

特别是，Memcached对于日志输出和日志轮换也有一些特殊之处，故障排除起来相对比较麻烦。
我主要使用的信息大多是通过STATS等方式来获取的，像Couchbase一样实时更新的图表等预先可视化并且易于确认，这相当令人高兴。
但是考虑到之后需要调查数据的获取方式并将其整合到我们公司内部的资源监控中，这确实有些困难…

此外，您还可以使用以下脚本以便实现基于命令行的操作。由于输出以JSON格式显示，所以建议管理员们提前熟悉，以备在无法使用图形用户界面时使用。

root@couch-test01 ~]# /opt/couchbase/bin/couchbase-cli help
couchbase-cli - command-line cluster administration tool

CLUSTER:
  --cluster=HOST[:PORT] or -c HOST[:PORT]

OPTIONS:
  -u USERNAME, --user=USERNAME      admin username of the cluster
  -p PASSWORD, --password=PASSWORD  admin password of the cluster
  -o KIND, --output=KIND            KIND is json or standard
  -d, --debug
  -s, --ssl                         uses SSL for communication with secure servers

NOTE:
  USERNAME can be set in environment variable CB_REST_USERNAME and/or
  PASSWORD can be set in environment variable CB_REST_PASSWORD instead

COMMAND:
  bucket-compact        compact database and index data
  bucket-create         add a new bucket to the cluster
  bucket-delete         delete an existing bucket
  bucket-edit           modify an existing bucket
  bucket-flush          flush all data from disk for a given bucket
...(長過ぎるので割愛)...

目前来看，以下是一些缺点…随着验证的进行，可能会增加。
– 由于似乎是为企业而设计，所以除非从相当大规模的配置开始，否则无法获得优势。
– 根据其他网站的比较，响应速度似乎比Memcached要快。
– 让人担心的是，官方文档中似乎没有列出类似的缺点。
– 相对于Memcached，一般的专业知识确实较少。我们要努力阅读官方的英文文档。
– 但即使阅读，也希望能够更加易懂地写下来。
– 在创建和删除与Memcached兼容的Bucket时，该Bucket周围的操作可能会不稳定。（无法复现）

提醒我

在后续的部分，我们将实际执行查询（NiQL）并公开用于在数据库中发出查询以及将其嵌入到PHP中用于访问日志分析时所尝试的测试代码。