列存储与行存储在增删改查方面优势的原理及体现

行存:
增删改查需要建立索引,根据索引一行一行排查找到具体行进行增删改查,同时要记录日志等文件,耗费I/O。
列存:
增原理:8a大批量数据入库时,可以边查询操作,边入库,两不耽误。查的是原数据,入库入副本,副本入完后与原数据置换同步;
改原理:修改时原数据加标记—包头偏移量处加标记,修改后新数据插入到最后(等于增)。每列最后一个包不进行压缩,减少插入数据的工作量;
删原理:删除时原数据加标记—包头偏移量处加标记,以后查操作会跳过该标记内容;
大数据查:只涉及需要查找的列,而且每列有智能索引,可以先按包排查,再在筛出的包内排查。不需像行存一样所有的列每条记录去排查;
智能索引:不是物理存在的表,是加载数据库时提取包头内容在内存形成的表。

shrink space磁盘回收功能说明

1、数据文件所占的磁盘空间回收以文件为单元,只有当这个数据文件涉及的数据都被删除后才能回收该文件占用的磁盘空间。
2、Global Hash需要改成分段存储后才能释放其被Delete掉后的磁盘空间;如果两个列上都建有hash列,但key_dc_size大小不一样,则需要删除这两个key_dc_size的最小公倍数的DC个数后,才能真正的释放掉索引数据空间。
全文索引与hash索引类似,全文索引也有一个库大小的概念。
如果两个列上分别有全文索引和hash索引,则也需要满足最小公倍数原则。
3、由于INSERT/LOADER需要使用尾块数据,因此尾块所在的文件不能删除,即最后两个文件不能删除(一个存了有效尾块,一个存了无效尾块)。

event_scheduler及集群定期清理表(DROP TEMPTABLE)的定时任务说明

在集群中,每个gcluster都存在一个user为event_scheduler的连接,如下:

Id        User        Host        db        Command        Time        State        Info 1        event_scheduler        localhost        NULL        Daemon        60428        Waiting for next activation        NULL

event_scheduler用户用于进行数据库执行计划的执行。
gbase集群的执行计划存储在gbase.event系统表中,查询该表可以看当前数据库定义的计划任务,默认如下:

gbase> select * from gbase.event \G
*************************** 1. row ***************************
                  db: gbase                                                           
                name: drop_temp_table                                                 
                body: DROP TEMPTABLE
             definer: root@localhost                                                               
          execute_at: NULL
      interval_value: 1
      interval_field: DAY
             created: 2015-01-30 10:07:34
            modified: 2015-01-30 10:07:34
       last_executed: 2015-03-23 02:07:34
              starts: 2015-01-30 02:07:34
                ends: NULL
              status: ENABLED
       on_completion: DROP
            sql_mode: ANSI_QUOTES,IGNORE_SPACE
             comment:                                                                 
          originator: 0
           time_zone: +08:00
character_set_client: utf8                            
collation_connection: utf8_general_ci                 
        db_collation: utf8_general_ci                 
           body_utf8: DROP TEMPTABLE
1 row in set (Elapsed: 00:00:00.00)

GBase相关的乱码问题以及解决办法

出现乱码问题的几种可能情况:操作系统乱码问题、GBase数据库乱码问题、应用系统乱码问题、Telnet、SSH工具乱码问题。一般情况将以上内容的字符集一致,则彻底解决乱码问题。
出现乱码的解决办法:

1、操作系统乱码问题
在Linux 操作系统里遇到中文乱码问题,执行以下命令设置字符集。

$ export LANG='zh_CN.UTF-8' --重启后失效

其他相关命令

$ locale -a   --查看本地的字符集
/etc/sysconfig/i18n --记录系统默认使用语言
或者设置 Linux 系统的环境变量/etc/profile (全局) 或者 ~/.bashrc (单个用户) 即可

2、GBase数据库乱码问题
修改字符集的语法

SET [SESSION] parameter_name=value;

使用vi 命令编辑gbase_8a_gbase8a.cnf 文件,插入配置参数:

default-character-set=value

查看数据库字符集:

gbase> show variables like '%char%';
+--------------------------+-------------------------------------------------+
| Variable_name            | Value                                             |
+--------------------------+-------------------------------------------------+
| character_set_client     | utf8                                              |
| character_set_connection | utf8                                            |
| character_set_database   | utf8                                            |
| character_set_filesystem | binary                                          |
| character_set_results    | utf8                                             |
| character_set_server     | utf8                                             |
| character_set_system     | utf8                                            |
| character_sets_dir       | /home/liming/GBase/server/share/gbase/charsets/ |
+--------------------------+-------------------------------------------------+
8 rows in set (Elapsed: 00:00:00.00)
3、应用系统乱码问题
系统联调中,应用开发与数据库交互发生的乱码问题,一般情况由于代码中未指定字符集,造成控制台的信息或前端页面出现乱码。尝试指定驱动包的URL。
例如,JDBC驱动包:

jdbc:gbase://localhost:5258/test?user=root&password=1234 &characterEncoding=UTF-8

4、Telnet、SSH乱码问题
远程连接工具的字符集设置,例如XShell:

Porperties(Alt+P)->Terminal->Encoding->UTF-8