数据库

增加一个节点和替换一个DOWN掉的节点，步骤都是一样的，只是启动参数不一样。 第一：准备一个新机器，cassandra的配置使用和集群中一个普通节点相同的配置。 第二：然后就可以启动了，增加一个节点，只要bin/cassandra 启动就可以了。 如果是替换一个节点（假设DOWN掉的节点ip=192.168.1.101），启动的时候，可以使用bin/cassandra -Dcassandra.replace_address=192.168.1.101来启动（只是第一次这样，以后就直接bin/cassandra启动就可以了） 第三：就是等待数据迁移，当你在其它机器上使用nodetool status看到新节点的状态变成UN状态的时候，就表示迁移完成了。你也可以在新节点上通过nodetool netstats查看数据迁移的进度。 注意：如果你的集群数据量很大，这个数据迁移的过程将会给集群带来很大的负载。你需要在启动新节点之前做两件事情： 1、关闭所有节点的压缩。 nodetool disableautocompaction 关闭自动压缩 nodetool stop COMPACTION 停止正在执行的压缩。 当新节点启动之后，也要执行nodetool disableautocompaction。 在数据迁移完毕之后，再放开即可nodetool enableautocompaction 2、限制所有节点数据迁移流量 ./nodetool setstreamthroughput 32 限制为32mbps 假设你的集群有10个机器，那么你的新节点的流量大约是32*10mbps。 你可以根据数据迁移的进度，完成的节点个数，慢慢调大这个值。

cassandra数据迁移有好多种方法，只要你的sstable文件没有丢失，这里只讲述两种常见易用的方式： 第一种方式：copy命令 使用方法：适用于数据量小的情况下。 使用方式： copy mykeyspace.mytable to ‘/home/db.csv’ 这样就成功的把表mytable以csv的格式导出到了db.csv文件。 然后再另外一个集群中，建一个一模一样的表，然后使用 copy app12345.mytable from ‘/home/db.csv’ 就把数据导入到了新的库中。 不过以上方式仅限于小数据量，当数据量一大，这个过程会持续很久，而且文件也会很大。 第二种方式：sstableloader工具。 在cassandra的bin目录下提供了一个sstableloader工具，这个工具专门用于把一个表的sstable文件导入到一个新的集群中。 假设你的表是mykeyspace.mytable。你的数据存一个10个节点组成的集群中，每个几点的数据都存在/disk/data1和/disk/data2目录下。 假设你的新集群的一个访问地址是192.168.2.1， 先在新集群建离相同名字的keyspace和表结构。 接下来你只要在老集群的每个节点执行下面的命令： bin/sstableloader -d 192.168.2.1 -u cassandra -pw cassandra -t 100 /disk/data1/mykeyspace/mytable bin/sstableloader -d 192.168.2.1 -u cassandra -pw cassandra -t 100 /disk/data2/mykeyspace/mytable 其中-u是 用户名 -pw是密码 -t是限制流量100M/bps 等所有节点执行完毕，你的表数据就成功导入到了新的集群中，当然只要你的机器io和网络条件允许，你可以多个节点并发执行。

elasticsearch集群，有时候可能需要修改配置，增加硬盘，扩展内存等操作，需要对节点进行维护升级。但是业务不能停，如果直接kill掉节点，可能导致数据丢失。而且集群会认为该节点挂掉了，就开始转移数据，当重启之后，它又会恢复数据，如果你当前的数据量已经很大了，这是很耗费机器和网络资源的。 本文转载官方提供的安全重启集群节点的方法： 第一步：先暂停集群的shard自动均衡。 curl -XPUT http://192.168.1.2:9200/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "none" } }' 第二步：shutdown你要升级的节点 curl -XPOST http://192.168.1.3:9200/_cluster/nodes/_local/_shutdown 第三步：升级重启该节点，并确认该节点重新加入到了集群中 第四步：重复2-3步，升级重启其它要升级的节点。 第五步：重启启动集群的shard均衡 curl -XPUT http://192.168.1.2/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "all" } }' 到此整个集群安全升级并且重启结束。

