一般型資料庫與特殊用途sqldb


#1

在這裡問我自己的感覺到最後還是會回到最一般的資料庫使用

在台灣要去使用特殊型的nosql架構 除了老闆心臟夠大顆 還要考慮到後續如果有維護需求 是否有人可以維護等等

事情是這樣的 最近在玩架設討論用的聊天版

可能後面會弄成一對一

或是直播活動要給全體n人去加入直播嘴砲大亂鬥 等等

大致上 一般型的db

Mysql Sql server Oracle 等 就是標準式 RDBMS Relational Model

但在最近的時間也走進了 NodeJS 與Python的世界

redis 把記憶體當作臨時的一個快取資料庫

Monogodb nosql架構

不管這上面的是用哪一種 其實在初期的使用上不管在任何的專案或實作上 我相信絕對都不會出現問題

差異性絕對只有電腦精算出來的微毫秒的差異 人類絕對感覺不出來

但是當資料的存取達到一定的程度後 一定會根據架構上的不同與資料庫特性產生不一樣的效果出來

而在聊天以及討論的這個範疇中 基本上伺服器 幾乎是處於隨時都在進行紀錄對話與操作log或是讀出歷史對話紀錄(看實際撰寫的應用範疇)

在我的理解上 redis 應該不適合做為一個這類型使用的

redis 會比較適合做為廣告類 例如 固定讀進去1萬筆廣告訊息 然後利用記憶體快取的優勢 一直隨機送出當中的訊息

redis 優點在於 跳脫 DBMS 利用記憶體cash來執行快速讀取 但是如果會經常反覆的寫入與讀取 redis 的優勢便會消失 反而會比較慢

Monogodb 則是nosql架構 但是在大數據的情況下會有怎樣的表現呢??

其實網路上也都有很多介紹的文章 但是比較專精的說明還真的是看不懂 = =

一大堆專有名詞

比較簡單的敘述 我是參考這一篇 https://read01.com/GPnEx.html

但還是無法簡單釐清他們的差異@@

我的基本見解只有在

傳統型RDBMS 基本上速度極限其實就在那邊
redis 則是屬於利用快取快速讀取類型(不建議一直去反覆寫入 某程度反而降低效率)
nosql 好像又可以在更上一層的效率

但是在台灣的市場上真的有需要用到嗎??

台灣的網站除非是應用在前100大的網站平台 在部分的功能應用可以有顯著的差別外 一般的應用開發會有這個需要嗎~~??

當然像JC大 有在做一些大陸在使用的網站 在大陸稱為一般性網站可能都是我們台灣相同的網站流量再放大5~20倍在評估

現在我是想在即時聊天或是一些直播嘴砲大亂鬥當中去找尋一個DB的使用模式

最簡單就是 RDBMS MYSQL OR SQL-SERVER

但是大流量之下 NOSQL的 MonogoDB又是一個好的選擇 也可以自己去摸看看 NOSQL的魔力

不知道版上的前輩有沒有一些看法可以做參考 或是實務上的建議

小菜鳥先謝過了~~~ :grin:


#2

hmm,看來單純你的資料庫看太少了,我之前有發過這主題的影片

還有你可以看一下吃了誠實豆沙包的『地表最快 DB』的對比(下面的圖表)

http://ledisdb.com/

最後你可以再看一下這個數字,你會知道為啥上面的那個不敢拿 RDBMS 進去比

