我的PHP&MYSQL
我的網站伺服器確定掛了….
關於PHP7升級這檔事,一個商業網站升級的經驗談
幾個月前,我幫我們公司網站,進行了一次系統性升級,其中包括了CentOS、PHP、tomcat、Java,前前後後花了超過三個月的時間, 當然中間還要持續做網站內容的更新維護,這次僅針對PHP的部分進行說明
因為公司網站有點歷史,所以這次升級是從php5.3升級至7.3,一口氣填補了很多前輩在公司挖得坑,這次我就列舉出一些我所知道的狀況,我的作法是無痛轉移,所以事先把網站內容改進程前後版本都通用後,才用臨時server做切換
1. E_DEPRECATED
是最基本的,他會告訴你使用到的函示庫中那些是即將失效的,看著LOG把所有的code改過一輪吧,這是最簡單,但又是最耗時的,為了解決mysql被廢棄的問題,我整合了網站中所有相關功能成一個class,最後在一次性改成mysqli
2.語法規則更加嚴格了,因為我一次跨多個版本更新,這部分我是在PHP7 的測試機台中,人肉把所有頁面檢查過一遍,確認沒有問題,這部份十分麻煩,因為有時候功能故障,網頁卻能正常顯示,主要的變更有array 跟 字串之間無法自由切換,function 輸入的變數如果不固定一定要給預設值,不再會有預設的false了,這部分算是強制改正工程師們的寫作習慣
3.global regester 根本是個恐怖的坑,因為這個我們卡在PHP5.3 很久了,為了清理這個問題真的是一把鼻涕一把淚,毫無快速搜尋的方法OTZ
4.老的wordpress 版本升級也很恐怖…..不提了….
網站就算經過三組人馬 花了一個多月的時間做最後檢查,網站上線後,還是會發現一些細微的功能出現異常…..
來自幹股票的回測系統吧-2 抓資料失敗
來自幹股票的回測系統吧
玩股票也玩了一年了,學習到許多知識,根據許多大師的教導,要來建立自己的交易規則,為了驗證,我應該開始回測我的理論,然後有啥軟體我也不知道,所以我決定 來自幹了,只要有資料,理論上所有數據都算的出來吧?
今天先把網站環境弄出來,為啥用網站? 因為我靠這個吃飯的阿,雖然我沒拿來當做數學計算,但應該OK的,NGINX+PHP+MYSQL,花了10分鐘 把網站弄出來了,因為部方便給大家用,就不公開了XD
今天第一步 找尋資料來源。
本來我打算使用goodinfo 的歷史資訊,但發現他的資料不好處理,說是xls 資料,其實是經過美化的HTML…..,後來我找到美版yahoo 的股票資訊,好用阿
OK 周末來搞吧
然後使用介面UI 啥的,應該就看心情了….XD
參考資料 https://blog.xuite.net/fly888/go/29185880-%E5%BE%9Egoogle+%26+yahoo%E4%B8%8B%E8%BC%89%E8%82%A1%E7%A5%A8%E6%AD%B7%E5%8F%B2%E8%B3%87%E6%96%99
HTTP轉HTTPS的血與淚,funtime https 轉換記
最近替我們公司網站 從http 轉換成https
這真的事血與淚的故事阿
https 的架設流程很簡單,基本上市已下幾個步驟
1.購買憑證,這部份我們公司是買全網域都可以用的
2.server 設定
我們是使用nginx 首先 把原先的server 設定加上 憑證,憑證包含一個key 跟一個 crt,crt應該就是憑證,key 是我們自己生成的私鑰
有些廠商不是給crt 而是給pem 不過差不多,另外 還有鎖有上游的憑證,這部分就通通放報crt 後面就OK了
另外 各人建議 把 80 port的網業透過301 通通轉址到 443 port的 https
3.網頁修正
這才是最令人頭大的地方
因為我們公司網站有放大量的外部廠商iframe 或是 js,另外因為歷史遺留問題
許多地方式使用絕對路徑,這在轉換的過程中 出現很多問題
因為在https的網頁中,大多數的瀏覽器會預設不讀取 http的 CSS /JS / iframe,這會導至網站一堆地方出問題
雖然有下列者種語法可以快速解決(功能是強制升級)
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 但還是有一些問題 1.IE 系列不之源 2.舊版safari不支援 3.如果廠商的憑證有問題,還是無法解決 說了那麼多 只是想要說 已後寫code多注意阿 最好不要用絕對路徑 http:// 最好改成 //,這樣系統會自動判定
強大的資料庫熱備份軟體 xtrabackup
最近我們公司網站碰到一個嚴重問題
就是原先使用的galera 的同步系統時有一個嚴重缺陷,就是 在 DB 故障再重新同步後,會造成另一台DB 也鎖死,雖然仍可以讀取但沒鳥用啊…..
當然這個問題 可以透過 架設三台來解決,但是 這成本太高…..
之後我們就找到一個很強的備份系統 xtrabackup
他 是直接在DB的檔案層做備份,針對innoDB 備份 可以做到快速熱備份
可以多線同時備份,可以快速壓縮,可以快速還原
經過測試在50G的資料量 備份可以在兩分鐘內完成,還原也只需要五分鐘(mysqldump大概要10~20倍的時間)
他可以全部備份、局部備份、增量備份,不過並不建議增量備份,他還原很麻煩…
不過他還是有缺點的
1.innodb的 ibdata檔案過大時,會備份很久,我在測試時只要兩分鐘,實際上機 要20分鐘….
2.有MYSYIAM 時會有鎖表的備份,所以使用前請小心
3.當備份時碰到鎖表時會備份 拜請小心
4.局部備份跟還原 不是很方便,也不建議使用(有要使用此功能的 請使用2.2版)
官方網站:https://www.percona.com/doc/percona-xtrabackup/2.4/index.html
mariaDB+galera 的ㄧ些優缺點
我們公司網站www.funtime.com.tw 已經使用mariaDB+galera 的DB cluseter 系統已經一段時間了
我們是使用兩台DB 的同步運作模式
這套同步系統的最大好處是她的同步運作效率很高,相同的資料量用檔案匯入要4小時’ 但SST 同不只需2小時
先來介紹一下galera的運作原理
galera 是在收到query時先作分析,如果是單純select 就會直接回應給對方,如果是insert這類會更改DB的指令,就會同不丟給每個cluster上的DB
另外galera有一個快取機制,儲存最新更新的資料,如果當某個DB故障重啟時,她會使用其他DB的ˊ快取來回復,這稱作IST 她速度很快
另外還有一個機制叫做SST,這是當 DB掛點帶久超出快取容許範圍,就會作整個DB的重新同步,這時間就會比IST久很多
SST有一個恐怖缺限,就是在同步時,會把另一台DB鎖死,當然為了同步這樣做合理,但碰到我們公司這樣只有兩台DB的情況下就麻煩了
ㄧ台掛了兩台都不能用………
當然官方建議的方案是 開三台………..
好吧 這套系統的缺陷就在這了,對於需求不上不下的網站來說這有點浪費
MYSQL 轉mariaDB+galera的兩三事
前幾個月我們公司的網站的資料庫系統從MYSQL 5.1.3轉移到mairaDB ,其中最大的目的就是使用galera 同步技術,這當中碰到一些狀況…..
這一篇 主要就是說明一些我所知道的事,至於怎麼安裝的,請自己google吧…..
一開始我要說的是”MYSQL 轉 mariaDB 不保證完全相容….”,沒錯就是不完全相容,架設你的網站用的SQL 有點複雜,強烈建議先去測試一下,個人猜測是這樣的,mariaDB 只保證 從他所說的MYSQL版本移植過去是相容的,其他版本號不保證,另外因為mariaDB有些加速的手法會導致部分語法失靈,個人目前碰到兩種狀況 Continue reading
MYSQL透過 SQL_CALC_FOUND_ROWS取得資料總筆數
參考自:http://blog.farmer.idv.tw/?p=250
http://ma-bank.com/item/998
通常我們碰到資料量大的結果,我們會使用分頁的方式來呈現,那分頁的方式我們會使用到limit的方式,但是這有個缺點,我們不知道解果有多少個,通常我們會下兩次SQL,一次取得資料總量,一次取資料 但這太麻煩了,現在有個快速的好方法
在 SELECT A,B,C FROM….WHERE 語句中 加入 SQL_CALC_FOUND_ROWS
變成
SELECT SQL_CALC_FOUND_ROWS A,B,C FROM …. ..WHERE
他是參數不是資料欄位所以不需要用逗點隔開
之後只需要用
SELECT FOUND_ROWS() 就可以取出剛剛SELECT 結果的資料總量,就算是有使用LIMIT也一樣
提升資料庫 (SQL)效能
引用自 http://blog.xuite.net/j2ee/code/15120677-調校+SQL+以徹底改善應用程式效能
單純引用 給自己看
有些程式員在撰寫前端的應用程式時,會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來,卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員,所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完;想當然爾,即使他前端的 AJAX 用得再漂亮,程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得,讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式,卻無暇研究 SQL 語法的程式員,避免踩到一些 SQL 的效能地雷。
1、資料庫設計與規劃
• Primary Key 欄位的長度儘量小,能用 small integer 就不要用 integer。例如員工資料表,若能用員工編號當主鍵,就不要用身分證字號。
• 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆,用 small integer 即可,不必用 integer。
• 文字資料欄位若長度固定,如:身分證字號,就不要用 varchar 或 nvarchar,應該用 char 或 nchar。
• 文字資料欄位若長度不固定,如:地址,則應該用 varchar 或 nvarchar。除了可節省儲存空間外,存取磁碟時也會較有效率。
• 設計欄位時,若其值可有可無,最好也給一個預設值,並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時,會花費額外的運算動作 [2]。
• 若一個資料表的欄位過多,應垂直切割成兩個以上的資料表,並用同名的 Primary Key 一對多連結起來,如:Northwind 的 Orders、Order Details 資料表。以避免在存取資料時,以叢集索引掃描時會載入過多的資料,或修改資料時造成互相鎖定或鎖定過久。
—————————— Continue reading