2年半を費やしたチャットワークのScala移行、もしやり直すならどうしますか？（後編） | HRナビ by リクルート
トレタCTOの増井雄一郎さんがチャットワークのScala化プロジェクトのお話を掘り起こすインタビューの後編です（前編はこちら：チャットワークのScala移行と大規模メッセージDB再構築、本当にできたんですね！）。ChatWork CTOの山本さんは2年半を費やしたプロジェクトを振り返り、「やっぱりScala化は必要だった」と語ります。 山本 2014年4月ぐらいにScala化を決断して、社内で勉強会が立ち上がりつつ、採用をかけていった感じです。2014年7月に加藤潤一（「日本Scalaユーザーズグループ」発起人のひとり）というScalaの優秀なエンジニアが入ってくれて。そこから設計をどうしよう、と始まって。しばらくは加藤と、もう1人ぐらいで設計をしていた。それが半年ぐらいあったのかな。 2015年ぐらいから実装を始めて。1年でチームメンバーも増えて、そのときは全部まるっと移そうと計画をたて
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
テレビ離れは、テレビの大きさのせいだと思う
またテレビを見てない自慢か、とか言われそうだけど、俺もめっきりテレビを見ない生活を送っている。で、俺がテレビを見なくなったきっかけは、テレビを大きいインチのものに買い換えたからだと思っている。 21インチのブラウン管を使っていた頃はテレビっ子を自認するほどよくテレビを見ていたんだけど、地デジ化のタイミングで液晶の32型に買い換えてから、なんとなくテレビを見る時間が減ったような気がしていた。そして3年前、そのテレビが壊れたのをきっかけに55型に買い換えたんだけど、そこでもう明らかにテレビを見る時間が激減した。 だって疲れるんだもん。画面いっぱいに明るく光るテレビは、朝起きた後や疲れて帰ってきた後に見るには刺激が強すぎる。大画面化と性能の向上がテレビをこれまでより疲れるものにしてしまった結果、テレビを見ない人が増えてきたんじゃないかと結構本気で思っている。「ながら見」が増えたっていうのも、無意
[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst
Percona MySQL Webinarsの発表(MYSQL開発でやってしまいがちな致命的なミスについて)のQAをご紹介します。 本発表はSQLアンチパターン著者のBill Karwinさんの発表です。 オリジナル: http://www.percona.com/resources/mysql-webinars/how-avoid-even-more-common-deadly-mysql-development-mistakes July 17, 2014 by Bill Karwin 水曜日に「MySQLを開発する上でよく起こる(そして致命的な)ミスをどのように回避するか」をPercona MySQL webinarsで発表した。お見逃の際は、ビデオとスライドを見る為に登録すればまだご覧にいただける。 参加いただいた皆様、そしてとりわけすばらしい質問をしていただきありがたく思っている
![[Q&A]MySQL開発でやってしまいがちな致命的ミス | Yakst](https://cdn-ak-scissors.b.st-hatena.com/image/square/cc3e540029d01309128ee24be8bc7c48c3fd73da/height=288;version=1;width=512/https%3A%2F%2Fyakst.com%2Fpost_icons%2Fpercona.png)
VOYAGE GROUP エンジニアブログ : MySQL InnoDBのinsertとlockの話
2015年03月08日17:06 カテゴリ MySQL InnoDBのinsertとlockの話 こんにちは。ECナビでアプリケーションエンジニアをやっている駒崎です。 今回はMySQLのInnoDBエンジンにおけるINSERTとロックの挙動について書きたいと思います。 はじめに アプリケーションでレコードの重複チェックをしてからINSERTをする。テーブルにはUNIQUE制約をかけてデータ不整合が起きないようにしている。という仕様はよくあるケースだと思います。 こういったケースでINSERTしたときにどのような仕組みが働いて重複データを防いでいるのだろう？アプリケーションで重複チェックをしてはいるけどMySQLではどんな挙動をしているんだろう？というのが気になったので調べました。 調べること INSERTした場合のロックの挙動 FOR UPDATE文で排他ロックをかけた場合のロックの挙動
MySQLでUPSERTとパーティショニングの両立方法が分からない
MySQLでUPSERTとパーティショニングを設定したいとします。運悪くパーティショニングをしたい列は一意にはなれないとします。 少し具体的にいうと、こんなテーブル。データが挿入された月毎でテーブルを分け、古いパーティションは後日捨てたい。timeがパーティショニングキーになります。一方システム要件として一意なデータを指定するにはidで十分なので、行の選択はidのみで指定されます。create table test(id int, datetime time default current_timestamp); MySQLでパーティショニングキーになる列には以下の要求事項があります。Partitioning Keys, Primary Keys, and Unique Keys (MySQL documentation) そのテーブルに設定されている全てのUnique key/Prima
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
巨大なサイズのテーブルに対するALTER TABLE実行時間の概算方法