Do you hate starting on a new project and having to try to figure out someone else's idea of a database? Or are you in QA and the developers expect you to understand all the relationships in their schema? If so then this tool's for you. SchemaSpy is a Java-based tool (requires Java 5 or higher) that analyzes the metadata of a schema in a database and generates a visual representation of it in a br
「RDBにおけるバリデーションをリレーショナルモデルから考える」という、なんとも捻りも面白みもないタイトルである。だが、RDBとValidationという2つが相容れないものだということを知っている人には、割と琴線に触れる話かも知れない。 正直なところ、現在私はデータベースエンジニア一直線なので、アプリケーション開発におけるセキュリティというのは門外漢であると言って差し支えない。しかもイベントにはあの徳丸浩氏(バリバリの本職)も発表されるというではないか!!順番的には徳丸氏の次に話したのだが、徳丸氏はSQLインジェクションの実演までするというガチっぷりである。 「場を白けさせてしまうのではないか・・・」 「ガチの人から特大のマサカリが飛んでくるのでは・・・」 そんな想いを脳裏に抱きつつ発表に望んだのであった。 今回の持ち時間は20分と短めであったが、あまりたくさん話したいネタも無かったので
久しぶりに「タッチ」を見てドキドキしました GW前半2日目、皆様いかがお過ごしでしょうか。 「引きこもり系エンジニア」を自称する私は、せっかく外出したのにすぐ帰ってきてしまい、PCとテレビの前で平日と変わらないお仕事ライフです。 テレビと言えば先日、「タッチ」が再放送していました。みなみちゃん、いつ見ても可愛いわぁ...*1。そして妄想をかきたてまくる主題歌に萌え殺されまくったあの日々。 ということで*2、今回は、先日のブログで紹介した『スッキリわかる SQL 入門』で公式に対応をうたった、我ら開発者の強い味方「H2 Database」を紹介していこうと思います。 H2 Databaseとは H2 Databaseは、Javaだけで記述されているオープンソースのRDBMSです。もともとHSQLDBを作っていたトーマス・ミューラーさん*3が、サラから作り直したものです。 「動作が超速い」とい
下記のようなシステムでパフォーマンスが良さげな 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のパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか? SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
モバイルファースト室の @rejasupotaro です。 Androidフレームワークには端末内にSQLiteでデータを保存するしくみがありますが、みなさんはどのようにしてますか? クックパッドのAndroidアプリでは、ActiveAndroidを使ってDBにデータを保存しています。 ActiveAndroidとは ActiveAndroid とは、Active Recordパターンを採用したAndroidのORMです。 テーブルのCREATEを行うときに、SQLiteOpenHeleperを継承したクラスでonCreateをOverrideしてdb.execQueryでCREATEクエリを実行…としなくても、ActiveAndroidを使えば、 public class MyApplication extends Application { @Override public void
9. 静的コンテンツを Reverse Proxy で配信 Reverse Proxy: クライアントからの接続を 受け、Applicationサーバに処理を中継す る。画像,js,css などの静的コンテンツを返す 役割もある Application Server: ユーザからのリクエス トを受けて適切なページを構築・レスポン スを行う 10. /etc/httpd/conf.d/isucon.conf <VirtualHost *:80> DocumentRoot /home/isu-user/isucon/webapp/public RewriteEngine on RewriteCond REQUEST_URI !^/favicon.ico$ RewriteCond REQUEST_URI !^/(img|css|js)/ RewriteRule /(.*)$ http://loc
« Stuff The Internet Says On Scalability For July 11th, 2014 | Main | Sponsored Post: Surge, Apple, Dreambox, Chartbeat, Monitis, Netflix, Salesforce, Blizzard Entertainment, Cloudant, CopperEgg, Logentries, Gengo, ScaleOut Software, Couchbase, MongoDB, BlueStripe, AiScaler, Aerospike, LogicMonitor, AppDynamics, ManageEngine, Site24x7 » “You just can't have it all” is a phrase that most of us are
« Update on Disqus: It's Still About Realtime, But Go Demolishes Python | Main | Stuff The Internet Says On Scalability For May 2nd, 2014 » This a guest post by Rajkumar Iyer, a Member of Technical Staff at Aerospike. About a year ago, Aerospike embarked upon a quest to increase in-memory database performance - 1 Million TPS on a single inexpensive commodity server. NoSQL has the reputation of spe
** DI = On Demand Instances ** RI = Reserved Instances ** All cost analysis is for a single instance of the given type. For Reserved Instances, the 1 year and 3 year terms have been calculated with heavy utilization (100% utilization). NB: These instances sometimes show better or worse performance. These numbers are based on typical results seen over many runs over a month. * Core Bottleneck : We
まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど
Presto is a distributed SQL query engine that allows for interactive analysis of large datasets across various data sources. It was created at Facebook to enable interactive querying of data in HDFS and Hive, which were too slow for interactive use. Presto addresses problems with existing solutions like Hive being too slow, the need to copy data for analysis, and high costs of commercial databases
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く