RDBとFirebaseのDB両方使ったっていいじゃない - Crieit
今年Firebaseを使い始めてからちょこちょこ自分の中で議題に上がるのが、RDBとFirebaseのデータベース（Firestore、Realtime Database）のどちらが使い勝手良いのか、ということ。ただ、そもそもどちらかを選ばなきゃいけないというわけではなく、適宜両方使えばいいということが分かったのでそれについての雑記。 そもそもまず、なぜ悩むところがあったのか。 Firebaseのデータベースのデメリット 一番大きいのはやはりリレーショナルでないことと、クエリが弱いということ。集計ができなかったり、欲しいデータがすぐ取れなかったりする。 RDBのデメリット とりあえずRDBにしておけば何でもできるというのはあるが、デメリットとしてはやはりサーバーもしくはお金が必要になってくるということ。サーバー内に入れると管理やスペックの調整などが気になるし、別途RDSやCloud SQL
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
嵐のコンサートがあるとダブルブッキングしてしまうホテル予約システムを作ってみた
今年の5月1日に、仙台市内のホテルで多重予約のトラブルが発生したと報道されています。 部屋数２０３室の仙台市のビジネスホテルで、９月１８～２３日の宿泊予約を数千件受け付けるトラブルがあった。アイドルグループ「嵐」のライブが宮城県内で開催される期間だった。インターネットでの申し込みが殺到し、システム障害が起きたとみられるという。 トラブルがあったのは、仙台市泉区の「ホテルルートイン仙台泉インター」。ホテルなどによると、９月１９、２０、２２、２３日に宮城スタジアム（宮城県利府町）で嵐がライブを開くことが明らかになった後の５月１日午前５時ごろ、ネットを使った予約申し込みが殺到していることに気づいたという。 ２０３室のホテルなのに「予約」数千件 嵐公演で殺到か：朝日新聞デジタル より引用 5月1日の朝に何があったのか調べてみると、この日の早朝にテレビや新聞でコンサートの情報が流れたようですね。 お
第38回 DBIx::Class：拡張性の高さが売りではありますが | gihyo.jp
国内では微妙な立ち位置に ずいぶん間が空いてしまいましたが、今回はデータベース話の3回目として、DBICことDBIx::Classについてまとめてみます。DBICは、海外ではMooseやCatalystと並ぶモダンPerl界の三種の神器のひとつとしていまも広く宣伝されていますが、国内では、当初こそClass::DBIからの乗り換えを強力に推進する流れが見られたものの、最近ではあまり名前を聞くこともなくなり、むしろDBICからの脱却が潮流になっているかの印象を受けることさえあります。いったい何がどうなっているのか、例によって歴史を追いかけながら見ていきましょう。 もともとはオブジェクトを永続化するためのもの DBICの立ち位置を理解するには、まずはその先駆けとなったClass::DBIがどういうものであったかを理解しておく必要があります。 連載第36回でも紹介したように、マイケル・シュワーン
第3回 DBIx::Classでデータベース操作（3） | gihyo.jp
Resultクラスの拡張 Resultクラス、ResultSetクラスは自分の好みに合わせて拡張できます。 カラムのinflate/deflate $tweet->created_dateのようなつぶやきの日付を取りたい場合、カラムの値そのままではなくDateTimeオブジェクトを返してくれたらうれしいと思います。その機能を実現するのがカラムのinflate/deflate機能です。inflate（膨らませる）は文字どおりカラムのデータをPerlオブジェクトに変換する機能で、deflate（収縮させる）はPerlオブジェクトをカラムデータへ変換する機能です。 Resultクラス内で __PACKAGE__->inflate_column('column_name', { inflate => sub { # カラムデータからオブジェクトを作って返す }, deflate => sub {
第2回 RDBMSとNoSQLを比べよう | gihyo.jp
NoSQLとRDBMSの比較 さて前回ご紹介したNoSQLの特色ですが、もう一度書きますと、 データ構造が単純である リレーションがない 拡張性／柔軟性が高い トランザクションがない 分散環境への対応が容易 ということでありました。 これらはどういうことなのか、改めてRDBMSと比較してみてみたいと思います。 データ構造とリレーション RDBMSの場合 RDBMSはデータをテーブルという表形式に集約し、データ同士の関係性を定義することで厳格なデータモデルを表現しています。テーブルはデータモデルごとに作成され、カラムという単位で項目を分けていきます。カラムはデータ型を指定する必要があり、投入されるデータの意味を理解した上で定義しなければなりません。 また、データ同士の関連性を定義することで、論理的な整合性が担保されます。 このように厳密でありますが、同時に複雑なデータ構造を表現することが可能
第3回 DBIx::Classでデータベース操作（2） | gihyo.jp
Schema::Loaderの利用 第3回（1）でResultクラスには各テーブルがどのようなカラムを持っているかを定義する必要があると書きましたが、「そのようなテーブル情報はデータベースから自動的に取得できるのでは？」と思った方もいるかもしれません。DBIx::Class::Schema::Loaderという別で配布されているモジュールを使用すると、Resultクラスでのテーブル情報の定義を省略できます。 Schema::Loaderを使うべきか 軽いデータベース操作であればSchema::Loaderがお手軽ですが、そうではない場合はResultクラスにテーブル定義をしっかりと書くのがお勧めです。Resultクラスにテーブル定義を書くべき理由は主に2つあります。 ●DBIx::Classからデータベースを作成できる Resultクラスにテーブル定義を書くと、DBIx::Classから
Cassandraのはじめ方─手を動かしてNoSQLを体感しよう 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Apache Cassandra | Apache Cassandra Documentation
What is Apache Cassandra? Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data.
フリーで使えるDBのモデリングツールまとめ
森川です。 巷ではエイプリルフールネタがおさかんですが、普通にデータベースのモデリングツールの紹介です（エイプリルフールネタが思いつかない…）。 普段MySQLならDBDesigner4、PostgreSQLならClayを使用しているのですが、他に何かよいツールはないものかと調べてみました。 Clay 言わずと知れた？モデリングツールです。Eclipseのプラグインで、無償でも使用可能です。MySQL、PostgreSQLで使用可能です。 無償版ではER-図や、DB定義書を出力できません。対応するDBが少なかったりもします。 個人的には、PostgreSQLを使用する場合によく使います。外部キー制約などにも対応しているのでそれほど困りません。 リバースエンジニアリングに対応しているのも気に入っている理由の一つです。 ちなみに、リバースエンジニアリングをするにあたってPostgreSQLのJ
naoyaグループ - naoyaの日記 - DBIx::Class->add_unique_constraint
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
システムの寿命はコードで決まる！
データベースをコードに依存しないように設計する さて、コードはできました。次はデータベースを設計します。コードがずっと同じ体系であれば何も考えずに設計できるのですが、残念ながらこの世は無常です。コードがパンクしなくても、業務・システム統合のためにコードを統一するという前向きな事情によりコード体系を変えることもあります。 そこで本稿では、「データベースをコードに依存しないように設計するためにはどうすればよいか」に重点を置いて、注意すべきポイントを解説します。また、解説の際にケーススタディとして、図1のように書店の販売システムとクライアント企業の購買システムが連携する場面を利用します。 （1）業務で利用するコードを主キーとして利用することは避ける 業務で利用するコードをテーブルの主キーとして利用することは、コード体系とデータベース設計を独立させるという観点からできるだけ避けるべきです。図1のケ
負荷対策概論 - Y-110's Wiki
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
【MySQLウォッチ】第25回 チューニングの指標，ベンチマークのノウハウ：ITpro
誰もが，データベースができるだけ高速で動くことを望む。そのために様々なテクニックを駆使してチューニングを試みる。 チューニングの結果を確認するには，何かしらの指標が必要となる。「体感的に向上した」というのは，まったく当てにならない。正確に性能を把握してこそ，効率的なチューニングが行えるのだ。今回は，ベンチマークについて紹介する。 MySQLのベンチマーク方法 ベンチマークには，２つの方向性がある。一つ目は，決まった処理を通じて，MySQLサーバーの処理速度を計測するものだ。これは，手順が決まっているため，それほど準備は必要ない。また，常に同じ処理を行うので，MySQLサーバーの基本的な処理能力を測るのに適している。 2つ目は，作成したデータベースの処理スピードを計測するものだ。一つ目も重要であるが，結局は，作成したデータベースが高速で動作するかが重要である。さらに，同時アクセス数やデータ量
MySQL :: MySQL 4.1 リファレンスマニュアル :: 5.2.8 MySQL による ORDER BY の最適化
余分なソートを行わずに ORDER BY または GROUP BY の要求に応じるために、MySQL はインデックスを使用する場合があります。 全ての使用されていないインデックス部分と他の部分が WHERE 節内で定数であるカラムである場合、ORDER BY がインデックスに完全にマッチしない場合でもこのインデックスを使用できます。 次のクエリではインデックスを使用して ORDER BY / GROUP BY 部分を解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2 SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2 SELECT * FR
LinuxWorld Online - 特集：PostgreSQL vs. MySQL：2大オープンソースDBの成熟度と可能性［前編］
LinuxWorld Online LinuxWorld Online サイト・クローズに伴うコンテンツ移転のお知らせ 「LinuxWorld Online」は、2007年1月12日をもって閉鎖し、一部の記事コンテンツはComputerworld.jpに統合いたしました。また、Linuxテクノロジー・フォーラムは、http://www.idg.co.jp/expo/lwtf/に移設しました。 Computerworld.jpでは、世界最大規模のIT関連メディアであるIDGグループのグローバル・ネットワークを生かし、世界80カ国6,000人のITジャーナリストが取材・編集した最新のIT情報をタイムリーにお伝えするとともに、専任記者によるIT動向記事や技術解説記事などを提供してまいります。今後ともご愛読のほどよろしくお願い申し上げます。 Copyright © 2006 IDG Jap
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Open Source Database (RDBMS) for the Enterprise | MariaDB
http://www.yktk.org/diary/20060310.html