タグ

redisに関するikosinのブックマーク (47)

  • 同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話

    LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog Overview 30万を超える同時接続数を持つチャットサービスにおいて、リアルタイムでメッセージの受信などのイベントを配信するメッセージブローカーとして、私たちはRedis ClusterのPub/Subを使用していました。 私たちのサービスでは、ユーザー数の増加に伴い、Redis Clusterのシャード数を増やすことでクラスターの性能を向上させてきました。しかし、Redis ClusterのPub/Subでは、シャード数の増加に伴ってネットワーク帯域が圧迫される問題が生じ、これ以上シャードを追加することができない状況になりました。 この課題を解決するために、メッセージブローカーをRedis Pub/SubからRedis

    同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話
  • Redis互換で25倍高速とする「Dragonfly」が登場。2022年の最新技術でインメモリデータストアを実装

    Redis互換で25倍高速とする「Dragonfly」が登場。2022年の最新技術でインメモリデータストアを実装 Redisやmemcachedに代表されるインメモリデータストアは、高速なデータアクセスを要求される場面で使われています。 このインメモリデータストアを2022年の最新技術を用いて設計、実装することで、Redis/memcached互換を実現しつつRedisの25倍高速とする「Dragonfly」が登場しています(開発元のアナウンス、GitHub)。 Redisやmemcachedが登場した十数年前と比べて、現在ではCPUのマルチコア化やI/Oの高速化、メモリの大容量化など、ハードウェア技術が大きく進化しています。 これらを最大限活用する設計と実装を取り入れることでRedisやmemcachedよりも大幅な高速化と高効率化を目指したのがDragonflyです。 採用した主な技術

    Redis互換で25倍高速とする「Dragonfly」が登場。2022年の最新技術でインメモリデータストアを実装
    ikosin
    ikosin 2023/01/24
  • 排他制御のためだけに Redis 渋々使ってませんか?データベース単独でアドバイザリーロックできるよ!

    トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため,必要に応じてまず以下を参照されたい。 背景 以前, Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが,関連している部分があるため引用する。 MySQL/Postgres とも, MVCC アーキテクチャの恩恵で, SELECT と UPDATE は基的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ,排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ,これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で,更新対象をサブクエリの SELECT から自己参照している場合は例外。

    排他制御のためだけに Redis 渋々使ってませんか?データベース単独でアドバイザリーロックできるよ!
  • Redisの25倍のスループットDragonflyを試してみる

    インメモリデータストアを現代風に再実装したら? 高速なデータアクセスのためのインメモリデータストアとしては、RedisやMemcachedが有名です。ただし、これらは10年以上前に設計されており、Memcachedに至っては、2003年と約20年前です。 長い年月を経て、機能追加や最適化が進む一方で、どうしても設計の古さも目立ってきます。 その課題を解決すべく開発されたのがDragonfly です。 全ての操作がアトミック 高スループットでもミリ秒未満のスループット を目指し、Redis/Memcached互換なAPIを提供します。 Redisの25倍のスループットを誇り、1インスタンスで百万オーダーのQPSをさばけます。 開発者が実施したAWS EC2上のベンチマークによると、Dragonflyは家RedisやRedisのマルチスレッドforkであるKeyDBよりも圧倒的なスループット

    Redisの25倍のスループットDragonflyを試してみる
    ikosin
    ikosin 2022/06/09
  • トランザクション — Redis Documentation (Japanese Translation)

    トランザクション¶ MULTI, EXEC, DISCARD および WATCH は Redis におけるトランザクションの基です。これらは、複数のコマンドの実行をひとつのステップで行えるようにします。その際、2 つの重要な点が保証されます。 トランザクション中のすべてのコマンドは直列化され、順に実行されます。他のクライアントにより発行されたリクエストが、Redis トランザクションの 途中に 入り込むことはありません。このことは、コマンド群がひとつの隔離されたオペレーションとして実行されることを保証します。 すべてのコマンドが実行されるか、ひとつも実行されないかのいずれかであり、すなわち Redis のトランザクションはアトミックです。 EXEC コマンドはトランザクション中の全コマンドの実行のトリガです。もし、クライアントがトランザクションの途中で、 MULTI [訳注: EXEC

    ikosin
    ikosin 2021/08/10
  • Transactions – Redis

    How transactions work in Redis Redis Transactions allow the execution of a group of commands in a single step, they are centered around the commands MULTI, EXEC, DISCARD and WATCH. Redis Transactions make two important guarantees: All the commands in a transaction are serialized and executed sequentially. A request sent by another client will never be served in the middle of the execution of a Red

    ikosin
    ikosin 2021/08/10
  • Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム

    概要 お仕事でRedisを触ってたので知見をまとめる。 Redisは高速はKVSだが、今回1000万件を超えるような大量のデータを扱った。 大量のデータをバッチで定期的に書き込んで、参照側では高速に返すシステムを考える。 バッチはユーザーの行動を『現在から1日以内にログインしたユーザー』のように時間区切りで条件検索している。そのため、検索する時間が変われば結果も変わるので、定期的に実行してデータを洗い替えている。 検索結果は1000万件あっても対応したい。 ユーザーがアクセスしてきたときにはこの検索結果の対象かどうか判断して結果を返したい。このユーザーからのアクセスは大量にあるため即座にレスポンスを返さなければならない。 洗い替えることによって使わなくなったデータは容量を空けるために削除したい。 クエリ結果はユーザーのidなので19475934や59103940のような法則性の薄い数字の列

    Redisで1000万件のデータを圧縮しつつ定期的に洗い替えする - スペクトラム
    ikosin
    ikosin 2020/06/21
  • MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比べてどんな利点や欠点がありますか? - Quora

    回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...

    MongoDBの様なNoSQLに勢いがあるのは何故ですか?SQLと比べてどんな利点や欠点がありますか? - Quora
  • ISUCON7 予選を通過した - eagletmt's blog

    ISUCON7 予選に†空中庭園†《ガーデンプレイス》として @ryot_a_rai、@mozamimy と参加して2日目1位で通過することができた http://isucon.net/archives/50956331.html 。 リポジトリは https://github.com/ryotarai/isucon7q 当日まで 例年 Ruby で参加していたけど、今年は発表された初期実装に Ruby が含まれていなかったこと (※後から追加された) もあり、@ryot_a_rai から Go で参加したいという話が出て Go を選択した。 僕と @mozamimy は Go はまぁまぁ書いたことはあるくらいの状態だったので、事前に一度 Go で練習したり pprof の使い方を教えてもらったりしていた。 Go は個人的にはあんまり好きになれなかった言語ではあるんだけど、ISUCON で

    ISUCON7 予選を通過した - eagletmt's blog
  • RedisサーバのCPU負荷対策パターン - ゆううきブログ

    Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R

    RedisサーバのCPU負荷対策パターン - ゆううきブログ
  • Redis 4.0の目玉機能解説 - Qiita

    redis 4.0 GA release ついに昨日(2017/07/15)に、redis 4.0のstableがリリースされました。 今までのredisと何が変わったのか?というのを、軽くまとめたいと思います。 間違いなどありましたら、指摘いただけると幸いです。 前回のqiita記事 プロダクションで2年間RedisClusterを運用してみて release notes 一部抜粋すると Note that 4.0 is probably one of the most extreme releases of Redis ever made in terms of changes inside the internals: all the aggregated data types no longer use Redis Objects structures but directly S

    Redis 4.0の目玉機能解説 - Qiita
    ikosin
    ikosin 2017/07/18
  • Redis 4.0正式リリース。モジュールによる機能やデータの拡張が可能に、新レプリケーションエンジンで運用が改善

    Redis 4.0正式リリース。モジュールによる機能やデータの拡張が可能に、新レプリケーションエンジンで運用が改善 Redis 4.0はモジュールによる機能拡張の実現、新しいレプリケーションエンジンによる高速なレプリケーション、新しいアルゴリズムの追加によるキャッシュの改善、フラッシュの非同期実行など、多くの機能追加が行われています。 リリースノートには、「内部における変更に関していえば、4.0はおそらくこれまででもっとも劇的なリリースだろう」と、次のように記されています。 Note that 4.0 is probably one of the most extreme releases of Redis ever made in terms of changes inside the internals 新しいレプリケーションエンジン「PSYNC2」 Redis 4.0では新しいレプリ

    Redis 4.0正式リリース。モジュールによる機能やデータの拡張が可能に、新レプリケーションエンジンで運用が改善
    ikosin
    ikosin 2017/07/18
  • Lua: A Guide for Redis Users

    You’ve heard that Redis has an embedded scripting language, but haven’t given it a try yet? Here’s a tour of what you need to understand to use the power of Lua with your Redis server. Hello, Lua! Our first Redis Lua script just returns a value without actually interacting with Redis in any meaningful way: This is as simple as it gets. The first line sets up a local variable with our message, and

  • Redis による分散ロック — Redis Documentation (Japanese Translation)

    Redis による分散ロック¶ 異なるプロセス同士が、相互に排他的な方法で共有リソースに対して操作を実行する、という環境において、分散ロックは非常に役に立ちます。 Redis を使った DLM (Distributed Lock Manager) の実装については、多くのライブラリやブログポストがあります。しかし、ライブラリごとに異なるアプローチがとられており、またその多くは、より複雑なデザインと比較するとシンプルで、そのぶん保証される内容が低いアプローチとなっています。 このページは、Redis 上で分散ロックを実装するにあたり、標準的なアルゴリズムを提供することを目指すものです。私たちはここで Redlock と呼ぶアルゴリズムを提供します。これは DLM 実装の一種で、よく見かけるような、ひとつのインスタンスを使うアプローチよりも安全である、と私たちは考えています。コミュニティがこの

  • Gunosy AdServerのデータ周りの話

    エムスリー x Gunosy Beer bash! http://gunosy-beer.connpass.com/event/22825/ 主にデータストア(Redis)やtd-agent周りの辛い話と対処法について書いてあります。

    Gunosy AdServerのデータ周りの話
  • Redis 本番障害から学んだコードレビューの勘所

    Redis不適切利用による問題は番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... (この話は事実ではなくファンタジーです。) 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以

    Redis 本番障害から学んだコードレビューの勘所
  • Redis作者自身によるRedisとMemcachedの比較 | Yakst

    Redisの作者antirez氏自らによる、memcachedとRedisの長所短所の比較。特に、Redisを単なるキャッシュ用アプリケーションとしてmemcachedと比較することの間違いと、それぞれの向いている使用方法についての私見。 あなたが私と面識があるなら、私が競合製品があることが悪いと考える人間でないことはご存知でしょう。ユーザーに選択肢があることは当にいいことだと思っていますし、だからこそ他の技術とRedisを比較するようなことはほとんどしませんでした。 しかし、最適なソリューションを選ぶためには、ユーザーは正しく情報を持たねばならないのも確かです。 この記事を書くのは、有名なライブラリであるSidekiqの作者として知られるMike Perhamが、Redisのバックエンドストレージとしての使い方を書いた記事を読んだのがきっかけです。従って、私はMikeがRedisに「反

    Redis作者自身によるRedisとMemcachedの比較 | Yakst
    ikosin
    ikosin 2015/10/21
  • GitHub - reborndb/reborn: Distributed database fully compatible with redis protocol

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - reborndb/reborn: Distributed database fully compatible with redis protocol
    ikosin
    ikosin 2015/07/09
    "Reborn is a proxy based high performance Redis cluster solution written in Go/C, an alternative to Redis."
  • RebornDB: the Next Generation Distributed Key-Value Store - High Scalability -

    « Stuff The Internet Says On Scalability For July 10th, 2015 | Main | Sponsored Post: VoltDB, Datadog, Tumblr, Power Admin, Learninghouse, MongoDB, Internap, Aerospike, SignalFx, InMemory.Net, Couchbase, VividCortex, MemSQL, Scalyr, AiScaler, AppDynamics, ManageEngine, Site24x7 » There are many key-value stores in the world and they are widely used in many systems. E.g, we can use a Memcached to s

    RebornDB: the Next Generation Distributed Key-Value Store - High Scalability -
  • Diagnosing latency issues

    Finding the causes of slow responses This document will help you understand what the problem could be if you are experiencing latency problems with Redis. In this context latency is the maximum delay between the time a client issues a command and the time the reply to the command is received by the client. Usually Redis processing time is extremely low, in the sub microsecond range, but there are