cassandra的连接池配置 cassandra的datastax驱动使用的是异步nio实现的，发出去的请求，不会阻塞线程，当有响应的时候会通知你。所以cassandra客户端和服务器之间不需要太多的连接，因为发送一个请求是很快的，只要一个线程不断监听响应就可以了。 cassandra的配置方式如下： PoolingOptions poolingOptions = new PoolingOptions(); poolingOptions .setMaxSimultaneousRequestsPerConnectionThreshold(HostDistance.LOCAL, 32); poolingOptions.setCoreConnectionsPerHost(HostDistance.LOCAL, 2); poolingOptions.setMaxConnectionsPerHost(HostDistance.LOCAL, 4); Cluster cluster = Cluster.builder() .addContactPoints("192.168.1.101") .withCredentials(username, password) .withPoolingOptions(poolingOptions)； 这就完成了一个对连接池的配置。 setCoreConnectionsPerHost(HostDistance.LOCAL, 2); 表示和集群里的机器至少有2个连接。注意是和集群里的每个机器都至少有2个连接。 setMaxConnectionsPerHost(HostDistance.LOCAL, 4); 最多有4个连接 setMaxSimultaneousRequestsPerConnectionThreshold(HostDistance.LOCAL, 32); 每个连接允许32请求并发。 也就是说你这个配置，最多允许（324机器个数)个并发请求。如果太多的并发可能会发生获取连接失败。 以上是说的集群部署在一个机房，只有一个数据中心DC的情况，如果有多个数据中心。要设置REMOTE连接数。 PoolingOptions poolingOptions = new PoolingOptions(); poolingOptions .setMaxSimultaneousRequestsPerConnectionThreshold(HostDistance.LOCAL, 32); poolingOptions.setCoreConnectionsPerHost(HostDistance.LOCAL, 2); poolingOptions.setMaxConnectionsPerHost(HostDistance.LOCAL, 4); poolingOptions.setCoreConnectionsPerHost(HostDistance.REMOTE, 2); poolingOptions.setMaxConnectionsPerHost(HostDistance.LOCAL, 4); 配置完之后，获取session，就可以全程序单例使用了。

cassandra集群可能有好多机器，这么多机器肯定有宕机的几率，而且机器越多，几率越大，当发生宕机的时候，你如何删除一个节点呢？ 本文仅适应使用了vnodes的cassandra集群，怎么判断是否用了vnodes呢？ 主要看你的cassandra.yml配置文件中，是否配置了initial_token，如果没有配置，就是使用了vnodes。使用了vnodes，删除了节点之后它会自己均衡数据，不要你手动处理。 根据官方文档的提示，操作步骤如下： 第一步：先每个机器都修复下每个keyspace nodetool repair -h ip_address_of_node keyspace_name 第二步：如果你要删除的机器是UP状态的机器，没有宕机 你可以在要删除的机器上执行 nodetool decommission. 就直接结束了，否则继续： 第三步：如果你的机器是宕机的。 你要先用在一个活着的机器上执行nodetool status 命令，获取宕机节点的id $ nodetool status Datacenter: DC1 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving – Address Load Tokens Owns (effective) Host ID Rack UN 192.168.2.101 112.82 KB 256 31.7% 420129fc-0d84-42b0-be41-ef7dd3a8ad06 RAC1 DN 192.168.2.103 91.11 KB 256 33.9% d0844a21-3698-4883-ab66-9e2fd5150edd RAC1 UN 192.168.2.102 124.42 KB 256 32.6% 8d5ed9f4-7764-4dbd-bad8-43fddce94b7c RAC1 第四步: 在活的节点上执行删除操作 nodetool removenode d0844a21-3698-4883-ab66-9e2fd5150edd 它会自己均衡数据，这里就直接结束了，否则继续。 第五步:再次使用nodetool status查看节点是否删除成功 $ nodetool status ...

