信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    MySQLの最大行サイズは65,535 バイトらしいです

    ## 試した環境* XAMPP v3.2.3  * mysql Ver 15.1 Distrib 10.1.38-MariaDB, for Win64 (AMD64)mariaDBなので厳密にはMySQLではないと思いますが無視しています。MySQLであると思っています。## 最大行サイズMySQLの最大行サイズは **65,535 バイト**らしいですテーブルの内部表現の最大行サイズは 65,535 バイトであり、ストレージエンジンがこれ以上のサイズの行をサポートできる場合でもこのサイズになります。BLOB または TEXT カラムはこのサイズに 9 から 12 バイトしか関与しないので、これらのカラムはこのサイズに含まれません。https://dev.mysql.com/doc/refman/5.6/ja/storage-requirements.html## 試す以下の状況だとエラーにはならない* varchar => 文字コードの1文字に使われるバイト数×長さ のバイトが確保される  * utf8 は1文字あたり3バイト使われる* MySQLの最大行サイズは **65,535 バイト*** int で**4バイト**確保される* のこり使えるバイト数 65535 - 4 = **65531バイトのはず*** utf8のvarcharで 65531 / 3 = 21843.666....  * 21843 文字は使えそうですが**実際にはエラーになりました**  * 21842 文字は大丈夫でした## 実際に使用されるデータ量を計算してみる### 前提として varchar は長さを格納するために 2バイト 使用します> 可変長カラムのストレージには長さバイトが含まれ、これには行サイズに対して評価されます。たとえば、VARCHAR(255) CHARACTER SET utf8 カラムは、値の長さを格納するために 2 バイトを使用するので、それぞれの値は最大 767 バイトを使用できます。https://dev.mysql.com/doc/refman/5.6/ja/column-count-limit.htmlvarcharだと**2バイト**は値の長さを格納するのに使うらしいです。### 踏まえて計算してみる* 21843 文字の場合、使用されるバイト数は 21843 * 3 + 2 = 65,531バイト  * int型の4バイトを足すと **65,535 バイト** になります。最大行サイズと一致しますが、65,535 バイトは駄目っていうことですかね。それとも別のデータを格納しているから駄目とか。* 21842 文字の場合、使用されるバイト数は 21842 * 3 + 2 = 65,528バイト  * int型の4バイトを足すと **65,532 バイト** になります。最大行サイズより 3バイト 少ないデータ量なので問題ないのは納得です。## 最大行サイズぴったりだとアウトなんですかね不明です。このブログ投稿のエディタには太字がないのか。

  • 画像:ブログサムネイル

    テクログ

    本当に面白いDBの世界【Neo4j】

    トイです。今日はDBの世界について語りたいと思います。データベースに興味がない又は好きじゃない方は意外といらっしゃるのではないかと思います(自分のことです、、)しかしそんな方々にご紹介したいDBがあります。その名もグラフデータベース:Neo4jです。すでにご存知の方もいらっしゃると思いますが、Neo4jはグラフデータベースと言う形で従来のリレーショナルデータベースとは全く違う構造になっています。グラフDBとはグラフDBとは一言で言うと、グラフ構造を備えたデータベースのことで、データの構造が従来のリレーショナルではなくネットワーク状になっている場合に、格納・検索の面で威力を発揮します。大袈裟に言えば関係性の数や深さに関係なく、待ち時間ゼロとリアルタイムパフォーマンスを保証してくれる。とまあ言葉でその性質を説明するには限界があるのでグラフDB、リレーショナルDBの違いはググってください、、、Neo4jの何がいいの??・とにかく自由な印象・場合によっては早かったり・DeskTopアプリが楽しすぎる(これ重要)下記画像のような形式で、関係性がつながっていたり親子関係があったりととにかく従来のリレーショナルとは違い思い通りに動きます!このDeskTopアプリはクエリ入力して表示するだけじゃなくデータに直接触れたりもできて楽しい!だから何なの?改めて今回お伝えしたいのは前述のデータベースに興味がない又は好きじゃない方がグラフDBなら好きになるのではないか!?といったお話です。私自身リレーショナルの形式ばった感じが嫌でDBやSQLに興味を持てずにいましたがグラフDBは全く形式に囚われなくて楽しく感じることができたのでおすすめさせていただきました!

  • 画像:ブログサムネイル

    テクログ

    ブロックチェーンくらいしか書くことがない

    皆さん初めまして。初めましてじゃない方も初めまして。しゃむぽんです。今回まじで何もネタ考えてなくてつい先週ブロックチェーンの講義受けたのくらいしか思いつかなかったのでこれ書きます。ご存知の方も多いかとは思いますが、とりあえずブロックチェーンとはなんぞやから書いていきますね。◆ブロックチェーンとは・データ管理技術の一つで仮想通貨の中核技術。・取引データをネットワーク上のコンピュータに分散して管理する分散型台帳技術。・通常のデータベースが一元管理を基本とするのに対し、台帳管理を基本とする。雑に説明するとネットワーク中にワラワラいるユーザー(一般ピーポー)が全員でデータを管理して台帳のようにデータを管理する方法らしいです。基本的には仮想通貨だったりを取り扱う金融系の企業で取り入れられることが多いみたいですね。誰もがデータを持ってて、誰もがそれを閲覧できるってすごいですよね。仕組みとしては以下のように各ブロックが連鎖的にデータの関連を持っていて、改竄が非常に難しい作りになっているみたいです。①隣のブロックが発行したハッシュ値②NONCE(ナンス)  ※ハッシュ値出すとき専用のデータっぽいです。詳しくはggってください。③取引データの要約の3つを用いてハッシュを作り、さらに隣へ渡してハッシュ値を作って…と連鎖させているそうです。なので改竄する場合、全てのデータを改竄する必要があるので事実上困難。というわけですね。各ユーザー(ブロック)が繋がっている(チェーン)からブロックチェーンなんですね。まんまですね。直近で活用することはなさそうですけどいつか活用したい技術ですね。発想がほんとすごい。ほいでは!

  • テクログ

    MySQLパーティショニング実践編

    MySQLパーティショニングの話をします!基本的なことや導入方法はグーグル先生で検索するといっぱい出てくるのでそちらで。☆パーティショニングが適切なパターンそもそも自分が考えるパーティショニングが適切であるパターンは、・int型のカラムでステータスを判定している(パターン分岐がそれほど多くない)・一週間毎に生成されるようなデータなどつまりあまりパターンが多くなく、indexが効きづらいものですね。イメージとしては、別テーブルに分けるという選択肢が出てくるものが適切だと思います。(パーティショニングってそういうことやってる訳ですし)☆実際に導入した時に気をつけたこと導入した事例の仕様は・一週間毎にユーザーに紐づいた計算されたレコードができる(200万くらい)・そのデータを一週間ごとで参照する▼レコードを入れる前にパーティショニングまず、パーティションの導入はテーブルを新規作成するときに行いました。テストで2ヶ月分、1000万レコード程度が存在する想定の状態でパーティショニングをして見ましたが、全然終わりませんでしたwなるべくサービスを止める選択を取りたくなかったため、事前にパーティショニングされたテーブルにinsertする形になりました▼PHP側の定期バッチで一週間毎にパーティションを追加今回の仕様的に定期的なパーティション追加が必要でした。と言っても簡単なSQLを流すだけです。▼そもそもパーティションを考えたテーブル構成にするパーティションの判定をするカラムがuniqueなindexに含まれている必要があります。とはいえ複合主キーとかに含めるだけでもオッケーです。逆にここで想定していたカラムが上手くユニークにできない場合、おそらくパーティションするのに向いていないです。長々と書きましたが、結構導入は簡単です!パーティションを辞めるときにデータが消えたりもしませんし。気になる方はやってみましょう!