ローカルタイムラインを保持する方法について #20

New Issue

kenmo-melon · 2023-10-05T23:12:28+09:00

kenmo-melon commented

2023-10-05 23:12:28 +09:00

First-time contributor

ちょっとPHPのjson_decode/json_encodeの仕様が不透明でJSONで保持するのは怖いなあ、と思ってしまいました。jsonファイルが一度壊れると手動で直さないと復旧できない、というのも嫌な感じです。ただredisのようなインメモリDBを使うのはさすがに大げさな気もしますし、何かいい方法はないでしょうか。

apple commented

2023-10-05 23:38:09 +09:00

First-time contributor

ぶっちゃけてしまいすとモデレーションのために検索が今後必要になると思われるので(現状おそらくそれを同じjsonをベースに書き込みログを生成している臭い）、結局DBを導入したほうが長期的にみると無難ではないかなと考えています
複数端末による自演、規制回避ユーザーなどを調べるための強化版必死チェッカーが求められていますので・・・

ぶっちゃけてしまいすとモデレーションのために検索が今後必要になると思われるので(現状おそらくそれを同じjsonをベースに書き込みログを生成している臭い）、結局DBを導入したほうが長期的にみると無難ではないかなと考えています複数端末による自演、規制回避ユーザーなどを調べるための強化版必死チェッカーが求められていますので・・・

apple commented

2023-10-05 23:49:37 +09:00

First-time contributor

また集団による荒らし（アフィカスグループによる荒らし/ネトウヨ・ネトサポによるスレ荒らし/Twitterなどのインフルエンサーからのファンネル飛ばし)のような判断の難しい荒らされているスレを管理者側が比較的炙りやすくするためにはグラフが必要になると思いますので将来的には結局DBが必要になるのではないかなと思います
この手の荒らし方は非常に質が悪く、対抗するためには管理者への負担もでかいのでシステムで補っていかないと難しいかなと

備考
データで見破るフェイクニュースの傾向とは？ SNSに潜む社会の「空気感」の数理的構造解明に挑む筑波大佐野幸恵助教
https://www.rikelab.jp/post/3144.html

また集団による荒らし（アフィカスグループによる荒らし/ネトウヨ・ネトサポによるスレ荒らし/Twitterなどのインフルエンサーからのファンネル飛ばし)のような判断の難しい荒らされているスレを管理者側が比較的炙りやすくするためにはグラフが必要になると思いますので将来的には結局DBが必要になるのではないかなと思いますこの手の荒らし方は非常に質が悪く、対抗するためには管理者への負担もでかいのでシステムで補っていかないと難しいかなと備考データで見破るフェイクニュースの傾向とは？ SNSに潜む社会の「空気感」の数理的構造解明に挑む筑波大佐野幸恵助教 <https://www.rikelab.jp/post/3144.html>

kenmo-melon commented

2023-10-06 00:10:25 +09:00

First-time contributor

なるほど、ありがとうございます
現状の使い方だとRedisのようなKV型のデータベースで十分かと思っていたのですが、最初からRDBMSで作ってしまうのも手かもしれませんね

なるほど、ありがとうございます現状の使い方だとRedisのようなKV型のデータベースで十分かと思っていたのですが、最初からRDBMSで作ってしまうのも手かもしれませんね

apple commented

2023-10-06 00:19:11 +09:00

First-time contributor

私はど素人ですのでなんとも言えませんが可視化するとき比較的マシなNeo4jに渡すのが楽なものを選ぶのがいいんじゃないかなと考えてます
もちろん掲示板自体のパフォーマンスが優先ではありますが

私はど素人ですのでなんとも言えませんが可視化するとき比較的マシなNeo4jに渡すのが楽なものを選ぶのがいいんじゃないかなと考えてますもちろん掲示板自体のパフォーマンスが優先ではありますが

kenmo-melon commented

2023-10-06 01:54:49 +09:00

First-time contributor

なるほど、可視化についても少し調べてみます
私もそれほどDBに詳しいわけではないので、もう少し色々な人の知恵を頼ったほうがいいかもしれませんね
ただ今のコードに合わせて実装しやすいのはRedisかなあという感じはします

なるほど、可視化についても少し調べてみます私もそれほどDBに詳しいわけではないので、もう少し色々な人の知恵を頼ったほうがいいかもしれませんねただ今のコードに合わせて実装しやすいのはRedisかなあという感じはします

apple commented

2023-10-06 07:44:16 +09:00

First-time contributor

DDoSが来たときにメモリ足りるのか
これがわからない
dashboardのURLをお伝えしてkenmo-melonさんにどういう状況なのかという現状を見てもらうのが一番早そうですが、そういうのを勝手に渡してもいいのか
これもわからない
もしよければ統計部員2さんにURLを渡してもらうようにお願いできませんか？

DDoSが来たときにメモリ足りるのかこれがわからない dashboardのURLをお伝えしてkenmo-melonさんにどういう状況なのかという現状を見てもらうのが一番早そうですが、そういうのを勝手に渡してもいいのかこれもわからないもしよければ統計部員2さんにURLを渡してもらうようにお願いできませんか？

kenmo-melon commented

2023-10-06 11:04:55 +09:00

First-time contributor

自分にDDoSに対処した知識・経験はないのでお役に立てるか自信はないのですが、どちらかというとDBへのアクセス部分がボトルネックになりそうなので、プログラム側で接続の持ち方を工夫すればいいのかなという気はします。
ちょっと後で統計部員2さんに聞いてみますね。

