読者です 読者をやめる 読者になる 読者になる

セカイモンの裏側

★毎週木曜日更新★ 海外ショッピングサイト『セカイモン』のブログです。私たちスタッフの仕事風景や日々の出来事など、     “セカイモンの舞台裏”とも言える日常を綴っていきます。

Google Feed APIが完全終了したっぽいので代替えを考えてみた

前職の人から次のような内容で連絡が来た。(ちなみにその会社内にITの知識を持つ者はゼロ)

----------------------------------------------------------------------

前職でサイト内のインフォメーション(社内向けとお客様向け)を管理するため、フリーのインフォ管理アプリを使用しそのRSSGoogle Feed APIで取得・表示していたのだが、ある時から取得(2017/1/13に確認)できなくなり今も取れていない。どうにかして。

----------------------------------------------------------------------

 


そこで代わりに使えるものがないか調べてみた。
まずは自分の手は動かしたくない(⇦超重要)ので作業工数を限りなくゼロにしたいのと自社内にシステムに詳しい人がいなくても運用できることを条件に探してみた。

1.phpで受ける
2.jsonで取得
3.YQL APIを使う
4.iframeを使う


1.phpで受ける
php使えないサーバーなのでダメ
社内にphpわかる人がいないと運用できない
工数ゼロじゃない


2.jsonで取得
ドメインなのでダメ
工数ゼロじゃない

 

3.YQL APIを使う
これもサービスが終了した時保守できる人がいないといけないのでダメ
工数ゼロじゃない

 

4.iframeを使う
工数ゼロに近い
サービスが終了することもない

 

結局最後の4を提案した。
jsonで取ることばかりを考えていたのですっかりiframeを使うという考えが抜け落ちていた。
何事も近視眼的になるのはよくないなーと感じた出来事。

どこまで引き返せるか

システム

20年以上前から登山を楽しんでおりますが、楽しみの中にも注意すべきことの一つに、道迷いがあります。

今でこそGPSで自分の位置が分かりやすくなりましたが、それでもなお遭難の呼び水として注意すべきところ。

山に入る前には、現在地と行き先を知るために、地図とコンパスでの確認方法を押さえておきました。

 

さて、先週に引き続き、新しいホームページの作成業務にあたっております。

一度に完成まで進むことはほぼなく、コードを1文1文編集してはプレビューを行ない、エラーの出ない組み立ての模索が続きます。

エラーが検出された際には、何を変えたことでエラーとなったかが分かっていれば、引き返すことができます。

慣れればなれるほど見落としのリスクが増すもので、いかに注意していても、時としてエラー起こりえます。

その際いかに冷静かつ素早く立て直しを行なえるかは、今どの作業を行なっているかを把握できる状態に保っていることが大きく影響します。

何をどこまで着手するのか、今どこまで進んでいるのかを見失うことのないよう、作業に当たっていきたいものです。

アクセスが多いテーブル、クリティカルなテーブルをチェックする時

システム

運用年数が10年以上もあると不要なテーブルから、いっぱいあってどれが一番アクセスが多いのかをロジックから見るのは途方もない時間がかかる。

 

そういう時に便利なSQLがありました。

 

SELECT COUNT (*), object_name
FROM v$sql_plan
WHERE operation = 'TABLE ACCESS'
GROUP BY object_name
ORDER BY COUNT (*) DESC;

でアクセスが多いテーブルがわかる

これで以外なテーブルがアクセスが多い事がわかった。。

 

あと、パフォーマンスチューニングをしていく上でデータ削減をしていく上で消すとクリティカルなテーブルがどれかを調査する必要があります。

 

そこで便利なSQLがこれ、

f:id:sekaimon-staff:20170207104033p:plain

これで各テーブルのプライマリーキーがわかるのである程度どのテーブルがどれだけ大事かがわかる。

 

オラクルのパフォーマンスチューニング データを削減するについて

システム

オラクルのDBのOSのロードアベレージが高くなっているので、サポートに問い合わせてみた。

 

[問合せ内容や障害の詳細]

現在稼働中のWEBサービスでアクセスするテーブル(インデックス設定あり/パーティション設定なし)でデータ量が400万件近くあり、テーブル検索に対するパフォーマンスが低い状態を改善しようと考えています。
データを別DBに退避し、データを20%位残して残りをDELETEでデータ削除した場合、パフォーマンスの向上は見込めるのでしょうか?
ネットでいろいろ調べた結果、データを消しても断片化が改善されないとあまり効果がでないような事も書いてありました。
できればサービスを停止せずに対応したいです。
ご回答よろしくお願い致します。

[回答]
先のご質問ですが、DELETEのみでは断片化や表の肥大化は解消できないため、こちらのみで
パフォーマンスの向上は難しい状況です。
こちらの対応に関しては以下の2点を実行いただくことで断片化や表の肥大化の解消になりますので
対応可能と判断しております。

・表のMOVE
・索引のrebuild

表のMOVEについては以下のように実行することになります。

SQL> alter table <表名> move;

*表領域名を省略した場合、デフォルト表領域に移動します。
もし明示的に指定する場合は以下のようになります。

SQL> alter table <表名> move tablespace <表領域名>;

上記を実行した場合の注意点として索引が使用不可になる点、実行中insert等の処理ができない
状態となりますので、該当表にアクセスが無い時間帯に行っていただくようお願いいたします。

