Suche senden
Hochladen
第10回solr勉強会 solr cloudの導入事例
•
24 gefällt mir
•
11,247 views
Ken Hirose
Folgen
第10回solr勉強会の資料
Weniger lesen
Mehr lesen
Technologie
Melden
Teilen
Melden
Teilen
1 von 33
Jetzt herunterladen
Downloaden Sie, um offline zu lesen
Empfohlen
業務で ISUCON することになった話.pdf
業務で ISUCON することになった話.pdf
TakuyaFukuoka2
20221209-ApacheSolrによるはじめてのセマンティックサーチ.pdf
20221209-ApacheSolrによるはじめてのセマンティックサーチ.pdf
Koji Sekiguchi
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
Shinsuke Sugaya
モノタロウを支える Solr による商品検索システム
モノタロウを支える Solr による商品検索システム
株式会社MonotaRO Tech Team
オンプレを少しずつコンテナ化する
オンプレを少しずつコンテナ化する
Kenkichi Okazaki
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
ElasticSearch勉強会 第6回
ElasticSearch勉強会 第6回
Naoyuki Yamada
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
ShuheiUda
Empfohlen
業務で ISUCON することになった話.pdf
業務で ISUCON することになった話.pdf
TakuyaFukuoka2
20221209-ApacheSolrによるはじめてのセマンティックサーチ.pdf
20221209-ApacheSolrによるはじめてのセマンティックサーチ.pdf
Koji Sekiguchi
SolrとElasticsearchを比べてみよう
SolrとElasticsearchを比べてみよう
Shinsuke Sugaya
モノタロウを支える Solr による商品検索システム
モノタロウを支える Solr による商品検索システム
株式会社MonotaRO Tech Team
オンプレを少しずつコンテナ化する
オンプレを少しずつコンテナ化する
Kenkichi Okazaki
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
NTT DATA Technology & Innovation
ElasticSearch勉強会 第6回
ElasticSearch勉強会 第6回
Naoyuki Yamada
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
ShuheiUda
Babelfish Compatibility
Babelfish Compatibility
Noriyoshi Shinoda
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Yahoo!デベロッパーネットワーク
Oracle GoldenGate入門
Oracle GoldenGate入門
オラクルエンジニア通信
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
NTT DATA Technology & Innovation
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
NTT DATA Technology & Innovation
OCI GoldenGate Overview 2021年4月版
OCI GoldenGate Overview 2021年4月版
オラクルエンジニア通信
Oracleからamazon auroraへの移行にむけて
Oracleからamazon auroraへの移行にむけて
Yoichi Sai
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
LIFULL HOME'SでのSolrの構成と運用の変遷
LIFULL HOME'SでのSolrの構成と運用の変遷
LIFULL Co., Ltd.
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
技術勉強会(Solr入門編)
技術勉強会(Solr入門編)
Atsushi Takayasu
Sonar qubeでちょっと楽しい静的解析
Sonar qubeでちょっと楽しい静的解析
政雄 金森
ストリーム処理勉強会 大規模mqttを支える技術
ストリーム処理勉強会 大規模mqttを支える技術
Keigo Suda
AWSでアプリ開発するなら 知っておくべこと
AWSでアプリ開発するなら 知っておくべこと
Keisuke Nishitani
はじめての検索エンジン&Solr 第13回Solr勉強会
はじめての検索エンジン&Solr 第13回Solr勉強会
Noritsugu Suzuki
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
Takahiro Moteki
IPv6 を始めてみた
IPv6 を始めてみた
miki koganei
Twitterのリアルタイム分散処理システム「Storm」入門
Twitterのリアルタイム分散処理システム「Storm」入門
AdvancedTechNight
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
Masahito Zembutsu
CSS3Rendererを使ってiOSでもサクサク3D
CSS3Rendererを使ってiOSでもサクサク3D
AdvancedTechNight
The new repository in AEM 6
The new repository in AEM 6
Jukka Zitting
Weitere ähnliche Inhalte
Was ist angesagt?
Babelfish Compatibility
Babelfish Compatibility
Noriyoshi Shinoda
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Yahoo!デベロッパーネットワーク
Oracle GoldenGate入門
Oracle GoldenGate入門
オラクルエンジニア通信
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
NTT DATA Technology & Innovation
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
NTT DATA Technology & Innovation
OCI GoldenGate Overview 2021年4月版
OCI GoldenGate Overview 2021年4月版
オラクルエンジニア通信
Oracleからamazon auroraへの移行にむけて
Oracleからamazon auroraへの移行にむけて
Yoichi Sai
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Motonori Shindo
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
LIFULL HOME'SでのSolrの構成と運用の変遷
LIFULL HOME'SでのSolrの構成と運用の変遷
LIFULL Co., Ltd.
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Akihiro Suda
技術勉強会(Solr入門編)
技術勉強会(Solr入門編)
Atsushi Takayasu
Sonar qubeでちょっと楽しい静的解析
Sonar qubeでちょっと楽しい静的解析
政雄 金森
ストリーム処理勉強会 大規模mqttを支える技術
ストリーム処理勉強会 大規模mqttを支える技術
Keigo Suda
AWSでアプリ開発するなら 知っておくべこと
AWSでアプリ開発するなら 知っておくべこと
Keisuke Nishitani
はじめての検索エンジン&Solr 第13回Solr勉強会
はじめての検索エンジン&Solr 第13回Solr勉強会
Noritsugu Suzuki
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
Takahiro Moteki
IPv6 を始めてみた
IPv6 を始めてみた
miki koganei
Twitterのリアルタイム分散処理システム「Storm」入門
Twitterのリアルタイム分散処理システム「Storm」入門
AdvancedTechNight
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
Masahito Zembutsu
Was ist angesagt?
(20)
Babelfish Compatibility
Babelfish Compatibility
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Solrで多様なランキングモデルを活用するためのプラグイン開発 #SolrJP
Oracle GoldenGate入門
Oracle GoldenGate入門
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
実践!OpenTelemetry と OSS を使った Observability 基盤の構築(CloudNative Days Tokyo 2022 発...
OCI GoldenGate Overview 2021年4月版
OCI GoldenGate Overview 2021年4月版
Oracleからamazon auroraへの移行にむけて
Oracleからamazon auroraへの移行にむけて
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
LIFULL HOME'SでのSolrの構成と運用の変遷
LIFULL HOME'SでのSolrの構成と運用の変遷
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
技術勉強会(Solr入門編)
技術勉強会(Solr入門編)
Sonar qubeでちょっと楽しい静的解析
Sonar qubeでちょっと楽しい静的解析
ストリーム処理勉強会 大規模mqttを支える技術
ストリーム処理勉強会 大規模mqttを支える技術
AWSでアプリ開発するなら 知っておくべこと
AWSでアプリ開発するなら 知っておくべこと
はじめての検索エンジン&Solr 第13回Solr勉強会
はじめての検索エンジン&Solr 第13回Solr勉強会
[社内勉強会]ELBとALBと数万スパイク負荷テスト
[社内勉強会]ELBとALBと数万スパイク負荷テスト
IPv6 を始めてみた
IPv6 を始めてみた
Twitterのリアルタイム分散処理システム「Storm」入門
Twitterのリアルタイム分散処理システム「Storm」入門
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
Andere mochten auch
CSS3Rendererを使ってiOSでもサクサク3D
CSS3Rendererを使ってiOSでもサクサク3D
AdvancedTechNight
The new repository in AEM 6
The new repository in AEM 6
Jukka Zitting
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera Japan
トレジャーデータ 導入体験記 リブセンス編
トレジャーデータ 導入体験記 リブセンス編
Kentaro Yoshida
Elasticsearch+nodejs+dynamodbで作る全社システム基盤
Elasticsearch+nodejs+dynamodbで作る全社システム基盤
Recruit Technologies
ちょっと理解に自信がないなという皆さまに贈るHadoop/Sparkのキホン (IBM Datapalooza Tokyo 2016講演資料)
ちょっと理解に自信がないなという皆さまに贈るHadoop/Sparkのキホン (IBM Datapalooza Tokyo 2016講演資料)
hamaken
データ分析チームの振り返り
データ分析チームの振り返り
Satoshi Noto
学術コンテンツサービスでの活用事例@Lucene/Solr勉強会(2015.5.13)
学術コンテンツサービスでの活用事例@Lucene/Solr勉強会(2015.5.13)
Ikki Ohmukai
Solr6 の紹介(第18回 Solr勉強会 資料) (2016年6月10日)
Solr6 の紹介(第18回 Solr勉強会 資料) (2016年6月10日)
Issei Nishigata
第17回Lucene/Solr勉強会 #SolrJP – Apache Lucene Solrによる形態素解析の課題とN-bestの提案
第17回Lucene/Solr勉強会 #SolrJP – Apache Lucene Solrによる形態素解析の課題とN-bestの提案
Yahoo!デベロッパーネットワーク
3DCG(3Dコンピュータグラフィック)をWebGLで始めよう
3DCG(3Dコンピュータグラフィック)をWebGLで始めよう
AdvancedTechNight
Solr Exchange: Introduction to SolrCloud
Solr Exchange: Introduction to SolrCloud
thelabdude
Hivemallで始める不動産価格推定サービス
Hivemallで始める不動産価格推定サービス
Kentaro Yoshida
Lucene/Solr Revolution 2016 参加レポート
Lucene/Solr Revolution 2016 参加レポート
Shinpei Nakata
SolrとElasticsearchの比較
SolrとElasticsearchの比較
genta kaneyama
Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016
Cloudera Japan
D3.jsと学ぶVisualization(可視化)の世界
D3.jsと学ぶVisualization(可視化)の世界
AdvancedTechNight
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
Kentaro Yoshida
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
Cloudera Japan
Apache development with GitHub and Travis CI
Apache development with GitHub and Travis CI
Jukka Zitting
Andere mochten auch
(20)
CSS3Rendererを使ってiOSでもサクサク3D
CSS3Rendererを使ってiOSでもサクサク3D
The new repository in AEM 6
The new repository in AEM 6
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
Cloudera + MicrosoftでHadoopするのがイイらしい。 #CWT2016
トレジャーデータ 導入体験記 リブセンス編
トレジャーデータ 導入体験記 リブセンス編
Elasticsearch+nodejs+dynamodbで作る全社システム基盤
Elasticsearch+nodejs+dynamodbで作る全社システム基盤
ちょっと理解に自信がないなという皆さまに贈るHadoop/Sparkのキホン (IBM Datapalooza Tokyo 2016講演資料)
ちょっと理解に自信がないなという皆さまに贈るHadoop/Sparkのキホン (IBM Datapalooza Tokyo 2016講演資料)
データ分析チームの振り返り
データ分析チームの振り返り
学術コンテンツサービスでの活用事例@Lucene/Solr勉強会(2015.5.13)
学術コンテンツサービスでの活用事例@Lucene/Solr勉強会(2015.5.13)
Solr6 の紹介(第18回 Solr勉強会 資料) (2016年6月10日)
Solr6 の紹介(第18回 Solr勉強会 資料) (2016年6月10日)
第17回Lucene/Solr勉強会 #SolrJP – Apache Lucene Solrによる形態素解析の課題とN-bestの提案
第17回Lucene/Solr勉強会 #SolrJP – Apache Lucene Solrによる形態素解析の課題とN-bestの提案
3DCG(3Dコンピュータグラフィック)をWebGLで始めよう
3DCG(3Dコンピュータグラフィック)をWebGLで始めよう
Solr Exchange: Introduction to SolrCloud
Solr Exchange: Introduction to SolrCloud
Hivemallで始める不動産価格推定サービス
Hivemallで始める不動産価格推定サービス
Lucene/Solr Revolution 2016 参加レポート
Lucene/Solr Revolution 2016 参加レポート
SolrとElasticsearchの比較
SolrとElasticsearchの比較
Cloud Native Hadoop #cwt2016
Cloud Native Hadoop #cwt2016
D3.jsと学ぶVisualization(可視化)の世界
D3.jsと学ぶVisualization(可視化)の世界
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
Apache development with GitHub and Travis CI
Apache development with GitHub and Travis CI
Ähnlich wie 第10回solr勉強会 solr cloudの導入事例
POWER8サーバでMariaDBベンチマーク
POWER8サーバでMariaDBベンチマーク
NHN テコラス株式会社
SunspotではじめるSolr入門
SunspotではじめるSolr入門
Takao Baba
Tokyo r30 beginner
Tokyo r30 beginner
Takashi Minoda
Tokyo r38
Tokyo r38
Takashi Minoda
Rユーザのためのspark入門
Rユーザのためのspark入門
Shintaro Fukushima
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?
Makoto SAKAI
1台から500台までのMySQL運用(YAPC::Asia編)
1台から500台までのMySQL運用(YAPC::Asia編)
Masahiro Nagano
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
Satoyuki Tsukano
WalBの紹介
WalBの紹介
Takashi Hoshino
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと
MITSUNARI Shigeo
Hive on Spark を活用した高速データ分析 - Hadoop / Spark Conference Japan 2016
Hive on Spark を活用した高速データ分析 - Hadoop / Spark Conference Japan 2016
Nagato Kasaki
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
Toru Takahashi
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
Toru Takahashi
位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた db tech showcase 2013 Tokyo
位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた db tech showcase 2013 Tokyo
Yoshiyuki Asaba
TripleOの光と闇
TripleOの光と闇
Manabu Ori
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews, Inc.
20121215 DevLOVE2012 Mahout on AWS
20121215 DevLOVE2012 Mahout on AWS
都元ダイスケ Miyamoto
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
Learning spaerk chapter03
Learning spaerk chapter03
Akimitsu Takagi
Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点
Kodai Terashima
Ähnlich wie 第10回solr勉強会 solr cloudの導入事例
(20)
POWER8サーバでMariaDBベンチマーク
POWER8サーバでMariaDBベンチマーク
SunspotではじめるSolr入門
SunspotではじめるSolr入門
Tokyo r30 beginner
Tokyo r30 beginner
Tokyo r38
Tokyo r38
Rユーザのためのspark入門
Rユーザのためのspark入門
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?
1台から500台までのMySQL運用(YAPC::Asia編)
1台から500台までのMySQL運用(YAPC::Asia編)
Elasticsearch as a Distributed System
Elasticsearch as a Distributed System
WalBの紹介
WalBの紹介
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと
Hive on Spark を活用した高速データ分析 - Hadoop / Spark Conference Japan 2016
Hive on Spark を活用した高速データ分析 - Hadoop / Spark Conference Japan 2016
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた db tech showcase 2013 Tokyo
位置情報を使ったサービス「スマポ」をPostgreSQLで作ってみた db tech showcase 2013 Tokyo
TripleOの光と闇
TripleOの光と闇
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
20121215 DevLOVE2012 Mahout on AWS
20121215 DevLOVE2012 Mahout on AWS
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Learning spaerk chapter03
Learning spaerk chapter03
Zabbixのパフォーマンスチューニング & インストール時の注意点
Zabbixのパフォーマンスチューニング & インストール時の注意点
Kürzlich hochgeladen
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
UEHARA, Tetsutaro
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
FumieNakayama
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
Yuki Kikuchi
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
FumieNakayama
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
akihisamiyanaga1
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
博三 太田
Kürzlich hochgeladen
(8)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
デジタル・フォレンジックの最新動向(2024年4月27日情洛会総会特別講演スライド)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
クラウドネイティブなサーバー仮想化基盤 - OpenShift Virtualization.pdf
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
自分史上一番早い2024振り返り〜コロナ後、仕事は通常ペースに戻ったか〜 by IoT fullstack engineer
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
AWS の OpenShift サービス (ROSA) を使った OpenShift Virtualizationの始め方.pdf
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
CTO, VPoE, テックリードなどリーダーポジションに登用したくなるのはどんな人材か?
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
モーダル間の変換後の一致性とジャンル表を用いた解釈可能性の考察 ~Text-to-MusicとText-To-ImageかつImage-to-Music...
第10回solr勉強会 solr cloudの導入事例
1.
第10回 Solr勉強会 SolrCloud導入事例 株式会社サイバーエージェント
アメーバ事業本部 弘瀬 健 CyberAgent, Inc.
2.
自己紹介
• 弘瀬 健(ひろせ けん) • ~2011年 業務系WEBシステム構築 • 2011年~ サイバーエージェントで検索システム構築 • 今までに関わったサービス • Ameba検索 • アメーバニュース検索 • プロフィール検索 • グルっぽ検索 • Candy検索 • Simplog検索 2013/03/27 CyberAgent, Inc. 1
3.
アジェンダ
• SolrCloudの概要 • 導入事例(Simplog検索) • Simplogとは • システム構成 • その他 • まとめ 2013/03/27 CyberAgent, Inc. 2
4.
SolrCloud概要
• Solr4.0からの新機能 • クラウドによる分散検索/インデクシング • zookeeperを使ってクラウド情報を管理 http://wiki.apache.org/solr/SolrCloud 2013/03/27 CyberAgent, Inc. 3
5.
SolrCloud概要
• SolrCloudの構成要素 要素 説明 collection 1まとまりの検索対象を表す。1個以上のshardにより構成される。 zookeeperにより管理されるsolrの設定ファイルはcollection単位で適用される。 shard collectionを分割したもの。1個以上のcoreにより構成される。 node 1JVMインスタンスで起動されているSolr。 ポートを分ければ1サーバ内で複数nodeを起動することも可能。 core shardを構成する最小の単位。 1node内で複数のcoreを管理することもできる。 2013/03/27 CyberAgent, Inc. 4
6.
導入事例(Simplog検索)
• Simplogとは • スマホ用のブログサービス • 実績(2013/3/26現在) • Solr 4.1 • 検索対象ドキュメント数 : 295万投稿 • データサイズ : 1.5GB • 検索への反映時間 : 5分 • 負荷 • クエリ数 : 3~10万 query/day • ピーク帯のスループット : ~3qps • 平均レスポンスタイム : 50msec http://spapps.ameba.jp/simplog/ 2013/03/27 CyberAgent, Inc. 5
7.
導入事例(Simplog検索)
• システム構成 LB api 2台 node simplog_bk simplog zookeeper 3台 node 3台 node 3台 batch 2台 Simplog DB 6 2013/03/27 CyberAgent, Inc.
8.
導入事例(Simplog検索)
• サーバ環境 • api (OpenStackによる仮想環境) • OS : Linux CentOS 6.2 • メモリ : 4GB • CPU : 4core • disk : 30GB • ファイルシステム : ext3 • node (OpenStackによる仮想環境) • OS : Linux CentOS 6.2 • メモリ : 8GB • CPU : 4core • disk : 30GB • ファイルシステム : ext3 2013/03/27 CyberAgent, Inc. 7
9.
導入事例(Simplog検索)
• サーバ環境 • zookeeper (OpenStackによる仮想環境) • OS : Linux CentOS 6.2 • メモリ : 4GB • CPU : 4core • disk : 30GB • ファイルシステム : ext3 • batch (OpenStackによる仮想環境) • OS : Linux CentOS 6.2 • メモリ : 4GB • CPU : 4core • disk : 30GB • ファイルシステム : ext4 2013/03/27 CyberAgent, Inc. 8
10.
導入事例(Simplog検索)
●node1_core1 • コレクション構成 shard1 node2_core1 • simplogコレクション • 6shard ●node1_core2 • 3node shard2 node2_core2 • 4core/node • node1 ●node2_core3 • shard1(leader) shard3 • shard2(leader) node3_core3 • shard5 simplog • shard6 ●node2_core4 • node2 shard4 • shard1 node3_core4 • shard2 • shard3(leader) ●node3_core5 • shard4(leader) shard5 • node3 node1_core5 • shard3 • shard4 ●node3_core6 • shard5(leader) shard6 • shard6(leader) node1_core6 2013/03/27 CyberAgent, Inc. 9
11.
導入事例(Simplog検索)
• コレクション構成 • simplog_bkコレクション • 6shard shard1 ●node1_core1 • 3node • 2core/node shard2 ●node1_core2 • node1 • shard1(leader) shard3 ●node2_core3 • shard2(leader) simplog • node2 shard4 ●node2_core4 • shard3(leader) • shard4(leader) shard5 ●node3_core5 • node3 • shard5(leader) shard6 ●node3_core6 • shard6(leader) 2013/03/27 CyberAgent, Inc. 10
12.
導入事例(Simplog検索)
• その他 • SolrCloudの性能について • 平均レスポンスタイム50msec!? • リクエスト数、データサイズの割には性能が出ていない? • 検索/更新を同時に行った際の性能を、node数/shard数を変えながら調 べてみた 2013/03/27 CyberAgent, Inc. 11
13.
導入事例(Simplog検索)
• その他 • テスト環境システム構成 テストサーバ api 1台 node test zookeeper 3台 node 1~6台 batch 1台 test DB 12 2013/03/27 CyberAgent, Inc.
14.
導入事例(Simplog検索)
• その他 • テスト環境ノード用サーバ(仮想環境) • OS : Linux CentOS 6.4 • メモリ : 14GB • CPU : 4core • disk : 160GB • ファイルシステム : ext4 • テストデータ • ドキュメント数 : 26万 • データサイズ : 850MB • テスト内容 • テストサーバからJMeterで30分ほど200req/secの検索負荷をかける • バッチサーバから更新を行う(約65000レコード) • 以降のテストケースに対する試行回数は時間の都合で1回となってます 2013/03/27 CyberAgent, Inc. 13
15.
導入事例(Simplog検索)
• その他 • テストケース1 • shard数1、node数1~6の場合の検索/更新 • 1core/node • shardのleaderはnode1 ●node1_core1 node2_core1 node3_core1 test shard1 ●node1_core1 ・・・ test shard1 node4_core1 node5_core1 node6_core1 2013/03/27 CyberAgent, Inc. 14
16.
導入事例(Simplog検索)
• その他 • テストケース1 • shard数1、node数1~6の場合の検索/更新 • 1core/node • shardのleaderはnode1 • テスト結果 CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 1 1 1 1 35.29 58.4 27 12 80 1037 200.1 13 2 21.17 47.74 21 11 23 6317 199.4 22 3 19.01 42.28 13 10 16 939 200.1 22 4 19.55 43.32 16 10 17 5424 199.8 22 5 20.55 46.46 12 10 16 574 200.1 22 6 21.06 43.77 12 10 15 538 200.2 22 • node数が増えるにしたがって検索性能が向上 • 更新性能は劣化 2013/03/27 CyberAgent, Inc. 15
17.
導入事例(Simplog検索)
• その他 • テストケース2 ●node1_core1 • shard数2、node数1~6の場合の検索/更新 node2_core1 • 2core/node node3_core1 • 各shardのleaderはnode1に集約 shard1 node4_core1 node5_core1 shard1 ●node1_core1 node6_core1 test shard2 ●node1_core2 ・・・ test ●node1_core2 node2_core2 node3_core2 shard2 node4_core2 node5_core2 node6_core2 2013/03/27 CyberAgent, Inc. 16
18.
導入事例(Simplog検索)
• その他 • テストケース2 • shard数2、node数1~6の場合の検索/更新 • 2core/node • 各shardのleaderはnode1に集約 • テスト結果 CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 2 2 1 2 67.38 90.98 1403 1449 1650 8116 134 19 2 42.13 85.82 509 426 1033 8625 192.1 26 3 34.03 64.65 121 55 261 4439 199.4 26 4 31.12 58.63 85 28 200 3673 199.7 27 5 29.52 55.67 61 24 158 3766 200.1 27 6 28.34 50.75 61 23 148 5881 199.7 27 • shard数1の場合に比べて検索/更新性能が劣化 • 1nodeの場合の検索性能は特に劣化 • shard数1の場合と同様にnode数が増えるにしたがって検索性能は向上 • 更新性能はnode数が増えるにしたがって劣化 2013/03/27 CyberAgent, Inc. 17
19.
導入事例(Simplog検索)
• その他 ●node1_core1 node2_core1 • テストケース3.1 node3_core1 • shard数3、node数1,3,6の場合の検索/更新 shard1 node4_core1 • 3core/node node5_core1 • 各shardのleaderはnode1に集約 node6_core1 ●node1_core2 shard1 ●node1_core1 node2_core2 node3_core2 test shard2 ●node1_core2 ・・・ test shard2 node4_core2 shard3 ●node1_core3 node5_core2 node6_core2 ●node1_core3 node2_core3 node3_core3 shard3 node4_core3 node5_core3 node6_core3 2013/03/27 CyberAgent, Inc. 18
20.
導入事例(Simplog検索)
• その他 • テストケース3.2 • shard数3、node数3の場合の検索/更新 • 3core/node • 各shardのleaderは各nodeに分散 ●node1_core1 shard1 node2_core1 node3_core1 node1_core2 test shard2 ●node2_core2 node3_core2 node1_core3 shard3 node2_core3 ●node3_core3 2013/03/27 CyberAgent, Inc. 19
21.
導入事例(Simplog検索)
• その他 • テストケース3.1 • shard数3、node数1,3,6の場合の検索/更新(3core/node、leader集約) • テストケース3.2 • shard数3、node数3の場合の検索/更新(3core/node、 leader分散) • テスト結果 CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 3.1 3 1 3 73.37 91.77 1561 1611 1885 7375 121.3 20 3.1 3 37.56 79.9 232 170 475 5108 197.2 28 3.2 3 35.65 90.52 203 141 388 16014 195.3 30 3.1 6 32.23 70.93 110 26 218 8192 196.9 30 • shard数2の場合に比べて検索/更新性能が劣化 • 1nodeの場合の検索性能は特に劣化 • shard数2の場合と同様にnode数が増えるにしたがって検索性能は向上 • 更新性能はnode数が増えるにしたがって劣化 • leaderを各nodeに分散させた場合の影響は判別不可(3.1、3.2) 2013/03/27 CyberAgent, Inc. 20
22.
導入事例(Simplog検索)
●node1_core1 node2_core1 • その他 node3_core1 shard1 • テストケース4.1 node4_core1 node5_core1 • shard数4、node数1,3,6の場合の検索/更新 node6_core1 • 4core/node ●node1_core2 • 各shardのleaderはnode1に集約 node2_core2 node3_core2 shard2 shard1 ●node1_core1 node4_core2 node5_core2 shard2 ●node1_core2 node6_core2 test shard3 ●node1_core3 ・・・ test ●node1_core3 node2_core3 shard4 ●node1_core4 node3_core3 shard3 node4_core3 node5_core3 node6_core3 ●node1_core4 node2_core4 node3_core4 shard4 node4_core4 node5_core4 node6_core4 2013/03/27 CyberAgent, Inc. 21
23.
導入事例(Simplog検索)
• その他 • テストケース4.2 • shard数4、node数3の場合の検索/更新 • 各shardのleaderは各nodeに分散 • node1 ●node1_core1 • shard1(laeder) shard1 • shard2(laeder) node2_core1 • node2 ●node1_core2 shard2 • shard1 node3_core2 • shard3(laeder) test ●node2_core3 • shard4 shard3 node3_core3 • node3 • shard2 ●node3_core4 shard4 • shard3 node2_core4 • shard4(laeder) 2013/03/27 CyberAgent, Inc. 22
24.
導入事例(Simplog検索)
• その他 • テストケース4.3 • shard数4、node数4の場合の検索/更新 • 2core/node • 各shardのleaderは各nodeに分散 ●node1_core1 shard1 node2_core1 ●node2_core2 shard2 node3_core2 test ●node3_core3 shard3 node4_core3 ●node4_core4 shard4 node1_core4 2013/03/27 CyberAgent, Inc.
25.
導入事例(Simplog検索)
• その他 • テストケース4.1 : shard数4、node数1,3,6の場合の検索/更新(4core/node、 leader集約) • テストケース4.2 : shard数4、node数3の場合の検索/更新(node1=2core、node2,3=3core、leader分散) • テストケース4.3 : shard数4、node数4の場合の検索/更新(2core/node、leader分散) • テスト結果 CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 4.1 4 1 4 76.19 92.96 1738 1785 2159 8203 109.6 22 4.1 3 40.95 87.97 548 459 1068 10010 189 31 4.2 3 2、3 29.28 78.14 228 163 428 9040 195.2 30 4.3 4 2 28.53 80.2 122 39 256 7352 198.2 28 4.1 6 4 33.77 88.28 179 79 373 10889 194.6 32 • shard数3の場合に比べて検索/更新性能が劣化 • 1nodeの場合の検索性能は特に劣化 • shard数3の場合と同様にnode数が増えるにしたがって検索性能は向上 • 更新性能はnode数が増えるにしたがって劣化 • shard数、node数が同じ場合、各node内のcore数が少ない方が検索/更新性能は良い (4.1 node3、4.2) • nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もある (4.3、4.1 node6) 2013/03/27 CyberAgent, Inc. 24
26.
導入事例(Simplog検索)
• その他 • テストケース5.1 • shard数6、node数3の場合の検索/更新 • 2core/node • simplog_bkコレクション同等の構成 shard1 ●node1_core1 shard2 ●node1_core2 shard3 ●node2_core3 test shard4 ●node2_core4 shard5 ●node3_core5 shard6 ●node3_core6 2013/03/27 CyberAgent, Inc. 25
27.
導入事例(Simplog検索)
• その他 • テストケース5.2 • shard数6、node数3の場合の検索/更新 • 4core/node • simplogコレクション同等の構成 ●node1_core1 shard1 node2_core1 ●node1_core2 shard2 node2_core2 ●node2_core3 shard3 node3_core3 test ●node2_core4 shard4 node3_core4 ●node3_core5 shard5 node1_core5 ●node3_core6 shard6 node1_core6 2013/03/27 CyberAgent, Inc. 26
28.
導入事例(Simplog検索)
• その他 • テストケース5.3 • shard数6、node数6の場合の検索/更新 ●node1_core1 shard1 • 2core/node node4_core1 • node1 • shard1(leader) ●node1_core2 • shard2(leader) shard2 node4_core2 • node2 • shard3(leader) ●node2_core3 • shard4(leader) shard3 • node3 node5_core3 • shard5(leader) test ●node2_core4 • shard6(leader) shard4 • node4 node5_core4 • shard1 • shard2 ●node3_core5 • node5 shard5 node6_core5 • shard3 • shard4 ●node3_core6 • node6 shard6 • shard5 node6_core6 • shard6 2013/03/27 CyberAgent, Inc. 27
29.
導入事例(Simplog検索)
• その他 • テストケース5.1 : shard数6、node数3の場合の検索/更新(2core/node、 simplog_bkコレクション同等の構成) • テストケース5.2 : shard数6、node数3の場合の検索/更新(4core/node、 simplogコレクション同等の構成) • テストケース5.3 : shard数6、node数6の場合の検索/更新( 2core/node 、simplog_bkコレクションにレプリカを追 加した状態の構成) • テスト結果 CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 5.1 6 3 2 42.05 77.33 152 99 317 5103 199.3 20 5.2 3 4 38.7 87.5 713 644 1340 10457 180.5 30 5.3 6 2 24.59 73.12 96 28 206 4668 199.1 27 • shard数4の場合と同様にnode数が増えるにしたがって検索性能は向上(5.1、5.3) • 更新性能はnode数が増えるにしたがって劣化 • shard数、node数が同じ場合1nodeあたりのcore数が少ない方が検索/更新性能は良い (5.1、5.2) 2013/03/27 CyberAgent, Inc. 28
30.
導入事例(Simplog検索)
• その他 • テスト結果(shard数による違い) CPU %user (node1) response テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min) 2 2 3 2 34.03 64.65 121 55 261 4439 199.4 26 5.1 6 3 2 42.05 77.33 152 99 317 5103 199.3 20 2 2 4 2 31.12 58.63 85 28 200 3673 199.7 27 4.3 4 4 2 28.53 80.2 122 39 256 7352 198.2 28 4.1 4 3 4 40.95 87.97 548 459 1068 10010 189 31 5.2 6 3 4 38.7 87.5 713 644 1340 10457 180.5 30 2 2 6 2 28.34 50.75 61 23 148 5881 199.7 27 5.3 6 6 2 24.59 73.12 96 28 206 4668 199.1 27 • node数/1nodeあたりのcore数に関係なく、collection内のshard数が少ない方が検 索性能が良い • 更新性能については判別不可 2013/03/27 CyberAgent, Inc. 29
31.
導入事例(Simplog検索)
• その他 • テスト結果(まとめ) • 1nodeあたりのcore数は少ないほど検索/更新性能が良い • 1collectionあたりのshard数は少ないほど検索性能が良い • 1node内のcore数が同じ場合、nodeが多いほど検索性能が良い • 更新性能はnode数が少ない方が良い • node数と1nodeあたりのcore数 • nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もあ る 2013/03/27 CyberAgent, Inc. 30
32.
まとめ
• SolrCloudの利点 • Solrの設定ファイルをコレクション内で一元管理できる • 検索/更新クライアントは各コレクション内のnodeを意識しなくてよい • コレクション内のnode(レプリカ)を追加しても検索/更新クライアントの変更は不要 • SolrCloud利用時の注意点 • shardの分割機能はまだないのでコレクション作成時のデータサイズの見積もり に注意 • shardを増やす場合は合わせてnode数も検討 • コレクション情報が壊れると検索/更新できなくなる • 更新処理の必須条件 • 全shardのleader nodeのステータスがactiveであること • 検索処理の必須条件 • 各shardに最低1つのnode(core)が割り当てられていること • shardが1つでも欠落するとそのコレクションに対しては検索不可 • shardsパラメータで検索対象shardを明示的に指定した場合は可能 • パフォーマンスは素のSolrの方が良い 2013/03/27 CyberAgent, Inc. 31
33.
ご清聴ありがとうございました 2013/03/27
CyberAgent, Inc. 32
Jetzt herunterladen