什么时候使用一个索引 cassandra的内建索引适合这样一个表，它有好多列都包含这个索引列的值。这个索引列有更多的值，你的开销越大，主要是对查询和维护索引。例如假设你有一个播放列表的表里面有数十亿首歌曲。很多歌曲可能有共同的艺术家。这个艺术家的列就比较适合作为索引。 什么情况不适合使用索引 不要在以下情况使用索引： 这列的值很多的情况下，因为你相当于查询了一个很多条记录，得到一个很小的结果。 表中有couter类型的列 频繁更新和删除的列 在一个很大的分区中去查询一条记录的时候（也就是不指定分区主键的查询） 值很多的列建索引的坏处 如果你在一个有很多值的列上创建了索引，在这个索引的上的查询就会导致多次查询，而最终查到很少的结果。在一个有数十亿首歌曲的表里通过作者(通常每首歌都不一样)去搜索，相比通过艺术家去搜索，是很低效的。更有效的方式是手动维护一个索引表，而不是使用cassandra的内建索引。对于一些特定值的列，使用索引有时候是很方便的，只要不是大量的查询，并且不是持续负载的情况下。 相反只有几个很少值的列也不适合创建索引，例如boolean型的列，这是没有意义的。索引列的每一个值在索引中都是一行。也就是说对于false的值，会形成一个超级大的行。也就是说索引一个值只有foo=false 和foo=true的列是没有意义的。 频繁更新和删除的列建索引的坏处 Cassandra stores tombstones in the index until the tombstone limit reaches 100K cells. After exceeding the tombstone limit, the query that uses the indexed value will fail. 在一个很大的分区中去查询一条记录的坏处 不指定分区key，在一个索引列上查询，相当于在集群中所有的机器上去查询，这种查询会变慢随着机器的增加。你要在你查询中指定分区key，避免这种查询性能问题。

cassandra的索引查询和排序 cassandra的查询虽然很弱，但是它也是支持索引和排序的，当然是简陋的查询，这一切都是为了追求性能的代价，所以要使用cassandra，你不能希望它完全适用你的逻辑，而是把你的逻辑设计的更适合cassandra。 第一：索引查询 cassandra是支持创建二级索引的，索引可以创建在除了第一个主键之外所有的列上，当然有些类型除外，例如集合类型。 例如 create table test( a int, b int, c int, d int, e int, m int, primary key(a,b,c)); create index on test(c); create index on test(e); 在第一主键a上创建索引是不可以的： create index on test(a) X 索引列只可以用=号查询，所以 select * from test where e=1; //是可以 select * from test where e>1; //就不行了。 如果你的查询条件里，有一个是根据索引查询，那其它非索引非主键字段，可以通过加一个ALLOW FILTERING来过滤实现、 例如： select * from test where e=1 and m>2 ALLOW FILTERING; 虽然m字段是非索引非主键字段，但是只要加了ALLOW FILTERING条件，它会先根据e=1查出来，再对结果进行m>2过滤 第二：排序 cassandra也是支持排序的，order by。 当然它的排序也是有条件的， 第一：必须有第一主键的=号查询。cassandra的第一主键是决定记录分布在哪台机器上，也就是说cassandra只支持单台机器上的记录排序。 第二：那就是只能根据第二、三、四…主键进行有序的，相同的排序。 第三：不能有索引查询 select * from test where a=1 ORDER BY b desc; select * from test where a=1 ORDER BY b desc, c desc; select * from test where a=1 ORDER BY b asc; select * from test where a=1 ORDER BY b asc, c asc; 以上都是可以的。 ...

