Naoya Murakami
visio****@gmail*****
2013年 10月 28日 (月) 13:15:49 JST
お世話になっております。村上です。 なるほど。 > データの更新はMroongaでやって、検索はexpress-droongaでやると > いう構成ってことですね。MroongaもDroongaも違ったデータ分散の > 方法を持つので難しいかもなぁと思いました。 > そうですね。その構成ができないかなぁと検討しています。 が、難しいんですね。自己責任で色々やってみます！ 分散の目的は、リアルタイムな更新のためでなく、肥大化した データベースを分割して検索するのが目的です。 mroongaでの更新の方は、別に分散しなくてもいいと思っていて、 また、SPIDERでできると思っています。 更新と検索の分散ルールが異なっていても問題ないです。 データを分散しなければ動きそうですが、それで割にあうか > （Groongaを直接使う場合よりもメリットがあるか。速いとか。） > は実際にちゃんと動くようになったのを使ってみながら検討しない > となぁと思いました。 > 検索の場合は、mroongaで生成されたgroongaのデータベースを 単純にgroongaで直接作れられたものと同じようにして、droonga に載せられればいいなぁと思ってます。 (mysql経由では基本的には全文検索はしない。) ストレージモードで作られるgroongaのデータベースは、mysqlの データディレクトリに作られるということと、.mrnというファイル名で 作られることを除き、基本的にgroongaで直接作られるデータベース と変わりないという認識です。 （DDLがある程度、決まった型になるとは思いますが。） ここまでするんなら、groonga直接でいいんでは？というのは、 その通りだと思います。 しかしながら、mroongaを使うメリットは、個人的には、以下のように考えています。 ・MySQLとの連携が容易。 MySQLの他のストレージエンジンから、insert selectで簡単にデータを移して、 groongaのデータベースを構築できます。 mroongaのデータベースのほかに、データ保持用のMySQLのデータベースを使ってます。 堅牢な他のストレージエンジンとレプリケーションもできます。 MySQLだと、関数つかって、データを加工しながら、データを移したりいろいろ便利です。 ・MySQLでテーブル設計が行える。 使い始め当初は、groongaになじみがなく、なかなか、groongaのコマンドやDDL設計に とっつきにくかったというのがありました。 これは、ストレージモードを使い始めて、groongaにだいぶなじみがでてきたので、 メリットとしてはだいぶ薄くなってきました。なので、MySQLとの連携を無視すれば、 検索用にgroongaで直接つくるのでもいいのかもなぁとも思っています。 当方のケースは、レアケースだと思うので、あまりに気にしなくていいです！ こちらでフィットする使い方をいろいろ試行錯誤します。今後の開発に期待しています！ 以上、よろしくお願いします。
