私の頭はデータベースについて読んで爆発しています。どちらを選択するかは、特定のユースケースによって異なることを理解しています。だからここに私のものがあります：
- 私はウェブアプリを持っています。ゲーム。
- レベルベースで、前に進むことはできますが、戻ることはできません。ただし、プレイした各レベルから続行できます。たとえば、レベル2を終了してから、レベル3をプレイします。次に、Level3を再度起動し、Level3bとして保存します。これで、Level3とLevel3bから続行できます。
- 一度に再生できるレベルは1つだけです。
- サーバーには、「progress」、「choices」、「vars」の3つのデータ配列が格納されます。
- レベルをプレイしている間に変更され、最初から始めたいときに備えて冷蔵保管されます。
現在のMySQLのセットアップは次のとおりです。
- テーブル「saves」は、各セーブゲームのメタデータ、重要なのはそれが属するsaveIDとuserIDを保持します。
- 各データ配列には、対応するテーブルがあります。
プレーヤーが選択した場合、挿入は次のようになります。
INSERT INTO choices VALUES saveid=:saveid, choice=:choiceしたがって、アレイは次のことを行うことで再構築できます。
SELECT * FROM choices WHERE saveid=:saveid- レベルが終了すると、データ配列はシリアル化され、これ専用の3つの列を持つ「saves」テーブルに格納されることにより、コールドストレージに配置されます。
- それらの値は、他の3つのテーブルからクリアされます。
- プレーヤーがLevel3bからLevel4を開始すると、レベル4の新しいsaveIDを使用していても、シリアル化された配列が「saves」テーブルからフェッチされ、シリアル化されずにそれぞれのテーブルに戻されます。
これがある程度理解できることを願っています。私はそれを考えます：
- 読み取りよりも多くの書き込みがあります
- プレーヤーは自分のデータしか操作できないので、それを正しく理解していれば、一貫性は必要ありません。
- それぞれのデータ配列にデータを入力するには、各テーブルを個別に読み取る必要があるため、（m）JOINSを実行することはないと思います。
- ですから、リレーショナルDBのように多くを必要とするとは思いません。
インサートが小さいので、ほとんどの場合、DBにとっては本当に軽い負荷になるはずです。
データストレージは信頼できるものでなければなりません！私たちが定期的にセーブゲームを失い始めたら、プレイヤーが私たちに固執することはないと思います。ここではミッションクリティカルなものを扱っていないので、Redisのディスクへの毎秒のフラッシュで十分だと思います。ゲームがプレーヤーの最後の1つか2つのアクションを忘れた場合、それは悪くありません。セーブゲーム全体を忘れないでください。
私のユースケースのDBについてアドバイスしてもらえますか？MySQLを使い始めましたが、CouchDB、MongoDB、Riak、Cassandraについて読みました。データセットがRAMを超えると、Redisはひどく劣化するように見えるため、Redisは視野に入れていないと思います。しかし、私はすべてにオープンです。私はまた、MySQLを使い続けるかPostgreSQLに行くと言っている人にも門戸を開いています。
また、ストレージの設定方法についての批判も受け入れます。あなたが言うなら：カサンドラを選んで、このようにそれを保存してください、私は聞きます。
これは健全性チェックです。ゲームが公開される前にDBを変更できるのはこれが最後であり、最後にやりたいのは、スケーリングが悪いために3か月以内にDBを交換する必要があるためです。
そうそう、アプリはJavascriptで書かれており、サーバーとの通信はPHPを介して行われます。