Top
<   2013年 03月 ( 14 )   > この月の画像一覧
*
*
2013年 03月 28日 *

[PR]
2013年 03月 28日 *
最初の出発点に戻って考えてみる。

数百万行のcsvファイルを編集したいが、エクセルやアクセスで編集しようとすると、PCが固まってしまう、orそもそも開くことができない。という状態に陥る。
そこで代替案としてRDBMSを使ってみたが、そこまで速いという訳ではなかった。
簡単な並び替えは速いが、重複の削除をしようと思ったら、連番の付与が必要になり、数十分を要する。
それならCSVファイルを100万行ごとに切り分けて、エクセルで編集した方が速いのではないだろうか。
ただそれだと1000万行のCSVだと10回切り分けなければならなくなるので、RDBMSで一度に処理した方が得策とも言える。
連番を付与するだけならEmEditorを使えばMySQL並みのスピードで可能だが、EmEditorの連番付与は有料版の機能らしい。

1GB前後のファイルを編集するにあたり、RDBMSとエクセルの決定的な違いを挙げるとすれば、PCが固まるか否かという点だ。
エクセルだと列を削除しようとしてもメモリが足りませんと表示され失敗することがよくあるし、とにかく一つ一つの操作に対してPCが固まる。
編集作業と並行して他の作業をしようと思ったら、もう1台PCが必要になるのだ。
それに比べ、RDBMSの処理はYouTubeの動画を再生する位の負荷はかかるものの、他の作業も十分可能だ。
個人的にはRDBMSの挙動の方が好感が持てる。
あと基本的に無料な点も良い。

100MB前後のファイルの加工ならエクセルVBAでいいだろうし、文字の置換だけならフリーのエディタでいいだろう。
ただ扱うファイルの容量が1GBを超えると厳しい。
そこで今回はRDBMSを試してみたが、
「そもそもRDBMSはファイルを編集・加工するためのソフトじゃねーからw」
という突っ込みもあるだろう。
だが、文字の置換はPerlやRubyに任せるとしても、重複行を優先順位を指定して削除するといった編集が必要な場合はどうすればいいのだろう。
他にもっといいやり方があればまた別の機会に取り上げてみたい。


最後に、便利なフリーソフトや参考サイトを紹介。

・KanjiTranslator
http://www.kashim.com/kanjitranslator/
RDBMSにCSVをインポートする際、文字コードはutf-8 BOM無しにするとか、改行コードはLFにするといった、ファイル形式を一括変換してくれる優れたソフト。
TeraPadやサクラエディタでも同等の機能はあるが、このソフトの方が気分的に楽。

あとSQLに関しては本よりもネットの方が詳しく書かれていたりする。
以下のサイトでは相関サブクエリや自己結合について解説されている。

・達人に学ぶSQL
http://codezine.jp/article/corner/51
・SQLアタマアカデミー
http://gihyo.jp/dev/serial/01/sql_academy2

あとOKWaveにMySQLとpstgreSQLの違いについて書かれていて、割と自分も同意する面があった。
http://okwave.jp/qa/q5229903.html
以下、回答を引用。

 私も一時期迷いましたが、結果的にPostgreSQLにしました。

・将来性
 PostgreSQLは将来性があります。これからもOracleに追いつき、追い越そうと進化していくでしょう。
 ですが、Oracleに買収されたMySQLにはそれは絶対にありません。むしろ棲み分けのために機能が押さえ込まれていく可能性の方が高いように思います。また、今までMySQLを支援してきた開発コミュニティの大多数は、「あのOracle社」の売り上げに貢献するためにボランティア活動を続けていけるほど心が広くないのではないかと思います。

・設計
 PostgreSQLはかなり「マトモな」DBだと思います。「え?こんなことが?」ということがほとんどありません。全般的に70点、というカンジです。
 ですが、MySQLはかなりクセがあります。一般的なSQLのコツ以外に、MySQL独自の制約やコツのようなものがけっこうあります。(サブクエリが異様に遅いとか) 普通ならこうするけど、MySQLの場合はこうしないといけない、というようなことはあまり考えたくないです。
 それよりなにより、なんといっても「シーケンスがない!」というのが衝撃でした。もちろん代替策はあるんですが、「代替策があるからシーケンスなんて無くてもいいだろ」という考え方はどうも納得できません。
 PostgreSQLは、機能改善の仕方が順序立っていて、まずこの機能、次にこの機能、という流れがとても自然な気がします。反面MySQLは行き当たりばったりで機能拡張していて、結果的に100点の部分もあるけど0点の部分もある、という印象です。