(( memcache 基本上是記憶體映射所以最快,Redis 有過包裝所以慢一點點,SSDB 有硬碟支援所以再慢一點點

因為 RDBMS 太慢了啊 … 對比的還是最佳狀況,你塞百萬筆後, Redis / SSDB 系列速度不要會掉太多,但 RDBMS 會掉到噴的啊 Orz",所以 Redis 的最差狀況還是比 RDBMS 好幾十倍唄,而 Redis 記憶體不夠的話(怕 out of memory)則選 RocksDB / SSDB 基本上是很好的解法哩

然而,你不應該把 RDBMS <=> MongoDB <=> SSDB 做對比,因為資料庫分類也完全不一樣哩(如上面的影片解釋)所以你應該依照資料的性質來做資料庫的選擇就是了,所以目前自己的專案基本起手式就是 memcache + Redis + MySQL,而有速度與大量資料需求會用 SSDB,如果這些你都不適用的話,你就沒得選了,因為只有大量分散式資料庫才能解了(類似把 mongodb / HBase / SSDB 打成多台彼此 sync),且都五台起跳的

速度比較我沒提到 mongodb,因為 mongodb 的問題有點多,我自己不敢採用就是,不過速度是介於 SSDB 和 RDBMS 正中間唄(因為要過 mapreduce … ),然而如果你真的要做聊天性質的話,什麼 DB 都不用,用 Ruby / Python / NodeJS 都會被笑唄(效能太差了,ActionCable 根本是"笑能"),簡單一點換 RabbitMQ,要操到底就換 Elixir / GO 唄( Elixir 內建推播系統,Go 可能要另外寫之類的 ),好東西不用咪?

另外的,如果你一開始就只想寫一個小眾產品,你用一般的 DB 當然沒問題,但是隨即出來的爆量撐不下時,你的產品只會滅亡而已,之前一個產品就是因為初期採用 Redis 當 playground 導致到最後都不用換,順順的跑到產品的生命週期結束,結果別人家用 ASP 寫的,廣告大超大還送黃金送啥鬼,上線一個月就不見了,你要當那一個呢?

anyway 這就是經驗值,一個要不要讓未來輕鬆點的經驗值,so~ 別偷懶了,多台一點反而省事,不會把問題集中在單一 server 上,因為你的問題從來都不是單一類型不是咪?


#3

我其實有找到幾個 websock的相關東西 不過部分nodejs部分是python系列就是了

在GitHub都有一些有趣的案例可以作為參考 不過很多都沒考慮到效能

只是單純的學習案例就是了

其中比較常見的就是

tornado 的 websock

django-websocket (引入wsgi)

然後儲存或是交換資料的工具 幾乎都是 MongoDB 或是 Redis 在做處理居多

<所以我的問題才會以這2個做為提出:sweat:>

然而jc大文章也有講道排程的問題

tornado 架構也可以做到異步處理 雖然不知道效能方面會差多少??

tornado 這東西感覺還是有一些價值 但感覺跟 Elixir /GO比起來就又有些弱掉了 這個感覺還是要自己塞測試資料去測試

有類似的比較 但不清楚會用相關架構主要是做那些功能 所以比較還是要看大數據去測試才會知道差在哪

wsgi 還有nodejs 看了許多大陸的文章也是會有固定單排程問題 如果是單文字的狀態 用單伺服器強制處理或許可以負荷一定程度的流量

但只要加上一些上傳圖片或是互動功能等 或是流量一超過 這樣的架構下直接gg

產品是無法再做延伸的開發或是要用其他的工具去切割開發 怎看都是註定ggg

不過jc大這一篇文章真的是高段阿~~

Elixir 完全不知道這是啥 = =
GO 語言還知道(雖然知道但也沒有實際玩過@@)

資料庫的部份jc這一篇資料庫概論我也有看過

雖然後面還是很抽象到底哪些東西可以用那些db實作還是很抽象

畢竟沒實際下去玩過很多都只是口頭論述 沒有實際會碰到上千萬筆資料 優缺點還是很難去實際體會

現在大概有個方向

原本想要幹下去了 看樣子要重新做功課消化

感謝jc大這一篇 有很多重要的訊息


#4

我建議一個問題不要只有一個解法,類似 Rails 其實很適合 API / Prototyping,Elixir 適合大量的用戶長時連線,或是你說的 Node JS 很適合做 Single Page Application

那我會建議你用 Rails 開 API server,然後用 Node JS + React 去做 APP,然後 Elixir 寫 websocket server 來做即時溝通,其實合併起來取其所長即可,中間溝通就類似 Redis / RDBMS / SSDB 之類的 server,而中介層用 session id 來作轉換,不就所有想要的東西都有了咪?類似我剛剛說的,起手式一定都是 memcache / mysql / redis / ssdb : )

對我而言只玩 Rails 不會 Ruby 就可惜了,而相同的想法可以擴展到其他語言去,取得你想要的成就唄 : )

如果你感覺你的人生無法學會全部的東西,或是沒有時間,這一點關係都沒有,因為都是團隊在做的,但是架構一開始就應該要趨近完美才行,否則後面通常很難收尾就是


#5

好的 謝謝JC大 很多東西可以學習或許我自己沒法全部自學完

但是多懂一些絕對不是壞事

或許將來碰到某些議題 心中自然會有 啊~這個可以用那些語言配合那些工具來達成

這幾天還要來抓些範例來摸索看看

感謝JC大觀念上的問題補充與建議:blush: