InnoDBの透過的ページ圧縮(MySQL Server Blogより) | Yakst
InnoDBではMySQL 5.1のInnoDBプラグインからページ圧縮の機能があるが、新しく透過的なページの圧縮が実装された。機能上の制約、内部の実装、ベンチマーク結果などをご紹介する。ハードとファイルシステムを適切に選ぶことで最大300%の性能向上と旧来の圧縮と同等の圧縮効果が得られる可能性がある。 免責事項 この記事はSunny Bains氏によるMySQL Server Blogの記事「InnoDB Transparent Page Compression」(2015/8/18)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 鋭敏な読者の皆様はInnoDBはMySQL 5.1のInnoDBプラグインから既に圧縮機能をもっていることに気がついているだろう。我々は「ページ圧縮(Page Compression)」という用語はMySQL 5.7でリリースされる予定の
Column SQL Truncation脆弱性にご用心
前回のブログ記事「CMS四天王のバリデーション状況を調査したところ意外な結果になった」にて、JoomlaとMovableTypeは長大なログイン名を登録することにより、ログイン名の重複が起こり得ることを指摘したところ、facebookの私のウォールにて、Column SQL Truncation脆弱性の話題になりました。Column SQL Truncationは、2008年にWordPressの脆弱性として報告されたことがあります（参照、参照）。 本稿では、簡単なログイン機能のSQL呼び出し例を用いてColumn SQL Truncationを説明したいと思います。 認証用テーブル定義の説明 認証に用いる会員テーブルを下記とします。ご覧のように、ログイン名を示す列 username には一意制約がありません。（追記）一意制約はふつうあるだろと思われるでしょうが、CMS四天王の中で一意制約
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
MySQLのバックアップ運用について色々
その Pod 突然落ちても大丈夫ですか！？（OCHaCafe5 #5 実験！カオスエンジニアリング 発表資料）
Mroongaのラッパーモードからストレージモードに変えた理由 - CreateField Blog
前回は、全文検索Webサービスを作ったときにはまったことの第1回という記事を書きました。 今回は、Mroongaを使って全文検索Webサービスを作ったときにはまったことの第2回として、ラッパーモードからストレージモードに変えた理由について書きたいと思います。 なお、かなり長く、MySQL、Groongaについて前提知識がないと理解できない部分が多々含まれている可能性があります。 ラッパーモードとは 全文検索Mroongaストレージエンジンでは、全文検索するためにラッパーモードとストレージモードの2つのモードが用意されています。 (引用) ラッパーモードでは全文検索機能のみGroongaの機能を利用し、データストアはInnoDBなど既存のストレージエンジンを利用します。ラッパーモードを利用することにより、ストレージエンジンとして多くの利用実績のあるInnoDBに全文検索エンジンとして実績のあ
SQLでエスケープなんてしたら負けかなと思ってる。 - めもおきば
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか - 元RX-7乗りの適当な日々
とりとめもなく書いてみる。主にルーキー向けです。 サーバの運用とかやっていると、不定期ではあるが、たまにタイトルのようなディスク容量が逼迫する話題に直面します。 まぁ、それが起こるのは一旦良いとして、みんなこういう時、どうやって調べているのだろう？ とりあえず、僕がどうやってるか書いてみます。 何はともあれ現状確認 みんな大好き"df"コマンドです。細かい説明は省きますが、各パーティション・ファイルシステムごとにディスクの使用状況を確認。 # df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/sda3 130G 88G 36G 72% / /dev/sda1 494M 23M 447M 5% /boot tmpfs 12G 0 12G 0% /dev/shm正確とは言いませんが、だいたいどのパーティションにどのくらい容量が空いているかが確認できます。 ど
MySQL 5.6正式版が公開。オプティマイザやInnoDBの向上でさらに高速。クラッシュセーフなレプリケーションなど
MySQL 5.6正式版が公開。オプティマイザやInnoDBの向上でさらに高速。クラッシュセーフなレプリケーションなど 米オラクルは、MySQL 5.6の正式版が公開されたことを発表しました。MySQLはオープンソースのデータベースで、無料で利用可能なMySQL Community Server 5.6.10も公開されています。 MySQL 5.6のおもな新機能はプレスリリースやドキュメント「What's New in MySQL 5.6」で紹介されています。本記事ではこれらと、オープンソースカンファレンス 2012 Tokyoで公開された日本オラクル 山崎由章氏の資料「圧倒的な進化を続けるMySQLの最新機能」（PDF）の一部を引用しつつ主な機能を紹介します。 オプティマイザ、InnoDB、レプリケーション MySQL 5.6では、SQLを解析して実行するオプティマイザの改善と、データベ
Ruby標準添付ライブラリcsvのCSV.tableメソッドが最強な件について
─ 問題１ ─ data.csvファイルには、５人のプレイヤー（Alice, Bob, Jimmy, Kent, Ross）が二種類のゲーム（gameA, gameB）をプレイした結果が次のような形で格納されている。各ゲームの平均点を求めよ。 data.csv player,gameA,gameB Alice,84.0,79.5 Bob,20.0,56.5 Jimmy,80.0,31.0 Kent,90.5,15.5 Ross,68.0,33.0 data = File.read('data.csv') headers, *scores = data.lines.map { |line| line.chomp.split(',') } scores # => [["Alice", "84.0", "79.5"], ["Bob", "20.0", "56.5"], ["Jimmy", "80
グーグル、MySQL互換の「Google Cloud SQL」性能強化。最大でメモリ16GBへ拡張。Google Apps Scriptからも利用可能に
グーグル、MySQL互換の「Google Cloud SQL」性能強化。最大でメモリ16GBへ拡張。Google Apps Scriptからも利用可能に グーグルはGoogle App Engineで提供しているMySQL互換のデータベースサービス「Google Cloud SQL」の性能強化を明らかにしました。Google Developpers Blogにポストされたエントリ「Get started at no cost with a faster, larger Cloud SQL database」で次のように説明しています。 ストレージ容量が従来の10GBから最大100GBへ インスタンスのメモリ容量が従来の4GBから最大16GBとなり、読み込み速度が向上 非同期レプリケーションを選択可能にしたことで、書き込み速度が向上 欧州データセンターで提供開始 Google AppsのGo
生 DBI ユーザーのための DBI Cookbook (1) - Yet Another Hackadelic
ちょっと前まで DBI で非同期アクセスなエントリが各所で上がっていましたが皆さん如何お過ごしでしょうか？ さてと、、、歴史的な経緯とか歴史的な経緯とかで生 DBI 相当を使ってる方もそれなりにいるでしょう。奥さん、大事な事なんで二度言いましたよ！ DBI のインターフェースってまぁそんな使いやすい物じゃないんですが、工夫次第で出来る事もあります。 ちなみにサンプルデータベースとして、MySQL Documentation - Example Databases の world データベースを使っています。 fetchall_arrayref でデータ整形 まず以下のように使ってみます。 #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use DBI; use Perl6::Say; my $dbh =
KVS系NoSQLのまとめ（Hibari、Dynamo、Voldemort、Riak編）
序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基本概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 本連載は書籍『NOSQLの基礎知識』（リックテレコム刊、ISBN：978-4897978871）で解説されている内容から一部を抜粋し、本連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基本概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基本概念から、各プロダクトの特徴を理解できる内容になっています。 本連載では、この書籍の内容から、主要プロダクトを紹介している第5章を抜粋し、そのエッ
DBIx::TransactionManager の目的と、その使用法について - tokuhirom's blog
DBIx::TransactionManager の目的と、その使用法について おはようございます。 DBI では当たり前のように $dbh->do('BEGIN') と $dbh->do('COMMIT') をつかえばトランザクションがつかえるわけですが、なぜ DBIx::TransactionManager のようなものが必要になったのでしょうか。 それは勿論、DBI で直接 transaction をとりあつかうと問題が発生するケースが存在するからです。 トランザクションと RAII 一番おおきいのは、トランザクションが中途半端な状態になってしまうことを阻止することです。たとえば、以下のようなケースでは、おかしなことになってしまいます。 my $dbh = DBI->connect(...); for (@stuff) { eval { $dbh->do("BEGIN"); $dbh
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
基礎から理解するデータベースのしくみ（5）：ITpro
SQL文を実行する際のパフォーマンスに大きな影響を及ぼすものとして，もう一つ，インデックスがあります。インデックスについては，どう定義すべきかというデータベース設計上の問題と，インデックスを有効に使うためのSQL文をどう書くべきかというコーディング上の問題があります。 ここではテーブル設計上の問題を主に取り上げます。SQL文のコーディングについては囲み記事「SQL文を最速にする11のポイント」を参照してください。 インデックスは，テーブルの検索速度を向上させるためのものです。それぞれのSQL文に対して最適なインデックスを定義するのが理想的ですが，実際にはある程度限られたインデックスで，必要なパフォーマンス要件を満たすようにインデックスを定義する必要があります。加えて，どんなSQL文が実際に発行されるのかがあらかじめわかっていない場合は，適当な想定に基づいてインデックスを定義しておかなくては
かわいいリレーショナルデータベース作った - きしだのHatena
リレーショナルデータベースの勉強用に、最低限の機能をもったリレーショナルデータベースを作ってみました。 今回実装した最低限の機能というのは、射影(select)・選択(where)・結合(join)です。 テーブル作成 テーブル作成は次のようになります。 Table shohin = Table.create("shohin", new String[]{"shohin_id", "shohin_name", "kubun_id", "price"}); shohin.insert(1, "りんご", 1, 300) .insert(2, "みかん", 1, 130) .insert(3, "キャベツ", 2, 200) .insert(4, "わかめ", null, 250) .insert(5, "しいたけ", 3, 180); System.out.println(shohin);
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.stat.go.jp/data/chiri/gis/did.htm
ComputerworldとCIO Magazineは閉鎖しました
http://neta.ywcafe.net/000597.html