また、索引が使用不可になった場合の対処として先に記載した索引のrebuildが必要となります。
索引のrebuildは以下のように実施いただくことになります。

SQL> alter index <索引名> rebuild;

上記実行中もinsert等の処理ができない状態となりますので、該当表にアクセスが無い時間帯
に行っていただくようお願いいたします。


以上、ご確認の程、どうぞよろしくお願いいたします。

 

[質問2]
回答ありがとうございます。
ご提案頂いた2点の対応で検討します。

ただ、DELETEしてからの作業となるかと思いますが、
所要時間はTOTALでどのくらいかかりますか?

データ件数:400万件→80万件
INDEX数:15

数分で終わるのか、1時間くらいか、またはそれ以上か大体の目安を教えて頂きたいです。


[回答2]
上記ですが、大変恐れ入りますが、実データ量や、Oracleのメモリ等の設定、マシンのIOや
CPU等のスペックなど様々な要素に左右されるものであるため、一概にどの程度の時間が
かかるといったような机上の計算は困難であり、目安等を提示することも難しいものと
なります。

こちらを確認するのであれば同様のスペックの環境に同様の表を作成し、実行し時間を
確認頂く以外に方法は無いものとなります。

ご期待に沿う回答とならず、大変恐縮ではございますが、何卒ご了承頂きます様お願い
いたします。

ちなみに、私の手元の環境では、数万件程の表で、索引が一つしかない状況ですが、
数分で終了しております。
そのため、先の様な点もあるため、一概に申し上げることはできませんが、1時間ほどでは
完了できる可能性があると考えております。

以上、ご確認の程、どうぞよろしくお願いいたします。

 

select segment_name, bytes, ROUND(bytes / 1024 / 1024 / 1024,2) AS GB from user_segments order by bytes desc

これでどのテーブルがどれくらいサイズがあるのかを確認

700万件程度のテーブルをdeleteしても予想通りサイズは変わらずselect文でも1行しかないのに20秒ぐらいかかった。

alter move, index rebuildで予想通りselect文も早くなったのでやはり効果はありかと。

新規ページ組みはじめ

システム

 2月に入り、今後実装となるホームページのコードを組み始めることとなりました。

 会社の看板ともいえるホームページの作成にも、一文一文が意味を持つコードによりシステムが構築されていることを改めて実感します。

 ページを改めて作るとはいえ、元のページから流用できるのものは活用しつつ、1文ずつ新しいものに更新していく作業。

 今では使われなくなった古いコードを目にし、このコードが組まれた当時の背景や作成者を思うに、さながらシステムを理解することは一つの作品を理解することでもあると感じます。

 業務に追われることの多い日々ですが、処理スピードを保ちつつも、多面的な視点を持ち続けられるだけのバッファを維持したまま、これから作業に当たっていきたいものです。

JSPのはまりどころあとマーケ用のリンクもあった。

システム

過去のドキュメントをあさってたら、入社当初にJSPでつまづいてたのを思い出した。

なぜか懐かしい。

PHP上がりでJAVA Tomcat環境で開発することを覚えるエンジニアって果たして何人いるんだろうか??

たいていのスタートアップの現場で使われている言語はいまどき、PHPRubyPythonなどのスクリプト言語が主流なので今からJAVAとかC++とかを学んでいこうという気にはなかなかなれない。

とはいえ、どこかの会社のAir**とかはがっつりJAVATomcatを使ってたりとかダサい構成のようです。大丈夫かなw。

 

JSPではCookieとサーバー側のセッションで一致していないと

 
${cookie.u_last_page_type.value}
 
などで認識しない
 
なのでEclipseを久々に再起動してCookie上には値があるが、Session上では値がない場合
表示されないので はまった
もう一度クッキーに保存しなおせばいい話ということ
 
成果タグのレスポンスヘッダを画像用にしてもらわないと、2重送信される」

というメモ書きがあったCookieとセッションはそうだろうが、成果タグがどうのこうのはおそらく、そのアフィリエイト媒体の仕様によるものかもしれないのでまちまちかと思います。

最後にこんなリンクが。。

海外ECサイト事例に学ぶ、売上アップのノウハウ | カート株式会社

 

 開発していくうえではまった部分とマーケで使えそうな部分を一緒のスレッドに記載していたみたい。

いずれにしても、今は必要ないのでここでメモして自分用にメモしていたスレッドは削除ということにします。

ためしにセカイモンテックはじめます。

システム

今では、たいていの有名スタートアップ系の会社ではやってるのもよく見るし、週報ないし日報の代わりにぐらいのコミット感で始めようかと思います。

 

「継続は力なり」どこまで続くかはわからないですが、まぁやってみましょう。

 

ちなみにどういった会社がテック系のブログをやってるかをまとめてみました。

ってまとめようと思ったけど既にまとめてあったサイトがあったのでそこから参照しました。

creive.me

 

意識しなくても、よく検索にひっかかって見かけるのはこの中でも

LINE、クックパッド、このブログを運用しているはてなとvasilyはよく参考にする事が多かったと思います。

 

はてなとかほかのソーシャルゲームの会社のブログでは負荷を分散するとかのブログが参考になったのを覚えています。

 

フリーの時も何かしら詰まって検索とかして時間をかけて解決しただけだとすごくもったいないと思い。個人で時折ブログにアップしてたけどもやっぱりモチベーションがあがらず継続できなかったので、会社の後押しがあればある程度のモチベーションを保てるのかなって期待してます。