Elasticsearch 2014/04/21 勉強会資料 「Couchbase と Elasticsearch が手を結んだら」
Elasticsearch 2014/04/21 勉強会資料 「Couchbase と Elasticsearch が手を結んだら」
Elasticsearch 2014/04/21 勉強会資料 「Couchbase と Elasticsearch が手を結んだら」
Kubernetesで構築する大規模時系列データのスケーラブルな分散処理
CloudNative Days Tokyo 2023 での登壇資料です
GitLab CIとCircleCIのキャッシュ戦略の違い - くりにっき
仕事でCI全般のお悩み相談されることが多くて .circleci/config.yml や .gitlab-ci.yml をリファクタリングすることがよくあるのですが、その時に一番意識してるキャッシュ戦略について長年自分の中の暗黙知になっていて明文化できてなかったので書きます。 前置き 用語の定義 その他 GitLab CIとCircleCIの両方に共通すること キャッシュを過度に使いすぎない 許容できるケース 11/6追記 ないと困るものはキャッシュにしない 10/30 12:00追記 キャッシュをバージョニングする 複数のブランチでキャッシュを共有できるようにする GitLab CI固有の話 GitLab CIのキャッシュの仕様 CircleCI固有の話 CircleCIのキャッシュの仕様 同一のkeyで一度キャッシュが作られたら上書きができない キャッシュのkeyは前方一致 どうして
強いキャッシュ 弱いキャッシュとはなにか – cat /dev/random > /dev/null &
先日とらのあなラボ様の勉強会に参加していたところ「強いキャッシュ」「弱いキャッシュ」とキーワードが出てきました。 初めて聞く表現だったので質問したところやはり知らない定義だったため、少し調べてまとめてみたものです。 なお、強いキャッシュ・弱いキャッシュという説明を否定するものではなく、補完したいと考えています。 強いキャッシュ・弱いキャッシュの定義 ネット上を調べると日本語・中国語・英語で説明が出てきますが、調べた限りでは強いキャッシュ・弱いキャッシュの初出はWebフロントエンド ハイパフォーマンスで、定義は以下の通りです。 ExpiresヘッダーとCache-Controlヘッダーでは強いキャッシュを設定できます。 ETagヘッダーとLast-Modifiedヘッダーでは弱いキャッシュを設定できます。 Webフロントエンド ハイパフォーマンス p124 こちらの文書の前後に詳しい定義があ
Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム
概要 お仕事でRedisを触ってたので知見をまとめる。 Redisは高速はKVSだが、今回1000万件を超えるような大量のデータを扱った。 大量のデータをバッチで定期的に書き込んで、参照側では高速に返すシステムを考える。 バッチはユーザーの行動を『現在から1日以内にログインしたユーザー』のように時間区切りで条件検索している。そのため、検索する時間が変われば結果も変わるので、定期的に実行してデータを洗い替えている。 検索結果は1000万件あっても対応したい。 ユーザーがアクセスしてきたときにはこの検索結果の対象かどうか判断して結果を返したい。このユーザーからのアクセスは大量にあるため即座にレスポンスを返さなければならない。 洗い替えることによって使わなくなったデータは容量を空けるために削除したい。 クエリ結果はユーザーのidなので19475934や59103940のような法則性の薄い数字の列
ストレージエンジンであそんでみた
こうなるはずだったんですがlightningのVGA変換アダプタとmini display portの変換アダプタを間違えて持って行ってしまいましたorz 次回から忘れないように全部まとめてキーホルダーに付けようと思います（´・ω...:.;::..
Redisストリームについて
RedisストリームはRedis 5で新しく追加されたデータ型です。 Apache Kafka に類似したメッセージ処理のためのパワフルな機能を持っており、様々な応用が可能です。 既存の類似の機能 最初にRedisのメッセージ処理に適した既存の機能をいくつか紹介します。 Pub/Sub RedisはPub/Subメッセージング機能を提供しています。SUBSCRIBE および PUBLISH コマンドにより、 Publisher(発行者)が送信したメッセージを複数の Subscriber(購読者)が受信することができます。PublisherはSubscriberを知っている必要がなく、メッセージを受け取れないPublisherがあってもSubscriberは影響を受けません。ただし、メッセージは保存されないため、SUBSCRIBEしていない期間のメッセージを受け取ることはできません。 Blo
GraphQL SubscriptionsとRedis PubSubを使ってリアルタイムチャットサーバーを作る - Qiita
はじめに 今まで触ってみたいと思っていたGraphQLとRedisを使って、リアルタイムチャットサーバーを作ってみました。 この記事では、主にGraphQLに重点を置いて実装を紹介していきます。 ソースコードはGitHubに上がっているので、そちらも合わせてご覧ください。 README.mdを見ればすぐにサーバーを建てることができるので、先に試してみるのも良いかもしれません。 アーキテクチャ 今回は以下のような構成になっています。 フロントエンドとサーバー間はGraphQLを用いた通信を行っています。 メッセージの送信やユーザーの作成は通常のGraphQLのMutationを、メッセージの受信は Websocket上で動作するGraphQL Subscriptionsを使用しています。 また、メッセージの配信にはRedisのPubSub機能を使っています。 これは、GraphQLサーバーが
Redisでオートコンプリート(5) 転置インデックス
Redisを使ったいろいろな autocomplete のアルゴリズムをメモ。 前方一致 zrange 範囲指定 @antirez trie inverted index これまでの実装例は、検索語が一語に限られている。 RubyGem の soulmate は転置インデックスを用いて、複数語の autocomplete に対応している。 今は実装が変わっているかもしれないけれども、転置インデックスを使った2011年11月当時の実装が次のブログにまとめられているので、これをベースにメモ http://patshaughnessy.net/2011/11/29/two-ways-of-using-redis-to-build-a-nosql-autocomplete-search-index T[0] = “it is what it is” T[1] = “what is it” T[2]
Redis Lua scriptingをatomicな処理とcache stampede対策に使った話
こんにちは。LINEでゲームプラットフォーム開発をしているKagayaです。この記事はLINE Advent Calendar 2017の18日目の記事になります。昨年新卒入社1年目で執筆した「マイクロサービスのためのプロジェクト生成ツールLazybonesを使ってみた」に引き続き、今年もAdvent Calendarの記事を書くことになりました。よろしくお願いします。 はじめに—RedisとLINE GAMEプラットフォーム LINE GAMEプラットフォームでは、インメモリNoSQLデータベースであるRedisをメインデータベースの1つとして利用しています。キャッシュとしての利用が多く、例えば、LINEやFacebookなどのアカウントで認証を行っているユーザのソーシャルデータ（プロフィールや友だちリストなど）のキャッシュに利用しています。基本的にはRedis Clusterとして利用
RedisのHyperLogLogを使ってユニークユーザー数を推定する – Rest Term
去年の内に公開することが出来ず、ずっと下書き状態だったエントリーをちょっとずつ消化していきたいと思います。ネタとして古いものも含まれていたりすると思いますがしばらくご辛抱ください。。 Redis 2.8.9から追加された HyperLogLog をちょっと触ってみました。 環境 * CentOS 7.0 (x86_64) / Intel Xeon E312xx (Sandy Bridge) 2.4GHz 仮想3コア / 2GB RAM * Redis 2.8.17 * redis-py (Python 2.7.5) HyperLogLogとは HyperLogLog (以下HLL)というアルゴリズムはデータマイニング(トラフィックデータの分析等)とか自然言語処理をやってる人ならともかく、Webアプリケーション開発者にはあまり馴染みがないかもしれません。 HyperLogLog – Wiki
Fine Parallel Processing Using a Work Queue
In this example, you will run a Kubernetes Job that runs multiple parallel tasks as worker processes, each running as a separate Pod. In this example, as each pod is created, it picks up one unit of work from a task queue, processes it, and repeats until the end of the queue is reached. Here is an overview of the steps in this example: Start a storage service to hold the work queue. In this exampl
アルゴリズムとデータ構造から理解するRedis / Learn Redis from Internal Algorithms and Data Structures
2019年新卒研修で使った資料です。 内部実装の雰囲気を感じとりながら、Redisについて理解を深める研修を行いました。 以下の内容について学びました。 1. Redisの概要 2. 社内での利用方法 3. 正しい用法用量 Redis についての前提知識は必要としていません。C言語の基礎的な知識は前提とします。
Dive Deep Redis ~ 入門から実装の確認まで - hayashier Tech Blogs
——————————————————————————————————————————————————— Redis(REmote DIrectory Server)Redisは例えば以下の特徴を持つLLOOGGを元としたインメモリの非リレーショナルのデータベースです。 String, List, Hash, Set, Sorted Setに代表される豊富なデータ型シングルスレッド処理イベント駆動処理 by aeライブラリ通常RESPプロトコルによるクライアント/サーバーモデルでリクエスト/レスポンスデータは条件を満たす場合にメモリ最適化されて保存。CPUとのトレードオフRAXを利用したメモリ利用量の最適化(Redis 4.0~)この記事では、入門から始まり、実装をより意識することで深く理解することを目標としています。 以下の説明中の(*)マークは、特にVanilla Redisでの話となり
Redisでセリーグの順位表を作ってみる - uokadaの見逃し三振は嫌いです
Redis使ってますか？ 今日はzrankを使わないでセリーグ順位表を作ってみましょう。 例として、下のような順位表があるとします。 Team Rank 勝 負 分 Tigers 1 5 0 0 Dragons 2 4 1 0 Swallows 3 3 2 0 Giants 4 2 3 0 Carp 5 1 4 0 BayStars 6 0 5 0 順位に関してはなんとなくな個人の趣味で決めてますｗ *1 上の順位表をデータとしてRedisにセットしましょう。 HMSET Tigers Win 5 Lose 0 draw 0 HMSET Dragons Win 4 Lose 1 draw 0 HMSET Swallows Win 3 Lose 2 draw 0 HMSET Giants Win 2 Lose 3 draw 0 HMSET Carp Win 1 Lose 4 draw 0 H
redis clusterを自力で構築してみた - Qiita
redis clusterを構築する際は、redis-tribという便利なツールがありますが、ここではredis-tribを使わずに自力でclusterを構築する手順を書きます。 ※redis-tribを使った方が安全に、簡単に構築できますし、いろんな機能があるのでちゃんと作るときはredis-tribを使うのを強く推奨します。 redisを3台起動する [redis clusterの作り方]を参考に3台起動してください。(参照先URLの手順は3まで行います) ここでは7000～7002 portを使って3台でクラスタを構築します。 redis.confにてcluster-enabled yesとするとcluster-config-fileに設定されたファイル名のクラスタ設定ファイルが作られます。 ただ起動しただけだと、こんな感じ
kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが（たぶん^^;）、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。（個人で開発している場合など、開発リソースが小さい場合はなおさら） そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います（もちろん、アルゴリズムも重要ですが）。 分散システムには複雑
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デバッガでRedisのコードを読んでみよう
gRPC Streaming によるスケーラブルな常時接続型 API の構築
計算量と僕とWeb開発 / computational complexity and I and Web
