Thank You for Using Graphcool 💚
Thank you for using Graphcool 💚After running for more than four years, Graphcool has sunsetted on July 1st, 2020. We want to thank everyone who has accompanied us during this exciting time! Looking back...The first version of Graphcool went live in March 2016. Since then, more than 59k users had signed up for Graphcool and created a total of 234k projects. Graphcool was used by the developers of
Rust の migration ツールを探して（diesel_cli 編） - Qiita
これはRust Advent Calendar 2017 16日目の記事です。 Rust でサーバーを動かしてみたく、探してみたところrustful を見つけたので、使ってみました。 API サーバーでデータベースを扱う上で良さそうなマイグレーションツールはないかと探してみたら、diesel を利用した diesel_cli を見つけたので紹介します。 diesel_cli は diesel を利用しており、同じ人たちが開発しているようです。現在（diesel 1.0.0-beta1）は PostgreSQL や MySQL、SQLite に対応しています。 以下の環境で動作確認をしています rustc 1.22.1 (05e2e1c41 2017-11-22) Ubuntu 16.04.3 LTS（Windows Subsystem for Linux） まずは diesel_cli を
SpringのDataSourceTransactionManagerを使うとエラー時にCommitされる可能性あり！？ - Qiita
SpringのDataSourceTransactionManagerを使うとエラー時にCommitされる可能性あり！？JavaspringSpringBoot 今回は、Springが提供しているDataSourceTransactionManagerをデフォルトの状態で使用していると、Commitフェーズで何かしらのエラーが発生するとCommitされる可能性がある・・・という話を紹介します。 Commitフェーズでエラーが起こる可能性はかなり少ないとは思いますが、発生してしまった時の衝撃を考えるとけっして見逃せません・・・ Note: ちなみに・・・JTA(JtaTransactionManager)使用時の動作は本エントリーでは検証できていません。 2016/12/10 12:20 追記 Spring BootがサポートしているOSSのJTA実装(Atomikos, Bitronix,
CrateDB – The Enterprise Database for Time Series, Documents, and Vectors
/* Based on device data, this query returns the average * of the battery level for every hour for each device_id */ WITH avg_metrics AS ( SELECT device_id, DATE_BIN('1 hour'::INTERVAL, time, 0) AS period, AVG(battery_level) AS avg_battery_level FROM devices.readings GROUP BY 1, 2 ORDER BY 1, 2 ) SELECT period, t.device_id, manufacturer, avg_battery_level FROM avg_metrics t, devices.info i WHERE t.
ここが好きだよIntelliJ - Qiita
はじめに こんにちは。 JetBrains Advent Calendar 2016 の12/19枠で参加させていただきます。 今回、表題の通りIntelliJ IDEAについてお話しします。 お忙しい方はざっと眺めるだけで構いません..... && ネタがすでにあるので、お腹いっぱいって方はスミマセン.... おはなしすること こんなことについて触れてみます。 「いんてりじぇい」ってなんですか？ IntelliJとの出会い なぜ使っていたのか インフラ / サーバサイド向け機能も！ こんなところが便利です（駆け足紹介） 触れないこと エディタ論争 (多様性があっていいじゃないか〜） コーディングスキル、テクニカルな話題には触れません それでは、以下、宜しくお願いします！ 「いんてりじぇい」ってなんですか？ JetBrains社製のIDEです（統合開発環境） IDEA は、「あいでぃあ」と
yesodで全てのモデルにcreatedAt, updatedAtを作りたかった話
User email Text name Text createdAt UTCTime updatedAt UTCTime のように, それぞれのモデルに生成時間と更新時間を付けたい. 役に立つことがあるかもしれない 全てのモデルにつけることで一貫性を保ちたい 問題 単純にFormを userForm :: Form User userForm = renderBootstrap3 BootstrapBasicForm $ User <$> areq emailField "email" Nothing <*> areq textField "name" Nothing <*> lift (liftIO getCurrentTime) <*> lift (liftIO getCurrentTime) <* bootstrapSubmit ("submit" :: BootstrapSubm
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
時系列DBって結局どれがいいんだっけ #TSDB - weblog of key_amb
※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと
まだAWSのみに頼って生きてるの？複数のクラウド利用で、大幅コストダウンした話 - Qiita
by @mixiappwchr 一人でがっつりAWSでサービス開始しましたが、運用を始めると多くの問題が起きえます。 今回はコストに対する問題を,AWSだけでなく、他のクラウドを活用することで大きく削減できたという事例を共有したいと思います。 例えばNetflixが Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開 といったオープンソースを公開していることを鑑みるに、すでにマルチクラウドでの運用は行われていることでしょうし、今後はこういった事例も多くなっていくことでしょう。 クラウドを複数使うにあたった経緯 前回 goからiOSまで一人でアプリ開発をしてたらいつの間にかマインクラフトエンジニアになった話 といった記事でリリースしたおしゃべりマルチというサービスですが、おかげさまでユーザー数も順調に増え、利用者に楽しく使っていただいてお
Presto: Free, Open-Source SQL Query Engine for any Data
Calling our Presto community speakers – we want to hear from you! Fill out out community call for papers to speak at upcoming meetups and conferences. What is Presto?Presto is an open source SQL query engine that’s fast, reliable, and efficient at scale. Use Presto to run interactive/ad hoc queries at sub-second performance for your high volume apps.
論理削除と一意性制約を両立させる方法・DB製品別 - Qiita
アプリケーション上でなにかエントリ（例えば記事だとかユーザだとか）を削除したとき、DB上の行は削除せず単に【削除済み】フラグを立てるだけという扱い方を 論理削除 と呼びます。 論理削除にはいろいろなメリットがあります。行削除のように関連する他テーブルへ削除が波及しないこと、エントリ復活ができること、障害時にデータ変更の経緯を追いやすくなることなどなど（デメリットもわんさかあるんですが、この記事の主旨からははずれるので別途お調べください）。 ところが論理削除の方針でDBを組んでいて困ったことはありませんか？ 「 メールアドレスは一意性(UNIQUE)制約をかけたいのに、それだと削除済みのユーザと同じメールアドレスが使えないことになる 」 論理削除と一意性制約、両立はできないのか？ できないと思っている方、多いと思います。実はちゃんとできます。DB製品によって実現方法がちょっと違ってくるだけで
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
リレーショナルモデルのドメイン設計についての議論
リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その
Redisを使う時は見積の二倍の容量必要だよね、という話 - Qiita
[15487] 04 Aug 21:02:37.523 * 1 changes in 900 seconds. Saving... [15487] 04 Aug 21:02:37.523 # Can't save in background: fork: Cannot allocate memory redis-cli infoしても、使用してるメモリは全体の半分ちょっとだったし、空きは十分にある… 答えは Redis Administration http://redis.io/topics/admin に書いてありました。 原因と解決策 redisのバックアップが走る際、おそらく現状使用している量と同じだけのallocateを要求しているために、redis自体はメモリ使用が50%強だとしても、バックアッププロセスが落ちてしまう模様。 解決は簡単で、Redis Administratio
カラム型データベースでトランザクション処理を実現するカラクリとは？ インメモリとカラム型データベースの可能性を調べる（その5） － Publickey
カラム型データベースでトランザクション処理を実現するカラクリとは？ インメモリとカラム型データベースの可能性を調べる（その5） SAPのHANAは、最初からインメモリデータベースとカラム型データベースの技術を用いて高速な集計や分析処理と高速なトランザクション処理とを両立させることを目指して開発されたと、HANAの開発者でありSAPの共同創業者であるハッソ・プラッタナー氏はHANAの設計思想と実装を解説した著書「In-Memory Data Management」で書いています。 ここでは、その書籍および公開されている論文「Efficient Transaction Processing in SAP HANA Database – The End of a Column Store Myth」（SAP HANAデータベースにおける効果的なトランザクション処理 ― カラムストア神話の終焉）から
DB batch job by Haskell
BATCH.md HaskellでDBバッチ処理 概要 これは Haskell Advent Calendar 2012 の11日目の記事、その2です。 Haskell で DBを使うバッチ処理を書くための記事です。 基本的な文法を把握したらバッチ処理を書くのは簡単だと示すのが目的です。 主な対象読者は プログラミングHaskell か すごいHaskellたのしく学ぼう! を読み、Haskell をより使いたい人です。 バッチ処理の概要 DB定義 persistentパッケージ を使ったDB定義の方法は Haskellで便利にデータ設計 を読んでください。 今回使うDB定義は以下です。 share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persist| Person name Text age Int sex Sex NumPe
Haskellで便利にデータ設計
persistent.md Haskellで便利にデータ設計 概要 これは Haskell Advent Calendar 2012 の11日目の記事です。 Haskell でデータ設計を便利に行う発想・方法について書きました。 persistent というライブラリを活用します。 Haskell を知らなくても読めます。 主な対象読者は プログラミングHaskell か すごいHaskellたのしく学ぼう! を読み、Haskell をより使いたい人です。 persistent の概要 いわゆる「ORマッパー」の機能を持つライブラリです。 データ設計を記述するという準備をすれば、 DBのデータ出し入れをよろしくやってくれます。つまり データ型を作ったら insert関数に渡せば、はい、DBレコードが追加されます select系関数で取り出したデータには対応する型が付いて安全に使えます RD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails 5.1以前に作成されたテーブルにFK制約を張れない問題の解決策 - Qiita
GitHub - facebookarchive/beringei: Beringei is a high performance, in-memory storage engine for time series data.
DBスキーマもバージョン管理したい！
