複数のフィールドを対象にユニークを付ける方法が全く分からなかったのですが、解決しましたので、メモを残しておきます。 やりたいこと やりたかったことは、 > db.collection.find() { "_id" : ObjectId("52721881fd0d0e71ffa8c31d"), "a" : 1, "b" : 1 } { "_id" : ObjectId("52721884fd0d0e71ffa8c31e"), "a" : 1, "b" : 2 } { "_id" : ObjectId("52721888fd0d0e71ffa8c31f"), "a" : 2, "b" : 1 } { "_id" : ObjectId("5272188bfd0d0e71ffa8c320"), "a" : 2, "b" : 2 } 上のようなフィールド "a" と "b" を持つコレクション co
![[MongoDB] 複数のフィールドにユニークインデックス(ユニーク制約)を付ける - 犬わらノート](https://cdn-ak-scissors.b.st-hatena.com/image/square/f21122b475c97fb3004aed60dd4cfcda8c591ae8/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F11696248318757692178%2F12921228815711612002%2F1397710152)
はじめに 今回は、MongoDBのシャーディングについて説明します。 シャーディングとは、データを複数のサーバに分散させる機能です。今回は、最初にシャーディングのメリットを説明し、続けてシャーディングの概要、さらにシャーディングに登場する重要キーワードを解説します。2ページ目以降ではシャーディングの構築手順について解説します。 シャーディングはMongoDBの機能の中でも重要かつ複雑なもののひとつです。手元の環境で構築することが、シャーディングを理解する大きな助けになりますので、本記事を参考にぜひ構築してみてください。 シャーディングのメリット シャーディングはMongoDBを水平スケーリングさせる機能で、以下のようなメリットをもたらします。 負荷分散による性能の向上 データを複数のサーバに分散させることにより、CPUやI/O負荷を分散させることが可能です。後述しますが、MongoDBはキ
Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
データサイエンスの聖地「Kaggle」は競技を超えて何をもたらすのか：データサイエンスの実務、キャリア、そして知の集積地としての全貌 5月22日 6:40
最近ランキングを実装する機会があって、どうやって実装しようかって話をしていたら、@attakei さんがRedisのsorted set使うと楽よ！って教えてくれたので、使ってみたら超楽ちんでした 2年位前に流行ったんですね、知らんかった。 リアルタイムランキング 旧時代の実装 私がゲーム制作していた時代は、ランキングというと一定時間ごとにバッチを回して、ランキングテーブルにソート済みのデータを流しこむという感じの実装でした。 おかげで、ユーザー参照用とバッチ作業用の二つのランキングテーブルと、ランキングテーブルを切り替えるためのスイッチングテーブルが必要になったり、バッチ流す必要があったり、とにかく面倒くさかったように覚えています リアルタイムなんて、いちいち全ユーザーの集計をしてデータをソートして順位を割り出すことになり、そんなことは無理な話でした Redis の sorted set
まずは繰り言だ！ データ構造って、一番大まかに言って、同種のデータ同士の関係と、異種のデータ同士の関係がある。人同士の関係、出来事同士の関係、等が前者だとすれば、人と性別の関係とか、人と所属サークルの関係、なんていうのが後者だ。 で、その一番ざっくりした関係に加えて、ある向きに1対1の関係なのか1対多の関係なのか、逆方向に1対1の関係なのか1対多の関係なのか、というのがあって、これによって、それぞれ3通りに分類される。4通りではないのは、「ある向きに1対1、逆向きに1対多」と「ある向きに1対多、逆向きに1対1」とは同値だからだね。 でもって、これらの関係を持ったデータ群に対して、CRUDという基本操作がある。ここまでで完結するなら、それはRedisで充分、ということだ。 さらに次のレベルは、集合演算、順序付け、値の加減算、値の乗除算やその他の演算、変更可能なものとそうでないもの、など、デー
今までsjisとかujisとかだったMySQLのデータベースをutf8mb4に変換しようとしていたときの話。キーの最大長という壁にぶつかったらしい。 http://d.hatena.ne.jp/takihiro/20080306/1219295452 MySQLのリファレンスを見ると、こんなことが書いてある。 プレフィックスは、最大1000バイト長(InnoDBテーブルに対しては767バイト)まで可能です。プレフィックスの最大長はバイトで評価されます。一方、CREATE TABLEステートメント内のプレフィックス長は文字数として解釈されます。プレフィックス長を、マルチバイトキャラクタセットを使用するカラムに対して指定するときこのことを考慮に入れなければいけません。 ここでは、直接的にはTEXT型やBLOB型について言っているのだが、VARCHAR型なども同様。 ということで、以下のようなC
tl;dr: MySQL 5.5.14以降だとinnodb_large_prefixオプションで3072バイトまでインデックス張れる MySQL(InnoDB)では、ひとつのカラムのキープレフィックスの最大値が767バイトという制限があるので、ついうっかりして Index column size too large. The maximum column size is 767 bytes. とか Specified key was too long; max key length is 767 bytes といったエラーを見たことある人は多いのではないかと思います。 よくあるケースだと、varchar(256)以上のutf8なカラムにインデックスを張ろうとするとこのエラーとご対面できます。 CREATE TABLE t (c varchar(256), index (c)); ERROR
本当はmysql側のエンコーディング変更すべきですが、アプリケーション側の応急処置として。 class Post < ActiveRecord::Base validate :no_4_bytes # 本文に4byte文字を使わないように def no_4_bytes if content.present? chars = content.each_char.select{|c| c.bytes.count >= 4} if chars.size > 0 errors.add(:content, "に絵文字(#{chars.join('')})は使用できません。") end end end end 文字列をeach_charで回して、バイト数が4以上ある文字を検出しています。 シンプルですが、文字量多い場合は大変。。 参考 Rubyで絵文字を削除するのは簡単ではなさそう - 動かざることバ
兼ねてからちょこちょこエラーが出ていたiOSの絵文字を含んだデータにようやく対応しましたので、その備忘録です。 Railsは3.2.11、MySQLは5.6.25です。 ちなみにMySQLは5.5以降からUTF8MB4に対応しています。 はじめに 文字コードをUTF8からUTF8MB4に変更をするにあたっていくつかの注意点があります。 コレーション問題 UTF8MB4のコレーションをデフォルトにしたままだと、寿司ビール問題("🍣"と"🍺"が同じものとして扱われる)と言われる問題に遭遇し、コレーションをUTF8MB4_UNICODE_520_CIにすると、ハハパパ問題("ハ"と"パ"が同じものとして扱われる)と言われる問題に遭遇します。 そのため、ハハパパ問題を気にしない場合(そんな国内サービスはあるのか！？)はUTF8MB4_UNICODE_520_CIを、気にする場合は、コードポイン
技術メモ帳 開発するうえで調べたこと、知ったことを備忘録としてメモメモ！ トップページページ一覧メンバー掲示板編集 × utf8_general_ciとutf8_unicode_ci 最終更新： clever_next 2012年07月27日(金) 13:50:19履歴 Tweet utf8_general_ciとutf8_unicode_ci utf8_general_ciとutf8_unicode_ciの違いは主に以下。 utf8_general_ci 英字の大文字小文字は区別しない。 全角半角は区別する。 utf8_unicode_ci 英字の大文字小文字は区別しない。 全角半角も区別しない。 さらに濁音、半濁音、ひらがな、カタカナも区別しない。 「は」で検索すると「は」「ば」「ぱ」「ハ」「バ」「パ」「ﾊ」がヒットする。 ちなみに全てを区別したい場合はutf8_binを使用すればよい
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
Klikbet77 - Situs Autentik Togel Asian & Prediksi Akurat Lewat Odms Club Klikbet77 adalah situs autentik togel Asian dengan prediksi akurat lewat ODMS Club. Menyajikan data real-time, analisis statistik mendalam, update pasaran lengkap, sistem aman, akses cepat, dan layanan profesional untuk pengalaman terpercaya.
今回はMySQLのストレージエンジンという重箱の隅をつつくようなネタをメモしておきます。 私はMySQLについてはよちよちレベルなので、込み入った内容には触れられません。初心者でも理解しやすい部分での違いを中心にまとめていこうと思います。 【復習】ストレージエンジンとは MySQLなどのデータベース管理システムが、データベースにデータを書き込んだり、読み込んだりするときに使われる基盤を「ストレージエンジン」と呼びます。初心者同士の会話の中で「MySQLを使ってデータを保存する」と表現することがありますが、実際にデータの保存処理を行っているのが、このストレージエンジンになります。MySQLの論理構造を図で載せます。 MySQLは「データベース管理システム」ですので、データベースを管理するために必要である様々な機能が搭載されています。その中の「データの読み書き」という部分を担当しているのがスト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
