Tcallusdb table definition of tcallusdb little knowledge

Posted by seoreferrals on Tue, 08 Feb 2022 22:23:53 +0100

Databases store data with tables as carriers. Different tables often represent different entities. As a domestic self-developed key value nosql database, tcallusdb supports two types of tables: protobuf(Protocol Buffers) table and TDR (tent data representation) table.

Protobuf is a descriptive language developed by Google, which serializes structured data while emphasizing simplicity and performance; TDR is a cross platform data representation language developed by Tencent. It combines the advantages of XML, binary and ORM (object relational mapping), and is widely used in the serialization scenario of Tencent game data. This article will briefly introduce how to define these two tables.

Protobuf table

The following is the protobuf table game_players.proto example, you can upload the file to Tencent cloud console and create the table.

syntax = "proto3";         // Specify the language version of protobuf, proto3

// Import tcallusdb public definition service  
import "tcaplusservice.optionv1.proto"; 

message game_players {  // Define the tcallusdb table, which contains the message type

// Based on the selection tcaplus service tcaplus_ primary_ Key create primary key field
// Tcallusdb can specify up to 4 primary key fields in a single table
    option(tcaplusservice.tcaplus_primary_key) = "player_id, player_name, player_email";

    // Based on the selection tcaplus service tcaplus_ Index create primary key index
    option(tcaplusservice.tcaplus_index) = "index_1(player_id, player_name)";
    option(tcaplusservice.tcaplus_index) = "index_2(player_id, player_email)";

    // Value types supported by tcallusdb:
    // int32, int64, uint32, uint64, sint32, sint64, bool, fixed64, sfixed64, double, fixed32, sfixed32, float, string, bytes
    // Nesting type: message

    // Primary key field
    int64 player_id = 1;  
    string player_name = 2;
    string player_email = 3;
	
    // Normal (non primary key) field
    int32 game_server_id = 4;
    repeated string login_timestamp = 5;
    repeated string logout_timestamp = 6;
    bool is_online = 7;
	
    payment pay = 8; 
}

message payment { 
    
int64 pay_id = 1;
uint64 amount = 2;
int64 method = 3;

}

TDR table

TDR supports generic tables and list tables. Generic table is a table that represents element attributes in the form of a table, such as students, employers and gamers. The list table is a series of records, such as game leaderboards and emails in the game (usually the last 100 emails).

It is recommended to create two different types of tables in one XML file.

  • The element metadata is the root element of the xml file. In addition, you can use union to create nested types:
  • The struct element containing the attribute primarykey defines a table; Otherwise, it is just an ordinary structure.
  • Each time the table structure is modified, the version attribute value needs to be increased by 1 accordingly, and the initial version is always 1.
  • The primarykey attribute specifies the primary key field; You can specify up to 8 primary key fields for the generic table and 7 for the list table.
  • The splittablekey attribute is equivalent to the shard key. The tcallusdb table is split and stored in multiple storage nodes. Splittablekey must be one of the primary key fields. A good splittablekey should be highly decentralized, which means that the range of values is very wide. It is recommended to use string type.
  • The desc attribute contains the description of the current element.
  • The entry element defines a field. Supported value types include int32, string, char, int64, double, short, etc.
  • The index element defines an index that must contain a splittablekey. Since the primary key attribute should not be the same as the query table, the primary key attribute can be used. Example: users_mails.xml
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>

<metalib name="tcaplus_tb" tagsetversion="1" version="1">

  <!-- generic_table `users`, store the user' information -->
  <!-- an user may has many roles -->
  <struct name="users" version="1" primarykey="user_id,username,role_id" splittablekey="user_id" desc="user table">
    <entry name="user_id" type="uint64" desc="user id"/>
    <entry name="username" type="string" size="64" desc="login username"/>
    <entry name="role_id" type="int32" desc="a user can have multiple roles"/>

    <entry name="level" type="int32" defaultvalue="1" desc="role's level"/>
    <entry name="role_name" type="string" size="1024" desc="role's name"/>
    <entry name="last_login_time" type="string" size="64" defaultvalue="" desc="user login timestamp"/>
    <entry name="last_logout_time" type="string" size="64" defaultvalue="" desc="user logout timestamp"/>

    <index name="index1" column="user_id"/>
  </struct>

  <!-- list_table `mails`, store the role's mails -->
  <struct name="mails" version="1" primarykey="user_id,role_id" desc="mail table">
    <entry name="user_id" type="uint64" desc="user id"/>
    <entry name="role_id" type="int32" desc="a user may has many roles"/>

    <entry name="text" type="string" size="2048" desc="mail text"/>
    <entry name="send_time" type="string" size="64" defaultvalue="" desc="timestamp of the mail sent"/>
    <entry name="read_time" type="string" size="64" defaultvalue="" desc="timestamp of the mall read"/>
  </struct>

</metalib>
  • The union element contains a collection of original types, such as integers and strings. Union can also be referenced as a custom type;
  • The Macro tag is used to define constants.
<macro name="DB_MAX_USER_MSG_LEN" value="301" desc="Max length of the message that user can define"/>
 <union name="DBPlayerMsg" version="1" desc="DB Player message">
   <entry name="SysMsgID"     type="uint8"         desc="Message ID" />
   <entry name="UsrMsg"       type="string"        size="DB_MAX_USER_MSG_LEN"   desc="player created message" />
 </union>

Tcallusdb is a distributed NoSQL database produced by Tencent. The storage and scheduling code is completely self-developed. It has the characteristics of cache + floor fusion architecture, PB level storage, millisecond delay, lossless horizontal expansion and complex data structure. At the same time, it has the characteristics of rich ecology, convenient migration, extremely low operation and maintenance cost and five nine high availability. Customers cover games, Internet, government affairs, finance, manufacturing, Internet of things and other fields.

Topics: Database nosql