MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボtatamilab.jp
LAMP環境（Linux,Apache,MySQL）の障害対応で最初のアタリをつけるための秘伝のタレ - Qiita
この記事は animateLAB Advent Calendar 2015 19日目の記事です。 こんにちは。ポエムおじさんこと@kariaです。今年のAdvent Calendarもついに19日目となりました。後半に入り歴戦のエンジニアたちが次々と参戦してくれて、主催者としてはありがたい限りです。 今日はポエムデーのはずだったのですが、予定を変更して私の手元の秘伝のタレに少し味付けをして公開することにしました。ということで、LAMP環境で障害対応をすることになった時にどこからアタリを付けてどう調べていくか？という初動対応のお話をします。 そもそもLAMP環境とは OS:Linux Webサーバ:Apache データベース:MySQL アプリケーション：PHP/Perl/Python という組み合わせの、IT用語辞典に項目があるぐらいメジャーな環境構成のことをLAMPと呼びます。最近だとW
二千万レコードあるテーブルへのalterをサービスを止めずに流す | All Your Bugs Are Belong To Ass
※このエントリはMySQL Casual Advent Calendar 2015の5日目のエントリです。 openark-kit というものについて ここまで読んでわかった方は、この先を読む必要はありません。 openark-kitとは、mysqlの運用に便利なツールキットを14個あつめたソフトウェアパッケージです。 Shlomi Noachという方がPythonで開発しており、少なくとも2009年に発表されているようです。 2015-12-05時点での最新版は196.1となっており、.tar.gz および .deb で配布されております。 このエントリを書いた背景事情 そもそも僕自身、50を超えるクラスタ化されたmysqlノードと一緒に業務生活を送っております。 ところが、システムが非常に古くさい構成のため、合計レコード数が2億から3億程度ある垂直分割されたテーブルに対しALTERを投
そーだいなるらくがき帳: 2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた
第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。 内容は前に書いたエントリーの MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた を元に発表してきました。 と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。 実際の資料は下記のとおりです。 当日はビデオ撮影があったのでそのうち動画が上がると思います。 第32回 PostgreSQL 勉強会まとめ ~ togetter ~ 流石に２時間は疲れました。 内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。 前半はMySQLとPostgreSQLの方向性の違いをメインにしました。 後半はMySQLは僕が実際にハマった事などをメイ
MySQL 5.7の罠があなたを狙っている
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと
— そーだい＠初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ（関白宣言） まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物
kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 TL;DR kamipo traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。 これらの記事を読んだ人向けです。 ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々 Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。 +激しく同意+ さて、激しく同意したところで、kamipo traditionalでは倒せないMyISAMという名の化け物の話をしたいと思います。 kamipo tr
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
MySQL 互換のDB、Percona Server を使う理由 - Qiita
# Time: 120114 6:34:33 # User@Host: user[user] @ [10.10.10.10] # Thread_id: 28313080 Schema: mydb Last_errno: 0 Killed: 0 # Query_time: 0.588882 Lock_time: 0.000068 Rows_sent: 3 Rows_examined: 183839 Rows_affected: 0 Rows_read: 100 # Bytes_sent: 121 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 /+ Percona Server 独自のログ +/ # InnoDB_trx_id: 9903E4DB1 # QC_Hit: No Full_scan: No Full_join: No Tmp
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
CoolUtils File Converters
Our File Converters support over 1,400+ formats Let's find the file converter for your case. Find your converter We've been developing file converters since 2003 Our powerful engines convert extra large and complicated files We focus on batch processing with smart auto-settings Windows 2000/2003/Vista/7/8/10/11. GUI and command line. Get them all in 1 bundle! Coolutils Gold Bundle 30 apps for $99
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
MySQL InnoDBのIndex - Qiita
mysqlのInnoDBではclustered indexというのを採用していて、indexを貼る際に注意が必要ということでメモ 結論から言うと InnoDBでは... * Primary Key(以下PK)はできるかぎり設定して、できるかぎりauto_incrementの整数型が良い * PKの検索は速いが、secondary indexやcount(*)での検索は若干遅い * PKのupdateは避ける * 無闇やたらとsecondary indexを付けない * covering indexを狙えると速い かんたんに解説 図とか用意したかったけど気力がなかった。 indexの構造 InnoDBのインデックスではB-Treeというデータ構造が使われている。B-Treeの解説はwikipediaに任せる。 ツリー構造の一番下のリーフブロックに目的の行の物理的な位置が記録されている。ルート
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インデックス使えてる？じぇじぇじぇ！
MySQLで全文検索 - FULLTEXTインデックスの基礎知識｜blog｜たたみラボ
MySQLのバックアップ運用について色々
MySQL 5.1 Database Reference Guide :: 16.9 Known Limitations of MySQL Cluster
My sql 5.6&MySQL Cluster 7.3
データベース技術の羅針盤
