void Test()
{
    var dao = new PlayerInfoDAO();

    //DBデータのキャッシュ化
    dao.LoadRecords();
    var info = dao.Cache.First();

    Debug.Log($"AppVersion: {info.AppVersion}");

    //キャッシュデータをDB反映
    dao.SaveAll();
}

新基盤での対応

// 基盤側定義
public interface ITableEntity
{
    int PrimaryIndex { get; set; }
}

public interface ITableEntityMeta
{
    // int用
    int GetIndexIntMember(ITableEntity entity,int index);
    void SetIndexIntMember(ITableEntity entity,int index, int value);

    // long用など他の型用のインターフェースが続きます
}

// プロジェクト側定義
[Table("player_test")]
public class TableEntity : ITableEntity
{
    [Column("id")]
    int PrimaryIndex { get; set; }

    [Column("int_data")]
    int IntData { get; set; }
}

//自動生成
public class TableEntityMeta : ITableEntityMeta
{
    //Columnの定義順に変数を返すgetter
    int GetIndexIntMember(ITableEntity entity,int index)
    {
        var casted = entity as PlayerAccount;   
        switch (index)
        {
            case 0:
                return casted.PrimaryIndex;
            case 1:
                return casted.IntData;
        }

        return default;

    }

    //Columnの定義順に変数を更新するsetter
    void SetIndexIntMember(ITableEntity entity,int index, int value)
    {
        var casted = entity as PlayerAccount;   
        switch (index)
        {
            case 0:
                casted.PrimaryIndex = value;
            case 1:
                casted.IntData = value;
        }

    }
}


// 基盤側の値更新イメージ
void UpdateEntityValue(System.IntPtr pState,ITableEntity entity,ITableEntityMeta meta)
{
    for (int columnIndex = 0; columnIndex < columnCount; columnIndex++)
    {
        var attribute = meta.ColumnAttributes[columnIndex];
        
        switch(attribute.DataType)
        {
            case "int":
                var intValue = SQLiteHelper.ColumnInt(pState,columnIndex);
                meta.SetIndexIntMember(entity,columnIndex,intValue);
                break;
            //他の型のデータ
        }

    }

}

具体的な値を扱うインターフェースがプロジェクトコードとして自動実装されることで、

基盤側のEntityへのデータ注入責任をプロジェクト側に移譲しobject型の中間キャッシュを回避することが出来ました。

 

既存基盤よりも複雑性がかなり増したため、自動生成ツールを基盤機能の一部として開発して対応しています。

このツールはコード生成後にRoslynでコンパイルを行うことでプロジェクト導入後にコンパイルが失敗しないコードを作成する機能があり、PlayerデータのMeta、マスタデータのEntityとMeta、初期化用のHelperやCacheのコードが生成されています。

 

また、Entity提供のユースケースとして読み込みしかできないEntityの需要もありました。

//プロジェクト定義
[Table("player_info", true, true)]
public class PlayerInfo : ITableEntity,IPlayerInfo
{
    [Column("id", "INTEGER", "PRIMARY KEY NOT NULL", "1")]
    public int PrimaryIndex { get; set; }

    [Column("app_version", "TEXT", "NOT NULL", "0")]
    public string AppVersion { get; set; }
}

void Test()
{
    var cache = new PlayerCache();
    StorageAgent.Instance.Setup(cache);

    //DBデータのキャッシュ化
    cache.LoadAll();

    var info = cache.PlayerInfo;
    Debug.Log($"AppVersion: {info.AppVersion}");

    //Entityは扱いたいが、変更されると困る
    info.AppVersion = "???";
}

そのためリードオンリーなEntityを提供するコードも生成されています。

//自動生成
public interface IPlayerInfo
{
    int PrimaryIndex { get;}
    string AppVersion { get;}
}

//自動生成
public class ReadonlyPlayerCache
{
    private readonly PlayerCache _cacheSource;
    public ReadonlyPlayerCache(PlayerCache cacheSource)
    {
        _cacheSource = cacheSource;
    }

    public IPlayerInfo PlayerInfo => _cacheSource.PlayerInfo;

}

