🚤 📦 🍢 ソーシャルネットワークの最高の出版物 🤚🏿 😲 🦗

私の電報チャンネル： https : //t.me/winc0de

こんにちは。空き時間には、ソーシャルプロジェクトを行います。私の友人と私は、さまざまなソーシャルネットワークに十分な数の「パブリック」を持っているため、さまざまな実験を行うことができます。書き込みの問題は、公開できる関連コンテンツとニュースを見つけることです。この点で、最も人気のあるページから投稿を収集し、指定されたフィルターに従ってそれらを発行するサービスを作成するというアイデアが生まれました。最初のテストでは、ソーシャルネットワークVKontakteとTwitterを選択しました。

テクノロジー

まず、データウェアハウスを決定する必要がありました（ところで、保存されたレコードの数は200万を超えています）。この数値は毎日解消されます。要件は次のとおりです。大量のデータを非常に頻繁に挿入し、それらをすばやく選択します。

その前に、私はすでにnosqlデータベースについて聞いていたので、試してみたいと思いました。私が行ったデータベースの比較については説明しません（mysql vs sqlite vs mongodb）。

キャッシングとしてmemcachedを選択しました。後で、その理由とケースを説明します。

Pythonデーモンは、データベースからすべてのグループを同時に更新するデータコレクターとして作成されました。

MongoDBとデーモン

まず、グループからの出版物のコレクターのプロトタイプを作成しました。私はいくつかの問題を見ました：

ストレージ容量
APIの制限

すべてのメタデータを含む1つのパブリケーションには約5〜6KBのデータが必要です。中間グループでは、約20,000〜30,000レコード、グループごとに約175MBのデータが取得され、これらのグループが多数あります。そのため、興味のない出版物をフィルタリングするタスクを設定する必要がありました。

あまり発明する必要はありませんでした。「テーブル」は2つだけです。1つ目は解析と更新が必要なグループのレコードを保存し、2つ目はすべてのグループのすべての出版物の範囲です。今、私には不必要で悪い判断さえしているようです。グループごとにテーブルを作成するのが最善であるため、レコードの選択とソートが簡単になりますが、200万であっても速度は失われません。ただし、このアプローチにより、すべてのグループのサンプル全体が簡素化されます。

API

VKontakteソーシャルネットワークからのデータのサーバー処理が必要な場合は、任意のアクションに対してトークンを発行できるスタンドアロンアプリケーションが作成されます。そのような場合のために、次のアドレスでメモを保存しました。

http://oauth.vk.com/authorize?client_id=APP_ID&redirect_uri=https://oauth.vk.com/blank.html&response_type=token&scope=groups,offline,photos,friends,wall

APP_IDの代わりに、スタンドアロンアプリケーションの識別子を挿入します。生成されたトークンにより、指定されたアクションにいつでもアクセスできます。

パーサーアルゴリズムは次のとおりです。

グループIDを取得し、ループですべてのパブリケーションを取得し、各反復で「悪い」投稿をフィルター処理してデータベースに保存します。

主な問題は速度です。 vkontakte APIを使用すると、1秒間に3つのリクエストを実行できます。 1回のリクエストで、合計100の出版物（1秒あたり300の出版物）を取得できます。

パーサーの場合、これはそれほど悪くありません。1分でグループをマージできますが、更新にはすでに問題があります。グループが多いほど、更新が長くなり、それに応じて、問題はそれほど速く更新されません。

解決策は、ヒープへのAPIへのリクエストを収集し、一度に実行できるexecuteメソッドを使用することでした。したがって、1回のリクエストで、5回の反復を行い、500のパブリケーション（1秒あたり1,500）を取得します。これにより、グループは約13秒で「ドレイン」されます。

実行に渡されるコードを含むファイルは次のとおりです。

 var groupId = -|replace_group_id|; var startOffset = |replace_start_offset|; var it = 0; var offset = 0; var walls = []; while(it < 5) { var count = 100; offset = startOffset + it * count; walls = walls + [API.wall.get({"owner_id": groupId, "count" : count, "offset" : offset})]; it = it + 1; } return { "offset" : offset, "walls" : walls };

