Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

近年はGo言語を用いたマイクロサービス開発がトレンドになっており、データベース周りの実装においてはGormがORMapperとして最も人気となっています。 Gorm - Github Ruby on RailsでいうActiveRecordのようにデファクトとも言えるORMapperであり、事前知識がなくともメソッドチェーンでクエリを作っていくことで、とても敷居が低くパワフルな機能を使うことができます。 一方でGithubのスター数の割には日本はもちろん海外を含めて実践にまつわる知見が不足しているので、実際にGormをプロダクトレベルで運用した経験からの注意点をまとめてみました。 (分かりやすい例としてRubyのActiveRecordとの比較を度々行っていますが、本来対立するもの同士ではないことを予め明示しておきます) SQLの知識は必要 少なくともGo言語を実戦投入しようとしている人で
では、今回もはじめていきましょう! DB(データベース)とは 今回からはSQLへの道題して、DB周りを勉強しSQLを学びましょうという内容でお送りします。DB、DBって当たり前のように会話が出てくるようになるので、業務で会話についていけるように勉強していきましょう。 DB(DataBase:データベース)とは、データの集まりです。以下のようなアイコンで表現されたりします。 データファイルが整理整頓されて格納されていて、DBMS(データベース管理システム)によって管理されています。 DBとDBMSをまとめてデータベースシステムという。 DBMSで管理されるデータとしては、大きく分けて以下の3つで構成されています。 データ・ファイル ログ・ファイル コントロール・ファイル 難しい言葉がたくさん出てきますが、最終的にはデータの集まりだと認識してくれればいいと思います。 データベースは基本的に以下
doublewrite とは? InnoDB が備わっている「データ二重書き込み」によるデータ保護機能。最初から有効になっている。1 この機能はトランザクションログとは別なので混同しないように。 MySQL Server での説明 https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html MariaDB Server での説明 https://mariadb.com/kb/en/library/xtradbinnodb-doublewrite-buffer/ Percona Server での説明 https://www.percona.com/doc/percona-server/5.5/performance/innodb_doublewrite_path.html SSD/HDD 混在環境のために d
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLのSELECT時にORDER BYを使用した時のソートの話 テーブルにINDEXが貼られている事が前提ですが、 例えば3テーブルを結合し、ソートをかける時などに、 全てのテーブルの結合を行った後にマスターとなるテーブルで並び替えると、 Using filesortが発生し、SELECTの実行が遅くなる場合があります。 回避方法として、カラムの表示用のマスターテーブルと、ソート用に使うマスターテーブル(別名付け)を用意し 用途を分けたSELECT文にするなどがあります。 #sample.sql SELECT tbl1.col1,
MySQL(RDBMS)でビッグデータを扱う ビッグデータというのは、概ね通常単一のPCでは扱いきれないデータ量のレコード数のデータのことを言います。 一般的にはDBなどに蓄積されているデータよりも蓄積はされても参照されることのないログファイルを指してビッグデータと呼ばれるようですが、通常参照されることのないデータをわざわざ検索することにそれほど価値や意味を見出すことには疑問が残ります。 また、ログファイルといえどもそうそう1億行にも達するようなデータというものはwebサービスを運営していたとしても早々お目にかかれるものでもありません。 なので、「ワイもビッグデータを扱ってみたい!」とふと思った少年少女そのほかおじさんなどに向けた「手軽に作れるビッグデータ」の方法を記述していこうかと思います。 本記事を試行するにあたって必要なシステム 本記事ではMySQL5.5を利用していますが、5.1以
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。
LambdaとRDSで爆死してみる 2019/12/05 Update こちらにRDS Proxyが発表されましたので、この投稿の内容はアンチパターンではなくなる可能性があります。 内容 LambdaとRDSは相性が悪い(というより、一緒に使うべきではない)というのはよく聞く話です。百聞は一見にしかずということで、爆死してみました 2019/07/19 Update こちらに続編を書きました 事前情報 なぜ相性が悪いかはこちらを。 http://keisuke69.hatenablog.jp/entry/2017/06/21/121501 https://qiita.com/teradonburi/items/86400ea82a65699672ad やってみる(概要) s3へのファイルPUTをトリガーにLambdaを起動させ。RDSのテーブルに「バケット名」と「ファイル名(key)」をI
何が起きたのか 作成していたアプリではサーバレス構成にてLambdaからRDS(MySQL)を呼び出していました。 リクエストが増えるとRDSのコネクション数が増加して すぐにDBコネクションエラーになってしまいました。 最大コネクションの上限値 結論から言うとLambdaとRDS(MySQL)は相性が良くないです。 理由はLambdaからRDSのDBコネクションを貼ると リクエスト単位でコネクションを張ってしまうため 仕組み上、同時接続に耐えられません (RDSのコネクション上限数が少ない) さらにVPC設定すると・・・ セキュリティのため、RDSをLambdaからのみアクセスさせるためには LambdaとRDSを両方とも VPC領域に置く必要があるのですが、Lambdaの起動が遅くなる場合があります。 これは、一定時間Lambdaがコールしない場合にスリープ状態になり、 起動する際にE
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 (追記:排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ) 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
技術系の記事色んなところで書いてたけど、ここにまとめることにした。昔書いてたやつは綺麗バッサリ消そうかと思ったんだけど、やたらView数が多いやつが何個かあったので気が向いた時に乗り換えしつつ(予定)今の知識で更新。 概要 以下の3つの不都合な読み込み現象がある。この意味に関しては後ほど解説。とりあえずはどれもRDBMSのACID特性のI(Isolation-隔離性)から外れたものと思ってくれればいい。 ダーティリード ファジーリード(非再現リード,ノンリピータブルリード) ファントムリード で、本題のトランザクション分離レベルは4つのレベルがある。 READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 下に行くほど高レベルで上に行くほど低レベル。 高レベルになればなるほど、先ほどの不都合な読み込み現象が発生しなくなる。が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 始めに:pandasの作者であるWes McKinneyさんがPythonのデータツール関連でとても興味深いblogを書かれているので、翻訳して日本のPyDataコミュニティに公開してもいいでしょうか、とお聞きしたところ、快諾をいただきましたので少しずつ訳して公開していこうと思っています。 翻訳元: Native Hadoop file system (HDFS) connectivity in Python 2017/1/3 これまで、Hadoop File SystemことHDFSとのやりとりするためのPythonライブラリが数多く
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 始めに:pandasの作者であるWes McKinneyさんがPythonのデータツール関連でとても興味深いblogを書かれているので、翻訳して日本のPyDataコミュニティに公開してもいいでしょうか、とお聞きしたところ、快諾をいただきましたので少しずつ訳して公開していこうと思っています。 2018/4/19(木) オープンソースソフトウェアへの投資は複雑なことです。私は、データサイエンスのツールにおけるイノベーションをミッションとする独立の開発ラボとしてUrsa Labs( https://ursalabs.org )を設立しました。
背景・動機 Pythonで時刻を扱うにはArrowが便利だが、依存しすぎると戻り値がarrowオブジェクトなのかdatetimeオブジェクトなのか統一が取れない事態に陥る可能性がある(あった)。 混ぜ過ぎ注意。 「よし、arrowから脱却しよう」と意気込んでみても、arrow.get()の壁が立ちはだかる。何でも引数に投げとけば、よしなに時刻オブジェクトに変換してくれる人をダメにする関数である。しかも副作用として、arrowオブジェクトを返す。arrow.get()を求めてarrowを使い、arrow.get()に依存しすぎて破滅する。 arrow.get(string)は、ISO 8601拡張形式1の文字列をarrowオブジェクトに変換してくれる。 これに習ってdatetimeオブジェクトへ変換する実装を行い、arrow.get()脱却のための代替関数を実装してみる。 ISO 8601
rake aborted! ActiveRecord::TransactionIsolationConflict: Transaction isolation conflict detected: Lock wait timeout exceeded; try restarting transaction 原因 MySQLでトランザクションがコミットされる前にプログラム何らかの原因で終了してしまい、ロックを握ったまま放置されたことが原因みたいです。 おそらくですがrails cのsandboxモードを終了しないままrakeタスクを走らせたからではないかと思います。 解決方法 1:mysqlにターミナルからログインmysql -u root -p 2:SHOW ENGINE INNODB STATUSで一覧が表示されるので"TRANSACTIONS"の項目を見る
(この記事は、「Elixir or Phoenix Advent Calendar 2017」の9日目です) fukuoka.exのメンバーにより連載されています。 昨日は、@piacere さんの「ExcelでElixirマスター2回目:「列の抽出」と「Web表示」でした 今日は、実際のプロダクト開発のお話2回目です。 はじめに Elixirで実際にプロダクト開発した経験からサンプルコードを交えて解説する本連載 基本となるデータベース排他制御の後編は、 Webサービスなどでより一般的な楽観的ロックです。 悲観的ロックと楽観的ロックに関する一般的な解説は例によってこちらの記事をお勧めします。 -> 排他制御(楽観ロック・悲観ロック)の基礎 本連載の前回記事はこちら |> ElixirでSI開発入門 #1 Ectoで悲観的ロック Ecto.Changeset.optimistic_lock(
MySQLコマンドでVARIABLESを変更する方法を調べました。 環境 MySQL5.7 MySQLのVARIABLESとは MySQLのVARIABLESとは以下のコマンドで表示されるシステム変数です。 mysql> SHOW VARIABLES like 'char%'; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8
データの読み込み速度を改善する上で、indexを張ることは非常に大切です。 ただし、張り方や張る箇所によっては、目に見えた改善が見られなかったり、むしろ速度が遅くなってしまうケースもあります。 そこで、indexへの理解を深めるべくindexの基礎的な内容を記します。 1.indexってなんぞや 特定のカラムからデータを取得する際に、テーブルの中の特定のカラムのデータを複製し検索が行いやすいようにしたものです。 例えば、あるユーザーをバイネームで検索したい!となった際に、Usersテーブルのnameカラムにインデックスを張ってないと、プログラムは、Userテーブルのnameカラムを上から順にみて、そのユーザーのデータを取得します。もし、これが1万人もしくはそれ以上の大量のデータを含むカラムだったらどうでしょう。すごく時間がかかりますね。 Usersテーブルのnameカラムにindexを張る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く