elasticsearch一个准实时的搜索引擎，基于lucene构建，它的主要强项还是在全文检索方面。工作中还是使用到了这部分功能，这里做一个简单的总结，可以使初次使用的人很快的配置和使用。 一、全文检索的概念 首先介绍全文检索的概念，就是对一篇文章进行索引，可以根据关键字搜索，类似于mysql里的like语句。 全文索引就是把内容根据词的意义进行分词，然后分别创建索引，例如”你们的激情是因为什么事情来的” 可能会被分词成：“你们“，”激情“，“什么事情“，”来“ 等token 这样当你搜索“你们” 或者 “激情” 都会把这句搜出来。 二、内置分词器 elasticsearch实现全文索引，首先要确定分词器，elasticsearch默认有很多分词器，你可以参考elasticsearch的官方文档。了解分词器主要是怎么实现的。 你可以使用 curl -XGET ‘http://192.168.1.101:9200/_analyze?analyzer=standard’ -d ‘你们有什么事情’ 命令来了解各种分词器的分词效果。 三、中文分词器 一般中文分词器一般使用第三方的ik分词器、mmsegf分词器和paoding分词器，他们最初可能构建于lucene，后来移植于elasticsearch。 在最新版的elasticsearch，我们主要使用了ik分词器。 安装ik分词器到elasticsearch很简单，它有个插件目录analysis-ik，和一个配置目录ik, 分别拷贝到plugins和conf目录就可以了。当然你可以使用elasticsearch的plugin命令去安装，这个过程可能会有些麻烦。 然后在elasticsearch.yml文件中配置 index: analysis: analyzer: ik: alias: [ik_analyzer] type: org.elasticsearch.index.analysis.IkAnalyzerProvider ik_max_word: type: ik use_smart: false ik_smart: type: ik use_smart: true 意思就是ik分词器，也可以使用别名ik_analyzer，使用IkAnalyzerProvider类分词。 ik_max_word、ik_smart也是ik分词器，只不过一个打开了use_smart开关，一个没打开use_smart。这个本文不关心。 四、curl命令测试分词器 第三方的分词器，你是没法使用 curl -XGET ‘http://192.168.1.101:9200/_analyze?analyzer=standard’ -d ‘你们有什么事情’ 来查看分词效果的。 你必须创建一个指定该分词器的索引才行。 1、创建索引 curl -XPUT http://192.168.1.101:9200/index 2、创建mapping，这里就一个字段content curl -XPOST http://192.168.1.101:9200/index/fulltext/_mapping -d' { "fulltext": { "_all": { "indexAnalyzer": "ik", "searchAnalyzer": "ik", "store": "false" }, "properties": { "content": { "type": "string", "store": "no", "indexAnalyzer": "ik", "searchAnalyzer": "ik" } } } }' 3、查看分词效果 curl -XGET ‘http://192.168.1.101:9200/index/_analyze?analyzer=ik’ -d ‘你们有什么事情’ 4、索引数据 curl -XPOST http://192.168.1.101:9200/index/fulltext/1 -d’{content:“美国留给伊拉克的是个烂摊子吗”}’ ...

cassandra集群要求严格的时间同步，有一点同步就会发生这样那样的问题，这个事情我已经在cassandra集群要求严格的时间同步里说明了，所以时间同步是cassandra集群的前提。 cassandra使用的是最后一致性模型，也就是说一开始的并发更新的数据可能是不一致的，但是经过这段不一致的时间之后，系统会达到最终的一致性。让每个客户端看到的结果是一样的。 这个最终一致性的强度，在cassandra中是有你所选的一致性模型决定的。通常使用cassandra，我们选择QUORUM级别，表示有半数副本收到请求的时候，返回客户端响应，这样保证插入的数据，可以肯定被查询到。然而这里存在一个问题，关于并发性，假设客户端对同一条记录进行更新，cassandra是根据什么判断请求的先后呢？只有时间，cassandra会根据请求到达服务器的先后时间。例如： QueryOptions options = new QueryOptions(); options.setConsistencyLevel(ConsistencyLevel.QUORUM); Cluster cluster = Cluster.builder() .addContactPoint("192.168.1.101") .withCredentials("cassandra", "cassandra") .withQueryOptions(options) .build(); Session session = cluster.connect(); RegularStatement update10 = QueryBuilder.update("myKeysapce","tableName") .with(QueryBuilder.set("col2", 10)) .where(QueryBuilder.eq("key1", 1)); session.execute(update10); RegularStatement update20 = QueryBuilder.update("myKeysapce","tableName") .with(QueryBuilder.set("col2", 20)) .where(QueryBuilder.eq("key1", 1)); session.execute(update20); 但是cassandra集群有多台机器，客户端发到服务器的不同机器上呢？糟了，数据乱掉了。是的，当你使用datastax的驱动程序的时候，你会发现快速对同一条记录进行两次更新，最终的结果有时候并不是第二个请求更新的结果，就像上面的例子，每次更新结果可能是20，也可能是10。即便你的一致性级别选择的ALL，也有可能发生这样的情况。因为两次请求的时间间隔实在很短，而集群的所有机器又不能完全时间同步，即便是使用了ntp同步，时间差也会在ms级别，两次请求发到不同的机器上，就会发生这样的问题。 怎么办呢？当我们换用另外一个cassandra客户端Astyana的时候，我们发现并不会发生上面描述的情况，这是为什么呢？难道客户端有问题，经过调查发现，Astyanax客户端发的两次请求都是发到了集群的同一个节点，而datastax官方驱动客户端，却是发向了不同的节点。 原来Astyanax客户端有一个请求策略的概念，它有三种策略(TOKEN_AWARE，ROUND_ROBIN和BAG)，其中TOKEN_AWARE就是根据主键token请求到相同的客户端。 那原生的datastax客户端有没有这样的概念呢？调查后发现也是有的，它叫做LoadBalancingPolicy，可以通过 Cluster.builder().withLoadBalancingPolicy(policy)指定，它也有三个策略，分别是: DCAwareRoundRobinPolicy RoundRobinPolicy TokenAwarePolicy 其中TokenAwarePolicy就是根据token把对同一条记录的请求，发到同一个节点，看代码我们发现datastax默认使用的策略就是TokenAwarePolicy，那为什么没有和Astyana一样的效果呢？ 通过阅读它的代码，原因找到了，那就是在更新的时候，要给它指定表的tablemetadata，否则datastatx无法知道哪些字段是主键，额，貌似这个客户端也太傻了。。。 上面的例子改成下面这样，就万事大吉了。 TableMetadata metaData = cluster.getMetadata().getKeyspace("myKeyspace").getTable("tableName"); RegularStatement update10 = QueryBuilder.update(metaData) .with(QueryBuilder.set("col2", 10)) .where(QueryBuilder.eq("key1", 1));

