第25個冬天

https://twiki.di.uniroma1.it/pub/Reti_elab/MZ/WebHome/Lezione_P2P-2.pdf https://www.kth.se/mwg-internal/de5fs23hu73ds/progress?id=Ve8FdOgvYxAWjFnLtpMJiEXbD4dLcRHhYDoiN98eH0E,&dl https://www.wikiwand.com/zh/articles/Vorbis https://news.post76.hk/2016/04/%E4%B8%B2%E6%B5%81%E9%9F%B3%E6%A8%82%E6%8A%80%E8%A1%93%E7%9F%A5%E5%A4%9Ad/

Spotify – Large Scale, Low Latency, P2P Music-on-Demand Streaming https://www.csc.kth.se/~gkreitz/spotify-p2p10/spotify-p2p10.pdf https://ieeexplore.ieee.org/document/5569963 Peer-to-peer streaming of media content https://patents.google.com/patent/US8316146B2/en former Spotify CTO-Andreas Ehn https://marketrealist.com/tech-comm-services/andreas-ehn-spotify-now/ Gunnar Kreitz https://www.csc.kth.se/~gkreitz/ Ludvig Strigeus https://torrentfreak.com/utorrent-inventor-wins-prestigious-technology-innovation-award-221114/ Spotify 於 2008 年 10 月推出，截至2010(論文發表時間)於當時，已在六個歐洲國家擁有超過 700 萬名使用者。 服務提供兩種版本： 免費版（含廣告） 每月付費的高級版:高級版提供一些額外功能，例如以更高位元率串流音樂，以及同步播放清單以供離線使用。 兩種版本皆可無限制地串流音樂，而大多數使用者使用的是免費版。 Spotify 客戶端的一大特色是其低播放延遲。播放一首曲目的中位延遲時間為 265 毫秒。此服務並非根據網頁，而是使用專屬的客戶端與通訊協定。 市面上有諸多「隨選音樂串流服務」(on-demand music streaming services)，在當時除Spotify之外，幾乎都是網頁型應用。通常使用 Adobe Flash 或網頁瀏覽器外掛程式進行串流。此外，它們都是純粹的Clinet-Server架構，並未採用P2P技術。在隨選串流領域中，點對點技術的應用在視訊隨選服務中更為普遍。 提供隨選串流的服務與檔案分享應用程式有許多共通之處。 例如，Spotify 用於尋找其他用戶的機制與 BitTorrent...

摘自:https://iq.opengenus.org/distributed-dbms/ distributed database (DDB):分佈在電腦網際網路上的多個邏輯上相互關聯的資料庫集合。 distributed database management system(DDBMS):是管理 DDB 的軟體，並提供一種訪問存取機制，使這種分佈對使用者是可見的。 Data Replication: 將一份資料，複製成多份，並把它放到不同的機器上。 為什麽我們會希望資料庫分散到多台機器上呢? 因為我們知道之所以會有分散式架構是因為單台機器的處理能力是有限的 如果我們把這個DB資料分到多台機器上面的話，我們能存在的這個負載就會大很多。 所以主要一個原因是為了可拓展性質，也是分布式系統本身存在的一個主因。 有可能針對不同功能大種類做拆分DB，各自都存放獨立的資料。 Information is distributed between all the individual database management system's nodes 資料庫架構 主要分集中式 跟 分散式管理兩種 Centralized vs Distributed database https://www.youtube.com/watch?v=QjvjeQquon8&ab_channel=ChristopherKalodikis 當然啦 分散式DB會比較頭大的點在於 同步多個資料庫之間的耗時滿可觀的 和多出Data Replication的操作 distributed database architecture 則又可再細分成如下兩種 1.Homogeneous Distributed Database 同構(均質)型 系統中每個結點上的資料庫類型都相同，即它們支持相同的數據模型、訪問方法、優化策略、併發控制算法，以及相同的命令語言和查詢語言等。 2.Heterogeneous Distributed Database 異質型 Ref: https://www.networxsecurity.org/members-area/glossary/d/distributed-database.html https://slideplayer.com/slide/8578733/ ...

  摘自:Designing Data-Intensive Application(設計數據密集型應用) 大部分當代系統都是屬於資料密集型(data-intensive)的 而非計算密集型(compute-intensive) 因此CPU較少遇到這類應用瓶頸 反而更大問題在於資料量龐大,資料複雜性以及資料的變更與成長速度。 以上述這個圖片來講 一般一個客戶的請求過來可能一個api request 他會存取呼叫到我們應用程式的code 一般的我們都會有一個 In-memory cache(內存中的緩存) 然後 我可能會先從緩存里面去讀資料 如果緩存里沒有,就緩存miss的話，我們再從這個主要的database中去拿資料。 主要的database這裡 經常也會有這種 Change data capture (CDC)( 異動資料擷取) 的一些機制(可能有些工具或不同的程式實作)換言之，假如DB發生了改變的話有可能有別的應用程序會監聽到這個改動監聽到這個改動了 以後同時有可能會對緩存進行寫入操作。 往往很多時候我們需要處理一些複雜的檢索(查詢)功能，是會用另外一種DB實現，也就是 全文索引(Full-text index) 的這類型DB。所以對於這種查詢的我們一般會另外放在這種全文搜索的資料庫當中。 另外一種我們經常用到的工具就是這個 消息隊列(Message-Queue) 消息隊列也是在現代的人應用程序中也是非常常見的一些異步的任務我們都會放到消息隊列裡面去，然後有另外的應用程序或許從消息隊列消息然後進行下一步的處理。 如果是單機系統的那個年代或者這類小型架構可能很多問題是比較簡單的  但是在分散式系統中增加了很多的覆雜度 需要考慮數據怎麽去複製分區、事務怎麽在分散式系統當中處理等等。