・コスト
 PostgreSQLはどこまでいっても無料、というのが安心です。反面、責任を持っている企業もないというのが不安といえば不安ですが、有償でサポートしている会社がないわけではないので必要ならそういうところを利用するのもあるかと思います。
 反面、MySQLは責任を持っている企業がある反面、そこがサポート収入に異様にどん欲なところである点が不安です。無償版の存続すら絶対とは言えない状況ですから。

・情報
 日本語の情報に関していえば、PostgreSQLが圧倒的です。ですが、マニュアル自体がかなり簡素なので、突っ込んだことを知りたいと思うとユーザのブログなどの非公式情報に頼ることが多く、ここが物足りない点ではあります。
 MySQLは今現在は日本語の情報が少ないのですが、Oracleはマニュアルなどの技術情報の開示についてはかなり積極的ですし、ドキュメントの日本語化もかなりスピーディです、今後は期待できるかもしれません。

・その他
 MySQLの利点は、無償版でもクラスタの機能があるところです。PostgreSQLは単体ではクラスタの機能がありません。(私はここで迷った)
 ただ、pgpool2などの外部のプロジェクトやDRBDなどを使えばカバーできますし、PostgreSQLも次のバージョンでクラスタリングがサポートされそうな雰囲気です。(本当は今のバージョンで実装されるはずだったが間に合わずに延期になった)

 これらの点を総合的に判断すると、やっぱりPostgreSQLかな、と自分的には判断しています。
[PR]
2013年 03月 28日 *
とりあえずMySQLはサブクエリが遅いため使用を断念し、次にフリー系で有名なpostgreSQLを使ってみる。
そもそも読み方がわからないこのソフトだが、重要なのはやりたい事ができるかどうかだ。


postgreSQLをインストール

postgreSQLをダウンロードし、インストール画面で適当にOKをクリックしていくとインストールは完了する。
あとはC:\Program Files\PostgreSQL\9.2\binフォルダにあるPSQLをコマンドプロンプトで起動すれば使えるはずだ。
これはMySQLのノリと同じである。
しかし、スーパーユーザーでログインする最初の場面でつまづいてしまった。
色々調べていくと、どうやらユーザー名はrootではなく慣習的にpostgresになるらしい。
これはわからなかった…。
あとデータベースを作成し、テーブルを作成したものの、それがどこにあるかがわからなかった。
色々調べたところ、どうやらスーパーユーザーは何も指定しないとpostgresというデータベースを使用するらしく。
自分の作ったテーブルはその中に保存されていた。

CSVをインポート

postgreSQLのコマンドはMySQLとは少し異なる部分がある。
MySQLで通用したSQL文がpostgreSQLでは通用しなかったりする。
SQLの解説サイトにあるSQL文がそのまま使えないこともあるので、その場合は若干修正が必要となる。

CSVのインポートはこのコマンドで実行できた。

COPY テーブル名 FROM 'csvの保存場所' WITH CSV;

うまくいくと、次のようなメッセージが表示される。

クエリーは、成功しました: 5293104 行の影響があり, 実行時間は、63570 ミリ秒でした。

インポートにかかる時間はMySQLよりも若干はやかったが、ほとんど変わらない感じ。

select * from テーブル名 limit 5;

このコマンドも叩いたと同時に結果が表示され、MySQLと変わらない。
次に並び替えを行った場合の時間を計測するため、下記のコマンドを入力。

select * from テーブル名 order by 列名 limit 5;

結果は下記のようになった。

クエリ全体 実行時間:3580 ms. 5 行検索しました

約3秒。MySQLと比較して若干速い結果になった。

それではお待ちかね、MySQLの苦手?なサブクエリを叩いてみよう。
コマンドはMySQLと同じ。

select * from テーブル名 where 列名 in (
select min(列名) from テーブル名 group by 列名
)
order by id limit 5;

結果は以下のようになった。

クエリ全体 実行時間:38400 ms.5 行検索しました

おお、わずか1分弱でちゃんと結果が返ってきているではないか!
MySQLは30分経っても返ってこなかったのに。
やはりpostgreSQLは使える!

