oceanbaseMysql Cluster 与 OceanBase 有哪些区别？哪个更优秀

“12306”要不要购买铁路乘意险？

可以根据您的具体需求来觉得是否购买保险。

一、什么是铁路乘意险。

从2015年11月1日开始，乘客在购买火车票的同时，还可一同购买铁路旅客人身意外伤害保险 业务服务，也就是铁路乘意险。

铁路乘意险保费3元，最高保障30万元意外身故、伤残和3万元 意外医疗保险金，乘客可自愿投保。

二、铁路乘意险保障范围。

车上和站内铁路乘意险保障期间为被保险人按保险单载明的乘车日期、列车车次和发到站，持 有效乘车凭证合法乘坐境内列车期间。

三、?铁路乘意险保障内容。

最高保障30万元意外身故、伤残和3万元意外医疗保险金。

四、铁路乘意险保费。

3元。

在12306网站购买铁路“乘意险”的成人父母，其免费携带的一名身高不足1.2米且不满 10周岁的乘车子女(经二代身份证核验)可免费领取一份铁路乘意险。

五、铁路乘意险如何购买。

网上购票提交订单后，系统中会提示旅客是否需要购买铁路意外保险，旅客需要阅读并同意相 关的保险条款并勾选购买后，系统会自动显示出相应的保费。

旅客通过网络购买“乘意 险”后，会自动生成电子保单，旅客可凭短信的保单查询号登录中国铁路保险网站查询相关信 息。

如果旅客需要保险发票，可以到火车站售票窗口领取。

六、铁路乘意险后购买注意事项。

1、首先，已投保旅客应妥善保管好火车票、12306所发的投保短信或保险告知单、购保时 所使用的有效身份证件和保险发票。

2、其次，在12306网站投保的旅客，可在不晚于自所购火车票载明的乘车日期起31日内，凭 火车票或投保时使用的有效身份证件到车站指定窗口领取保险发票。

3、最后，铁路部门特别提醒旅客注意的是，投保人一定要妥善保管好火车票、保险发票，以及 投保时所使用的有效身份证件，便于出险时查询和核实有关信息。

oceanbase 底层用的什么数据库

入口：ObSql类 本部分的入口函数在ob_sql.h中,调用函数ObSql::direct_execute可以直接执行SQL语句,并返回结果集ObResultSet。

函数stmt_prepare用于解析要预编译的SQL语句,stmt_execute则用于执行Prepare过的SQL语句。

[cpp] view plaincopy class ObSql { public: ObSql(){} ~ObSql(){} int direct_execute(mon::ObString &stmt, ObResultSet &result) int stmt_prepare(mon::ObString &stmt, ObStmtPrepareResult &result); int stmt_execute(const uint64_t stmt_id, mon::mon::ObObj> params, ObResultSet &result); int stmt_close(const uint64_t stmt_id); };

oceanbase rowkey 有几个

Rowkey是OceanBase诞生之初就引入的概念，最终被确立是在OceanBase 0.3。

为了便于理解，不妨把OceanBase想象成一个Key-Value系统，Rowkey就是Key，Value就是返回的行数据。

如果你对mysql数据库熟悉，那么不妨把Rowkey理解成primary key，它就是那几个主键列的组合，列的顺序与primary key中定义的顺序一致。

OceanBase中的静态数据是按照rowkey顺序存储在磁盘中的，这样做的好处是： 1. 支持每一行的快速定位（想象一下BTree的查找过程，如果数据无序，根本无从查起，也不叫BTree了） 2. 支持连续行的扫描。

一个rowkey对应一行，一个rowkey前缀则对应一片连续行。

在OceanBase 0.3之前的Rowkey是一个概念，在代码中并没有一个实体对象。

例如，在0.2版本中，内存中的行数据是存储在一个大的二维数组中（实际是用一维数组存储，不过逻辑上是二维，对象叫ObCellArray），纵向维度就是一行行的数据，横向维度就是一列列的数据。

每一行的开头几列都是Rowkey列，后面几列就是用户看到的数据列。

0.3之后引入了ObRowkey对象，用于表示一行的rowkey，它的构成要素包括： 1. 它记录了主键列的列数 2. 它以数组的形式记录了主键列的值，值在数组中的顺序与primary key的定义顺序一致。

Mysql Cluster 与 OceanBase 有哪些区别？哪个更优秀

1. 分布式存储部分是做为mysql的一种存储引擎实现的（NDB），上层SQL没有感知，所以SQL层应该没有支持分布式并行查询处理。

OceanBase的基于代价的查询优化器对于大查询会充分发挥分布式数据库的并行处理能力。

再如OB分布式执行计划可以下压到存储所在机器。

而ndb node实现存储引擎接口没有复杂的查询处理能力。

2. Mysql cluster中主备同步是用两阶段提交实现的，这个有点无语。

另外REDO日志异步写入，延时一秒。

也就是说宕机会丢一秒的事务，想象一下双十一每秒17万笔交易丢失……这块是它的整体架构导致事务层实现机制的问题。

btw，mysql cluster属于分布式数据库，mysql主从几节点都不是分布式数据库。