「Ignite」を含む日記

■anond:20240918152313

クリックデータの集計において、毎回全データに対して集計SQLを実行すると時間がかかりすぎ、一方でバッチ処理で集計結果を保存すると、その後に発生したクリックをリアルタイムで反映できないという問題があります。この課題を解決するためには、以下の方法を検討すると効果的です。

---

### **1. インクリメンタル集計の導入**

方法**:

• **累積集計の更新**: 既存の集計結果に新しいクリックデータを追加することで、全データを再計算せずに最新の集計結果を得る。
• **トリガーやストアドプロシージャの活用**: データベースで新しいレコードが追加された際に、自動的に集計テーブルを更新する仕組みを構築する。

利点**:

• データの追加ごとに小さな計算で集計結果を更新できるため、高速でリアルタイム性が高い。

---

### **2. リアルタイムストリーミング処理の活用**

方法**:

• **Apache KafkaやApache Flink、Apache Spark Streamingの利用**: これらのツールを使用して、データストリームをリアルタイムで処理・集計する。
• **イベント駆動型アーキテクチャ**: 新しいクリックが発生するたびにイベントとして処理し、リアルタイムで集計結果を更新する。

利点**:

• リアルタイムでのデータ処理と集計が可能。
• 大量のデータを効率的に処理できるスケーラビリティ。

---

### **3. データウェアハウスとマテリアライズドビューの利用**

方法**:

• **データウェアハウスの構築**: BigQuery、Amazon Redshift、Snowflakeなどのクラウドデータウェアハウスを使用して、大量のデータを高速にクエリ可能な形で保存する。
• **マテリアライズドビュー**: 集計結果をマテリアライズドビューとして保存し、定期的またはトリガーで更新する。

利点**:

• 大量データに対するクエリが高速。
• マテリアライズドビューにより、最新データを含む集計結果を効率的に取得可能。

---

### **4. NoSQLデータベースの活用**

方法**:

• **時系列データベース**: InfluxDB、TimescaleDBなどを使用して、時系列データの集計とクエリを高速化する。
• **キーバリューストア**: Redisなどを使用して、集計結果をキャッシュし、必要に応じて更新する。

利点**:

• 時系列データの処理に特化しており、高速な集計が可能。
• データの追加や更新が高速で、リアルタイム性を確保できる。

---

### **5. キャッシュとインメモリデータグリッドの使用**

方法**:

• **インメモリデータグリッド**: Apache Ignite、Hazelcastなどを使用して、データをメモリ上で分散管理し、高速な集計を可能にする。
• **キャッシュ層の導入**: 頻繁にアクセスされる集計結果をキャッシュし、新しいデータが発生したときのみキャッシュを更新する。

利点**:

• メモリ上での処理により、高速なデータアクセスと集計が可能。
• キャッシュを活用することで、データベースへの負荷を軽減。

---

### **6. ラムダアーキテクチャの採用**

方法**:

• **バッチ層とスピード層の分離**: バッチ層で定期的な全体集計を行い、スピード層でリアルタイムの増分データを処理する。
• **データの統合**: 最終的な集計結果は、バッチ層とスピード層の結果を組み合わせて得る。

利点**:

• バッチ処理の利点（高い精度）とリアルタイム処理の利点（最新データの反映）を両立。
• スケーラブルで柔軟なアーキテクチャ。

---

### **7. ウィンドウ関数と部分集計の活用**

方法**:

• **時間ウィンドウを設定**: データを時間帯（例：1時間ごと、1日ごと）に分割し、部分的な集計を行う。
• **部分集計結果の組み合わせ**: 必要な期間の部分集計結果を合算して全体の集計結果を得る。

利点**:

• データの分割により、各集計処理の負荷を軽減。
• 新しいデータが発生しても、該当するウィンドウの集計のみ更新すればよい。

---

### **8. メッセージキューと非同期処理の導入**

方法**:

• **メッセージキュー（RabbitMQ、AWS SQSなど）の使用**: クリックイベントをメッセージとしてキューに送り、非同期に処理・集計する。
• **ワーカーのスケーリング**: 非同期処理を行うワーカーを必要に応じて増やし、処理性能を向上させる。

利点**:

• 非同期処理により、リアルタイム性を維持しつつシステムの負荷を平準化。
• スケーラビリティが高く、処理量に応じて柔軟に対応可能。

---

### **まとめと提案**