と、まずまずの結果に満足だったが、連番の振り方はどうすればいいのだろう。
MySQLではユーザー定義関数を使用することで並び替え後の連番の振り直しが実現できたが、postgreSQLで同じコマンドを叩いてもエラーになってしまう。
仕方なく別の方法を探すことにした。

調べると下記の方法でテーブルの列に連番を振れることがわかった。

一つ目は相関サブクエリを使う方法。
二つ目はROW_NUMBER()を使う方法。

相関サブクエリが何であるかは解説サイトを読んでもわからなかったが、重複データに対してちゃんと連番が振れるかどうか不安に感じた。
例えば成績テーブルから得点順に並び替えて連番を振ることを考えた時に、100点の人が2人いると2人とも順位は1位という状態になるのではないだろうか。
現実世界ならそれでOKだが、自分が欲しい結果は、2人いる1位をどうにかして1位と2位に区別して番号を振りたいのだ。

相関サブクエリを使用した場合に得られる結果(予想)
(順位、得点、名前)
1,100,Aさん
1,100,Cさん
3, 98,Eさん
4, 96,Bさん

自分が欲しい結果
(順位、得点、名前)
1,100,Aさん
2,100,Cさん
3, 98,Eさん
4, 96,Bさん

あくまで予想のレベルだが、得点が一意であるテーブルなら相関サブクエリを使用して連番を振ってもいいが、得点が一意でない場合はもう一工夫、回避方法が必要な感じ。

それでは2番目の方法はどうか。
postgreSQLにはROW_NUMBER()という便利な関数が用意されている。
これをそのまま列にコピーするSQLが書ければ目標は達成できる。
しかし、下記のようなコマンドを叩いてもエラーになってしまう。

update テーブル名 set 列 =ROW_NUMBER();

これについて調べてみると、以下のように相関サブクエリ?を使用することで回避できることがわかった。

update テーブル名 set 列 =
SeqTbl.列3
FROM (SELECT 列,
ROW_NUMBER() OVER (ORDER BY 列2) AS 列3
FROM テーブル名) SeqTbl
WHERE テーブル名.列 = SeqTbl.列;

列には連番を振る列を指定。
SeqTblは適当に付けられている仮の名前なので好きに付けていい。
列3も好きな名前でOK。
列2には並び替えしたい列を入力。

そして結果は…

クエリーは、成功しました: 5293104 行の影響があり, 実行時間は、889959 ミリ秒でした。

所要時間は約15分…。待てない時間ではないが、連番を振る動作に関してはMySQLの方が速い。
これなら並び替えをしたCSVファイルをエクスポートしてMySQLで連番を振った方がトータルだと早い。
まあ邪道ではあるが…。
[PR]
2013年 03月 28日 *
NHKでビッグデータを連呼しているから、容量の大きいデータをどのように処理するか考えてみた。

その前に、比較的容量の少ないデータを扱う場合に普段どうしているだろう。

エディタで加工したり、エクセルを用いたり。
プログラムの得意な人はエクセルマクロを使うかもしれない。
データを結合するのにアクセスを使うかもしれない。
普段のオフィスワークに関しては、それで事足りる場合がほとんどである。

しかし、問題はファイルサイズが大きい場合だ。

そもそもエクセルではファイルサイズの大きいデータを開くことすらできない。
昔のエクセルでは65,536行、最近のエクセルでも1,048,576行が限界である。
エクセルマクロもその制限の影響を受けるので、正常終了するマクロであっても大容量のデータを扱おうとすると異常終了で終わる。
また、100万行に近いデータは開くだけでも時間がかかり、ちょっと編集するだけでも動作が重くなる。


この重い動作を何とかできないか考えるのが今回のテーマだ。


ならばアクセスはどうか。
アクセスなら2Gまでのデータは扱えることになっている。
が、やはり1G超のデータを扱おうとすると処理が重くなる。
インポートだけでも数分かかり、クエリの実行だけでも数分かかり、エクスポートにも数分かかる。
その間もアプリが固まっているのか不安になり、他の操作を受け付けないので、椅子に座ってじっとしている以外にない状態。
結論として、アクセスで1G超のデータを扱うのはあまり得策ではない気がする。


