ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城目次・記事一覧(1) レトロゲーム(185) 日記(767) 雑文(511) 書籍・漫画関連(55) 子育て・子どもたち観察(115) ゲームブック(12) フォルクローレ・ケーナ・演奏関連(86) FF14(40) レトロでもないゲーム(334) 始めたばっか(13) アナログゲームいろいろ(37) 人狼(48) ネットの話やブログ論(61) 三国志大戦(20) 無謀的世評(52) ゴーストライター(16) 大航海時代ONLINE(38) FF3(6) Civ4(18)
論理削除がデータを汚している - jfluteの日記
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
Fiddlerを使って艦これのバトルJSONを解析（敷波復活編） | Moonmile Solutions Blog
ちょっと気になるツイートを見かけたのでそれ絡みで。 https://twitter.com/Sikushima/status/374120078976880640 「艦これ」から、ソーシャル系のサーバ構成を考える – SQLer 生島勘富 の日記 http://d.hatena.ne.jp/Sikushima/20130901/1378021345 艦これサーバーのトラブル云々には同意しかねるのですが、素直にMySQLのSQLで組んだほうが、下手にデータ構造を考えてAPIを作ったりするよりは断然早い、ところの同感です。更新系は兎も角、参照関係は断然RDBMSは早く作られているので、下手のO/RマッピングやるよりもSQL直で書いたほうが手早くかつ実行スピードがすばやくできます。ええ、SQL文を書ければ、の前提なのですが。 で、艦これの同時セッション絡みの部分、いくらか艦これをやっていて、いく
今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ
あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆
既存のMySQLサーバからRDSインスタンスへの移行をテストする - サーバーワークスエンジニアブログ
こんにちはインフラエンジニアの柳瀬です。 今回の内容は少しエントリー向けの内容になるかと思いますが、既存環境のMySQLからRDSへ移行するテストについて記載したいと思います。 オンプレミスの環境でMySQLを使用されている方は多くいらっしゃるかと思いますが、そういった方がRDSへ移行される事を検討した際に何かしらの参考になりましたら幸いです。 今回はEC2上のCentOSにMySQLをインストールして10GBのテストデータを投入しました。 こちらのデータをRDSに移行したいと思います。 ※RDSデータベースの作成方法はこちらのリンクをご覧頂けると分かりやすいと思います。 まず考える事がmysqldumpコマンドの--all-databasesオプションを使用して一気に移行する事ですね！ これを実施すると以下のようになります。 # mysqldump -u root -x --all-da
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
第3回 MongoDB勉強会 ダイジェスト
「第3回 MongoDB 勉強会 in Tokyo」 : ATND 先週土曜日（2011年5月14日）にフューチャーアーキテクトさんのセミナールームにて行われたMongoDBの勉強会に行ってきました。 MongoDBの仕様・機能などの体系的な話からチューニングの話、開発に利用する話、プロダクションとして運用している話と、バランスよくまとまっていてとても勉強になりました。 RDBとの違いや特有の挙動をきちんと把握して利用すれば、十分プロダクションで利用出来るというビジョンが見えました。 詳細は各発表者の方のスライドを見るとわかると思いますが、当日会場でメモしたものでダイジェスト的にまとめました。 MongoDB勉強会は毎月開催（予定）しているそうなので、興味を持たれた方は是非参加して見てください。 MongoDBコミュニティー：MongoDB JP | Google グループ 【発表1】Mo
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今まで見た中で最もひどいDBのテーブル設計は？ | スラド デベロッパー