• **リアルタイム性とパフォーマンスの両立**: インクリメンタル集計やストリーミング処理を導入することで、最新のクリックデータを含む集計結果を高速に取得できます。
• **適切なツールとアーキテクチャの選択**: データの規模や必要なリアルタイム性に応じて、ストリーミング処理、データウェアハウス、NoSQLデータベースなどを選択します。
• **スケーラビリティの確保**: 将来的なデータ増加を見据えて、スケーラブルなシステム設計を行います。

---

具体的なステップ**:

1. **要件の明確化**: リアルタイム性の程度、データ量、システムリソースなどを考慮して要件を定めます。

2. **プロトタイプの構築**: 小規模なデータでインクリメンタル集計やストリーミング処理のプロトタイプを作成し、性能を評価します。

3. **システムの実装**: 選定した方法とツールを用いて、実際のシステムを構築します。

4. **モニタリングと最適化**: システムのパフォーマンスをモニタリングし、必要に応じて最適化やスケールアップを行います。

---

参考ツールと技術**:

• **データベース**: TimescaleDB（PostgreSQLベースの時系列データベース）、Amazon Redshift、Google BigQuery
• **ストリーミング処理**: Apache Kafka、Apache Flink、Apache Spark Streaming
• **キャッシュ**: Redis、Memcached
• **データウェアハウス**: Snowflake、Amazon Redshift
• **メッセージキュー**: RabbitMQ、Apache ActiveMQ、AWS SQS

---

ご質問の課題に対して、リアルタイム性とパフォーマンスを両立する方法として、インクリメンタル集計やストリーミング処理の導入を強くお勧めします。これにより、新しいクリックデータを即座に集計結果に反映しつつ、全データに対する集計処理の負荷を大幅に削減できます。

Permalink | 記事への反応(0) | 15:32

ツイートシェア

■言語学馬鹿にしてたわ

数学程ではないが高度な識者同士の議論になると言語学でも何言ってるのか分からんもんなんだな

テレビでありがちなことわざや語源系の蘊蓄のイメージで言語学全体があんなんだったら程度が低い学問だろって馬鹿にしてたんだわな

71鳩摩羅童子（くまら どうじ）2022/10/15(土) 14:33:31.920

68へ

> キミの言う「山ほどある」という対応例を、2、3、ここで提示してほしい

まず、確認しておくが (b-a) という表記は、発音「b」が発音「a」に化けた、ということを表す。before-after の順番の並び。

例えば (b-p) の音通例。--- web 内 page 検索 (Ctrl+F) で 「b-p」と入れれば、在れば、引っ掛かる。

ex0. http://www5d.biglobe.ne.jp/~the_imai/etymology/AA_Indo.html

ex1. http://www5d.biglobe.ne.jp/~the_imai/etymology/Grimm's_Law_in_J_20.html

結果

[ﾊﾁ137] ◆へっぞ◆へっそめ◆へっちょめ◆へっつをめ　　　（トンボ。）

【ﾁﾍﾞ】bu bla ma ni (= dragonfly [IW]) へっそめ (b-p, l-s)

ex2. http://www5d.biglobe.ne.jp/~the_imai/etymology/Grimm's_Law_in_J_17.html

結果

18

↑ jepi₁ 窓枠 不明 oNpi₁ c. window, frame, sash 全てイマイチ。しかし、これ以外の候補は考えられない。　→　やはり、有った。

