Groongaで学ぶ全文検索 2016-01-15 - Groonga | Doorkeeper
という勉強会に参加した。
このポストはこの勉強会の方針に基づき書いている。
この勉強会では準備をしない。
予習、復習をしない方針。
この場でまとまった知識を共有し合う方針。
以下、昨日聞いた事を書き留めた。（あまりまとまってはいない。）
この記事を書いた時は昨日2016年1月16日で同席したみなさんにはサラッとお見せした。
一つの内容を複数の人が書いているので他の方のブログが読みやすいと思う。
要約としては以下になる。
全般的にRDBMSと違って、全文検索はトランザクション機能を有するものが少なく、データロストにどのように対応するかという事。
groongaは他のRDBMSより書き込みが早い。（早い理由はデータ圧縮などをしているとのこと。）
mroongaではmysqlのレプケーションを利用して、データの損失に備えている。
mroonga自体にはレプケーション機能はないとの事。
RDBMSの信頼性について
最終的にはディスクは壊れる。
壊れる種類
論理的に壊れる
物理的に壊れる
物理的にディスクが壊れた場合はデータは助からない。
RDBMSはトランザクションによって、論理的にデータが壊れることを防いでいる。
運用ではコピーを取ることが必須。
コピーは同時に壊れる確率を下げる。
コピーをすれば費用がかかる。
1台のサーバでサービス運用をするのは無理があるので複数台で運用する。
mroongaの話
全文検索製品ではトランザクションに対応したものが少ない。（理由は難しいなど） よって、RDBMSに比べ全文のDBは論理的に壊れる可能性が高い。
対策
バックアップをとっておくというやり方
途中のデータは捨てる。というやり方
普通のやり方はマスターデータをキープするやり方。
マスターデータから復旧するには何かしらのデータを足す。
（差分バックアップを足すなどの方法。）
全文検索はデータを足すという方法をとっている。
復旧するにはダウンタイムとのトレードオフ
0から作り直すのは時間かかる。
対策として複数のサーバ間でコピーをする。
サーバ間のコピーでも遅延がある。（replication遅延）
クライアントからのクエリ発行数に対して、レプケーションのセッションが1つしかなく遅れる。
今のmysqlは、セッションが複数張れて改善されている。
RDBMSのトランザクションは大きいと(commitまでのクエリが多数発行されると)、レプケーション遅延が発生する場合がある。
groongaは他のRDBMSより書き込みが早い。
mysqlのreplicationを利用してgroongaは書き込みしている。
InnoDBがマスターDBとして機能してスレーブにコピーができる。
検索だけはスレーブ側に発行する。
データの格納方法について
mroongaはデータとインデックスをに入れる
pgroogaはデータだけpostgresに入れて、 groongaがインデックスを持つ。
運用上の注意点
1マスタ2スレーブの構成の際スレーブへのアクセスが少ないからと言って、スレーブ側にも書き込みしてはならない。
mroongaは1マスター2スレーブ構成も出来る。
mroongaは強制終了しなければデータは壊れない。
今日知り得た知識
全文検索エンジンは検索時は書き込みしない。（ものが多い）
書き込みが都度発生してかつ、全文検索する場合はやはりKVSなどのものがいいのではないか。
とここまで書いて、ブログを発表しあった際、正しくないと御指摘いただいた。
違うらしい、groongaはカラムベースのロックで、書き込みロックとなっている。
（さらに書き込みリクエスト毎にこまかな制御をされているのだと推測する。）
参照される情報は新しい方が良いという設計方針のため、書き込みが多くても検索には支障がない。
情報の書き込みがあっても、検索のQueryを発行しても問題がないとの事です。
須藤さんから説明いただいた。
ありがとうございました。
この様に人の話を聞いて、理解した内容を文章に起こしその場で発表するという画期的な勉強会でした。
須藤さんは物腰が柔らかい印象な方で、丁寧に解説いただけた。
この会では最初に参加者が疑問に思っている事を聞いて、興味を持っている内容を須藤さんから話ていただいている。
あと、自分は早めに会場についてしまって、1つ質問をしました。
「mroongaのMariaDB対応について」
デフォルトでバンドルされているとの事でした。
これは自分が無知で無礼な質問であったかも知れません。
この場でお詫び申し上げます。
デフォルトで入っているならば直ぐに試せるので非常にありがたい。
このMariaDBにデフォルトでmroongaがバンドルされているという事は大きく知らせた方がいいのではと思う。
（自分はmysqlの話を聞いている傾向があってMariaDBの話にあまり関心がないからかも知れない。）
参考までに須藤さんの活躍の記事があったのでリンクを貼っておきます。
0 件のコメント:
コメントを投稿