「ORMがトラブル起こすから嫌い」なんじゃなくて、「ORMが起こすトラブルが解決できないから嫌い」ってのがほんとのところじゃない?だったら解決方法を知ればいいんじゃね?というお話。「N+1問題」もろくに知らずにORMを批判せんでほしい。Read less
![O/Rマッパーによるトラブルを未然に防ぐ](https://cdn-ak-scissors.b.st-hatena.com/image/square/d8eb83a6a8acba6a90e3d4998e8f2cb3b9e66f1b/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fhowtopreventormtroubles-141220165645-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Webアプリケーションが実運用に耐えうるかどうかテストするためには, 大量のテストデータが必要になる。 規模にもよるが,場合によっては1テーブルあたり,数十万〜数百万レコードを要求されるだろう。 システムの負荷テストを実施する際には, (1): 「システムの内部に保有する負荷」つまり「DBの重さ」をまず作り出し, SQL実行性能を現実の運用状態に合わせてチューニングする。 (2): その後で,「システムの外部で発生する負荷」つまり同時アクセスをかける。これがサーバーの重さとなる。 そして各機能ページのパフォーマンスを測定する。 後者は,jmeterなどの便利なツールが存在する。 が,前者の「データ生成」に関しては,方法がそれほど確立していないように思える。 下記は,そういった大量のデータをうまく作るためのメモ。 (1) Excelでデータを作るべし (2) できれば Excelは 2007
Continuing from the last post (Three Rules for Database Work), I wanted to drill into some database versioning strategies that have worked well for me. Caveats and Considerations As a preface, let me say there are many different strategies that can work. I'm not presenting the one true way. My goal is to roll out database changes in a consistent, testable, reproducible manner. I'm used to working
Some developers love working with relational databases, and other developers can't stand to touch them. Either way - if your application uses a database, you have to treat the database with some respect. The database is as much a part of an application as the code and the models inside the software. Here are three rules I've learned to live by over the years of working with relational databases. 1
After considering the three rules and creating a baseline, an entire team can work with a database whose definition lives safely in a source control repository. The day will come, however, when the team needs to change the schema. Each change creates a new version of the database. In my plan, the baseline scripts created a schema change log to track these changes. By "change", I mean a change to a
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
DynamoDBを大雑把にさくっと日本語で理解したい方向けの説明。 (まだ書き途中) API Version 2012-08-10 を元に書いています。 印象と感想 管理が楽! 容量の増加を気にしなくていい! スループットやパフォーマンスの監視、管理が楽! ソーシャルゲームでは、一部のデータではすごく良さそう 検索や集計は弱いから、MySQLと併用 レイテンシが低いと書いてあるが、memcache の方が当然早い テーブル設計の理解と指定方法がちょっと面倒 料金体系の理解がちょっと面倒 DynamoDBとは何か? 大雑把に NoSQL, スキーマレスなAWS上のデータベースサービス スケールに関して何も気にしなくていい まずは、公式サイトを読むと概要はわかります。 Amazon DynamoDB (フルマネージドNo SQLデータベースサービス) | アマゾン ウェブ サービス(AWS 日
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く