ではエディタならどうか。
フリーのエディタとして有名なのがTeraPadとサクラエディタである。
しかし、TeraPadで1G超のテキストファイルを開こうとするとメモリ不足のエラーで開くことができない。
なんだよと思いながら、試しにサクラエディタで開こうとするとPCが固まった状態になる。
これでは最初からファイルを開かないTeraPadの方が動作としては良心的なのかもしれない…。

大容量データを開けるエディタとしてはEmEditorがある。
有料版はWindows7 64bit対応しており、1G超のファイルを軽快に開くことができる。
フリー版でも1G超ファイルを開くことができ、正規表現にも対応しているので、ちょっとした編集ならこのソフトが使えるかもしれない。
でも100万行全てを置換しようとするとやはり何分も時間がかかってしまうところが少し残念。
またエクセルと違って自由に並び替えしたりできないので、これだけで編集を完結させるのは無理そうだ。


という訳で、PCにRDBMSというものをインストールし、1G超のデータの加工にどれくらいの時間がかかるのか測ってみようと思った。


■MySQL

まずはオープンソース系で世界シェアNo1と言われているMySQLをインストールしてみる。
実際にはXAMPPをインストールすると色々なソフトと一緒にMySQLも簡単に使えるようになるので、XAMPPを入れてみた。

今回、データの加工用に用意したのは、約1.2GBのCSVデータ。
行数だと500万行ちょっとくらい。
当然エクセルでは開くことすらできない。
またアクセスを用いてもかなり動作が重くてイライラするデータ容量と言えるだろう。

データをインポートする前に、まずテーブルを用意しなければならない。
いちいちコマンドを打つのが面倒な人はphpMyAdminを使うとGUIベースでテーブルを作成することができる。

また作成したテーブルの型だけを複製したいといった場合も

CREATE TABLE 新規テーブル LIKE 既存テーブル;

という風にLIKE~を使うと便利。

では早速データをインポートしよう。

コマンドは、

load data local infile "ファイルの場所" into table テーブル名 fields terminated by ',';

のような感じで入力。
結果は

Query OK, 5293104 rows affected (1 min 43.75 sec)

2分弱か…。
決して速い訳ではないが、遅いとも言えない。

ではテーブルの中身を5行ばかり表示してみよう。

コマンドは、

select * from テーブル名 limit 5;

のように入力。
するとエンターキーを叩いたと同時に結果が表示された。

5 rows in set (0.00 sec)

おお、これはすごい速いぞ!
ちなみに列が沢山あるテーブルが変に改行されて見づらくなってしまう現象が起こる場合は、コマンドプロンプトのプロパティで幅の設定を変更できる。

今度は並び替えをしてみよう。

コマンドは、

select * from テーブル名 order by 列名 limit 5;

のように入力。
結果は、

5 rows in set (17.89 sec)

まあこれもそれなりに速いじゃないか!

と、この時点では興奮気味に色々コマンドを叩いていたのだが…。

テーブルを並び替えて連番を振ってみようと思ったが、そう単純にはいかない。
そもそもデータベースにはオートナンバーのようなレコードを一意に特定するための数字を振る概念はあるが、並び替えた順序で連番を振るといった考えはあまり存在しないようだ。
ただネットで検索すると、ユーザー定義関数を使用すれば実現できるらしい。

SET @i := 0;
UPDATE テーブル名 SET id = (@i := @i +1) ORDER BY 列名1,列名2,…;

実際にやると確かに連番が振れた。
が、6分近く時間がかかった。
単純に100万行の連番を振るのに1分近くかかる計算。
やはりあまりメジャーな操作でない分、実行は速くできないようだ。

次に重複の削除をしてみよう。
ちなみにエクセルにも2007から重複の削除機能が追加されている。
データベース的にはデータを削除するというより、重複データを表示しないようにするという感覚に近い。

コマンドとしては、以下のように先ほど連番を振ったid列とサブクエリとgroup by句を使用することで実現できる。

select * from テーブル名 where id in (
select min(id) from テーブル名 group by 列名
)

だがしかしここで問題が生じる。
数百行のテーブルならすぐに実行できるが、数百万行のテーブルだと実行に時間がかかりすぎる様子。
30分近く経っても結果が返ってこない…。
ネットで調べてみるとMySQLのサブクエリは遅いらしく。
自分はこの時点をもって、MySQLを使用していくことを断念した。orz
そもそも使うコマンドが間違っている可能性もあるが、ここで心が折れました…。