【趣】ab (= : window; opening; niche 隙間, nook 〔部屋の〕片隅、引っ込んだ場所 (cf., aba) [AB archaic frequency; 384; concatenates 2 sign variants (sign also used for èš and aba - for this reading and meaning in Fara period, see Krebernik, Beschworungen]. ) あぶ／あば、おんぴ (+ん, b-pi), いぇぴ (a-ye)

32

↑ pu 火 武藏 pi, po₂ cf. スワデシュ・リスト 207 個の単語の検証（鑑定）167 番の fire

【趣】bul(4); bu(5) (=: to blow; to ignite 点火する, kindle; to sprout (onomatopoeic). ) ぶ、ひ (b-p)

2

↑ isajo₁p(i₁|u) 躊躇う 不明 isajup

【賛】dvaMdvIbhU (= to become joined in couples BhP. ; to engage in single combat MBh. ; to hesitate or be doubtful (cf. %{-dva-bhUta}).) いさよふ (d 無音, d-s)、いざよひ (d 無音, d-s, b-p)

ex3. http://www5d.biglobe.ne.jp/~the_imai/etymology/Grimm's_Law_in_J_20_19.html

結果 --- b-p は、ナシ。

----

音通側のサンプル探しは、 web page システムは、向いていて、便利。

同一語族であることが証明されているインド・ヨーロッパ語族においてすら、s:s, r:rが常に対応しているとは限らない

英語 smith /smɪθ/ : ドイツ語 Schmied /ˈʃmiːt/

英語 sit : アヴェスタ語 had

英語 wolf, 古代教会スラブ語 vlъkъ : アヴェスタ語 vəhrka

74名無し象は鼻がウナギだ！2022/10/15(土) 17:46:55.180

71へ

1）母音の音韻対応規則は、まだひねり出せないか？

子音のみでなく、母音の対応規則もあってしかるべきだろう

2）規則にブレ（例外）があるなら、例外が起きる条件や機序を述べるべし

上の例で言うと、「s : s」が本来の対応規則なら、それから逸脱する、「bla : そ」、「d: s」、さらにキミが先だって書いた「ch : t/s」の例外がなぜ発生するのか、その条件と機序を述べよ

3）キミが先に書いた規則(s-s), (b-p), (b-p-m)と、新たに書いた(ch-t/s) (m 無音) (r-r) (p-p)のどちらが正しいのか？

もしも、どちらも成立するというなら、それは音韻対応規則とは呼べない

キミは、日本語「s」に対応する音をいくつも並べている

繰り返すが、多対1の対応は、音韻対応規則とは言えない

4）語義が、日本語、シュメール語、サンスクリット語、アッカド語の各言語でバラバラである点の説明もなされていない

5）最も重要な点だが、日本祖語、シュメール語、サンスクリット語、アッカド語の共通祖語について言及がないのだが、どうなっているのだろうか？

Permalink | 記事への反応(0) | 18:56

ツイートシェア

■マッチをすり、戦争を起こせ

マッチをすり、戦争を起こせ

Light a Match, Ignite a War

Permalink | 記事への反応(0) | 13:28

ツイートシェア

■[あとで読む]2021年3月はてブのあとで読むトップ30リスト

はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

441あとで/3236users コグニカル

285あとで/1829users 経産省が公表した「フリーランスとして安心して働ける環境を整備するためのガイドライン」はフリーランスじゃない人も必読らしい - Togetter

238あとで/1442users Python言語による実務で使える100+の最適化問題 | opt100

227あとで/2515users 山本ゆり（syunkon レンジは600W) on Twitter: "友達に「どうやって作ったん？！」と聞かれた自信作。衣ザックザクで中ジューシー！もう売りもんの域。 【レジ横チキン】 特別な材料ナシ。油も少量でいける！袋2枚で作るから洗い物少ないし衣が飛び散らんし片付けがラク！下味の水と油、小… https://t.co/7gDCHTjdjB"

216あとで/1280users 主観と客観を切り替える鍛錬｜Miwa Kuramitsu｜note

215あとで/1696users 庵野秀明（2000） - 早稲田大学　人物研究会　公式サイト

202あとで/1882users note版 突然画力が伸びだした時、僕が発見した事｜安倍吉俊｜note

200あとで/1416users 心のバリアを取り去って「正規表現」に取り組む一歩を踏み出すためのメモ｜DTP Transit 別館｜note

197あとで/1580users 地震発生から72時間｜NHK東日本大震災アーカイブス　証言webドキュメント

194あとで/1964users 100均収納グッズのカタログ情報サイト MONO SIZE（モノサイズ）

186あとで/987users 2021年にJavaScriptやNode.jsを勉強し始めたので、読んで良かった資料をまとめる | matsumanaの技術メモ

184あとで/1208users プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

175あとで/1439users ［速報］マイクロソフト、無料でRPA機能「Power Automate Desktop」をWindows 10ユーザーに提供開始。Microsoft Ignite 2021

175あとで/1975users 「ごめんなさい 救助のヘリじゃなくてごめんなさい」｜NHK取材ノート｜note

175あとで/1412users 長かった10代の終わり、エヴァが想い出になった日。(『シン・エヴァンゲリオン劇場版』感想 ※ネタバレ注意)｜祥太｜note

174あとで/970users YouTubeで「中学生から分かるAI数学講座」が無料公開 E資格に対応 | Ledge.ai

172あとで/1798users ジャンプの漫画学校講義録⑥　作家編　松井優征先生「防御力をつければ勝率も上がる」 - ジャンプの漫画学校

167あとで/1331users カズオ･イシグロ語る｢感情優先社会｣の危うさ | 読書 | 東洋経済オンライン | 経済ニュースの新基準

