大規模データベースを安全にマイグレーションする仕組み - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Yakumo兼コネクト支援チームの@ueokandeです。 サイボウズには体験入部という制度があり、数週間〜数ヶ月の期間、他チームの業務を体験できます。 自分もこの制度を使い、1ヶ月ほどGaroon開発チームを体験してきました。 自分はこの期間で、Garoonの大規模なデータベースを安全にマイグレーションするための仕組みの設計と、そのプロトタイプを実装しました。 背景 Garoonはサービスのアップデートと同時に、データベースのマイグレーションを実行します。 ここでいうマイグレーションは、主に2つの処理があります。 テーブルスキーマの更新。ALTER TABLEによるカラムの追加、削除など。 データの変換。既存レコードのデータ編集など。 Garoonはメンテナンスウィンドウを設けてバージョンアップを実施します。 このバージョンアップが毎回確実に成功すればいいのですが、実際はそれ
NewSQLのコンポーネント詳解 - Qiita
4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー
ERDをPlantUML形式で自動生成するツールを作った - くりにっき
PlantUML + ERDでPlantERDです github.com モチベーション PlantERDの特徴 使い方 出力するテーブル数の制限について 技術的に頑張ったこと テストのこと Foreign keyで隣接している別のテーブルを探す方法 複数DB対応のつらみ 追記：2019/12/13 9:45 モチベーション 既存プロダクトへの不満が一番大きいです。 https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい そもそもRails前提なので他言語とかでは使えない https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する 僕は初め
Buy and Sell Domain Names | Dan.com
NewsLearn more about the company, PR and product updates here.
DBMSをGoで実装してみた - Sansan Tech Blog
こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか？ データベースの内部実装はどうなっているのか？ トランザクションとはどのようなアルゴリズムで実現されているのか？ NoSQLが遅いのはなぜか？ 古典的なデータベースとは内部的にどのように違うの？ データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU（カーネギーメロン大学）のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義
ある期間内に更新されたデータを素早く検索できるモデル - モナドとわたしとコモナド
特定の技術とは関係ない、誰でも思いつきそうな、でも便利なお話。 こんなケースを考えてみよう。 人気のトレーディングカードゲームAugur Unlimitedを扱うショップ「しらさぎ商店」では、1000種類にも及ぶカードの買い取り・販売をしている。記録のため、カードごとに日時、価格、在庫数などをまとめたレコードを毎日データベースに書き込んでいる。 新着・売り切れや、価格の変化などを、指定された期間について一覧で表示するようなWebページを作りたいとオーナーは考えた。しかし、ユーザーからの要求ごとに全データの差分を取るのは、あまり効率的な手段とはいえない。レアなカードでもない限り価格は一定であることが多いからだ。 どうすれば更新されたものだけを効率よく取り出せるだろうか？ 答えはシンプルで、「日時」を「作成日時」と「終了日時」に分け、価格などが変わった時だけ新しくレコードを作成すると同時に、前
FoundationDB | Home
FoundationDB gives you the power of ACID transactions in a distributed database.Get StartedDownload FoundationDBMulti-model data store. FoundationDB is multi-model, meaning you can store many types of data in a single database. All data is safely stored, distributed, and replicated in the Key-Value Store component.Easily scalable and fault tolerant. FoundationDB is easy to install, grow, and manag
月数100万アクセスをDB使わず超簡単にさばく - Qiita
初Qiitaな個人開発者のひさしAppと申します @Hisashi_vc 最近「じぶんコイン」というコイン系SNSサービスを作り、月間100万～数百万アクセスを激安サーバー（1000円ちょい）でさばき中です。 じぶんコイン https://crypto-app.tokyo/qCoin/?m=hisashi_vc おまけになかなかの高負荷で、３ヶ月で数百万回送金したり、10連ガチャ回しまくったり、全ユーザーページにチャットあったり、数百人に一斉メッセージ＆送金したり、さらに内部API叩きまくってたりと、かなりのヤバさですが、ブロックチェーンどころかデータベース一切使ってません。 そんなツイートしたら予想よりビックリしてもらえたので、種明かししようと思います。ちなみに私はサーバーサイドエンジニアでも何でもないので、Hellow world覚えて３日目の中学生でもできるくら超簡単ですｗ この２つ
SingleStore | The Real-Time Data Platform for Intelligent Applications
SingleStore Now returns to Chase Center October 3.Get your ticket for 50% off with code S2NOW-Save50 →
SingleStore: Now Free to Use
Today, we announced our latest product version, SingleStoreDB Self-Managed 6.7. With this release, SingleStore is now free for everyone to use for databases with up to 128GB of RAM usage, and no limit on database size on disk, including solid state drive (SSD). Unlike what customers get from other database providers, the free tier of SingleStore is full featured and includes all enterprise capabil
Timescale | an open-source time-series SQL database optimized for fast ingest, complex queries and scale.
Timescale is Postgres made powerful3.2M+ Timescale databases power apps across IoT, sensors, AI, dev tools, crypto, and finance—all built on PostgreSQL. We use PostgreSQL for everything; we built our cloud so you can too. Time series, events, and analyticsFor workloads that ingest and query high volumes of data, Timescale queries up to 350x faster, ingests 44% faster, and saves 95% storage over RD
名前、電話番号、メールアドレス等の最適なmaxlengthはいくつか調べてみた - Qiita
はじめに 文字列を格納するカラムを作成するには、最大長を決めなければなりません。 例えば、 「姓名の最大長を何文字に設定したら良いか？」 という問題は、よくエンジニアを悩ませていると思います。 この記事が回答の目安となるよう、よくあるカラム（下記）を何文字に設定するのが適切か調べてみました。 なお、バイト数は UTF-8 で計算しています。 【姓名】 姓30文字 + 名30文字 （60バイト） 世界最長の名前を調べた1ところ 771文字 だったので、 あらゆる名前をカバーすることは諦めましょう。 世界中の姓名を保有するSNSである Facebook の登録フォームに名前を打ち込む続けたところ、 漢字 姓4文字 ＋ 名12文字 アルファベット 姓30文字 + 名30文字 までという結果が出た2ので、文字数・バイト数の多いアルファベットを採用とし、合計60文字までとします。 【法人名】137文
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
カード型データベースとして一世を風靡、FileMaker の今
1990年代後半から2000年代前半、独自技術を採用し、クライアント/サーバー型のアプリケーション開発を効率化するためのツールがブームになった。それから約20年。クラウドやモバイル活用が当たり前になった今、そうしたアプリケーション開発ツールは進化を続けている。一世を風靡したあのツールは今、どう姿を変え、活用されているのか。その最前線を伝える。 「カード型データベース（DB）ソフト」。こう呼ばれ、簡易なアプリケーションの開発ツールとして20年前に導入が進んだのがFileMakerだ。「用途は個人の住所録から、業務部門のアプリケーション構築など幅広い」とファイルメーカーの荒地暁マーケティング部 FileMakerコミュニティ＆ビジネスデベロップメント シニアマネージャーは話す。 今でも手軽に開発できるカード型DBの印象はあるが、2004年5月発売の「FileMaker Pro 7」で、1つのD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fast Open-Source OLAP DBMS - ClickHouse
Distributed PostgreSQL for Modern Apps
Source Code in Database - Wikipedia
GitHub - apple/foundationdb: FoundationDB - the open source, distributed, transactional key-value store
Back to the Future with Relational NoSQL
GitHub - AndrewRademacher/drifter: Simple schema migration manager for Haskell