关于数据库连接池的最大空闲时间的配置 java的所有的连接池 无论是c3p0、dbcp还是druid，都有一个类似maxIdleTime配置项。具体含义就是当连接长时间没有向服务器发请求的时候，断开这个连接，避免对数据库连接的浪费。这个时间不是随便设的，它的依据是数据库的连接最大空闲时间。 以mysql为例，它有个_wait_timeout 参数，你可以通过命令show variables like “%timeout%”查看 +—————————–+———-+ | Variable_name | Value | +—————————–+———-+ | connect_timeout | 10 | | delayed_insert_timeout | 300 | | innodb_flush_log_at_timeout | 1 | | innodb_lock_wait_timeout | 50 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 28800 | | lock_wait_timeout | 31536000 | | net_read_timeout | 30 | | net_write_timeout | 60 | | rpl_stop_slave_timeout | 31536000 | | slave_net_timeout | 3600 | | wait_timeout | 28800 | +—————————–+———-+ ...

1、内存优化 在bin/elasticsearch.in.sh中进行配置 修改配置项为尽量大的内存： ES_MIN_MEM=8g ES_MAX_MEM=8g 两者最好改成一样的，否则容易引发长时间GC（stop-the-world） elasticsearch默认使用的GC是CMS GC 如果你的内存大小超过6G，CMS是不给力的，容易出现stop-the-world 建议使用G1 GC 注释掉： JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC" JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC" JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75" JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly" 修改为： JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC" JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200" 如果G1 GC优点是减少stop-the-world在几率，但是CPU占有率高。 需要更优化的性能，你可以参考 http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html 2、合理配置主节点和数据节点 配置文件：conf/elasticsearch.yaml node.master: true node.data: true 当master为false，而data为true时，会对该节点产生严重负荷； 当master为true，而data为false时，该节点作为一个协调者； 当master为false，data也为false时，该节点就变成了一个负载均衡器。 3、设置合理的刷新时间 建立的索引，不会立马查到，这是为什么elasticsearch为near-real-time的原因 需要配置index.refresh_interval参数，默认是1s。 你可以像 http://zhaoyanblog.com/archives/299.html 文件中一样，调用接口配置 也可以直接写到conf/elasticsearch.yaml文件中 index.refresh_interval：1s 这样所有新建的索引都使用这个刷新频率。

