Skip to main content

DB Optimization Guide

The BACKND DB is a pay-as-you-go service that charges for the amount that you use.
Optimizing the way game data is stored and loaded can help manage read/write charges efficiently.

Optimize table design​

By grouping related information into a table and managing it, you can use read/write processing efficiently.

Save all data at once(throughput-intensive structure)​

This is a structure used in casual games. You can manage and store all information in one table.
This has the advantage of simplifying development, but it also consumes more read/write usage than necessary.
When the value of one item, character, or stage changes, all data must be rewritten and read every time. It is recommended to partition the table for DB optimization.

  • Using one userData table
    {
        // Item information managed inside userData
        "item": 
        [
            "Owned item 1", "Owned item 2", "Owned item 3", "Owned item 4"
        ], 
        // Character information managed inside userData
        "character": 
        [
            { "nickname": "Owned character 1", "level": 5 },
            { "nickname": "Owned character 2", "level": 99 }
        ],
        // Stage clear information managed inside userData 
        "stage": 
        [
            { "stage1": "clear", "clearTime": 55 },
            { "stage2": "clear", "clearTime": 120 }
        ] 
    }

Save data by table(improved structure)​

It is a structure in which information integrated and managed in the userData table is separated into each table.
When the information in the item table is changed, only the item table can be read and written, and when the information in the character table is changed, only the character table can be read and written.

  • Using three tables: item, character, stage

    • item table

      [ "Owned item 1", "Owned item 2", "Owned item 3", "Owned item 4" ]

    • character table

      [
          { "nickname": "Owned character 1", "level": 5 },
          { "nickname": "Owned character 2", "level": 99 }
      ]

    • stage table

      [
          { "stage1": "clear", "clearTime": 55 },
          { "stage2": "clear", "clearTime": 120 }
      ]

Optimize data storage time​

By adjusting the timing when data is stored on the server, you can efficiently manage the read/write throughput.

Classify core and non-core data​

  • Core data is information that has a large impact when it disappears, such as character leveling, stage clearing, and purchasing paid currency(eg. Diamond).
  • Non-core data is information that changes frequently, such as general items(Misc.) obtained after hunting low-level monsters and click reward gold in clicker games.

Separate data storage time​

  • It is recommended to save core data immediately at the time of change.
    Exception: A game in which changes to core data occur multiple times in a short period of time due to continuous upgrades, continuous level-ups, etc. → Data must be saved after the core data change is completed.
  • It is recommended to save non-core data only when certain events occur, such as stage clearing.
    Unimportant information can only be stored when absolutely necessary, saving read/write throughput.

Optimize log storage​

BACKND's log storage feature performs BACKND DB write process. Storing logs frequently can result in spikes in write throughput.

Separate core and non-core logs​

  • Core logs are logs that are related to a member’s account information or sales, such as payment, in-app item purchases, and nickname changes.
  • Non-core logs are logs that do not interfere with the game operation even if some parts are lost, such as game play time and play type.

Separate storage time​

  • It is recommended to save the core log data immediately at the time of action.
    Exception: A game in which the core log storage action occurs multiple times in a short period of time → The log should be saved after the action is completed.
  • It is recommended to save non-core logs at a specific point in time with a delay as much as possible, such as when quitting a game, clearing a stage, or at a set period(e.g.: 30 minutes).

Optimize console lookup​

Game user management and game information management menus in BACKND Console perform read processing upon lookup.

Optimize game information management reading​

  • If you click the Search button without search conditions, all members will be searched. → Uses a lot of read throughput.
  • If you specify target search conditions(member number, member ID, nickname), a search for a specific user is attempted. → Less read throughput can be used.
  • If you do not know the member number or member ID → You can check the member number by searching member information with their nickname in the game user management menu.