コードがメモリに読み込まれ、 replace_group_idおよびreplace_start_offsetトークンが 置き換えられます。その結果、公式のVK APIページvk.com/dev/wall.getで見ることができる出版物の配列を取得します

次のステップはフィルターです。私はさまざまなグループを取り、出版物を調べて、可能なスクリーニングオプションを考え出しました。まず、外部ページへのリンクを持つすべての出版物を削除することにしました。それはほとんど常に広告です。

 urls1 = re.findall('http[s]?://(?:[a-zA-Z]|[0-9]|[$-_@.&+]|[!*\(\),]|(?:%[0-9a-fA-F][0-9a-fA-F]))+', text) urls2 = re.findall(ur"[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[az]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)", text) if urls1 or urls2: #

その後、再投稿を完全に除外することにしました-これは99％の広告です。誰か他の人のページを再投稿する人はほとんどいません。再投稿の確認は非常に簡単です。

 if item['post_type'] == 'copy': return False

item-executeメソッドによって返される壁コレクションの次の要素。

また、古代の出版物の多くは空であり、添付ファイルがなく、テキストは空であることに気付きました。フィルターの場合、アイテム['attachments']およびアイテム['text']が空であることを確認するだけで十分です。

そして、時間の経過とともに推測した最後のフィルター：

 yearAgo = datetime.datetime.now() - datetime.timedelta(days=200) createTime = datetime.datetime.fromtimestamp(int(item['date'])) if createTime <= yearAgo and not attachments and len(text) < 75: #

前の段落と同様に、多くの古い出版物にはテキスト（添付ファイル内の画像の説明）が含まれていましたが、画像自体は保存されていません。

次のステップは、「行かなかった」という失敗した投稿をクリアすることでした。

 db.posts.aggregate( { $match : { gid : GROUP_ID } }, { $group : { _id : "$gid", average : {$avg : "$likes"} } } )

このメソッドは、likesフィールド（パブリケーションのいいねの数）を持つpostsテーブルで実行されます。このグループのいいねの算術平均を返します。

これで、平均以下のいいねが3日以上経過したすべてのパブリケーションを簡単に削除できます。

 db.posts.remove( { 'gid' : groupId, 'created' : { '$lt' : removeTime }, 'likes': { '$lt' : avg } } )

 removeTime = datetime.datetime.now() - datetime.timedelta(days=3) avg =   ,    ( ).

結果としてフィルタリングされたパブリケーションをデータベースに追加すると、この解析は終了します。グループの解析と更新の違いは、1つの点のみでした。更新は、グループに対して1回だけ呼び出されます。最後の500エントリのみを取得します（5〜100実行）。 VKontakteが出版物の数に制限を設けていることを考えると、これで十分です：1日あたり200。

フロントエンド

javascript + jquery + isotope + inview + moustacheについてはあまり詳しく説明しません。

同位体は、タイル形式の出版物の最新の出力に使用されます。
Inviewを使用すると、特定の要素のビューポートにヒットするイベントに簡単に応答できます。（私の場合、見た出版物を覚えており、新しい出版物を特別な色で強調表示しています）。
Moustacheを使用すると、テンプレートでdomオブジェクトを構築できます。

グループ投稿フィルター

グループごとにデータを出力するために、簡単なphpスクリプトが作成されました。

これは、時間フィルターの種類によって、リクエストで直接使用できるオブジェクトを作成するヘルパー関数です。

  function filterToTime($timeFilter) { $mongotime = null; if ($timeFilter == 'year') $mongotime = new Mongodate(strtotime("-1 year", time())); else if ($timeFilter == 'month') $mongotime = new Mongodate(strtotime("-1 month", time())); else if ($timeFilter == 'week') $mongotime = new Mongodate(strtotime("-1 week", time())); else if ($timeFilter == 'day') $mongotime = new Mongodate(strtotime("midnight")); else if ($timeFilter == 'hour') $mongotime = new Mongodate(strtotime("-1 hour")); return $mongotime; }

