MySQL :: MySQL 8.0 リファレンスマニュアル :: 24.3.1 RANGE および LIST パーティションの管理
レンジパーティションとリストパーティションの追加および削除は同様の方法で処理されるため、このセクションでは両方のパーティション化の管理について説明します。 ハッシュまたはキーによってパーティション化されたテーブルの管理については、セクション24.3.2「HASH および KEY パーティションの管理」を参照してください。 RANGE または LIST によってパーティション化されたテーブルからパーティションを削除するには、DROP PARTITION オプションを指定した ALTER TABLE ステートメントを使用します。 レンジでパーティション化され、次の CREATE TABLE および INSERT ステートメントを使用して 10 個のレコードが移入されるテーブルを作成したとします: mysql> CREATE TABLE tr (id INT, name VARCHAR(50),
Mroongaを使って全文検索Webサービスを作ったときにはまったこと(第1回) - CreateField Blog
前回のエントリに書いたように、１年半ほどをかけて、独学で特許の全文検索サービスを開発しました。 PatentField | 無料特許検索 最初は、MySQLを使ったこともない状態だったこともあり、かなり紆余曲折しました。Groonga開発チームの懇切な対応もあって、専用サーバ1台で最大で1千万レコード超、400GiB以上のサイズのテキストデータを高速に検索できるようになりました。 今後、何回かにわけて、Mroonga(Groonga)を使って全文検索Webサービスを作ったときにはまったこと、学んだことを全て書き出したいと思います。 全文検索エンジンMroongaとは？ Mroongaは全文検索エンジンであるGroongaをベースとしたMySQL用のストレージエンジンです。Mroongaは、MySQLが使える人であれば、簡単に高速な全文検索機能が使えます。MariaDB10.0系にもバンドル
データベースとSQLの業務スキルレベル 判別表 （５段階） - 主に言語とシステム開発に関して
スキルチェックの目次へ リレーショナル・データベースを利用したシステム開発の，簡易スキルチェックのための調査表。印刷用。 データベース・エンジニアのレベルを測定する。 レベルは，０から４までの５段階。 （０） 非エンジニア （１） 初学者（入門書を学習してゆく段階） （２） ノーマル（基礎的な知識があり，ある程度の動くものを作れるようになった段階） （３） 中級者（開発プロジェクトで１人月としてカウントできる水準） （４） 上級者（メインPG/メンターとして，主設計を任せられる水準） Webアプリのプロジェクト開始時に作業振り分けをするにあたって，新規メンバ全員にこれを渡して回答してもらうという用途を想定。 なお，開発上のスキルをチェックする事が主眼なので，DBAとしての技量はあまり考慮しない。 下記で「自分に当てはまる項目が最も多いレベルが，自分の属するレベルである」とする。 ※ただし，
第1回 全文検索エンジンgroongaを紹介します！ | gihyo.jp
今回から始まった隔週連載groongaでは、groongaを使いたくなるような情報を隔週毎にお届けします。 groongaとはGitHubで公開されているオープンソースの全文検索エンジンです。大量にある文書の中から目的のキーワードを持つ文書を高速に見つけることができます。 groongaのロゴ©groongaプロジェクト 第1回目である今回は、この連載についてとgroongaの特徴を紹介します。 この連載について まず、この連載について説明します。 この連載は「読者の皆さんがgroongaを使いたくなる！」ことを目指しています。そのために、次の2点の情報を次回から交互にお届けします。 groongaの利用事例の紹介 利用事例に関連した役立つ情報の紹介 利用事例を紹介することで、「あそこでも使っているなら自分も使ってみようかなぁ」とか「こんな使い方をしているなら自分も使ってみようかなぁ」と
MySQLのクエリ集計手法いろいろ | Ore no homepage
Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないww オジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。 2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。 innotopで集計 実は以前、Qiitaに書いたので↓をば。。。 http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa 流れるクエリ、ロックの状況、トランザクション(show engine innodb s
ゲーム・サービス評価対応で定評のあるデバッグ代行会社10選
「令和6年能登半島地震」とそれにともなう津波により、亡くなられた方に心よりお悔やみ申し上げるとともに、被災された皆様に心よりお見舞い申し上げます。
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
パフォーマンス比較 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標準で
SQLアンチパターン - ナイーブツリー
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。
マスタテーブルの履歴管理: mitのぺーじ
Oracleというかテーブル設計の話。 マスタテーブルを作る時に、時間によって値が更新されるマスタデータがある。 そういった場合にどうテーブルを設計しているか、今までの見たことあるパターンを考えてみた。 1.現在値のみ保持 何も考えなければこれになる。 値が変わった場合は参照している過去データも新しい値になってしまう。 つまり、履歴管理できない。 なので、「過去データについては当時のマスタ情報で利用したい」という要望に応えられない。 どうしてもという場合は、既存のデータを残したまま別のレコードを追加し、 そちらで新しい値を入れてそっちを使ってもらう。 同じマスタが別のデータとして存在してしまい、ユーザーがどっちかを選ぶとか片方を削除するとか、 テーブル構造がシンプルだけど運用が複雑になってしまうという非常にマズイパターン。 2.現在値＋過去の履歴データのテーブル このパターンは1.のテーブ
履歴を管理するテーブル構造について - OKWAVE
>例えば、履歴管理の為の販売履歴テーブルに商品コードの外部キーが存在するとします。 >この場合商品テーブルを現行テーブルと履歴管理用に分割した方がよいのでしょうか？ このあたりは、要件次第だと思います。まず、日常的に読み書きするデータベース（一般にOLT用）と、履歴を管理し分析などに使うデータベース（DWH用）のデータベースを、1つのデータベースとするか、はたまた別のデータベースとするかが、ポイントになると思います。同じデータベースなら、できるだけマスターとなるテーブルは共通のほうが使いやすいでしょうし、別ならば別にしなければどうしようもありません。 >その場合の履歴用商品テーブルについてですが、販売履歴のプライマリーキーはシリアルで、商品テーブルのプライマリーキーは商品コードであったとき、商品コードが永続的に一意でない、流動的に変化するような会社の場合は、商品履歴テーブルは、連番を新たに
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 のブログ
私は、ソーシャル系とは縁遠い仕事ばっかりしているのですが、そういう依頼も若干増えてきたので話題になっている「艦これ」をお盆にやってみた。 残念ながら、「艦これ」の魅力は分からなかった。しかし、ミッションを用意されると、「クリアーしたい」という欲求から意地になるのは、何となく理解できました。それより、同時に始めた「Clash of Clans」には嵌まりました。気になっていた「ゲームの中に如何に自然に課金システムを取り入れるか」という課題についても、個人的には「Clash of Clans」の方が上手に解決しているように思います。 「艦これ」は、同時アクセスが10万以上あって、何度かシステム障害があったとのこと（そりゃあるでしょうが……）。私の興味の方向性は、課金システムであったり、システム構成にあるので、「艦これ」のシステム障害の方が強い興味の対象になります（苦笑） というわけで、「ソーシ
東大/日立の「超高速データベースエンジン」、フラッシュ環境で従来比100倍の処理性能を達成
東京大学と日立製作所は2013年8月6日、共同開発中の「超高速データベースエンジン」が、フラッシュストレージ環境において、従来型のデータベースエンジン比で約100倍のデータ検索処理性能を達成したと発表した。 HDD構成のストレージ環境で実績を上げてきた超高速データベースエンジンが、フラッシュストレージにも有効であることが確認できたという。性能検証には、日立のストレージ「Hitachi Unified Storage VM」に、同社のフラッシュモジュール「Hitachi Accelerated Flash（HAF）」を搭載して用いた。 超高速データベースエンジンの共同開発は、内閣府最先端研究開発支援プログラム「超巨大データベース時代に向けた最高速データベースエンジンの開発と当該エンジンを核とする戦略的社会サービスの実証・評価」（中心研究者：喜連川優 東大教授/国立情報学研究所所長、実施期間：
ドキュメント指向のNoSQLデータベース（CouchDB、MongoDB）編
書籍紹介 本連載は下記書籍から第5章を基に、＠IT向けに再構成して掲載しています。 目次 序 章 ビッグデータの時代 第1章 NOSQLとは何か? 第2章 NOSQLのデータモデル 第3章 アーキテクチャの基本概念と技術 第4章 HadoopはNOSQL? 第5章 主なNOSQLデータベース製品 第6章 NOSQLデータベースの選択基準 第7章 NOSQLを使うビジネス 本連載は書籍『NOSQLの基礎知識』（リックテレコム刊、ISBN：978-4897978871）で解説されている内容から一部を抜粋し、本連載向けに一部再編集して掲載したものです。 書籍では、一般にNoSQLと呼ばれている各種データベース技術について、基本概念から主要なプロダクトの特性、ベンチマーク結果までを紹介しています。データモデルやアーキテクチャの違いといった基本概念から、各プロダクトの特徴を理解できる内容になっていま
すべての学問分野をネットで無料で探すための210個のリソースまとめー新入生におくる探し方その２
引き続き、新入生向けを口実にする。 前回はオフラインでの探し方の話をしたので、今回はオンラインでの（ネットをつかった）探しものについて。 ごくごく基礎的な話は、 googleで賢く探すために最低知っておくべき５つのこと 読書猿Classic: between / beyond readers あたりにまかせて、今回は足がかりになりそうなものをつくってみた。 こうしたリンク集は、検索エンジンが今ほど便利でなかった／ソーシャル・ブックマークが存在しなかった時代にはよくつくられたが、ネットではどれだけ有益なサイトでもあっという間に（つまり本屋や古本屋よりもはやく）消えてしまったりするので、大規模なリンク集ほどメンテナンスが大変で、あまり望まれなくなった。 自分でも、なんだか久しぶりにつくってみた気がするが、個人的にはネットの定点観測的な意味合いがある。 つまり、つくってみることで、ネットの情報の
「SQL アンチパターン」は色んな戦争の火種になりそう - yoshiori.github.io
監訳の一人である @t_wada に献本頂きました。 ありがとうございます！！！ でだ、いきなりだけどコレ、タイトルで損してると思うんだよね…… だって、SQL のアンチパターンてタイトルだったら、 join した結果の方で where で絞るよりも on 句で先に絞れ 的なのが書いてあると思うじゃん！！ 問い合わせ言語の事だと思うじゃん！！！ 違った…… ほとんど書いてあるのは DB 設計についてだった…… まぁ、副題は「Avoiding the Pitfalls of Database Programming」のだし、まぁいいか。 んで、読んでみた感想とか もうね、何年か DB 絡んだ開発したことのある人なら（・∀・）ﾆﾔﾆﾔ出来ると思う。 「”マルチカラムアトリビュート”とか 10 年前に通ったわー」 とか 「あーはいはい”インデックスショットガン”乙」 みたいな。 Explain
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベース設計徹底指南
Jepsen: PostgreSQL, Redis, MongDB および Riak の分割耐性をテストする
