→データ処理関連
→データ移行
→AWS データ処理系サービス <RDSについてはこちら
→AWSストレージ関連
サブトピック†
DB一般†
NewSQL†
NoSQL†
- 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†
- 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.
トランザクション†
ANSI標準の4つの分離レベル(アイソレーションレベル)†
- 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 Server†
Oracle†
PostgreSQL†
SQLite†
- なぜSQLiteはバイトコードを使うのか 2024.5
- バイトコードが人間にとって理解しやすい
- バイトコードはデバッグがしやすい
- ステートメントを段階的に実行できる
- メモリ消費量が少ない
- 実行速度が速い(と考えられている)
Jet/MDAC/DAO†
- Order byをつけなくても順序が保証されることを期待してはいけない。
- DAOを使ってMDBのSelectを行う場合、対象のテーブルにテーブルレイアウト上でキー項目が設定してあったとしても、レコードをキー順に取ってくることは保証されない模様(ORDER BYで指定すれば当然保証される)。特にVistaの場合。キー順になることが保証されると思っている人が多いので注意されたし。
→Office関連メモ
HSQLDB†
DB2†
その他†