ネットゲームデータベース設計むかしばなし、あるいはとんでもないMMORPGの設計の話: 不倒城目次・記事一覧(1) レトロゲーム(185) 日記(773) 雑文(512) 書籍・漫画関連(57) 子育て・子どもたち観察(115) ゲームブック(12) フォルクローレ・ケーナ・演奏関連(86) FF14(40) レトロでもないゲーム(338) 始めたばっか(13) アナログゲームいろいろ(37) 人狼(48) ネットの話やブログ論(61) 三国志大戦(20) 無謀的世評(52) ゴーストライター(16) 大航海時代ONLINE(40) FF3(6) Civ4(18)
イミュータブルデータモデル(入門編)
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
DDLレベルの外部キー制約は不要 - 設計者の発言
テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注
明暗くっきり、オライリーと技術評論社
オライリー本の値段は高いが、質も高い。 自分の専門分野のオライリー本は必ず一冊は持っているのが当たり前だった。「サイ本」とか本にニックネームが付けられてそれで通用するぐらいに、とにかくオライリーの本はwebエンジニアにとって特別な本であった。そして時代は変わる。 オライリー自体は変わっていないが、時代が変わってしまった。 日本語で出版されるオライリー本の価値がゆっくりと毀損する間に、技術評論社の書籍の評価はうなぎ上りだ。 うん、ここ最近ではHadoop本は秀逸だった。トレンド技術を捉えてうえで数年は価値が落ちない網羅っぷり。 まだ枯れきっていない分野で日本語オライリー本が存在感を示した最後の例になるかもしれない。 乱立するKVS分野において日本語オライリー本は無力極まりなしで目も当てられない。 cassandraがようやく出たがversion0.8だ。外人さんが書いた原本を数ヶ月から一年か
『アメブロで行ったチューニングの紹介』
はじめまして。ブログを担当しているNと申します。 ブログ絡みの技術ネタをと依頼をされましたが、 ブログは枯れた技術を多く使っていて目新しいことはあまりないので、 以前行ったチューニング内容について紹介したいと思います。 2008年にブログの記事データについて行ったDB+アプリでのチューニングです。 ブログの記事データはMySQLのMaster-Slave構成で保持していて、 Slaveサーバーをスケールアウトしてブログの閲覧のリクエストを処理しています。 SlaveのMySQLのバージョンは4.1でEngineはMyISAMです。 記事テーブルには以下のようなデータを保持しています。 記事ID,ブログID,記事タイトル,日付,テーマ,公開区分,ステータス,･･･ チューニング前の記事テーブルには以下のようなINDEXを張っていました。Key_name Seq_in_index Collat
NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog
APサーバ層やWebフレームワークの進化によって、Webアプリケーションの開発は昔よりも大分楽になりました。 また、それらのコアとなる部分がオープンソースであるこでお、この恩恵を広く世の中の開発者が受けれるようになりました。 というわけで、最近ではRDBMSを中心とした永続化層のミドルウェアを見直して、よりスケーラブルなアプリケーションを 作れないかという動きが活発化しつつあります。その中心的なものになりうるのが、*NOSQLムーブメント*です。 NOSQLとは、字面のとおり*No SQL*ではないです。Noｔ Only SQLというのが正しい理解で、つまりはRDBMSを効果的に使うには RDBMSが向いている領域に専念させ、RDBMSが向いていない領域では別のプロダクトを使いましょう、ということです。 じゃあどんなプロダクトがあるの？というと、 Google BigTable Amazo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The SQL Injection Knowledge Base
ソーシャルゲームのためのデータベース設計