大規模システムにおけるディレクトリ構成をRDBのカーディナリティを参考に考える - ぷらすのブログ
モノリシックなプロジェクトにおいて、トップレベルのディレクトリ構成が異なる 2 つのディレクトリ構成を考え、それらの違いは何で、どちらが優れているか？という問いについて考えた。そして、「複雑な概念をトップレベルのディレクトリ構成にした方が良いのでは？」という結論に落ち着いた話をする。 はじまり ちょっとしたシナリオを想像してみよう。 プロジェクト立ち上げ期 「最近のトレンドはレイヤードアーキテクチャだ！」 そう言って、プロジェクトはスタートした。 . ├── application │ ├── xxx_usecase.go │ ├── xxx_repository.go │ ├── yyy_usecase.go │ └── yyy_repository.go ├── domain │ ├── xxx.go │ └── yyy.go ├── infrastructure │ └── xxx_
MongoDBが遅いときの切り分け方法
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python ba
MongoDB のクエリ $in と $or について調べてみた :: by and for engineers
> db.animals.find({}).count(); 100248 > db.animals.getIndexes(); [ { "v" : 1, "key" : { "_id" : 1 }, "ns" : "document.animals", "name" : "_id_" }, { "v" : 1, "key" : { "type" : 1 }, "ns" : "document.animals", "name" : "type_1", "background" : true } ] > db.animals.find({ type: { $in: ["dog", "cat"] } }).explain(); { "cursor" : "BtreeCursor type_1 multi", "nscanned" : 3470, "nscannedObjects" : 3469
世界第4位！最有力NoSQLデータベースMongoDBはRDBとどう違うのか？特徴と使い分け | tracpath:Works
世界第4位！最有力NoSQLデータベースMongoDBはRDBとどう違うのか？特徴と使い分け By tracpath • 2016-07-08 • Development はじめに 昨今、AjaxやWebAPIは広く普及し、ほとんどのウェブサイトで使用されるようになりました。それを支えているのは、JavaScriptとJSONです。もちろん、今やAltJSやYAMLなど、多数の関連技術が生み出され利用されています。とはいえ、ベースとなっているのはJavaScriptとJSONですから、これからも基盤技術として長い間利用されることでしょう。 最近では、TwitterなどのSNSからWebAPIでデータを取得できることもあり、分析やシステムでの利用のために、JSONを保存する必要が出てきました。しかし、従来のRDB（リレーショナルデータベース）では、階層的なJSONのスキーマ定義をすることは困
アルゴリズムとデータ構造から理解するRedis / Learn Redis from Internal Algorithms and Data Structures
2019年新卒研修で使った資料です。 内部実装の雰囲気を感じとりながら、Redisについて理解を深める研修を行いました。 以下の内容について学びました。 1. Redisの概要 2. 社内での利用方法 3. 正しい用法用量 Redis についての前提知識は必要としていません。C言語の基礎的な知識は前提とします。
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？
スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX（ドラクエ10）」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝： 皆様、本日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と
SQLite4: The Design Of SQLite4
1.0 Executive Summary SQLite4 is a compact, self-contained, zero-adminstration, ACID database engine in a library, just like SQLite3, but with an improved interface and file format. The run-time environment is encapsulated in an object. A greatly simplified Key/Value storage engine is used: A single large key space - not separate key spaces for each table and index as in SQLite3. Keys sort in lexi
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
FacebookがHBaseを大規模リアルタイム処理に利用している理由（前編）
Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか？ 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ（Jonathan Gray）氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日本語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか？ MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb
Googleが開発! 高速データベース「LevelDB」登場 | エンタープライズ | マイコミジャーナル
LevelDB is a fast key-value storage library. Googleから新しいプロジェクトが公開された。高速なキーバリューデータベースライブラリ「LevelDB」だ。2条項のBSDライセンスのもとでオープンソースソフトウェアとして提供されている。 対象言語はC++。なるべくほかのライブラリやプラットフォームへの依存が少なくなるように設計および実装されており、アプリケーションへの組み込みやOSへの移植が簡単に実施できるという特徴がある。 LevelDBの提供する機能はキーから値への順序付きマッピングを提供するというもの。SQLに対応したリレーショナルデータベースのような機能は提供していない。割り切った機能に特化しており、基本的にPut(key,value)、Get(key)、Delete(key)で操作を実施する。Chromeに搭載されているIndexedD
第1回 サブクエリ・パラノイア～副問い合わせ乱用による性能劣化を治療せよ！ | gihyo.jp
図1 テーブルのレイアウト 図2 リスト1の実行結果 cust_id | seq | price --------+-----+------- A | 1 | 500 B | 5 | 100 C | 10 | 600 D | 3 | 2000 リスト1 サブクエリ・パラノイア 患者1号 SELECT R1.cust_id, R1.seq, R1.price FROMReceiptsR1 （※） INNER JOIN (SELECT cust_id, MIN(seq) AS min_seq FROMReceipts ※ GROUP BY cust_id) R2 ON R1.cust_id = R2.cust_id AND R1.seq = R2.min_seq; ※ 同一テーブルを結合する自己結合 さてワイリー、お前ならどうする。 ええっ、ちょっと待ってください。整理します。このReceip
第一の大罪（1） ～ データベースアプリケーションのパフォーマンスにおける七つの大罪
第一の大罪は''データベースの物理設計''に関するもので、たとえばスキーマ設計の問題、テーブルの列の順序、インデックス付け、データベースページサイズの選択など、パフォーマンスに悪影響を及ぼしかねない重要な要因はいくつも考えられます。今回の記事では、SQL Anywhereのデータベース設計にまつわる具体的な問題と、ドメイン（定義域）の概念に関する内容を取り上げていきます。 ドメイン（定義域）とは ドメインの概念は、E. F. Coddが発案した最初のリレーショナルデータモデルに含まれています。Chris Dateは、彼の重要な著書 [1, pp. 81] の中でドメインを次のように定義しています。 次に、ドメインという言葉を、すべて同じ型の、スカラー値の名前付きの集合と定めることにする。たとえば、サプライヤー番号のドメインは、サプライヤー番号として取り得るすべての番号の集合になり、出荷数量
ORM is an anti-pattern | Seldo.com
I tweeted about ORM last week, and since then several people have asked me to clarify what I meant. I have actually previously written about ORM, but it was in the context of a larger discussion about SQL and I shouldn't have confused the two issues. So here I'm going to focus on ORM itself. I'm also going to try to be very brief, since it became very apparent from my SQL article that people tend
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
データベースの間違った使い方10項目
一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。 それによるとデータベースのアンチパターンは以下の通り。 動的なテーブルの作成 テーブルをキャッシュとして使う テーブルをキューとして使う テーブルをログとして使う 分散したグローバルなロック ストアドプロシージャ 使われない項目 JOIN地獄 ORMによって繰り返されるクエリ 負荷のコントロール どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「
第7回 集合論――数学の「集合論」に，RDBの正体を見る
リレーショナル・データベース（RDB）のデータ構造やSQL命令による様々なデータ操作については，多くの人が知っていることだろう。しかしRDB技術の根底にある「集合論」を詳しく語れる人は少ないはずだ。集合論とRDBの結びつきを理解すれば，RDBの本質が見えてくる。 ITエンジニアの皆さんなら，米IBMサンノゼ研究所に在籍していたE.F.コッド博士（Edger.F.Codd，1923～2003）をご存知だろう。コッド博士は1970年，「A Relational Model of Data for Large Shared Banks（大規模共有データバンクのためのリレーショナル・モデル）」という有名な論文を発表した。現在の「リレーショナル・データベース（RDB）」（「関係データベース」とも呼ぶ）は，この論文が起源となって誕生したものだ。 コッド博士が数学の「集合論」を基に，表を使うRDBの仕組
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
村上昴平@エンジニア on Twitter: "『MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？』 凄い記事って中身難しくて長くても、読み入るな...... 該博な圧倒的解答は勿論、データベースの歴史や、アルゴリズムの… https://t.co/csd3HIehBO"
PostgreSQLでUNIX時刻とTimestamp型の相互変換 - ゆるゆると
日付と時刻を取得する(date関数, time関数, datetime関数, julianday関数, strftime関数)