(PostgreSQL編に続く)
[PR]
2013年 03月 23日 *
ITの変化の流れは激しいと言われるように、使われる技術がすぐ陳腐化したりする。
カタカナ用語が一人歩きするのもよくあり、その用語もいつの間にか死語になっていたりする。
よく分からないカタカナ用語が飛び出してくるのは、ベンダーやコンサルが売り込む際の手法によく見られる。
リスクがどうのとか、最新動向がどうとか、危機を煽るため、聴衆を何となく巻き込むために訳の分からない単語を混ぜてくる。
これは奴らの常套手段で、昔から変わっていない。

NHKの震災ビッグデータという番組名を見た時も、何だか微妙な違和感があった。
国民の受信料で成り立っている放送局が、なぜ民間企業の広告塔に成り下がっているのかと。
まあ汚れた目で見ればそういうことになるが、今まで膨大なデータを扱うことができなかったのは事実。
一つはIT技術の発達により大容量のデータの保存・解析が可能になったこと。
もう一つは携帯が一人一台の時代になり、携帯やカーナビにGPS機能が付いていること。
これによって、人の動きを追跡することができるようになった。

人の動きを追跡できるようになったのは分かったが、そのデータは一体何の役に立つのか。
犯罪のアリバイを証明できるのだろうか。(そんな例は聞いたことがないが)
例えばSNSに組み込んで近くにいる友達とコミュニケーションを取ったりとか。
そういえば昔auでそんなサービスを見たことがある。
でも、友達同士で居場所を共有できるようになったらなったで、うざいと思う。
企業が社員を管理するために活用するとか。
そんな人の嫌がるようなサービスが普及するとは思えないが。

この前、ビッグデータ婚活という言葉を見た。
利用者の行動パターンからその人の趣味やよく行くお店や生活スタイルを分析し、合う人をマッチングしてくれるサービスなのだろうか。
それとも、お前ただビッグデータと言いたいだけちゃうんかと。

ともかく、ITでこんな用語が流行っているといっても、利用者の立場からしてみれば用語なんてどうでもいい。
問題はサービス内容とクオリティである。
人の動きの追跡データを民間企業に売るとか、今後そういうことは起こるかもしれない。

だけどこのデータを今後の震災に役立てるとかいうのはどうなんだろう。
少なくとも番組で出てきた登場人物がそれをやってくれるとは思えなかった。
データ量が膨大なのはわかる。
ギガやテラの単位でないことはわかるし、それを逐一保存していったらすさまじい量になり、設備だけでも何億とかかる。
番組で出てきた大学教授はおそらくドコモからデータ提供を受けて映像化しただけなのだろうけど、データを分析した結果が橋を広げることを提案しようとかね。
役所もそれに乗って本当にやってしまいそうな雰囲気とかね。
結果がこれじゃ、あまりビッグデータがすごいものには見えなかった。
[PR]
FC
2013年 03月 19日 *
ここ2日間、パソコンでファミコン風BGMを鳴らすことが自分の中でブームになりつつある。

やり方は簡単。

1.ネットで公開されているMIDIファイルをダウンロードする。
2.矩形波を出せる音源を使ってMIDIを演奏する。

するとあら不思議、どんな曲もファミコン風になる!

まあそういう遊びが自分の中だけで流行っているというだけの話。
今は試行錯誤の段階だけど、こんな風になる。

サンプル

まだ全然ちゃんとしたものは作れないけど、雰囲気だけでも感じてもらえれば。

それからファミコン音源のことを調べているとModPlug Trackerというツールの存在を知り、これで昔のスーパーファミコンの曲を再生してみた。
え、スーファミの音ってこんなにクリアだったっけ?
特にドラムの音がリアルに聞こえる。
これは意外な発見だ。

例としてFF6のあの曲の一部を録音してみた。

サンプル
[PR]
2013年 03月 13日 *

[PR]
2013年 03月 12日 *

[PR]
2013年 03月 11日 *
そういえば2年前の今日も花粉がきつかった。
ビルから退避するよう言われ、何度か余震が続いている間もずっと屋外にいたせいで、ひどく花粉を浴びてしまった事を憶えている。