void Test()
{
    var cache = new PlayerCache();
    var readOnlyCache = new ReadonlyPlayerCache(cache);
    StorageAgent.Instance.Setup(cache);

    //DBデータのキャッシュ化
    cache.LoadAll();

    var info = readOnlyCache.PlayerInfo;
    Debug.Log($"AppVersion: {info.AppVersion}");

    //セッター不要なケースならリードオンリーなinterfaceに切り替えて使用できる
    info.AppVersion = "???";//error
}

リードオンリーなEntityアクセスの手段が提供され、変更されたくないEntityの表現が容易に行えるようになりました。

余談 : 自動生成ならではの最適化

List<TableEntity>のリクエストがあった場合、基盤内ではList<ITableEntity>として扱うため、必要に応じて相互変換が必要です。

OfType<TableEntity>やCast<TEntity>を使用する場合、別のListインスタンスが必要になるケースがあり、不要なアロケーションが走ってしまいます。

そこで自動生成ならではの最適化として、List同士のUnsafeなキャストを行っています。

 

処理のフローイメージは以下になります

//自動生成
public class TableEntityMeta : ITableEntityMeta
{
    public List<ITableEntity> CreateEmpties(int length)
    {
        var result = new List(length);
        for (int i = 0; i < length; i++)
        {
            result.Add(new TEntity());
        }
        
        return Unsafe.As<List<TEntity>,List<ITableEntity>>(ref result);
        
    }
}

//基盤実装
List<TEntity> LoadEntityies() where TEntity : class, ITableEntity
{
    // metaHolerへのMeta/Entityのひもずけを行う初期化コードも自動生成されます
    var meta = metaHolder[typeof(TEntity)];

    var resultCount = SqliteHelper.クエリ結果のデータ行数取得();

    // 自動生成コードでリクエストにきた派生先のEntityを作成する
    List<ITableEntity> result = meta.CreateEmpties(resultCount);

    // 自動生成コードなので必ず一致する
    return Unsafe.As<List<ITableEntity>, List<TEntity>>(ref entities);
}

新基盤では、MetaとEntityを紐付けて登録するHelperコードも含めて自動生成しています。

人が書いたコードであればList<ITableEntity>の実態がTEntityでリクエストされた型あることは限らないためOfTypeやCastで安全に扱う必要がありますが、自動生成コードの場合ヒューマンエラーは基本無いため自動生成ならではの最適化が行えています。

テーブル内データ量

課題

EntityのキャッシュをC#常に載せてLinqなどで走査を行う都合上、レコード量の多いテーブルが発生するとパフォーマンスへの影響が大きいという課題感がありました。

これはPlayer/Master両方のデータで起きており、同じインターフェースでの解決が必要でした。

 

新基盤での対応

Entityに対して水平分割を提供する事で対応しています。

具体的には、コード上のEntietyと実体のテーブルの関係が1対多にできる機能を実装しました。

ユーザーはentitiyに分割数を追加で指定する事で分割idを指定してデータを操作するmetaが自動生成されます。

 

    //基盤定義
    public interface IHorizontallyDivideTableEntity 
    {
        int DivisionIndex { get; set; }
    }

    // プロジェクト定義
    [Table("horizontally_table", divisionCount:3)]
    public class PlayerTestDiv : IPersistentEntity,IHorizontallyDivideTableEntity
    {
        [Column("id", "INTEGER", "PRIMARY KEY NOT NULL", "1")]
        public int PrimaryIndex { get; set; }

        [Column("divisionIndex", "INTEGER", "NOT NULL", "0")]
        public int DivisionIndex { get; set; }
        
        [Column("content_id", "TEXT", "NOT NULL", "0")]
        public string ContentId { get; set; }
    }

    var playerDivideEntity1 = new PlayerTestDiv { PrimaryIndex = 1, DivisionIndex = 1, ContentId = 100 };
    var playerDivideEntity2 = new PlayerTestDiv { PrimaryIndex = 1, DivisionIndex = 2, ContentId = 200 };
    var playerDivideEntity3 = new PlayerTestDiv { PrimaryIndex = 1, DivisionIndex = 3, ContentId = 300 };
    
    StorageAgent.Instance.SaveEntity(playerDivideEntity1);
    StorageAgent.Instance.SaveEntity(playerDivideEntity2);
    StorageAgent.Instance.SaveEntity(playerDivideEntity3);

