-
- いいね！347
こば -Koba as a DB engineer-
@tzkb
Disaggregated HCIがあるなら、AggregatedなNewSQLがあっても良いのかも知れない。
2020-01-27 12:44:25
こば -Koba as a DB engineer-
@tzkb
[SQLite Is Serverless] へーってなった。曰くSQLiteはClassic Serverlessでアプリケーションと同じプロセス・名前空間で実行される（サーバ的な別プロセスがない=Serverless）。 最近のCosmos DBとかはNeo-Serverlessと。Aurora Serverlessも多分そう。 sqlite.org/serverless.html
2020-01-27 18:09:26
こば -Koba as a DB engineer-
@tzkb
client/serverモデルにおけるserverが居ないことをServerlessとする古典派もいて、「最近のはmanageableなnodeがないだけじゃろ？」とか言う人がいるのかも知れない。
2020-01-27 18:31:22
こば -Koba as a DB engineer-
@tzkb
RocksDBが近年開発されているシェアードナッシング型の分散DBで多く使われている。Facebookも自作のストレージエンジンではなくRocksDBを採用してるぜ、というお話。 rockset.com/blog/rocksdb-i…
2020-01-28 08:54:03
こば -Koba as a DB engineer-
@tzkb
RocksDBの話が伸びてるので、TiKVの記事も一つ紹介。CNCF Incubatingな分散KVSで、こちらも内部にRocksDBが使われている。Raftログの用とデータ保存用の2種類。 TiKVではRawKVとTxnKVという2つのAPIが用意されており、TiDBでは当然TxnKVが使われる。 pingcap.com/blog/how-tikv-…
2020-01-28 19:05:45
こば -Koba as a DB engineer-
@tzkb
NewSQLの解説記事。NoSQLが満たせなかったものを実現するために、VitessやCitusのようなShardingやSQLエンジン+分散ストレージの2種類のアプローチがあったと紹介されている。Citusなどの弱点も書かれており興味深い。 blog.yugabyte.com/distributedsql…
2020-01-29 08:46:44
こば -Koba as a DB engineer-
@tzkb
もちろんYugaByteDBのブログなよで、過去のDBの評価は辛めだけど、Shardingと他の分散SQLデータベースを比較しているものは貴重。
2020-01-29 08:49:21
こば -Koba as a DB engineer-
@tzkb
TiKVがどんな仕組みで大規模な分散ストレージを実現しているかについて。どのようにShardingするかは重要で、rangeまたはhashから選択する。TiKVはTiDB(MySQL互換の分散SQL)での利用を想定し、rangeを採用している。 #distributedsql pingcap.com/blog/building-…
2020-01-30 08:42:41
こば -Koba as a DB engineer-
@tzkb
rangeかhashかというのは以前Y7DBやC8DBでも紹介した通り、各プロダクトの設計方針に根付いている。rangeはRDBによく見られる範囲検索に強いが、hotspotが生まれる。hashは範囲検索に弱いが、hotspotが生まれにくい。さらにTiKVはhashはリバランス負荷が高いと言っているが、そこは疑問。
2020-01-30 08:48:23
こば -Koba as a DB engineer-
@tzkb
TiKVでは複数のRaftグループを用いてレプリケーションをしているが、etcdやconsulなど単一のRaftグループを扱うものとは実装が異なり複雑。この辺はY7DBなどでも同じ。
2020-01-30 08:54:09
こば -Koba as a DB engineer-
@tzkb
ちなみに、 Y7DB = YugaByteDB C8DB = CockroachDB と読み替えてください。
2020-01-30 08:55:12
こば -Koba as a DB engineer-
@tzkb
#DatabaseInternals の5章を読み直してるのだけど、 - ロック:論理整合性、キー単位で獲得される - ラッチ:物理整合性、ページ(ブロック)単位で獲得される の説明が分かりやすくて、何故私は20年DB触ってるのにこの説明が出来なかったのかと思う。
2020-01-31 22:56:44
こば -Koba as a DB engineer-
@tzkb
CassandraからNewSQL、CockroachDBに移行した話。Cassandraのデータモデルに対応するために特別な設計が必要だったが、SQLは柔軟で整合性も担保されてて良いということだ。 #distributedsql cockroachlabs.com/blog/cassandra…
2020-02-01 09:24:36
こば -Koba as a DB engineer-
@tzkb
少し前のブログだが、CAPのうち、APからCPにフォーカスが移ることでNewSQLが台頭したとするもの。Cのないデータストア上でアプリ開発をするのは(不可能ではないが)非常に難しく、一方Aは完全な(100%の)保証はありえないから。 #distributedsql dbmsmusings.blogspot.com/2018/09/newsql…
2020-02-02 16:37:51
こば -Koba as a DB engineer-
@tzkb
分散システムで最小限のコストで一貫性を保証するにはPaxos/Raftを用いるが、単一のコンセンサスグループを使うDBと複数グループを使うものがあります。後者がSpannerやそのクローン(CockroachDBやYugaByteDB)です。
2020-02-02 16:56:13
こば -Koba as a DB engineer-
@tzkb
YugaByteによる4つのSharding戦略の話。先日紹介したrangeとhash(consistent hash sharding)の他、Algorithmic ShardingとLinear Hash Shardingが紹介されている。Linear Hash Shardingは初期Cassandraで採用されたが問題があり、現在は非推奨とのこと。 #distributedsql blog.yugabyte.com/four-data-shar…
2020-02-03 08:47:19
こば -Koba as a DB engineer-
@tzkb
Algorithmic ShardingはmemcachedやRedisで使われ、メタデータ管理が不要だが、rebalanceやprewarmのコスト・影響範囲が高いという欠点がある。
2020-02-03 08:54:28
こば -Koba as a DB engineer-
@tzkb
Linear Hash Shardingは相対的順序を保証しつつデータを複数Shardに分割する筈だったが、分離境界を適切に設定するのが難しく、hot spotが避けられなかった。そのためCassandraでもconsistent hash Shardingが後に採用されている。
2020-02-03 08:58:12