适应于cassandra2.0以上的版本 1、首先修改配置文件 cassandra.yaml 把默认的authenticator: AllowAllAuthenticator运行所有人登录设置为用密码登录： authenticator: PasswordAuthenticator 2、登录cassandra创建用户 使用默认账户登录cassandra 在bin目录下执行 ./cqlsh -ucassandra -pcassandra 创建用户 CREATE USER myusername WITH PASSWORD 'mypassword' SUPERUSER ; 3、使用新用户登录 删除默认帐号： DROP USER cassandra ; 4、java使用用户名密码访问cassandra Cluster cluster = Cluster.builder() .addContactPoint("192.168.22.161") .withCredentials("myusername", "mypassword") .build();

elasticsearch是基于lucene的，lucene是可以做到实时的，就是创建索引之后，立即能查询到。 但是这样，要么是牺牲索引的效率，每次都索引之后都刷新，要么就是牺牲查询的效率每次查询之前都进行刷新。 索引之后进行刷新是通过： elasticClient.prepareIndex("indexName", "Person") .setSource( XContentFactory.jsonBuilder() .startObject() .field("name", "zhangsan") .field("desc", "you are good chaoji good") .field("age", 18) .field("height", 256789l) .field("sex", "M") .field("bool", true) .field("double", 33.6f) .field("date", new Date(16554755464l)) .endObject()) .setRefresh(true) .execute().actionGet(); 进行搜索前进行刷新 elasticClient.admin().indices().refresh(new RefreshRequest("indexName")); 无论哪一种，都会让你的性能下降10倍以上，所以只能采取一种折中的方案，每隔n秒自动刷新，这样你创建索引之后，最多在ns之内肯定能查到。 这就是所谓的准实时(near real-time)查询。 构建客户端的时候设置 Settings settings = ImmutableSettings.settingsBuilder() .put("client.transport.sniff", true) .put("index.refresh_interval", "1s") .put("cluster.name","elasticsearch") .build(); TransportClient client = new TransportClient(settings);

cassandra的集群对时间的要求是很严格的，在集群中的任何一台机器时间都必须保持同步，即便有一秒的延迟，也会带来莫名其妙的问题。因为cassandra是根据时间戳分辨出最后到达的响应，假设对同一个记录进行不同的操作，如果时间不同步，可能会导致前面的操作在后面的操作之后生效。当在高速操作的时候，可能会发生记录删除不掉，表drop了仍然存在等等奇怪的现象。 同时如果发生这些形形色色的奇怪问题，你应该首先查一下你的集群是否时间同步，假设真是时间不同步导致的，而你又没发现，这会浪费你好多时间去调查原因。 做时间同步可以是集群里的所有机器和同一个时钟同步服务器同步，也可以集群中的某一个机器作为时钟同步服务器，其它机器都和它做同步。 同步方式一般都有两种，一种是定时同步，就是linux下面用crontabl做个定时任务，定时同步。每隔多少时间去同步一次这种同步是粗劣的，不可取的。如果你想保证你的cassandra集群长期稳定的同步，你需要精准的时间同步，就是使用ntp同步，ntp也是一种时钟同步协议。它有自己的一套算法，当前相差多少，下次什么时候同步等等，它的这一套算法，可以保证时钟时时刻刻的同步。 ntp是linux的一个服务，配置文件是/etc/ntp.conf 配置和启动ntp服务的方法不用赘述了，百度下两个linux服务器如何同步，怎么配置ntp同步，文章一大片。

本文介绍cassandra支持的，目前我所知道的所有查询表达式类型。如果你需要更复杂的查询，单单依靠cassandra是很难做到的，你需要借助其它手段或者工具。 cassandra目前支持的表达式目前有三种： 我们先假设我们的表结构是这样的： create table test( a int, b int, c int, d int, e int, primary key(a,b,c,d) ); create index on test(e); 1、前缀表达式 就是查询条件必须是主键，且前面的主键是=号，只有最后一个主键是> >= < <=。 举例： select * from test where a=1 and b>2; select * from test where a=1 and b=1 and c>2; select * from test where a=1 and b=1 and c=1 and d>2; select * from test where a=1 and b=1 and c>2 and c<2; 以上都是可行的。 ...