自分にDDoSに対処した知識・経験はないのでお役に立てるか自信はないのですが、どちらかというとDBへのアクセス部分がボトルネックになりそうなので、プログラム側で接続の持ち方を工夫すればいいのかなという気はします。ちょっと後で統計部員2さんに聞いてみますね。

kenmo-melon commented

2023-10-06 14:09:25 +09:00

First-time contributor

やはり拡張パッケージ(https://pgroonga.github.io/ja/)をいれれば日本語全文検索ができるPostgresがいいかもです。定番だし情報も一番多いと思うので。

alice2ch commented

2023-10-06 15:20:38 +09:00

First-time contributor

横から。

NDJSONを利用するのがいいと思います。
（行単位で壊れてしまったとしても、壊れた行をスキップするだけで済みます）

また、分析を行うのであればFluentd / Logstashのようなログ収集基盤を使って転送する方がいいでしょう。

横から。 NDJSONを利用するのがいいと思います。（行単位で壊れてしまったとしても、壊れた行をスキップするだけで済みます）また、分析を行うのであればFluentd / Logstashのようなログ収集基盤を使って転送する方がいいでしょう。

kenmo-melon commented

2023-10-06 17:32:24 +09:00

First-time contributor

ありがとうございますー
確かに現状の使い方ではndjsonなども良さそうです
また、私が一つ気づいたのは、ndjsonなど「ファイル全体を読み込まず追記するだけでいいデータ構造」もしくはDBを使う場合、恐らくPHP側でデータ全体をロードする必要はないのかな、という点です。たぶん「datに追記」「ndjson等に追記orDBに追加」だけすればいいです。
この方式だとjsonを読み込んで落ちるということはなさそうです。

もう一つ問題になるのが管理画面やブラウザ版とのデータの受け渡しですが、これはjson以外を使うと少しややこしくなるのかなと思ってます。ただDBにfetchするにしてもndjsonなどのデータを読み込むにしても大した手間ではないでしょう。

また、分析を行うのであればFluentd / Logstashのようなログ収集基盤を使って転送する方がいいでしょう。

私は経験がないのでなんとも言い難いところですが...ログ収集基盤・解析基盤を整備する人的・金銭的コスト次第といったところでしょうか？DBにつっこんでおくだけでもまあなんとかならなくはないと思いますし(今後の書き込み数次第かもしれませんが)

ありがとうございますー確かに現状の使い方ではndjsonなども良さそうですまた、私が一つ気づいたのは、ndjsonなど「ファイル全体を読み込まず追記するだけでいいデータ構造」もしくはDBを使う場合、恐らくPHP側でデータ全体をロードする必要はないのかな、という点です。たぶん「datに追記」「ndjson等に追記orDBに追加」だけすればいいです。この方式だとjsonを読み込んで落ちるということはなさそうです。もう一つ問題になるのが管理画面やブラウザ版とのデータの受け渡しですが、これはjson以外を使うと少しややこしくなるのかなと思ってます。ただDBにfetchするにしてもndjsonなどのデータを読み込むにしても大した手間ではないでしょう。 > また、分析を行うのであればFluentd / Logstashのようなログ収集基盤を使って転送する方がいいでしょう。私は経験がないのでなんとも言い難いところですが...ログ収集基盤・解析基盤を整備する人的・金銭的コスト次第といったところでしょうか？DBにつっこんでおくだけでもまあなんとかならなくはないと思いますし(今後の書き込み数次第かもしれませんが)

kenmo-melon commented

2023-10-08 12:20:03 +09:00

First-time contributor

@stat2 @apple こちら、今後もdelightlyを使用していく予定であれば私の方で実験的に実装してみますが、どうしますか？

👍 3

stat2 commented

2023-10-08 19:10:19 +09:00

出来ればdelightlyを改修して使っていきたいです。VPSなので色々自由は効きます。ただ、他の掲示板運営者も共有ホスティングで使用できるというメリットが大きいので、使うとしたらPostgresが最有力で他にエクスポート等可能、あるいはオプションとして使える形がいいと考えています。

現在運営に関わるサーバーは3台体制で、その内1台はs3互換オブジェクトストレージをインストールしているため、NGINXログや過去ログdatもそこに飛ばせるといいなと、alice2chさんの言うFluentd等調べているとことでした。

ちょっと疲れていて的外れなこと書いているかもしれませんがいかがでしょうか。

追記：ローカルタイムラインというよりは全体のログも含めての意見です。今のdelightlyはログの保存、閲覧の仕様も少し問題があります。

出来ればdelightlyを改修して使っていきたいです。VPSなので色々自由は効きます。ただ、他の掲示板運営者も共有ホスティングで使用できるというメリットが大きいので、使うとしたらPostgresが最有力で他にエクスポート等可能、あるいはオプションとして使える形がいいと考えています。現在運営に関わるサーバーは3台体制で、その内1台はs3互換オブジェクトストレージをインストールしているため、NGINXログや過去ログdatもそこに飛ばせるといいなと、alice2chさんの言うFluentd等調べているとことでした。ちょっと疲れていて的外れなこと書いているかもしれませんがいかがでしょうか。追記：ローカルタイムラインというよりは全体のログも含めての意見です。今のdelightlyはログの保存、閲覧の仕様も少し問題があります。

Sign in to join this conversation.