YAPC::Asia Tokyo2015 で発表させていただきました。 主にMySQLのチューニングの話です。 http://yapcasia.org/2015/talk/show/0af26fe4-0b7b-11e5-a29c-67dc7d574c3a
「ビッグデータプロジェクトを始めることになった」ら、何をすればいいのか──。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点/ビジネス視点の両面から具体的に理解し、実践していくための導入指南です。 前回は、ビッグデータおよびビッグデータ基盤の概要について、そしてその第一歩として「小さくても、確実な成功を収めることが重要である」と説明しました。今回はこの第一歩を踏み出すに当たって必要となる、「PoC」(Proof of Concept:導入前実機検証)を、具体的にどう進めていくかを説明します。なお前回も触れましたが、本連載におけるビッグデータ基盤の説明には、業界標準であるオープンソースの分散処理基盤「Apache Hadoop(以下、Hadoop)」を用いることとします。 PoCとは、新規システムの本番導入に先駆けて、小規模なシステムを試験的に導入し、ビジネスにおける有効性を調査
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
はじめに このページでは、MySQL InnoDBの介在する大規模サービスにおいて考慮すべきインサート性能の問題と、ID生成戦略として、ゆるやかに増える64bit(8byte)の整数値を使う方法と、UUIDを問題を回避して用いる方法について説明します。 100万行以上でおこるインサート性能問題 MySQL InnoDBで大規模サービスを設計/運用している方なら周知の事実かもしれませんが、MySQLのInnoDBには、int(4byte)よりも大きなサイズのカラムにインデックスが貼られたテーブルに、カーディナリティの高いランダムなデータを入れてインサートをしようとすると100万行以上で急激にインサート性能が落ちるという問題があります。 MySQL InnoDB Primary Key Choice: GUID/UUID vs Integer Insert Performance 、というサイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く