161あとで/892users Dockerfileのベストプラクティス Top 20 | Sysdig

157あとで/1386users 建築好きなら死ぬまでに見ておきたい建築１００（日本国内編） | anond.hatelabo.jp

157あとで/1279users Microsoft、文字起こしアプリ「Group Transcrib‪e‬」を公開 - iPhone Mania

156あとで/1347users お金のことを考えたくない人はFP3級を勉強するといい - アオヤギさんたら読まずに食べた

156あとで/1290users 「プロフェッショナル 庵野秀明スペシャル」NHKが取材を後悔した庵野監督の生態 - Togetter

153あとで/1239users Keigo Hattori on Twitter: "YouTubeで学ぶコンピュータ・サイエンス。これを完了したら実質学位を取ったようなもん。という話だが、すごいなこれ・・・。全部無料でここまでの・・・。 https://t.co/xNHNvBM5Aa"

150あとで/1018users 「シン・エヴァンゲリオン劇場版」公開から１週間分の感想エントリまとめ - まなめはうす

148あとで/705users React を深く知るための入り口 | Panda_Program | Zenn

148あとで/1130users 情報ではなく経験をアウトプットすること - lacolaco

144あとで/1159users 「浄土」PDF一覧 | 法然上人鑽仰会

140あとで/1166users 売られている防災リュックがピンとこないので…カバンから食料まで『100均だけ』で防災グッズを揃えて検証してみた→防災士もオススメ - Togetter

137あとで/1028users こうやって切れば良かったんだ！鶏むね肉がぷるっぷるになる「うましおごま油漬け」が鶏ムネ肉を疑うレベルの柔らかさ | Gourmet Biz-グルメビズ-

トップのコグニカルは個人運営の"「分かりやすさ」と「心地良さ」を追求した学習サイト"だそう。

なぜか仏教雑誌「浄土」がブクマを集める。無料公開されて古い号の歴史的な価値を面白がられている。読み切れなそう。

YouTubeで「中学生から分かるAI数学講座」……で紹介されていた動画を開いてみたが1000弱のブクマを集めている割に再生数数百止まり。

Permalink | 記事への反応(0) | 17:21

ツイートシェア

■anond:20201115210740

Ignite

Permalink | 記事への反応(0) | 21:08

ツイートシェア

■anond:20201114222346

Ignite

Permalink | 記事への反応(0) | 22:25

ツイートシェア

■

ちょまどさんの例の姫騒動ってもう四年前なんか。ほってんとりで久々に思い出して軽くググったら、裏綴じのある週刊誌を一年に一回ぐらい読む感じになんか丁寧に経緯を追ってしまって時間無駄にしてしまった。人の醜聞なんか追っても何の得にもならないのに。。好奇心と腐った性根は並存することを教えてくれる。あのキモイスライド作った人もバースデーケーキ切ってた人もは普通に現役でTwitterやっててびっくりした。あのキモいスライドを良い感じにネットアーカイブ残した人はAWSの中の人だったっていうのも笑えた(ツイートはごちうさの産廃オタでほんとかは知らん)。そういえば先日もMSのIgnite振り返りセッションにクラウドアドボケイトポジションで彼女おったけど、ぶっちゃけAKSなどコンテナ系の話を総スルーされた上に皆Zoomこのタイミングで作りたがるんかなー？って疑問符しかなかったAzureCommunicationの紹介と、深いようで浅い機械学習の話でそもそも個人的にあんまりおもしろくなかった上に、(多分唯一笑えたのがazure salt serviceのくだりか？)、twitterイイね係で存在感なかったなーってそんなことを思い出した。

Permalink | 記事への反応(0) | 02:03

ツイートシェア

■アニソンアーティスト/声優のSpotify今月のリスナー数

対象:今月のリスナー数10万以上

調査日:2020/6/14(お昼過ぎ)

アニソンアーティスト

今月のリスナー数/アーティスト名/再生回数トップ3

※★マークはSpotify未解禁の楽曲も多いアーティスト、ただしマークが無い=全曲配信済というわけでもない

※SawanoHiroyuki[nZk]は「SawanoHiroyuki[nZk]:○○」名義の分も集計されてるっぽいのでトップ3省略

※ヒゲダン(236万)、ワンオク(206万)、ミセス(201万)より多いLiSA、もしかして国内アーティストトップなのか

※中川翔子はアニソンアーティストにカウントしていいのか

声優

※GRANRODEOは日本ではほとんど未解禁。リスナー所在地の上位がほぼ中南米なので、海外向けには解禁済なのだろうか