そして、次のコードは、今月のベスト15の投稿を既に受け取ります。

 $groupId = 42; // - id  $mongotime = filterToTime('week'); $offset = 1; //   $findCondition = array('gid' => $groupId, 'created' => array('$gt' => $mongotime)); $mongoHandle->posts->find($findCondition)->limit(15)->skip($offset * $numPosts);

ロジックインデックスページ

グループの統計を見るのは面白いですが、絶対にすべてのグループとその出版物の一般的な評価を作成する方がはるかに興味深いです。あなたがそれについて考えるならば、タスクは非常に難しいです：

評価は、3つの要因（いいね！、再投稿、サブスクライバーの数）によってのみ作成できます。チャンネル登録者が多いほど、いいね！と再投稿が増えますが、これはコンテンツの品質を保証するものではありません。

ほとんどの億万長者グループは多くの場合、インターネットを数年間サーフィンしてきたすべてのゴミを発行します。

裸の数字に基づいて評価を作成するのは簡単ですが、決して得られた結果は、出版物の品質と独自性による評価とは言えません。

各グループの品質係数を導き出すためのアイデアがありました：時間スケールを構築し、各期間のユーザーアクティビティを監視します。

残念ながら、私は適切な解決策を思いつきませんでした。何かアイデアがあれば、喜んで聞きます。

私が最初に気づいたのは、インデックスページのコンテンツを計算し、すべてのユーザーに対してキャッシュする必要があるという認識でした。非常に遅い操作だったからです。これがmemcachedの助けとなります。最も単純なロジックでは、次のアルゴリズムが選択されました。

すべてのグループを循環します
i番目のグループのすべての出版物を取得し、指定された期間に最適なものを2つ選択します

その結果、1つのグループからの出版物は2つまでになります。もちろん、これは最も正確な結果ではありませんが、実際には、良好な統計とコンテンツの関連性を示しています。

ストリームコードは次のようになります。15分ごとにインデックスページが生成されます。

  # timeDelta -     (hour, day, week, year, alltime) # filterType - likes, reposts, comments # deep - 0, 1, ... () def _get(self, timeDelta, filterTime, filterType='likes', deep = 0): groupList = groups.find({}, {'_id' : 0}) allPosts = [] allGroups = [] for group in groupList: allGroups.append(group) postList = db['posts'].find({'gid' : group['id'], 'created' : {'$gt' : timeDelta}}) \ .sort(filterType, -1).skip(deep * 2).limit(2) for post in postList: allPosts.append(post) result = { 'posts' : allPosts[:50], 'groups' : allGroups } #     timestamp  mongotime,    json dthandler = lambda obj: (time.mktime(obj.timetuple()) if isinstance(obj, datetime.datetime) or isinstance(obj, datetime.date) else None) jsonResult = json.dumps(result, default=dthandler) key = 'index_' +filterTime+ '_' +filterType+ '_' + str(deep) print 'Setting key: ', print key self.memcacheHandle.set(key, jsonResult)

発行に影響するフィルターについて説明します。

時間：時間、日、週、月、年、常時

タイプ：いいね、再投稿、コメント

すべての時点でオブジェクトが生成されました。

  hourAgo = datetime.datetime.now() - datetime.timedelta(hours=3) midnight = datetime.datetime.now().replace(hour=0, minute=0, second=0, microsecond=0) weekAgo = datetime.datetime.now() - datetime.timedelta(weeks=1) monthAgo = datetime.datetime.now() + dateutil.relativedelta.relativedelta(months=-1) yearAgo = datetime.datetime.now() + dateutil.relativedelta.relativedelta(years=-1) alltimeAgo = datetime.datetime.now() + dateutil.relativedelta.relativedelta(years=-10)

それらはすべて、タイプ（likes、reposts、comments）によるさまざまなフィルターバリエーションとともに_get関数に順番に渡されます。これらすべてに加えて、フィルターバリエーションごとに5ページを生成する必要があります。その結果、次のキーがmemcachedに付加されます。

設定キー：index_hour_likes_0

設定キー：index_hour_reposts_0

設定キー：index_hour_comments_0

設定キー：index_hour_common_0

設定キー：index_hour_likes_1

