android手機app 中央儲存database問題

想寫個類似openrice的android手機app
程式功能要求:
1) administrator要update database,大約每天一次,例如openrice update restaurant list
2)所有user可以update database,所有user即時睇到,例如user可以對restaurant比分,留評語,所有user即時睇到

請問係點將database放web server到?租一個付費shared webhost,個plan有mysql database而且database support external query同modification?有無推介?

想寫個類似openrice的android手機app
程式功能要求:
1) administrator要update database,大約每天一次,例 ...
sailoralan 發表於 2016-10-28 15:47

點解要用MySQL(relational database)?如果係類似openrice,點解仲要整出嚟,市場唔係咁易搶
(請人做啦)

TOP

點解要用MySQL(relational database)?如果係類似openrice,點解仲要整出嚟,市場唔係咁易搶
(請人做啦) ...
ip4368 發表於 2016-10-28 16:14

用mysql database易改易更新
我係寫非商業app

TOP

用mysql database易改易更新
我係寫非商業app
sailoralan 發表於 2016-10-28 16:34

有咩database係難改難更新?
小弟想學下嘢。

TOP

有咩database係難改難更新?
小弟想學下嘢。
ip4368 發表於 2016-10-28 16:41

唔知你會推薦乜野database? 睇你回應好似係.... 唔贊成人地用好Relational Database.. 即係建議人地用NoSQL類database?

我只係想叮囑一句.....
選一個database server... 如果係for production.. 你應該選擇一個... 有一定歷史o既database server... 唔好因為一D所謂新/快/好似好勁.. 而用一D你唔清楚唔熟識, 有鑊唔識救o既database server, 因為咁會好容易令到你冇左份工...  當然如果hobby project就真係用乜都冇所謂..

TOP

唔知你會推薦乜野database? 睇你回應好似係.... 唔贊成人地用好Relational Database.. 即係建議人地用NoSQ ...
7h1r733n 發表於 2016-10-28 17:32


我並無講過MySQL(relational database)唔好,我亦都未講過唔贊成,亦都未建議用NoSQL,我只係問個原因。
IT世界裡面,基本上咩都係講tradeoffs,需要因應唔同嘅情況用唔同嘅嘢,唔分析個case就話要用某一個stack,咁就有機會係未來需要由頭寫過。
我都只係問下個原因,睇下樓主有無分析過,答案好明顯係無。易改易更新,有邊個database係難?

另外,有啲嘢non-relational係唔做亦做唔到嘅,而係relational做得好好嘅,非用relational不可,咁咪用relational,我完全覺得無問題。
但係無可能攬住relational過世。

你嘅意思係Google production用NoSQL係錯誤選擇,Google應該永遠都要用有歷史嘅SQL
(唔好又get錯我嘅意思,我唔係話Google無用SQL,只不過Google依家好多service都係行Hybrid,一個system裡面可以同時用SQL同NoSQL)

TOP

本帖最後由 7h1r733n 於 2016-10-28 20:11 編輯
我並無講過MySQL(relational database)唔好,我亦都未講過唔贊成,亦都未建議用NoSQL,我只係問個原因。
...
ip4368 發表於 2016-10-28 18:48


我自己有production用redis.. 所以我唔覺得用NoSQL=錯誤.. 只係有問題果陣適唔適得解決先係最重要.....
唔好有咩就放"Google"用乜乜乜我就要用乜乜乜.. 人地Google大把人有問題果陣有得fix.. 唔等於你有咁o既resource.....  

利申吓先..... 我用redis係game server... channel server.. 但真正store user data都係用返RDBMS...

TOP

我自己有production用redis.. 所以我唔覺得用NoSQL=錯誤.. 只係有問題果陣適唔適得解決先係最重要.....
...
7h1r733n 發表於 2016-10-28 18:54


Mongo shard + replica係好容易deploy,只要有replica,基本上死到好難救嘅機會幾低(尤其如果上cloud,cloud死disk理論上唔應該影響到用戶)。而且backup Mongo,上mongo官網,已經講幾個back up方法,有咩好處,有咩風險,唔睇就係developer嘅問題啦。(如果講香港個個忙到無工收,邊有時間睇,咁我無嘢好講)

Netflix 大部分用(AWS SimpleDB / Cassandra) + EV Cache(甚至EV Cache穩定程度去到有啲service直頭唔用SimpleDB / Cassandra。但係仍然,Netflix仲有少部分用SQL,例如billing需要非常transaction safe嘅services)。

咁多engineering blog教人點樣deploy得安全,唔識咪去學。
deploy之前諗定一堆死嘅機會,點樣處理。

就算行SQL都應該要諗架啦。好似Dropbox好似完全MySQL(就算唔係完全,都9成),佢地差唔多每個星期三都試唔同嘅嘢,睇下個system會唔會有好大impact(佢地真係會係production server成rack斷晒網絡,甚至shutdown一個data centre一陣)。

幾年前,Dropbox都曾經試過死database,搞到dropbox停咗兩三日,所以先搞咁多SRE/chaos engineering嘅嘢。Dropbox engineer廢咩?Dropbox無engineer?應該唔係,所以唔見得SQL就易救過NoSQL。

如果有行開chaos engineering,根本就唔洗咁驚。chaos engineer係有問題之前已經plan定解決方案。到有問題先諗?遲啦。

TOP

Mongo shard + replica係好容易deploy,只要有replica,基本上死到好難救嘅機會幾低(尤其如果上cloud,cl ...
ip4368 發表於 2016-10-28 20:32

好心提醒你, 你就打遍千字文出黎, 算啦, 有咩事都係閣下嘅事, 關我春事咩, 留返淡氣算

TOP

好心提醒你, 你就打遍千字文出黎, 算啦, 有咩事都係閣下嘅事, 關我春事咩, 留返淡氣算 ...
7h1r733n 發表於 2016-10-28 20:47


原來係提醒,多謝晒。
我個人認為討論係好重要,如果閣下剩係鍾意提醒咁我都唔阻閣下。
(原來討論區唔係用嚟討論)

TOP