哈哈。的確我寫的太武斷。我當初腦袋中所想的是，問題"可以適合用parallel"就用parallel，但不能說所有問題都適合平行。直接這樣寫確實不太恰當。
那什麼叫做適合parallel?
- 你跑的job要夠長!! 如果跑的東西都是瞬殺，那就直接用sequential跑就好了。
- 可以Split。可能input本身就可以split那最好，如果你中間的某一段開始一分多，例如collectors.groupingBy，那就可以讓後續的aggregation平行做。
- 問題本身適不適合平行。如果你的filter, mapper會有side effect，那就不能平行。reducer有沒有交換律結合律的特性，沒有也不適合平行。
- 輸出需不需要符合原有順序。如果你只是想要stream.map().foreach()。那是不是還想要某個順序執行。
以上幾點都非常重要，很多時候你的東西在沒有parallel是對的，但是丟到平行就錯了。當然如果以上都符合，那用parallel的好處就是善用你的每個CPU Core。看到CPU榨乾才會有滿滿的效能啊!!
另外不一定說要用Stream的平行，也不一定直接用ForkJoinExecutor。用CompletableFuture + Sequencial Stream也可以輕鬆善用CPU Multicore的好處。
還有cassandra有一個anti-pattern就是read before write1。為什麼要在這邊會有這種anti-pattern呢？
這個好!! 尤其是對Cassandra這種一天到晚在denormalize得更棒。而且對client side不用改，就可以讓未來新增的Materialized View也有資料進來，真是太棒了。
不過不太懂這一段
Materialized views do not have the same write performance characteristics that normal table writes have The materialized view requires an additional read-before-write, as well as data consistency checks on each replica before creating the view updates. These additions overhead, and may change the latency of writes.
感覺實作上不需要read-before-write啊
With these two operations on the menu, calculating the total word count is a two-step pipeline.
some_articles
.map{|a| a.words}
.reduce {|acc, w| acc + w}
如果你以為這樣寫就等同於MapReduce那就錯了。我們講的MapReduce的Map比較像是sql的group by, reduce是aggregation function。reduce就跟collection pipeline的一樣，MapReduce的map在java stream裡面是用Collectors.groupingBy，並且搭配collect去使用。
所以不要再說我用Java8做MapReduce，然後只用map()跟reduce()了。先試著寫一個WordCount才比較清楚什麼叫做MapReduce。
最大的進步是新增了R的支援。看起來最近資料分析大大崛起，不只個資料庫都開始要增加R的Support，而各個生態系也漸漸看到R的身影。 還有Spark也漸漸變成資料分析的第三生態系
- R。原本就是有Total Solution。統計, ML, dataframe, 原生的線性代數, 還有豐富的視覺化功能,IDE也有R Studio
- Python。統計線代有scipy/numpy, ML有Scikit-Learn, dataframe有pandas, 資料視覺化有matplotlib,還有ipython notebook的加持
- Spark。統計ML線性代數就是在MLLib，dataframe從1.3之後把原本的SparkSQL更一般化成DataFrame。現在只差好用的分析IDE。
前兩個適合Agile的分析應用。Spark負責online大數據的分析處理。
如果你是說跟其他家的Iaas比，我就沒意見 XD
我以為是跟Cassandra, ElasticSearch比。
還有Azure的上限我知道，但是那個是到那個點的時候，我想真正scalable的問題不會只有那個 XD。500TB是一個很可怕的量，而且是IOPS的上限比較可能先達到頂。還有那個Account是Storage Account，不是真正一個Account，所以沒有到那麼緊繃。
我同意你說的量夠大，需要人力的部分。這種成本是不會少的，不管用哪一種solution。HDFS也不是沒有自己的成本需要考量，NameNode的ScaleUp也是要處理的。
請問是跟什麼比?
如果是說跟類似AWS Glacier這種專門備份用的，的確是。 如果是跟HDFS，BlobStorage會比較便宜，也不用自己Ops，Scalability我不知道有什麼問題? IOPS或頻寬上限? HDFS的優點是用Hadoop MR會快上許多。
如果Storage分類
- RDBMS: MySQL, PostgreSQL,
- Row-Based NoSQL: MongoDB, ElasticSearch, ..
- BigTable-based NoSQL: Cassandra, HBase
- HDFS
- IaaS Blob Storage: S3, Azure BlobStorage, GCP Storage
以下是我的見解，歡迎打槍 XD
- Cost Effective: RDBMS = Row-based < BigTable-based < HDFS < IaaS
- Scalability: RDBMS < Row-Based < BigTable-based < IaaS = HDFS
- Query/Aggregation Ability: RDBMS > Row-based > BigTable-based > IaaS = HDFS
- Ops Complexity: IaaS < RDBMS < Row-Based < HDFS = BigTable-based
另外Query的能力在特別說明一下 像ElasticSearch這種Full-Text Engine當然在Fulltext query是強項 再來Document based當然在Hierarchy的資料query是強項 傳統RDBMS最強的還是join，還有大家都會的SQL。所以我才會有RDBMS > Row-Based NoSQL 這種結論。
回主題的Cassandra就是犧牲Query換取Scalability。但是比Distributed File System還是rich一些。
還有RDBMS，Row-Based都是把Storage, Query合一。相對的，BigTable-Based, IaaS, HDFS基本上都沒有Query Engine。所以要搭配外部的Query方法。
因為絕大多數的人還是用AWS啊 XD
話說Hadoop 2.7增加了對azure blobstorage1的支援，一整個覺得存BlobStorage很有搞頭
Queue版的Redis，作者也是同一個..
雖然Redis也可以當Queue，但是針對Queue的應用特別優化..
- 支援At-least once跟At-most once semantic
- 支援Cluster，是分類在AP (CAP分類)，每個Node都是同樣Role，所以是Multi-Master的架構
- 支援Async Send
- 支援Queue Message Ordering
- 支援In-Memory跟Append Only File兩種模式
- 簡單易用。基本上用法跟Redis沒什麼兩樣，甚至有些Redis client可以直接操作。
目前還是Alpha階段，要拿來Production用的話請自行負責 XD