データベース関連の履歴(No.7)

RDBの限界とNoSQLの登場 2019.11
- トランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。
- 1998年Carlo StrozziによってSQLのない軽量なDBを推進する運動として"NOSQL"という言葉が使われる。
- 2009年にサンフランシスコで開かれたミートアップで「NoSQL」がハッシュタグとして使われ、次々生まれることになるRDBでないデータベースは「NoSQL」と呼ばれることになる。
- Facebookは2008年7月にCassandraをオープンソースソフトウェアとして公開し、2009年3月からApache Incubatorプロジェクトとなる。DynamoDBのような高い可用性とスケーラビリティを保持している。
- DBのボトルネックは二つ
  - 一貫性を担保するためストレージを共有する構成を取る必要があること
  - SQLが強力で柔軟なため複雑な処理を実行できてしまうこと
- NoSQLではQueryに頼らない設計をせざるを得ない。NoSQLではClient Side Joinを推奨しておりJOINをClient側で行う。これによりデータベースの負荷を分散している。
- RDBは構造化データを表現しにくい
- Googleは2011年スケーラビリティと一貫性を両立した分散データストアMegastoreを発表。
- Google Cloud Platform（GCP）では、Cloud Datastoreというデータストアを利用することができ、Cloud Datastoreは、内部的にMegastoreを用いて実装されている。

↑

Tool†

「A5:SQL Mk-2」という変態(←褒め言葉)なソフトがあった 2013

https://dbeaver.io/
- Free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports all popular databases: MySQL, PostgreSQL, MariaDB, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Derby, etc.

データベースもアジャイル開発に対応したい 2008.9.4
- http://www.jiemamy.org/
- Eclipseのプラグインとして動作するDBリファクタリングツール

汎用コネクションプーリングサーバ「SQLrelay」 - 導入編
- http://sqlrelay.sourceforge.net/
Hypertable GoogleのようなハイパフォーマンスDBのクローンとのこと
Object Browserオンラインマニュアル

↑

トランザクションの分離レベル†

DBのロックについてあまり意識したことがない人に向けた実は覚えておきたいロックについての知識 - CARTA TECH BLOG 2022.12

排他制御のためだけに渋々 Redis 使ってませんか？ - Speaker Deck 2022.11
- ロックするものがない場合に、Redisのアトミック機能よりもDBMSのアドバイザリーロック機能を使った方がよいという話

ダーティリード、ノンリピータブルリード、ファントムリードを起こして挙動を確認してみた｜SHIFT Group 技術ブログ｜note 2022.8

↑

ANSI標準の４つの分離レベル†

READ UNCOMMITED
- もっとも安全度低い
- 他プロセスがトランザクション中にUPDATEしたデータをCOMMITする前にSELECT(ダーティリード)可能

READ COMMITED
- デフォルトの分離レベル。引数なしでBeginTrans()するとこれになる(SQL Server 2005)
- ダーティリード不可
- 自分のトランザクション中に、自分がSELECTしただけのレコードは他プロセスがUPDATE-COMMITできる（＝反復不可能読み取りが可）
- つまり、自分のトランザクション中のSELECT結果の一貫性が保証されない
- READ_COMMITED_SNAPSHOTオプションの状態によって動作が異なる
  - OFFのとき、トランザクションにひっかかったクエリは待たされる
  - ONのとき、トランザクションにひっかかったクエリは、トランザクション開始前の状態を取得し、ロック待ちをしない

REPEATABLE READ
- ダーティリード不可
- 自分のトランザクション中に、自分がSELECTしただけのレコードも他プロセスがUPDATE-COMMITできない（＝反復不可能読み取りが不可）
- 自分のトランザクション中に、自分がSELECTした条件にマッチするレコードをINSERT可能（＝ファントム発生可）
- つまり、自分のトランザクション中のSELECT結果は、その時点で存在していたレコードについては同じであることが保証されるが、存在していなかったレコードが追加されている可能性はある

SERIALIZABLE
- ダーティリード、反復不可能読み取り、ファントム発生すべてが不可
- トランザクションのSELECT結果は外部からの影響を一切受けないことが保証される

↑

DBプログラミング一般†

SQL挿入処理の高速化

↑

SQL Server†

SQL Server関連
- T-SQL関連メモ
- MSDEメモ

↑

Oracle†

Oracleに関するメモ

↑

PostgreSQL†

あまり知られていないPostgreSQLの機能 | POSTD 2022.4

オープンソースデータベース標準教科書 -PostgreSQL- (Ver1.0.0） 2011.10.6

↑

SQLite†

↑

Jet/MDAC/DAO†

DAOによるDBの最適化
- DBEngine.CompactDatabase()を使う

Order byをつけなくても順序が保証されることを期待してはいけない。
- DAOを使ってMDBのSelectを行う場合、対象のテーブルにテーブルレイアウト上でキー項目が設定してあったとしても、レコードをキー順に取ってくることは保証されない模様(ORDER BYで指定すれば当然保証される）。特にVistaの場合。キー順になることが保証されると思っている人が多いので注意されたし。