ドリコム、MySQLデータベース環境強化のためFusion-io製品を採用 | gamebiz
Fusion-ioは、ドリコム<3793>がソーシャルゲームのMySQLデータベース環境強化のためFusion-io製品を採用したと発表した。 ドリコムは、「陰陽師～平安妖奇譚～」「ビックリマン」などの人気のソーシャルゲームのほか、モバイルコンテンツ、アドソリューションなど様々なオンラインサービスを提供している。急速に増加する利用者数や配信コンテンツの増加に対応するため、サービスの人気上昇にあわせてシステムの許容量や性能を拡張できる柔軟性が高いシステムを必要としていたという。 こうしたなか、ドリコムは、ハードディスク型SSDの採用することで対応しようとしていたが、書き込み寿命と性能の観点から信頼性要件を満たさないと判断し、Fusion-io製品を採用するに至ったとのこと。 Fusion-io ioDriveは、不揮発性メモリ（NANDフラッシュメモリ）をPCIeカード型に収めたストレージ製
Web/DB プログラミング徹底解説
*.keicode.com について 2005年頃から個人的にソフトウェアの技術記事をまとめて、 当サイトに情報を掲載開始。その後、さまざまなテーマ毎に初心者向けの入門サイトなどをまとめてきました。 主な姉妹サイトとしては 「Python 入門」「Android 入門」 「Java 入門」「基礎からの IoT 入門」などがあります。 最近は YouTube チャンネル「IT なるほど TV」も開設し、動画を用いた技術解説も行っていくつもりです。 (なかなか更新できていませんが、やめたわけではありませんので、ぜひチャンネル登録をよろしくお願いします！) 当サイトのウェブホスティングについて 当サイトはブルーホストという米系のウェブホスティングを利用して運用しています。 参考までに書くと 2018年3月の実績では keicode.com ドメインの関連サイト合わせて、 月間約 25万 PV で
Linux KVM上のWindows XPにおけるMySQLの性能 - SH2の日記
小ネタです。 Visual Studioの英語環境が必要になってLinux KVM上にWindows XPの環境を構築していたのですが、ついでなのでMySQLの性能測定をしてみました。 ホスト CPU：Intel Core i5-2400S (Quad-Core、2.50GHz、Max 3.30GHz) OS：Scientific Linux 6.2 64bit RDBMS：MySQL 5.5.21、innodb_buffer_pool_size=1024M ゲスト1 OS：Scientific Linux 6.2 64bit RDBMS：MySQL 5.5.21、innodb_buffer_pool_size=1024M ゲスト2 OS：Windows XP SP3 32bit DRIVER：Red Hat VirtIO Ethernet Adapter 51.63.103.2200 R
ジョインが70倍高速で、Memcached API搭載の「MySQL Cluster 7.2」正式版が登場
米オラクルは、オープンソースのデータベースとして普及しているMySQLをクラスタ化して利用するためのソフトウェア「MySQL Cluster 7.2」の正式版を公開しました。 GPLに準拠したオープンソース版と同時に、管理ツールを同梱し、24時間365日のサポートも行う商用版の「MySQL Cluster Carrier Grade Edition」も同時に公開しています。 ジョインが70倍高速に MySQL Cluster 7.2の最大のポイントは、ジョインが高速になったことです。これまでクラスタでのジョインは、ジョインするテーブルのデータがクラスタ内のノード間をいちいち飛び交っていたため、複雑なジョインになるほど遅いものになっていました。 MySQL Cluster 7.2で採用されたAdaptive Query Localization（あるいはPush Down Joins）と呼ば
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
つみきWeb
MySQLにおけるJOINのチューニングの定石