上記の様な定義を保存APIに投げると、DivisionIndexを参照してテーブルが更新され下記の状態になります。

 

//手動定義
public class PlayerDTOBase
{
    public　bool LogicallyDeleted;
}
//手動定義
public class PlayerInfoDTO : PlayerDTOBase
{
    public int Id;
    public string AppVersion;
}

//自動生成
public class PlayerInfoDAO
{
    public List Cache {get;} = new();

    void LoadRecords()
    {
        //この時点では論理削除されてデータも入っている
        List<Dictionary<string, object>> allRows Records = BaseDAO.GetAllData();

        foreach (var raw in allRows)
        {
            var hasKey = raw.TryGetValue("logically_deleted",out int value);
            var isLogicallyDeleted = hasKey && value == 1;

            if(!isLogicallyDeleted)
            {
                Cache.Add(Row2DTO(raw));
            }

        }        
    }

    public PlayerInfoDTO Row2DTO(Dictionary<string, object> row)
    {
        var dto = base.Row2DTO(row);

        dto.Id         = row.TryGetValue("id", out object id)? (int)id : 1;
        dto.AppVersion = row.TryGetValue("app_version", out object appVersion)? (string)appVersion : "0";

        return dto;
    }

}

新基盤での対応

DB上で論理削除が行えるようなsqlをmeta上で自動生成することで対応しました。

 

//基盤定義
public interface ILogicalDeleteEntity
{
    bool IsLogicalDeleted { get; set; }
}

//プロジェクト定義
[Table("player_info", enableLogicalDelete:true)]
public class PlayerInfo : ITableEntity,IPlayerInfo,ILogicalDeleteEntity
{
    [Column("id", "INTEGER", "PRIMARY KEY NOT NULL", "1")]
    public int PrimaryIndex { get; set; }
    
    [Column("is_logical_deleted", ColumnDataType.Boolean, "NOT NULL", "false")]
    public bool IsLogicalDeleted { get; set; }

    [Column("app_version", "TEXT", "NOT NULL", "0")]
    public string AppVersion { get; set; }
}

//自動生成
public sealed class PlayerInfotMeta 
{
    public string SelectSQL => IsActiveLogicalDeleted ? $"論理削除が考慮されたクエリ" : $"論理削除を無視したクエリ";
    public string SelectSQLFirst => IsActiveLogicalDeleted ? $"論理削除が考慮されたクエリ" : $"論理削除を無視したクエリ";

    //リクエストの際のフラグが反映される
    public bool IsActiveLogicalDeleted {get; set;}= true;
}

//ユースケース
void Test()
{
    var cache = new PlayerCache();
    StorageAgent.Instance.Setup(cache);

    // 論理削除を無視した読み込み
    var entity1 = StorageAgent.Instance.LoadEntity(enableLogicalDelete: false);

    // 論理削除を考慮した読み込み
    var entity2 = StorageAgent.Instance.LoadEntity(enableLogicalDelete: true);
}

この対応によってdbレイヤーで削除済みデータを作成できるため、C#レイヤーで作成するEntityを減らすことができました。

public class PlayerInfoDTO
{
    public int Id;
    public string AppVersion;
}

void テーブルの情報更新()
{
    var dao = new PlayerInfoDAO();
    //テーブル上の全てのレコードをキャッシュ化
    dao.LoadRecords();

    var info = dao.Cache.Last();
    info.AppVersion = "new version";
    dao.Save(dto => dto.Id == info.Id);
}

    var info = dao.Cache.Last();
    info.AppVersion = "new version";
    dao.Save(dto => dto.Id == info.Id);

void テーブル情報更新のプロジェクトコード運用()
{
    var dao = new PlayerInfoDAO();
    //テーブル上の全てのレコードをキャッシュ化
    dao.LoadRecords();

    var info = dao.Cache.Last();
    info.AppVersion = "new version";

    dao.SaveAll();
}

