なぜバッチ処理が得意なのか、純国産の次世代高速RDB「Tsurugi」
オープンソースの高速な国産リレーショナルデータベース「Tsurugi」が登場した。Tsurugiの特徴やアーキテクチャ、導入方法などを解説する。 来歴 Tsurugi1は、国のバックアップ2を受けて作られた、純国産のOSS-RDBです。もともと有志の勉強会から始まったコミュニティ活動がベースで、各民間企業（ノーチラス・テクノロジーズ/NEC）、大学（東京工業大学/慶応大学/名古屋大学/大阪大学）、研究機関（国立天文台）などが主体となり、さまざまな企業・関係者の協力のもとに開発された、次世代高性能RDBです。OSSなので、だれでも自由に利用できます。商用サポートも提供されています。 2 なお、国によるバックアップは国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）によるもので、「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発／次世代コンピューティング技
MySQL/Postgres におけるトランザクション分離レベルと発生するアノマリーを整理する
読者対象 ANSI 定義の古典的なトランザクション分離レベルとアノマリーは概ね理解している MySQL/Postgres では理論的な部分がどうなっているのかを知りたい 理論面の前提知識 2022-08-19 追記: 社内勉強会向けのスライドを作成しました。先にスライドを見てから，引用文献およびこの記事を読むと理解が深まると思います。 まず ANSI 定義の古典的な定義を聞いたことが無い方は，以下のリンクを参照されたい。 ANSI 定義に対応する解説はこれらのサイト以外にもたくさんあるため，自分にとって読みやすいと感じる情報をあたってほしい。（既に熟知されている方は十分） 次点で読んでいただきたいのが， @kumagi さんの以下の記事。古典的には 4 つの分離レベルと 3 つのアノマリーだけで説明されていたものの，不十分であることが学術的に指摘され，解像度を上げようとする流れが後になって
Relational Databases Explained
It is often surprising how little is known about how databases operate at a surface level, considering they store almost all of the states in our applications. Yet, it's foundational to the overall success of most systems. So today, I will explain the two most important topics when working with RDBMSs indexes and transactions. So, without fully getting into the weeds on database-specific quirks, I
Vitess as a Service：Vitessのフル・マネージド・サービスを試す（導入編） - そこはかとなく
注意：本記事の内容は所属企業とは全く関係がありません。個人の趣味です。 Kubernetes Advent Calendar 2019 - Qiita 15日目です。 Vitessとは Vitess as a Service：PlanetScale CNDb ログイン Create your first cluster Create Database 終わりに Vitessとは Vitessを皆さんはご存知でしょうか？ CNCFが2019/11/5にVitessのGraduateを発表し、 さらにCloudNativeCon 2019 SanDiegoでもKeynoteに取り上げられたこともあり注目度・認知度が上がってきているのではないでしょうか。 Vitessは一行で説明すると"MySQLの水平スケーリングを実現するためのデータベースクラスタリングシステム"です。 Vitessの大きな特
Vitess のパフォーマンスと運用性を検証してみた
結局Kubernetesのストレージどうするの？ - cndjp第8回勉強会 Vitess に入門したい方へ
PlanetScaleというサーバレスDBが凄く勢いのあるサービスらしいのでQuick Startやってみた - Qiita
PlanetScaleというサーバレスDBが凄く勢いのあるサービスと聞いて、公式にクイックスタートがあったのでやってみました。 環境 PC: MacBook Pro (Intel Core 2016) OS: macOS Montery12.2.1 では概要から確認していきます。 サーバーレスDBとは サーバがない、のではなく、サーバ管理や検討が不要 AWS Lambda(NoSQL)など PlanetScaleとは PlanetScale年表 2010年頃 YouTubeが急激に成長し、データベースが爆発しそうになっていたので、Sugu氏ともう一人のYouTubeのエンジニアがオープンソースプロジェクト「Vitess.io」（ヴィテス）を立ち上げる 2016年頃 MySQLでバイナリプロトコルを扱えるようにしたことで、VitessはYouTube以外の企業にとっても魅力的なシステムになり
本当にtransactionは必要なのか？ - 急がば回れ、選ぶなら近道
前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
データベース設計で派生関係は難しい - プログラマの思索
@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向
DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） - 主に言語とシステム開発に関して
データベースには，「トランザクション分離レベル」というものがある。 以下では，それが なぜ必要なのか？ デフォルトのレベルでは，どうして駄目なのか？ PostgreSQLでは，どうやってレベルを変更・確認するのか？ などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは： 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか，のレベル。 ANSI規格では，４つのレベルがある。 READ UNCOMMITTED （一番低い） READ COMMITTED REPEATABLE READ SERIALIZABLE（一番高い） 徹底比較!! PostgreSQL vs MySQL 第３回：トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく
MySQL versions at Wikipedia
More of information about how we handle database stuff can be found in some of my talks. Lately I hear people questioning database software choices we made at Wikipedia, and I’d like to point out, that… Wikipedia database infrastructure needs are remarkably boring. We have worked a lot on having majority of site workload handled by edge HTTP caches, and some of most database intensive code (our pa
MySQLでNoSQL·Friendly MOONGIFT
FriendlyはRuby製のオープンソース・ソフトウェア。ここ最近話題になっているのがNoSQLという概念だ。NoSQLというのはRDBMSのようにスキーマを定義してリレーションを組んだものではなく、いわゆるスキーマレスで柔軟なシステム開発を可能にするデータベースだ。 こんな感じで定義する。まさにNoSQL AmazonのSimpleDBやGoogle App EngineのDataStoreなどが良く知られているが、同様のNoSQLをMySQLで実現するのがFriendlyだ。FriendlyはRails用に開発されているライブラリで、スキーマを定義することなくデータベースを利用できるようにするものだ。 Friendlyはクラス名をテーブル名とし、クラスの中で定義した属性を利用できるようにする。特にその要素名でフィールドを作る訳ではなく、attributesというテキストフィールドに全
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NASでも動く！ Excel感覚で使えるウェブデータベース「Baserow」と「NocoDB」【イニシャルB】
Amazon.co.jp: 事業分析・データ設計のためのモデル作成技術入門: 佐藤正美 (著), TMの会 (その他): Digital Ebook Purchas
Vitessへのいざない
Cloud Native時代のデータベース
VM時代からコンテナ時代へストレージ管理の移り変わり
Home
