タグ

DBに関するhirat2のブックマーク (7)

  • PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita

    PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」(ヴィテス)を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり

    PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita
  • JSONで疲弊したら試したい、アプリのデータをSQLiteで受け渡すという選択肢 - アニマネ開発日誌

    アニマネの内部ではアプリとサーバー間でどのようにデータを受け渡ししているかという話をしてみます。 一般的にアプリとサーバー間のデータの受け渡しだとJSONやXML、YAMLなどが多いと思います。 ここにSQLiteという選択肢を入れると色々幸せになれるという話です。 もはや何で今までJSONという固定観念が捨てられなかったのかというぐらい、個人的にはコロンブスの卵でした。 あまり事例はなさそうなので、ここで紹介してみます。 アニマネでの問題点 アニメアプリのアニマネでは主にアニメの番組表やニュースをサーバーから受け取って表示しています。 都道府県にもよりますが、一つの都道府県の1週間分の番組表(アニメだけ)をJSONにすると大体750KBぐらいになるんですね。 これを開発初期ではMessagePackに置き換えてました。 話の筋とは関係ないですが、JSONよりはMessagePackの方

    JSONで疲弊したら試したい、アプリのデータをSQLiteで受け渡すという選択肢 - アニマネ開発日誌
  • データベース設計徹底指南

    DBエンジニアのための技術勉強会(第3回)で使用した資料です。主にリレーショナルモデルと正規化について解説しています。リレーショナルモデルの限界について正しく認識してこそ、リレーショナルモデルを理解したと言えると思います。

    データベース設計徹底指南
  • 開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage

    なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス?クラウドってやつ?ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」

  • 1台から500台までのMySQL運用 MySQL Beginners

    Designing Opeation Oriented Web Applications / YAPC::Asia Tokyo 2011Masahiro Nagano

    1台から500台までのMySQL運用 MySQL Beginners
  • DBサーバーの負荷分散

    MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する

  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
  • 1