設定キー：index_hour_reposts_1

設定キー：index_hour_comments_1

設定キー：index_hour_common_1

設定キー：index_hour_likes_2

設定キー：index_hour_reposts_2

設定キー：index_hour_comments_2

設定キー：index_hour_common_2

設定キー：index_hour_likes_3

設定キー：index_hour_reposts_3

設定キー：index_hour_comments_3

設定キー：index_hour_common_3

設定キー：index_hour_likes_4

設定キー：index_hour_reposts_4

設定キー：index_hour_comments_4

設定キー：index_hour_common_4

設定キー：index_day_likes_0

設定キー：index_day_reposts_0

設定キー：index_day_comments_0

設定キー：index_day_common_0

設定キー：index_day_likes_1

設定キー：index_day_reposts_1

設定キー：index_day_comments_1

設定キー：index_day_common_1

設定キー：index_day_likes_2

設定キー：index_day_reposts_2

設定キー：index_day_comments_2

設定キー：index_day_common_2

設定キー：index_day_likes_3

設定キー：index_day_reposts_3

...

クライアント側では、目的のキーのみが生成され、json文字列がmemcachedから取り出されます。

Twitter

次の興味深いタスクは、CIS諸国で人気のあるツイートを生成することでした。また、このタスクは簡単ではありません。関連情報を受け取り、「ゴミ」の情報は受け取りません。 Twitterの制限に非常に驚きました。特定のユーザーのすべてのツイートを取り込んでマージするのはそれほど簡単ではありません。 APIはリクエストの数を非常に制限するため、VCのようにはできません。人気のあるアカウントのリストを作成し、ツイートを常に解析します。

1日後、Twitterでアカウントを作成し、出版トピックが関心のあるすべての重要な人々を購読します。秘Theは、ケースのほぼ80％で、これらの人々の1人が人気のあるツイートをリツイートすることです。つまりデータベースにすべてのアカウントのリストを保持する必要はありません。常に流行している500〜600人のアクティブな人々のデータベースを収集し、本当に興味深く人気のあるツイートをリツイートすれば十分です。

Twitter APIには、フォローしているユーザーのツイートとその再投稿を含むユーザーフィードを取得できるメソッドがあります。今必要なのは、VKontakteで行うように、テープを10分ごとに最大まで読み取り、ツイート、フィルター、その他すべてを保存することです。

そのため、別のスレッドがデーモン内に書き込まれ、10分に1回このようなコードが実行されました。

  def __init__(self): self.twitter = Twython(APP_KEY, APP_SECRET, TOKEN, TOKEN_SECRET) def logic(self): lastTweetId = 0 for i in xrange(15): #     self.getLimits() tweetList = [] if i == 0: tweetList = self.twitter.get_home_timeline(count=200) else: tweetList = self.twitter.get_home_timeline(count=200, max_id=lastTweetId) if len(tweetList) <= 1: print '1 tweet, breaking' # ,   API    break # ... lastTweetId = tweetList[len(tweetList)-1]['id']

さて、通常の退屈なコード：tweetListがあり、各ツイートをループして処理します。公式ドキュメントのフィールドのリスト。私が集中したい唯一のもの：

  for tweet in tweetList: localData = None if 'retweeted_status' in tweet: localData = tweet['retweeted_status'] else: localData = tweet

リツイートの場合、購読者のツイートではなく、元のツイートを保存する必要があります。現在のレコードがリツイートである場合、キー 'retweeted_status'内にはまったく同じツイートオブジェクトが含まれ、元のレコードのみが含まれます。

ファイナル

サイトの設計とレイアウトには問題があります（私自身はWebプログラマーではありません）が、誰かが説明した有益な情報を持っていることを願っています。私自身は、社会サービスと長い間仕事をしています。ネットワークとそのAPI、そして私は多くのトリックを知っています。誰か質問があれば、喜んでお手伝いします。

さて、いくつかの写真：

インデックスページ：

私が常に監視しているグループの1つのページ：

1日あたりのTwitter：

ご清聴ありがとうございました。

-88.198.106.150

ソーシャルネットワークの最高の出版物