※ヒプマイはコンテンツ全体だともっと多いはず

※fripSideは声優アーティストにカウントしていいのか

Permalink | 記事への反応(0) | 16:20

ツイートシェア

■【抄訳】【途中で力尽きました】AKSの運用に関するベストプラクティス

はじめに

AKSの運用に関するベストプラクティス(原題: Applying best practices to Azure Kubernetes Service (AKS))がMS Igniteというイベントで話されていたので

内容をかいつまんで紹介します。

参考資料

映像

https://myignite.techcommunity.microsoft.com/sessions/81598?source=SessionDeck

ソースコード等

https://github.com/Azure/aks-bestpractices-ignite19

アジェンダ

このセッションでは下記の二つについて紹介します。

高可用性設計(High Availability)に関するベストプラクティス

クラスタ管理に関するベストプラクティス

高可用性について

今回取り扱うのは主にワーカーノードの高可用性です

• k8sにはマスターノードとワーカーノードという大きく二つのコンポーネントに分かれるが、本セッションで扱うのは主にワーカーノードです。

マスターノードについて

• コントローラプレーンの可用性は99.5%...ですが、基本的に費用がかからないのでSLO目標です。
• PIサーバーがダウンした場合スケールやデプロイなど新しいマネジメントオペレーションはできない。
• しかし、稼働中のアプリケーションは影響をうけない(訳注: したがってワーカーノードの方がより考慮すべき)
• それでもコントローラプレーンで高可用性を確保したい場合下記の方法がある
  • プレミアムSKUの採用:2019年の終わりに登場予定
  • 複数クラスタの構成(副作用があるのでコントローラプレーンの冗長性確保だけを目的として実施してはいけない)

ワーカーノード

RTO(リカバリ時間目標)とRPO(目標複数時点)に応じて下記の4通りのシナリオがある

4にいくにしたがって

RTO=復旧するまでの時間が短くなる

RO=より直近の状態で復旧できる

しかし、コストや構成の複雑さは増す。

1. バックアップとリストア

2. AZ(Availability Zone)

3. リージョン内の複数のクラスタ

4. リージョン間の複数のクラスタ

バックアップとリストア

• 下記の通り、ステートフル環境の方がバックアップとリストアが難しい。
  • ステートレスクラスタ: マニフェストファイルをデプロイしなおすだけ
  • ステートフル: マニフェストファイルをデプロイして、コンポーネントの状態をさらに再構築する必要がある

• どちらのクラスタにせよ、クラスタの構築は、再デプロイ処理をより早くするためにcluster deployment as code の必要がある

コードのバックアップ(スナップショット)方法

• スナップショットには二つのオプションがある
  • Azure Snapshot APIを使用したスナップショット
  • heptio ark/vmware veleroなどのOSSプロジェクト

AZを用いた冗長性確保

17:22～

• AKSクラスタはAvailability Zoneをまたいで分散ノードを作成できる
• AZとはAzure regison内の個々の物理的場所
• AZを利用すると99.99%の可用性
• 標準のAzure Disks(ストレージ)はZoneに紐づいている
• Zoneをサポートするリージョンの数は限りがある
  • 2019年11月現在は10リージョン(https://docs.microsoft.com/en-us/azure/availability-zones/az-overview )
  • 日本だと東日本のみ
• Zoneごとの分散処理を行うためにはStandard Load Balancer SKUが必要
  • Basic SKUはZone分散をサポートしていない

複数クラスタ構築

23:48～

• 同じリージョン内に複数のクラスタを構築する方法とリージョンをまたいで複数のクラスタを構築する方法がある
• データベースのR/Wをメインクラスタで行って他のクラスタでは基本的にレプリカ構成にしたデータベースでReadのみにする
  • 基本的に他のクラスタではReadしかできないので機能に制限がかかる(縮退運転)
  • CosmosDBを使用すればR/Wの制限なく構築できるが...(訳注: コストは一番高い)

(以下作業中)

最後に

Nofalさんごめんなさい、年末頑張って仕上げます。

Permalink | 記事への反応(0) | 23:00

ツイートシェア

■いげっちゃ　いぐなっちゃ　いげっちゃ

It get you.

Ignite you.

It get you.

Permalink | 記事への反応(0) | 19:13

ツイートシェア

■http://anond.hatelabo.jp/20170219143625

曲とアニメAnilogia IDの対応表です。

ご確認お願いします。

Permalink | 記事への反応(0) | 14:39

ツイートシェア