Entityに主キーを定義する共通インターフェースを提供し、それを元にEntityを保存するAPIを用意しましました。

 
//手動定義
[Table("player_info", true, true)]
public class PlayerInfo : ITableEntity,IPlayerInfo
{
    [Column("id", "INTEGER", "PRIMARY KEY NOT NULL", "1")]
    public int PrimaryIndex { get; set; }

    [Column("app_version", "TEXT", "NOT NULL", "0")]
    public string AppVersion { get; set; }
}

//基盤定義
public interface ITableEntity
{
    int PrimaryIndex { get; set; }
}

void 単体レコードの情報更新のユースケース()
{
    var cache = new PlayerCache();
    StorageAgent.Instance.Setup(cache);

    var info = cache.PlayerInfo;
    info.AppVersion = "new version";

    //基盤側でPrimaryIndexを元にDBとキャッシュに反映
    StorageAgent.Instance.SaveEntity(info);
}

void 複数レコード更新のユースケース()
{
    var cache = new PlayerCache();
    StorageAgent.Instance.Setup(cache);

    var infos = new List()
    {
        new PlayerInfo(){PrimaryIndex = 1,AppVersion="1"},
        new PlayerInfo(){PrimaryIndex = 2,AppVersion="2"},
    };

    //基盤側でPrimaryIndexを元にDBとキャッシュに反映
    StorageAgent.Instance.SaveEntities(infos);
}

このAPI追加により単体/複数を問わず、PrimaryIndexを使用しての効率的なリクエストが行えるようになりました。

データ変更量とキャッシュ量との乖離があるケース、プレイヤーの所持品や所持キャラなど長期運用でキャッシュ量が増える様なデータ設計に対する効果が期待できます。

計測

新基盤と既存基盤のシナリオ毎の計測結果です。

計測環境

M1 Max 64G

Unity 2022.3

TestRunner 1.1.33

計測環境はPerformance Testing Extensionを使用し、下記のようにウォームアップをかけて100回ほど計測しています。

計測結果はマイクロ秒です。

Measure.Method(() =>
    {
        //計測内容
    })
    .WarmupCount(10)
    .MeasurementCount(100)
    .Run();

結果

保存シナリオ

データのキャッシュ数は1000固定です。

保存条件を指定しない保存

既存基盤のSaveAllによる保存と、新基盤SaveEntitiesの比較です。

新旧での最もよく使われる保存APIのユースケース比較になります。

 

 

新基盤の方が1.09~12.02倍ほど高パフォーマンスになっています。

既存基盤のSaveAllの場合、キャッシュを全て保存するため更新データ量に関わらず負荷がかかります。

新基盤だとリクエストの方法が改善されたため、キャッシュ量とデータの変更数の乖離があるケースでもパフォーマンスが発揮されるようになりました。

保存条件を指定した保存

既存基盤のPredicate<DTO>による保存と、新基盤SaveEntitiesの比較です。

PrimaryIndexやIDでのデータを指定した永続化のパフォーマンス比較になります。

 

 

新旧で同じような負荷の傾向が出ていますが、新基盤の方が1.2~2.8倍ほど高パフォーマンスになっています。

読み込みシナリオ

論理削除のないデータ読み込み

既存基盤のRecord2Cacheによる読み込みと、新基盤LoadEntitiesの比較です。

新旧での最もよく使われる読み込みAPIのユースケース比較になります。

 

 

件数の増加に伴い倍率は下がるものの、3.8~5.1倍のパフォーマンス向上になっています。

書き込みのAPIに比べ精度が向上しているのは、アロケーション抑制の効果が出ていそうです。

論理削除のありデータ読み込み

論理削除の効果を図るために、読み込みの計測1で使用したAPIの対象を論理削除を有効にしたテーブルにして計測しています。

 

 

新旧の比較で、5~63倍のパフォーマンス向上効果が出ています。

論理削除を行うレイヤーをネイティブ上に写したことで、sqliteの本領が発揮された効果が出ていそうです。