QuestDB | Peak time-series performance database
Peak time-series performanceQuestDB is the world's fastest growing open-source time-series database. It offers massive ingestion throughput, millisecond queries, powerful time-series SQL extensions, and scales well with minimal and maximal hardware. Save costs with better performance and efficiency. PerformanceColumnar storageSIMD-optimized queriesIngest 4M rows/s per nodeDon’t worry about cardina
NoSQLのテクニックが書いてある「Advanced Data Modeling With Firestore by Example」を翻訳してみた - くらげになりたい。
オリジナルの記事は、こちら。 Advanced Data Modeling With Firestore by Example | AngularFirebase NoSQLのデータ構造や設計について、いろんな事例が書いてあってすてきだったので、 Google翻訳で翻訳した(´ω｀) 翻訳精度すごい。。 ちょっと整理した記事はこちら www.memory-lovers.blog Advanced Techniques in NoSQL Duplication: 複製 データ複製は、複数のDocumentを参照する必要性を排除するための非常に一般的な手法です。 簡単な例 ユーザードキュメントに対して二次クエリを行わないようにするために、 すべてのツイートドキュメントにユーザー名を複製または埋め込むことがあります。 または、ユーザープロフィールに表示するために、ユーザーDocumentに最近の
DB変更リリースの停止時間を最小化するには？「DevOps with Database on AWS」 #AWSDevDay | DevelopersIO
「DevOpsってアプリの話ばっかりな気がするけど、DBもアプリ以上に変更入るよなぁ」 データベースの変更をいかにノーダウンタイムで本番リリースするか？ステート（データ）を持つという宿命上、そう簡単にいかないことは皆さん想像つくかと思いますが、その制約の中でも工夫次第では停止時間を極小化する方法が有るんだなぁと気付かされました。 AWS Dev Day Tokyo 2018 | AWS、「DevOps with Database on AWS」のセッションレポートです。 （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 無停止DBﾘﾘｰｽﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ セッション内容 タイトルは「DevOps with Database on AWS」 DevOps のアプローチでシステム開発に取り組む上で、データベースに対する変更をどのように扱うかは難しい問題です。
RDBを使わない究極のマルチテナント
先日、SmartHRさんのDB移行の話が話題になりました。 これは、「つらくないマルチテナンシーをどのように実現したか」という生々しくインパクトのあるプレゼンでした。 ただ、個人的にはちょっと引っ掛かるところがありました。そもそもテナント毎にテーブルを作成するという設計に無理があったのではないかと思ったからです。Citus Cloudで解決できたそうなので結果オーライではあるのですが。 マルチテナントでDBを分けたくなる気持ちはわかります。②のパターンですね。 それは、顧客データを全て一つのDBに混ぜてしまうのはデータ混濁のリスクがあるのでDBの機能・ユーザーでデータを分離したいというのがその理由なのだろうと思います。 ですが、本当にDBを分ける必要があるかはよく考える必要があると思います。なぜなら、テナントごとに1 つのDBをサポートするという状態はマルチテナンシーが回避しようとしている
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
Row Level Securityはマルチテナントの銀の弾丸になりうるのか / Row Level Security is silver bullet for multitenancy?
builderscon 2019の発表資料です
2章 Naive Trees(素朴な木) - Qiita
第二章 ナイーブツリー 「ブログのコメント欄をスレッド形式で見れるようにしたいよね・・・」 目的 階層構造を格納して、クエリを実行する こんなテーブル設計したとして、 comment_id parent_id comment etc
RDBのトラブルの現場を追え！ / rdb-Troubleshooting
そーだいなる DBRE Nightでの登壇資料です https://connpass.com/event/138437/ # 紹介資料 - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://www.yout…
[補足資料] Go Conference 2019 Springでdatabase/sql入門を発表した #gocon - My External Storage
database/sql入門 | 2019 Spring Sessions データベースサーバについて DockerHubを使えば使い捨てのRDSをすぐ起動することができる。 DockerHubを見れば公式イメージがある。 mysql | Docker Hub https://hub.docker.com/_/mysql マイグレーションツールについて sql-migrateを推した。 リポジトリパターンについて 設計パターンとして、DBをあつかうときに大抵は選択するであろうリポジトリパターンを紹介した。 pospomeさんがBOOTHで販売しているpospomeのサーバサイドアーキテクチャにGoで書かれた「第4章 詳解リポジトリパターン」という章があるのでそちらを読むと良い（その前の章のアーキテクチャ設計に関する部分も大変参考になる）。 ORMについて ORMについてはizuminさんら
![[補足資料] Go Conference 2019 Springでdatabase/sql入門を発表した #gocon - My External Storage](https://cdn-ak-scissors.b.st-hatena.com/image/square/f3ca5145f819bb37539bafba90f1c2353dbe1f00/height=288;version=1;width=512/https%3A%2F%2Fbudougumi0617.github.io%2Flogos%2FGo-Logo_Aqua.png){kind=logo}
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
Firestore で、DB設計を考える際に参考になった情報
Firestore におけるDB設計 DB設計について考える場合、そもそもFirestoreのようなドキュメント指向のNoSQLデータベースではどんなDB設計をするべきなのか、いろいろと情報を漁ってみました。 以下は、いろいろ調べた中で、個人的に参考になった記事です。 おそらくFirestore のDB設計について考える場合、今回挙げた記事は、何度も読むことになりそうなので、備忘録的に残すことにしました。 NoSQLデータモデリング技法 参考になった点 Firestore に限定されず、NoSQLデータベースとしてのプラクティスが網羅されている いきなり具体例ではなく、概念から解説してから、具体的な技法について解説している RDBでは、基本的には、正規化を徹底するが、NoSQLデータベースでは、非正規化を許容する、むしろ活かす Firestore Database Design https
RDBMSのモニタリングについて - そーだいなるらくがき帳
dbstudychugoku.github.io 中身の薄い資料で登壇してきた。 speakerdeck.com 具体的な内容が知りたい人は末尾に関連リンクをまとめたのでそっちを見て欲しい。 資料には書いてないけど伝えたかったことをまとめる。 RDBMSの監視の勘所 RDBMSがどれくらいのトランザクションを捌けるかというのが大切な要素の一つ。 単純な処理が多くてキャパオーバーになったとき、多くの場合はインスタンスのサイズを上げるなどのスケールアップで対応できる。 これは費用対効果の高いケースが多く、有効な手段だ。 しかし ロックが原因の場合 はスケールアップしても問題が解決しないことが多い。 例えばバッチ処理で長時間テーブルロックを取り、それが起因でパフォーマンスが問題になっているときは単純なスケールアップで問題は解決しない。 よく見られる処理例は次のようなケース。 トランザクションを開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Database schema templates by DrawSQL
Spanner vs. Calvin: Distributed Consistency at Scale
Fauna | The Distributed Document-Relational Database
モデル設計を適当にやるとどうなるのか
はじめてのB2B SaaSデータモデリング in 吉祥寺.pm#18
履歴を持つデータの設計
イベント・ソーシングを知る
2019 Database Trends – SQL vs. NoSQL, Top Databases, Single vs. Multiple Database Use - High Scalability -