2020/3/31 Google Cloud Data Platform Dayでの、山田、佐伯、白鳥の講演資料になります
これはなに? Webサービスを開発する際に使えるサービスのうち、無料枠があるものをまとめました。 自分でちょっとしたWebサービスを作ろうと思ったときに一銭も払いたくないなという気持ちがあるが、そもそもどの程度までちゃんとした構成が取れるんだっけというのをこれまでに100万回調べている気がするので自分用にまとめたメモです。 前提として、基本的にはAWSとGCPを対象に調べて、一部はそれ以外のサービスも追加で調べている、という感じです 最初に結論 「無料でWebサービスを提供する」というところだけに集中するならAWSよりはGCPのほうが良さそう(ハードルが低そう + できることが多そう) 無料枠だけで完結させるならherokuはSQLも使えるし視野に入れて良さそう ドメイン周りだけはどうにもならないので諦めてお金を払うか各クラウドサービスのドメインのまま使いましょう 無料の範囲内で最低限のW
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが(決してメインの仕事ではないですが)、その中でよく出くわす問題の1つに「ぐるぐるSQL」(もしくは「ぐるぐる系」)といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%:ぐるぐる SQL 20%:SQL 文の書き方が不適切 15%:索引がない or 不適切 15%:パーズが遅い 10%:データモデルがおかしい 10%:その他 (大昔は2番目 / 3番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…) ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
Prismaのドキュメントを読んでみたので、基本的なことをまとめていきます。 Primsaとは オープンソースのORM(Object-relational mapping) Node上のアプリケーションで直接DBに接続し、クエリー発行が可能 RDB周りの処理をより簡単に行えるようにし、開発者の生産性を向上させることを目的に開発 Next.jsアプリケーションでDBを扱う際に特に有用 Schemaファイルから型情報が生成され、クエリ結果がタイプセーフになる 対応状況 言語 JavaScript TypeScript Go (開発途中) データベース PostgreSQL MySQL SQLite SQL Server (開発途中) 主な構成要素 Prisma Model アプリケーションで使用するモデルを表現する。 モデル内でテーブルやカラムの定義を行う。 また、Prisma Clientで
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
目的別データベース選定 それぞれのDBの特徴や特性を軽く紹介していきます。 リレーショナル(Amazon Aurora) RDSに管理されるMySQL/PostgreSQL互換のRDBです。 RDSのMySQL/PostgreSQLと比較したAuroraのメリット 対障害性 並列クエリ Global Database パフォーマンス: MySQLの最大5倍, PostgreSQLの最大3倍高速 RDSでは特段理由がなければ、Auroraを選択することになるかと思います。 適しているユースケース ERP CRM 財務・銀行 SaaS(マルチテナントアプリケーション) 構成要素 DBCluster DBInstance プライマリインスタンス(Writer)(書き込み/読み込み) Auroraレプリカ(Reader) エンドポイント クラスターエンドポイント 読み取りエンドポイント カスタムエ
Gigazineさんでdrawthe.netを取り上げていたので紹介です。使い方はGigazineさんのほうが丁寧なので、気になる方はチェックしてみてください。(2020年12月1日、追記) drawthe.netとは cidrblock/drawthe.netは複雑なネットワーク図も「テキストで書いてブラウザ上でSVGレンダリングできるようにしよう」というコンセプトのもと開発されたツールです。下図のように複雑な構成図も精度高く描くことができます。 拡大してみると情報量が多いこと、またいかに整っているかがわかると思います。 デモサイトも用意されているので、サクッと試したい場合はコチラが便利です。コードはGitHubで公開されています。更新が2017年末で止まってしまっているのが玉に瑕ですが、十分な性能を発揮してくれます。 drawthe.netを使いたい理由 美しい構成図といえばInter
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが1時間越えに化けることもザラにあるので原
Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
Intro DBML (Database Markup Language) is an open-source DSL language designed to define and document database schemas and structures. It is designed to be simple, consistent and highly-readable. It also comes with command-line tool and open-source module to help you convert between DBML and SQL. Table users { id integer username varchar role varchar created_at timestamp } Table posts { id integer
これまでのDocker Compose入門は、Docker Compoesの紹介に始まり(第1回)、簡単なウェブサーバを起動する方法(第2回)、ネットワークの理解を深める方法(第3回)でした。今回は連載のまとめとして、ネットワークとボリュームの活用によって、1つのサーバもしくはPC上に複数のアプリケーション環境を動かす方法をみていきいましょう。 Docker Composeはプロジェクトごとにネットワークを持つ 前回はDockerのネットワークの扱いを学びました。Dockerコンテナを実行すると、そのコンテナ内のプロセスは、デフォルトで「bridge」という名称の仮想的な内部ネットワークを通して通信を行います。またホスト上のブリッジ(仮想的なネットワーク・スイッチ)を経由して、Dockerが作成する他の内部ネットワークや、ホスト側のインターフェースを通して、インターネットなどの外部ネットワ
[2021/04/28追記] 新しく提案仕様が出たので、新しく記事を書きました asnokaze.hatenablog.com 先日IETFに提出された「UUID Format Update」という提案仕様の中でUUID version 6のフォーマットが言及されている。このDraftはUUIDを定義しているRFC4122を更新するものです。 ただ、まだIndividual Draftのdraft 00であり、この提案自体どうなるかは全くわからない点に注意が必要。 なお、UUIDv6自体はこの提案を行っているBrad G. Peabody氏が以前から取り組んでいた模様で、4年以上まえから案は存在していたようだ(URL)。またそのタイミングでサンプル実装も公開している。 UUIDv6 この提案仕様の中で、UUIDをデータベースのプライマリキーとして使用する際の課題をあげている。時系列順に並び
Oracle データベースの内部構造に着目して、さらなるチューニングを行うために必要な基礎知識をまとめた資料です。
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 パフォーマンス勉強会OracleデータベースMySQLInnoDB こんにちは、羽山です。今回はOracleデータベースのチューニングで少し踏み込んだ内容です。途中で比較対象としてMySQLも登場します。 日頃からSQLチューニングの機会があってそれなりに得意としているのに、それでもなぜかパフォーマンスがでないSQLに悩んだ経験はありませんか? 謎の遅い現象は特に大規模データベースになってくると発生しがちなのですが、速い場合も遅い場合も必ず理由があります。そこで本記事ではデータベースのチューニングにおいて意外と見落とされがちなローレベルな部分に着目して、さらに一歩上のパフォーマンスチューニングに必要な知識を解説します。 この記事を書くきっかけとなったのは私た
Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという
DA事業本部の春田です。 AWS Summit Online絶賛開催中!ということで、本記事では「CUS-65: ペイメントプラットフォームにおける AWS の活用」の内容についてまとめていきます。 セッション情報 楽天株式会社 グローバルテクノロジー統括部 國谷 彩 氏 AWS上でのPayment Platformシステムの歴史についてお伝えします。AWSへ移行してからこれまでの課題と解決方法について説明します。 ※セッション動画は以下リンク アジェンダ 楽天グループについて ペイメントプラットフォームについて ペイメントプラットフォームにおけるアマゾンウェブサービス(AWS)の歴史 楽天グループについて Eコマースのサービス「楽天市場」をはじめ、Fintech事業やエンターテイメント事業まで、さまざまなビジネスを展開 各サービスが楽天共通IDで繋がることで、サービスを跨いだグループシナ
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー(特に新規参加者)がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか? 今回は、そんな方々にこそ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く