電話は翌朝になっても復旧せず、携帯メールが唯一の連絡手段だった。
会社にTVはなく、インターネットの情報が頼りだった。
コンビニの食料がなくなった。(辛ラーメン以外)
その後、数日で伊藤園の飲料は復活したが、サントリーの烏龍茶は復活までに数週間かかった。
カップラーメンは時々入荷したが、一人何個までと制限されていた。
東京の物流は数ヶ月で元通りに戻ったが、東北の暮らしや経済の落ち込みは未だに戻らない。
ネットでは東日本と西日本の書き込みに温度差があった。
今こうして見ても、もし東京で震災が起こっていたら、復興はもっと早く進んでいたのにと思う。
東京に電気を送電するため、東京の人々の暮らしのため、なぜ福島県民が犠牲にならなければならないのだろう。

3.11の前から元々電気を使う方ではなかったが、利用料金が少ないと請求書に不正利用を疑うような警告文が印字されるようになる。
基本料金は支払っていて、電気を使うかどうかは個人の自由であるはずなのに、使わない自分が犯罪者のように扱われ、東電はヤクザな会社だとその頃から思っていた。

NHKスペシャル「3.11 あの日から2年 メルトダウン 原子炉"冷却"の死角」 2013年3月10日(日)午後9時00分~9時58分
を観た。
これを観ると、どうして現場の人間は無能ばっかりなんだ、優秀な社員を現場に配置しろ、という感想を抱くかもしれない。
だが色々な種類の現場を見てきた経験からいうと、正社員だから必ずしも安全とも言い切れないことがわかる。
現場には様々な人間がいて、優秀な人もいればそうでない人も混じっている。
非正社員が現場を仕切っている光景は普通にあるし、逆に正社員に現場を任せていたりすると予想しないトラブルに見舞われるケースもある。
非正社員はいつ切られるか分からない状態で必死になるのに対し、正社員はクビにならない環境につい安心しきってしまうからだ。
だから公務員や大企業が何重もの下請けを使うのはある意味正しいと言える。
要するに現場にいる人間が課題認識を持ち、問題解決能力を有しているかどうかが重要であり、担当者の肩書きや正規雇用かどうかは関係ない。

3.11ではICが稼動しているかどうかの判断を誰も出来ていなかった。
それはICを過去40年間1度も稼動させていなかった為、稼動時の状況を誰も知らなかったからだった。
東電の現場の人間の無能さが被害を悪化させたと思うかもしれないが、これは例えば点滴をうっかり間違えて患者が死ぬような人的ミスの類とは異なり、誰もIC稼動時の状況を知らないのだから、現場にいくら東大卒を揃えたとしても、結果的に被害を食い止めるのは不可能だった。

その後、消防車で原子炉内への注水を試みるも水が漏れて失敗。
これじゃ原子炉へ水が流れないのは当たり前だと言わんばかりに設計図を示しながら説明する法政大教授。
なぜそれを事故の時に言わなかったと思ってしまうが、東電がGEやプラント設計メーカーからの助言を断ったとの情報もあるし、メーカーは製造責任を取りたくないだろうから意図的に助言しなかった可能性もある。
確かに誰も責任を取りたくないわな。
本当の損害を算出しようものなら天文学的な数字になり、一企業が負えるような金額ではなくなるから。
原発の製造や利用に関わることが、そもそもの間違いだった。
毎日の繰り返しの中でミスしない現場の努力も大切だが、数十年に1度起こるか起こらないかというケースに対してはいくら優秀な社員でも等しく無力だった。
そのことを認めなければならない。





「福島原発メルトダウン」(広瀬 隆 著)
■なぜ東京電力はもっと早く電源復旧を考えなかったのか? どうして事故の収束に手間取る羽目になったのか? と思われるかもしれません。その答は簡単です。東京電力は「原発のプロ」ではないからです。私はパソコンで原稿を書いたりグラフを作成したり、割と自在にこの電子機器をつかいこなしています。しかし、故障したパソコンを私は自分では直せません。メーカーに修理を頼むほかありません。東京電力と原発の関係もこれと同じです。テレビに出てきた原子力関係の専門家と称する学者たちも同じで、実際の原子炉ごとに異なる細部の設計については、素人にすぎません。
[PR]
2013年 03月 10日 *

[PR]
ページトップ
The Original by Sun&Moon