This account is not set to public on notestock.

ActivityPubのリレー、サーバーの負荷上がる割に得られる恩恵そこまでないなというのが正直なところ

ぽよだよ

BIOSアプデした

This account is not set to public on notestock.

きつね

NewDBの類、LSMTreeの長所・短所を理解した上で設計しないとスケールしないし、単純に置き換えれば全て解決するってことではないらしいよ。

今はNoSQLじゃなくて、NewSQLがホットですよ。
TiDB, YugabyteDB, CockroachDBとかね。

RDBで主流だったBTreeじゃなくて、LSMTreeっていうやつを使うんだって。NoSQLで蓄えられた知見を使った新しいSQLエンジンだよ。

別に1つのサーバーに多くのユーザーが集中してても、そこまで問題では無いと思うよ。

ただ技術的課題として、その規模にスケールさせる設計にしたら、LTLは表示出来なくなるであろうってのはあるよ。

Facebook, TwitterがDBどうしてる系記事は、同じSNSのDBスケールについて考える時は必見だと思う。

ポスグレにスケーラビリティの問題が出てきたときに真っ先に検討したい、マネージドサービスのDBはGoogle Cloud Spannerだと思う。

Amazon RDSは所詮、毛の生えたポスグレってイメージ。

Twitterだって最初はMySQLで作ってたけど、途中からCassandra入れたり、最後にはManhattanって独自のDB作ったりしてたからね。

スケーラビリティのためにNoSQLにするという線はなくはないとは思う。

だけど、それならTiDBとかNewSQL的ソリューションじゃダメなのとか、そもそもFediverseの実装に最適なスケールするDB設計とはってところから始めないといけなさそう。

日本企業が近視眼的な「技術」に目を取られてるうちに、Adobeとか国際的な大企業は「環境」を作るムーブを取ってるし、そもそも闘う土俵を考えたほうがいいんじゃないんですかね、というのを、未だにクリスタの生成AI機能搭載とりやめにうだうだ言ってる生成AI狂信派チックな人を見て思いました。

一方でAdobeさんは、「コンテンツ認証イニシアチブ」っていってコンテンツの来歴とか編集情報をトラックできる技術に力を入れたり、ポスト生成AIの時代に備えた動きを万全にやってる印象がある。
https://t.co/a9ukx7n4nW

技術デモの内容をそのまま搭載しましたって言われても、結局別ソフトでやったほうが更新とか小回り効きそうでいいじゃんってなる。発展の早い生成AIなら尚更。

クリスタはそういう機能ばっかで、生成AI機能についても微妙に思ってたので、別に実装とりやめでもどーでもいいかなって思ってた。

お絵かきソフトウェア作る会社に求められてるムーブ、拙速に生成AIを使う機能を本体に搭載することよりも、手段は問わずクリエイター側が権利的に安心して生成AIを使える環境を整備することだよなぁ。