Wei-Ming's Blog

Storage and Retrieval (3) - Column-based storage engine

Sun, 19 Dec 2021 23:12:04 GMT

Preface

This is the third article of a series to summarize the key concepts of Chapter 3. Storage and Retrieval in the Designing Data Intensive Application book. The series consists of 3 articles, including log-structure storage engine (SSTables and LSM Tree), page-oriented storage engine (B Tree) and column based storage engine.

Landscape of database storages

In short, database storages are divided into two categories, row-based and column based. In this article we will focus on the core concept of column-based storage engine, and compare the pros and cons between row-based storage engine.

Column-based storage engine

Before introducing column-based storage engine, we need to know 2 terms first:

OLTP v.s. OLAP

	OLTP (OnLine Transactional Processing)	OLAP (OnLine Analytical Processing)
Primarily used by	End user/customer, via web application	Internal analyst, for decision support performance reporting
Main read pattern	Small number of records per query, fetched by key	Aggregate over large number of records
Main write pattern	Random-access, low-latency writes from user input	Bulk import (ETL) or event stream
What data represents	Latest state of data (current point in time)	History of events that happened over time
Dataset size	Gigabytes to terabytes	Terabytes to petabytes

Since the analytical requirements in large companies arise, and this two different scenarios actually have quite different access pattern to database, new database was evolved to enhance its performance. And one of the most important one is column-based storage engine.

Star Schema

While business analysts or data analysts are analyzing business data, it’s very common that there is a fact table (e.g. orders, transactions, events), and several metadata tables that fact tables will reference to them (e.g. product, customer table). The shape of schema and their foreign keys will be like a “star”. So we call it start schema.

The fact table is usually very very large (> trillion data for large company), this makes analytical operation difficult for traditional row-based database.

Column-based storage engine

The core concept of column-based storage engine is quite intuitive. We store data by column instead of by row. Imaging that we have millions of customer data, if we store data by row, then while doing aggregation (e.g. summation, average), it will be very time consuming because we may need to load each rows (Unless we have index).

On the other hand, if we store data by column, then calculating all customers’ average age will only require to load the file for age column. It will tremendously enhance the performance.

The benefits

reduce query latency: when we want to access few columns but large portions of records, we don’t need to load every record from disk into memory and select what we want, this can extremely increase speed
column compression → less disk space and faster execution: some of column have limited outcomes, we can compress it by encoding like bitmap / running length. Then we require less disk space, and have faster execution because data can be fitted in L1 cache & AND/OR operation

The drawbacks

worse write performance: insert one record need to update every column, so it’s better to do this in batch (or use memory for temporally storing data, then writing to DB in batch)

Real world DB

DBs: Clickhouse / Vertica

Comparison matrix of Row-based & Column based storage engine

	Pros & Cons	Real world DB
Row-based	- Better write performance - Easier to handle transactional operation	Cassandra / LevelDB / HBase / Lucence MySQL / PostgreSQL / MongoDB
Column-based	- Largely better aggregation performance of few columns but on large portion of data Worse - write performance, usually we will write data in batch	Clickhoise / Vertica

Summary

If also read the previous 2 articles about storage and retrieval, then congratulation! Now we should be able to have some thoughts in our mind to determine what databases to use for our application.

Let’s recall the landscape of database storage engines. Now, how will you determine the selection of databases in your application ?

Mine is pretty simple, for analytical requirements like internal analysis or performance reporting, we should firstly consider column-based storage engine. Then, for write intensive application, we can consider using log-structured storage engine, and on the other hands we can consider page-oriented storage engine if number of reads are usually larger than writes.

Yes, this is just the first step of how to design data intensive application. But everything comes from the first step. Let’s proceed to the future chapters of this book.

Storage and Retrieval (2) - B Tree

Sat, 18 Dec 2021 23:12:04 GMT

Preface

This is the second article of a series to summarize the key concepts of Chapter 3. Storage and Retrieval in the Designing Data Intensive Application book. The series consists of 3 articles, including log-structure storage engine (SSTables and LSM Tree), page-oriented storage engine (B Tree) and column based storage engine.

Landscape of database storages

In short, database storages are divided into two categories, row-based and column based. We will talk more about the difference of them in next article. In this article, we will talk more about the page-oriented storage under row-based storage.

Page-oriented storage engine

Almost log-structured storage engine have pro-found influence on database evolution, the most widely adopted engine is actually page-oriented storage engine.

Different from log-structure storage engine, page oriented storage engine update the value in place (in its original page), instead of appending data to latest segment file.

B Tree, which were adopted by MySQL, PostgreSQL and MongoDB, are the most adopted data structure.

B Tree

How it works

For read request:
- Binary search for root page
- Go to corresponding child page if necessary or get the value of corresponding key directly
For write request:
- Find corresponding node first
- If found, update the value in that page directly
- If not found, insert a node in the page.
- If the page is full, split page into 2 pages, and equally distribute the nodes
Branching factor: the number of nodes in one page, usually it’s several hundreds.
- Since B Tree is a balanced tree, the depth of tree is O(log n), where n is the number of key-value pairs.
- A four-level tree of 4KB pages with a branching factor of 500 can store up to 256 TB.

Pros & Cons

Better read performance: because we are searching a N-ary search tree, the time complexity is O(log n). Where N is branching factor. On the other hands, the worst case of log-structured storage engine is nearly O(n).
Worse write performance: write request in log-structured storage engine is to intuitively append data, but in B Tree, we need to search key first, open the target page, update value, and then save the page back.
More complex concurrency control & crash recovery.

Comparison matrix of Log-structure & Page-oriented Storage engine

Category	Pros & Cons	Well know data structure	Real world DB
Log-structure	Better write performance	SSTables & LSM Tree	Cassandra LevelDB HBase Lucence
Page-oriented	Better read performance more complex concurrency control & crash recovery	B Tree	MySQL PostgreSQL MongoDB

About write performance

Write Amplification: one write query can produce how many disk writes ?
- For write-intensive application, disk I/O is usually the bottleneck. Usually log-structured storage engine will have less write amplification, so its write performance is usually better.
Log structure engines have higher write latency at high percentiles:
- although log structure storage engines usually have better write performance, however, they are sometimes largely influenced by background compaction process disk I/O. So log structure storage engine usually have higher write latency at higher percentile.
- On the other hands, the write latency of page oriented storage engine is more stable.

Summary

In this article, we walk through the design of page-oriented storage engine, mainly B Tree. We can know that data was updated directly in page file, so in general we can have worse write performance. But Since it’s a balanced tree structure, it can have much better read performance.

So in short, if the scenario requires much more read than write, we can consider use page-oriented storage engine. On the other hands, if we to handle a write intensive application, we can consider using log-structured storage engine.

In next article, we will talk more about column-based storage engine, which has many different design philosophy comparing to row-based storage engine. Let’s go.

Storage and Retrieval (1) - SSTable and LSM Tree

Thu, 16 Dec 2021 23:12:04 GMT

Preface

This is the first article of a series to summarize the key concepts of Chapter 3. Storage and Retrieval in the Designing Data Intensive Application book. The series consists of 3 articles, including log-structure storage engine (SSTables and LSM Tree), page-oriented storage engine (B Tree) and column based storage engine.

Why study database storage and retrieval ?

There are so many different types of database available, like MySQL, MongoDB, Cassandra, Clickhouse and etc. While designing our application, we should be able to select proper tool. Besides, Understanding underline core concepts is crucial for us to tune database performance.

What we are going to learn in this article ?

The underlining core concepts of different data storage structures and retrieval among modern databases.
The pros and cons of each type of it and when we should use it.

Landscape of database storages

In short, database storages are divided into two categories, row-based and column based. We will talk more about the difference of them in future article. In this article, we will talk more about the log-structure storage under row-based storage. And in next article, we will talk more about page-oriented storage engine.

Log-structured storage engine

High level concept

Every time when there is an new write query, we append the data to the end of file.
When file size reach certain threshold (e.g. several MB), we append data to another new file. We call each file as “segment”.
Compact & Merge the files at some points in background process.

Very first version of our own DB

The concept sounds very simple, let’s write a simple version of DB by using shell script.

#!/bin/bash

db_set () {
    echo "$1,$2" >> database
}

db_get () {
    grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}'

$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}

It works! Wow, we already write our first very simple database. So, let’s think about pros and cons of this kind of databases.

Pros: very good write performance.
Cons: while searching data, we need to search from newest segment, one file after another. The performance could be worse if we search old data.
Then, how can we improve the read performance ?

Enhancement: adding index

Now one bottleneck is, we need to search the key one by one in a segment file. The time complexity is O(n). If we ever learned any programming language, we can intuitively think of the hashmap data structure (e.g. dict in python, object in javascript).

If we add a hashmap for each segment, maintain the position of value for each key. Then we can reduce the searching performance around O(log n). This is actually what Bitcask did.

How it works:

For write request:
- Update key value in hashmap, append data to log file.
- When file is large enough, write both hashmap & data as file.
For read request:
- Load hashmap from newest segment, search whether the key is in hashmap.
- If not found, load next segment, and do the same thing.

Discussions

Okay, let’s stop here for a while. What is the pros and cons of this kind of database ? Can we make it even better ?

SSTables & LSM Tree

Yes, here comes SSTables and LSM Tree.

Let’s do almost exactly the same logic we mentioned above (log + index), but with a change: the data in each segment file are sorted by keys

The benefits of sorted data in segment file

Merge several segment files can be very efficient by merge sort algorithm, even for very large file that cannot be loaded into memory.
Since segment data was sorted, we don’t need to store all key value pairs, we can keep sparse index and do binary search.

How it works

For write request:
- Update key value in a balance tree, append data to log file (only for recovery)
- When the tree is large enough, write the data in key order as a segment file
- only need to kept very sparse index for each segment since segment file is sorted
For read request:
- try to search it from memtable first
- if not found, search the newest SSTable
- do binary search via sparse index
- extract entire small block from disk into memory, if not found, search next next SSTable
Background process:
- merge several SSTables(segment file) by merge sort
For index:
- We can have smaller index data stored in disk.
- For example if there are 10,000 key-value pairs in one segment file, we can only sparsely store 100 key-pairs in our index only. Then after doing binary search, we can locate the possible 100 key-value pairs in segment file.
- Because OS load file into memory by fixed size block, there isn’t much difference of I/O performance comparing to only load 1 key-value pair (disk I/O is usually the bottleneck of database performance). And scan 100 key-value in memory can still be very efficient.
- So, to sum up, more sparse index, we can save more disk space, but the searching performance can be worse.

Terms

SSTables (Sorted String Tables) → the data stored in segment was sorted
LSM Trees (Log Structured Merge tree) → balanced tree in memory, sorted log file in disk
Real world databases use the concept of LSM tree & SSTables: Cassandra / LevelDB / HBase
Full-text search engine: Lucence / Solr / ElasticSearch

Discussions

What is the potential bottleneck for this kind of database ?
How can we improve for this design ?

Summary

In this article, we walk through the design of log structure storage engine, and the basic concepts of SSTables & LSM tree. We can know that data was appended to segment file, so in general we can have good write performance. But the read performance, in worst case we have to read every segment file. In order to enhancement read performance, we can add index on segment file, including hash map or balanced tree with sparse index.

We will learn more about page-oriented storage engine, then we can compare the pros and cons of these two categories of databases.

希望我 20 歲就有的投資理財懶人包

Wed, 14 Apr 2021 23:12:04 GMT

這一陣子看了很多投資、理財學習資源（書、網站、影片），也為自己做了理財規劃，才發現自己原來這麼需要學會理財，也才知道原來投資要及早開始，時間才是資產成長的最大力量。

深深覺得這些思維與知識，應該要是人人都能懂、都能取得，因此決定寫這篇文章，把最精華的部分濃縮起來。內容將主要包含三大部分：基礎理財、保險以及長期投資。

我認為這些知識將可以協助大部分的「我們」—— 家裡沒有有錢到不需要工作，經濟負擔也還沒有大到完全無法儲蓄的大多數人，擁有更安全、更有餘裕的人生。

那我們就開始吧！

為什麼投資理財很重要？

我想講兩個小小的故事

通貨膨脹事實上侵蝕著我們的資產，要如何藉由正確的投資方法，並藉助他人的力量，以滿足生而為人的財務需求，其實十分重要

第二個故事是個悲傷的故事

我們生命中其實充滿著不可預期的風險，如何運用財務工具，讓我們以及我們所愛的人，可以有尊嚴地活著，也很重要

具體來說，我們要如何好好為自己投資理財呢？

我認為，大致上可以分為五個步驟，這五個步驟就是我認為最重要的基礎理財觀念。接下來我們會一步一步介紹，其中將會在保險＆長期投資這兩塊有最多的篇幅

Step 1. 釐清財務狀況

理財的第一步，其實是了解自己
了解自己具體來說，有什麼財務需求？
現在的每個月花費是多少？未來想過什麼樣的生活？想投入什麼行業？
接下是否有預計養育小孩、買房、買車，以及父母是否需要扶養？
這些問題其實相當重要，不瞭解自己的財務需求，就沒有辦法準備緊急備用金，也無法知道保險要保多少，更無法分配預算，將部分資產做長期投資
有些問題不容易一次就回答，但我們可以可以每一年，或每一季，給自己一個週末，排開所有事情，把時間留給自己，好好釐清自己的財務狀況與需求。我習慣放在跨年後的第一個週末，因為那時候最常去規劃未來的事情
先從養成記帳習慣開始：如果你喜歡紙本，那就用紙本。如果你喜歡用手機 App，這裡有很多可以供選擇。記帳不是一件容易維持的事情，可以找伴侶一起記帳，或是養成睡前記帳的習慣

Step 2. 償還債務

債務會讓我們的資產不斷減少，尤其是信用卡循環利率動輒 5~15 %
所以，信用卡費，請盡一切努力先還完。如果無法控制自己刷卡，不要辦信用卡
如果是向親友借錢，就是欠人情，還是早點還。我們沒有那麼多親友可以借錢的

Step 3. 準備緊急預備金

如果你已經瞭解自己每個月生活的花費，而且償還債務了，接著，請為自己準備一筆緊急預備金！
顧名思義，這筆錢，是緊急的時候可以用的，例如：小意外/小疾病而暫時無法工作、突然被資遣，或是現在的工作真的不適合自己，想要裸辭換工作
除此之外，這筆錢，也可以避免自己在突然需要用錢的情況下，不幸遇到股票大跌，只能賤賣股票
大概準備多少夠呢？我認為 [至少 6 個月 x 每個月支出]，不過還是根據自己的需求與個性調整
這筆錢可以存哪裡？
- 最推薦的是高利活存帳戶，利率可以到 1%，存普通的銀行帳戶，利率通常只有 0.1% 以下。近幾年比較紅的就是永豐大戶跟台新 Richart 帳戶，不過台新今年已經調高門檻了。相信每一年都會不太一樣，請自行每年查詢。如果沒有利率高的活存帳戶，可以考慮定存
- 然後，我非常不建議買儲蓄險/投資型保單，緊急備用金就是你並不知道什麼可能會用到，一需要就是很急，這兩項商品雖然低風險，但提前解約都會有很大的損失

Step 4. 為自己以及家人保險

如果你已經償還債務，這一步可以跟第三步同時做，逐步把緊急備用金存夠，也逐步為自己和家人保保險

在為自己以及家人買保險的過程，其實也是在釐清自己與家人財務狀況。可能需要花費一些心力，但其實是一個很值得的過程

為什麼要買保險？一定要有保險嗎？

如果你家真的很有錢，即使發生什麼意外、重大的疾病，都有辦法負擔，要不然，你就應該要買保險
我們永遠無法預期明天會發生什麼事，而通常發生意外、重大的疾病的時候，都會有筆巨大的開銷，或失去收入，很可能就會掉入負債的循環
一旦進到負債的循環，通常難以脫身

保險的本質是什麼？

保險是大家各掏一點錢出來，組成一個基金，即使一部分的人意外或疾病，突然有有鉅額開銷，也能夠從這筆基金應付這樣的緊急狀況
就是人們互助一起分擔風險的一種方法。別忘了，一個人雖然走得快，但一群人可以走得遠。人類從來不是獨居動物，我們其實相當需要有其他人和我們一起分擔風險

所以我們到底應該保哪些？額度要多少？

我相信絕大多數人，並不知道自己到底應該要保哪些保險、保多少額度，我們多數對於保險的知識，來自保險業務員
但請一定要理解保險業務運作的商業模式：保險業務員主要的報酬來自於你投保之後的抽成，可以抽越多的保單，業務員一定會想辦法推薦，但那不一定是你需要的
要釐清自己需要什麼保險，我們要先想一個問題，我們這輩子可能會面臨什麼樣的財務風險？
哪一些是最嚴重的？哪一些是相對還好的？現在身上有哪些責任要扛、家庭的開銷有多大？
我們來嘗試著把人生會遇到的幾個財務風險列出來，並且根據影響程度、發生的機率來分析：

接著大致上把風險分成三塊，綠色、黃色、紅色
綠色的部分雖然機率很高，但影響程度很小。如果有緊急預備金，是可以安然度過的
黃色的部分，是我們這輩子難免會遇到，財務負擔也不小的風險，可能突然需要幾十萬的現金做手術、或有幾個月無法工作，我們應該重視它
最後是紅色的部分，我們都不希望遇到，但一遇到就會讓整個家庭陷入巨大的財務困境，如果你是家裡的經濟支柱，這一塊是絕對不能忽略的，請務必務必為自己買保險

每一種風險相對應的保險

接著，我們把每一種風險相對應的保險列出來，然後逐一介紹

壽險

理賠條件：死掉就給錢
保險額度計算：[每一個你需要扶養的對象，到不需要扶養的狀況，總共需要多少錢]
如果有伴侶、兄弟姊妹可以共同分擔，請和他們一起討論
舉個實例：小貍的爸爸 65 歲，過去沒有儲蓄習慣，現在已經無法工作，平常生活費一個月 2.5 萬，只能靠兩個兒子支付，小貍和弟弟要一起分擔爸爸的經濟需求。以國人平均餘命 85 歲來估算，(85 - 65) = 20 年 x 12 個月 x 每個 2.5 萬 = 600萬，小貍和他弟弟共同分擔，兩個人都要投保 300 萬的壽險
在有小孩後，請一定要重新計算額度，相信我，會差很多
其他情況下，可以每三年重新算一次

失能險

理賠條件：根據殘廢等級表分 1 ~ 11 級，不同級會給不同比例的理賠
值得注意的是，殘廢等級表主要涵蓋身體的缺失，年老而無法自理生活的情況，很可能不會被包含進去
理賠方式：有分一次性給付，以及每年/每月給付兩種
保險額度計算：[每一個你需要扶養的對象，每個月需要多少錢]＋[家人要扶養你，每個月要多少錢]
舉個實例：假設小貍是家庭經濟支柱，只有他在賺錢，每個月生活費 6 萬，加上房貸 2 萬。如果小貍全身癱瘓要請看護，一個月要 3 萬。那麼小貍要保的額度，就要到每月 6 + 2 + 3 = 11 萬
失能 / 長照險真的很重要，主要的經濟支柱無法工作其實比死掉還慘。我們簡單算一下，如果沒有保險理賠，十年的資金缺口有多大： 10 年 x 12 個月 x 11 萬 = 1320 萬，這只是 10 年喔，小孩還不見得長大，房貸也可能還沒還清
一樣請和兄弟姊妹、伴侶一起討論，有小孩後，一定要重新計算額度

長照險

理賠條件：符合巴氏量表六項中的三項，或是認知功能(時間、場所、人) 3 項有 2 項缺失者。每年要重新評估
值得注意的是，長照險衡量的標準，主要是自主生活的能力，身體部位的缺失，並不一定可以理賠到
其他額度計算等項目同失能險
請注意，其實還有類長照險，而且每一間保險公司的條款可能都不一樣，務必要仔細看過條款

長照險 v.s. 失能險

長照險與失能險並不是能互相取代的兩種保險，有交集，但也有個別無法涵蓋的部分

險種	優點	缺點
失能險	理賠條件明確、不用每年重新評估	年紀大而無法自理，並不一有殘疾，賠不到
長照險	涵蓋年老失能的狀況	理賠容易有爭議、每年要重新評估

不過，困難的點其實在這裡，長照/失能險的保險費通常不便宜，資源有限的情況下很難兩個都保
我個人是會推薦年輕/壯年一點的時候買定期的失能險，因為理賠條件明確，也是年輕/壯年時期比較容易遇到的狀況
年紀稍為大一點之後，補上長照險

重大傷病險

其實分成三種：重大疾病/特定傷病/重大傷病，涵蓋範圍分別是重大疾病 < 特定傷病 < 重大傷病，範圍越廣，保費越貴

險種	涵蓋範圍
重大疾病險	針對七項疾病，包含心肌梗塞、冠狀動脈繞道手術、腦中風、末期腎病變、癌症、癱瘓及重大器官移植
特定傷病險	針對二十二項特定傷病(可能上述七項重疾)，像是阿爾茲海默氏症、帕金森氏症等
重大傷病險	依據健保重大傷病卡資格，裡面有數百項

理賠方式：通常是一次性大筆理賠
注意：每一張保單的項目可能有所不同，請看清楚條款
保險額度計算：建議 100 萬以上

癌症險

理賠條件：罹患不同程度的癌症有不同比例的理賠
理賠方式：通常是一次大筆理賠，但也有針對手術、門診理賠
保險額度計算：建議重度癌症的一次性理賠達 100 萬
癌症險跟重大傷病險，其實有滿大的重疊，所以我會建議，家族有癌症病史的人，資源允許的話再保

醫療險

分成住院日額、手術理賠、實支實付三種理賠方式
- 住院日額：住院一天給一筆錢
- 手術理賠：某一項手術給某一筆錢
- 實支實付：只要是有動手術，在額度內支付，通常可以包含雜費＆自費項目
我個人會推薦實支實付，因為現在多數手術不用住院，醫院也不想要讓你住院住太久。此外，現代手術有很多自費的醫療器材項目，過去的住院日額、手術理賠都無法涵蓋
保險額度計算：建議實支實付至少 20 萬
如果有兩張保單，其中一張要可以副本理賠

保險的順序

我最前面有說到，如果可以運用的資金有限，保險可以逐步到位
順序的話，我個人會認為是：失能/長照險 → 壽險 → 重大疾病/特定傷病 → 實支實付醫療險 → 癌症險 → 意外險

定期 / 平準 / 終身險的差別

在保保險的時候，一定會聽到業務員介紹終身險，但其實我們還有定期險以及平準型的保險

保險形式	繳費方式＆保障範圍
定期險	每一年繳費，保障的是接下來這一年，隔年沒繳，就沒有保障。每一年費用不同
平準型	將接下來 N 年（例如：10 年）的保費平均算，這 10 年內每年繳一樣的費用。10 年過完的下一個 10 年的費用就會不同
終身險	這 N 年繳（例如：20 年）這輩子的保費，每年保費一樣，20 年繳完終身都有保障

乍聽之下終身險比較有保障？真的嗎？
- 羊毛出在羊身上，你想要一輩子的保障，錢當然要自己出
- 把這輩子的保障，集中在 20 年繳完，當然保費不會太便宜，或保的額度要很低
- 考慮通膨的情況下，40 年後你大約 60~70 歲，真正比較頻繁申請保險理賠的時候，物價大約已經成長 2 倍，可以想一下，真的要用到的時候，額度夠嗎？
- 我們在人生的每個階段，需要的保障額度其實不一樣：出社會無小孩 / 有小孩 / 小孩長大獨立，每個階段的經濟負擔並不同
- 沒錯，年紀太大就沒有辦法再保險了，這是所有業務員推薦你買終身險的原因。但如果你可以有紀律地長期投資，照理說到那個年紀，你應該要能夠負擔這些費用了
小小結論是：
- 如果你真不是個有紀律的長期投資者，請考慮終身險
- 但如果有辦法，請有紀律地做長期投資，並買定期/平準型的保險就好

買保險的眉角

查詢保險公司訴訟率，最高的幾個不要保，你不會想要人生已經低潮還要跟保險公司訴訟
找已經做保險很久的業務員，並且從親友問過去是否積極協助理賠。你不會想要你受傷/生病的時候，你的業務員還愛理不理，自己準備那些文件真的很麻煩
Finfo 保險資訊站這個網站真的真的非常好用，它幫你把台灣所有保險公司的保單都整理好了，並且可以讓自己配保險組合，計算額度是否足夠。規劃保險的時候必用！

Step 5. 長期投資

我們終於來到第五步驟了！在存夠緊急備用金，也為自己和家人保好保險後，我們可以把多的資產，扣掉教育基金等等的必要費用，拿來做長期投資
介紹長期投資的方法之前，一定要先讓你理解複利的力量

複利的力量 - 七二法則

這是一個簡單估算你的資產多久可以翻倍的方法
假設你做投資，每年報酬率 6 % ，那麼 72/6 = 12，你的資產 12 年後可以翻倍
每年報酬率 18 % → 72/18 = 4 年資產可以翻倍
猜猜看巴菲特平均年化報酬率是多少？
你期待每年可以有幾 % 的投資報酬率呢？你覺得你的能力跟巴菲特比起來是如何呢？
多數投資人都對自己有過度的信心，設定過高的報酬率目標，最後就是承受過高的風險，而蒙受損失
事實上，可以到每年 6~8 % 就已經相當不錯。這也是簡單的長期投資工具，長期來說可以為我們做到的
在進到我最推薦的長期投資方式之前，先讓我們對投資標的有初步的理解

投資標的選擇

如果想知道更詳細的資產類別，以及其報酬率，可以看市場先生的這篇文章

最適合我們的投資方式

定期定額買費用率低的全市場或大型股指數型股票 ETF ＋全市場債券 ETF，並且長期持有

一下子看到一堆專有名詞可能覺得有點可怕，我們來說文解字一下，我們先從「全市場指數型股票 ETF」的最右邊開始

ETF = Exchanged Trade Fund 交易所交易基金
- 指的是，可以在交易所交易的基金。一般的基金，一天只能買/賣一次，每天只會有一個結算的資產價值，但如果是 ETF 這種基金，隨時都可以在交易時間內下單進行買賣
- 什麼又是「基金」呢？一群人集合一筆錢，一起做投資，買下多種標的，共同分享報酬，就是基金
- ETF 就只是一種交易比較方便的基金，它可以是根據某個指標投資，也可以是人為管理，它可以投資極高風險的資產，也可以是投資股票。不要以為買 ETF 就是低風險
標的總類：
- 可以有股票、債券、房地產，甚至最近也有虛擬貨幣的基金了
基金管理方式：
- 指數型：意思是會有一個公式/指標，直接決定該基金要買進哪些公司、多少比例的股票。例如：元大 0050，追蹤的是台灣 50 指數，該基金會去買台灣市值前 50 大的公司的股票
- 主動型：如果不是追蹤指數，我們可以簡單歸類為「人為主動管理型」，就是有個或一群基金管理人在操盤。銀行理專推的主要屬於這類型
投資標的範圍：
- 全市場：指的是盡可能買下整個市場上所有標的。例如：全世界所有公司、全美國所有公司。實務上當然不可能做到，所以會進行抽樣
- 大型股指的通常是該市場內，公司市值最高的前 N 間公司
- 除此之外，還有科技類股、醫療股、5G/IOT、新興市場等等各種市場範圍的基金

為什麼要買「指數型」 ETF?

指數型 ETF 費用很低，讓我們的資產不會被基金公司吃掉
人為管理型的 ETF，費用率動輒 1~2% 甚至更多，但 0050 是 0.355%，美股的 ETF 通常更低，例如投資全美國市場的 VTI ，費用率只有 0.03%
1~2% 跟 0.03% 差很多嗎？
- 假設你買了兩種基金，年化報酬率都是 6%，A 基金每年會被扣掉 1% 費用，B 基金每年會被扣掉 0.03% 費用，假設投入 100 萬，30 年後
- 投入 A 基金的資產：100 萬 x (1.05)^30 = 432 萬
- 投入 B 基金的資產：100 萬 x (1.0597)^30 = 569 萬
指數型 ETF 的指標明確，相對可驗證歷史成效。人為管理的基金，你根本不知道是哪些人在管、他們在想什麼

為什麼要買下全市場或大型股的指數型 ETF？而不是買幾間績優公司的股票？或是人為管理的主動型基金？

2008 年的時候，有一個人叫巴菲特，嘿對，就是眾所皆知的股神，他向投資界下戰帖，他決定買一個追蹤標普 500 的指數型基金，然後放著 10 年不管它，尋找有意挑戰的基金公司，可以組出比它好的投資組合
有一間叫 Protégé Partners 的基金公司接受挑戰，他們總共動用了 200 位基金管理人，組了 5 個基金組合，每個都是由多個基金組成
2018 年，結果出爐，巴菲特放著 10 年不管的追蹤標普 500 的指數型基金，整體報酬率完勝這五個基金組合

source:Berkshire's open letter in 2016

這故事告訴我們，即使動用大量的專業基金管理人，絕大多數人為管理的基金，仍然難以贏過追蹤標普 500 指數(我們俗稱大盤指數)的指數型基金
根據標普道瓊指數公司（S&P Dow Jones Indices）在 2019 年的研究，他們發現，過去 10 年，有 85% 的主動型基金，表現不如標普 500 指數。如果時間拉長到 15 年，落後標普 500 指數的主動型基金將近 92%
台灣有近千檔基金，美國有 8000 多檔，你覺得你找得到那 8% 可以勝過大盤的基金嗎？
台灣有 1 千多家上市櫃公司，美國有 4~5 千家上市公司，全世界有超過 63 萬家公司，你打算怎麼找、怎麼買，讓自己的年化報酬率超過標普 500 指數？
成千上萬的基金管理人全職投入，都難以做到。我們為什麼要浪費這麼多力氣研究、看盤，而不去買追蹤大盤指數的指數型 ETF，然後把時間省下來精進自己的專業，或為社會創造更多價值呢？

全市場或大型股的指數型股票 ETF 長期會獲利的基礎假設

當我們買下全市場型，或大型股的指數型 ETF，可以想成投資整個市場的所有公司，或最大的那些公司
照理說，如果整個國家的經濟有在成長，投資將近所有公司的話，應該可以獲得經濟成長的果實
而如果整個國家所有公司、或最大的公司們，全部都沒有賺錢的話，那意味著國家的經濟衰退中。這種時候我們要擔心的可能不是股票跌，而是可能會失業
如果我們回顧歷史，僅有在經濟大衰退來臨時，會有這種情況，短則幾個月，最長 5 年

還有一個理由你不該買人為管理的基金

就是利益衝突
我們只要想清楚一件事就好，這些基金公司，是如何賺錢的？
基金公司的主要收入，其實是收「管理費」，我們把錢給他們管理的時候，他們就可以收一筆固定的費用。因此他們會希望我們把越多錢給他們管理，就可以賺越多。他們確實有誘因創造更高的報酬率。然而，他們也有誘因，希望我們不要把錢領出來。而什麼情況我們會想贖回？通常是基金一直賠錢，或是覺得賺得夠多的時候
意思就是說，基金管理人，不會想要基金的報酬率太高，不然我們覺得賺飽就會贖回賣出，他們就收不到管理費了
這就是利益衝突，整個基金公司的商業模式，讓公司的利益，與投資人的利益相衝突

為什麼還要再買全市場指數型債券 ETF ？

相比於現金、債券，股票是一個相對風險較高的資產，而債券這項資產的走勢，經常與股票無相關，或甚至些微負相關 (相關係數 0.3 ~ -0.3 之間)
配置一定比例的債券，可以讓我們在股災來臨時，減少跌幅
減少跌幅，不僅僅是讓資產不要減少這麼多，更重要的是避免過度恐慌，全數在低價時賣出
最後是個有趣的數學現象，第一年賠 20% 的時候，第二年其實不是賺 20% 就會賺回來。你覺得第二年要賺多少 % 才賺回來？
藉由不同屬性的資產配置，讓資產價值的波動幅度減少，以避免恐慌心理，並提高報酬率，就是「資產配置」的目的

資產配置的原則

每一種資產項目的占比不要大到影響力太大 (>25%)，也不要小到沒有影響力 (<5%)
每一種資產項目，盡可能涵蓋整個市場，費用率越低越好
每一種資產項目之間，盡可能是零相關、低度負相關或低度正相關 (相關係數 0.3 ~ -0.3 之間)
以股票為主，作為長期獲利的主力
可以根據個人偏好做比例、標的選上的調整，要是你自己會相信的標的，不然一直換，不會有效益
最基本且簡單的組合：股票 80% + 債券 20%，如果想要更低風險，就調高債券比例，如果想要追求更高報酬，就調高股票比例

為什麼要「定期定額」？

節省時間與精力：不用想什麼時候買進，省下研究、決策時間、價格到底是高還是底
人其實意志不堅：人其實很容易被新聞、市場波動影響，而不斷改變自己的想法，最後的結果通常就是賠，或賺得不多
分散風險：如果每隔一段期間就買，有時候雖然會買在高點，但也有機會買在低點
符合一班上班族的資金流動，每個月領薪水，就可以撥一筆去投資，某種程度強迫自己儲蓄
每年買一次、每季買一次、每月買一次，有差嗎？如果是長期持有，其實差異不大 → 數據實證 by 市場先生

為什麼要長期持有？

如果你是買股票，公司賺錢是需要時間的！
如果你是買債券，領債券的利息，也需要時間！
想要短期內獲得高報酬，只有兩種可能，一是找到發放高額股利的公司，二是找到股價飆漲的公司，而且你還要買在低點
同上面有提到的問題，台灣有 1 千多家上市櫃公司，美國有 4~5 千家上市公司，全世界有超過 63 萬家公司，你打算怎麼找？
而且，股價飆漲，就意味著價格波動較大，風險相對就比較高

長期投資的心法 (總結)

雞蛋不要放在同一個籃子，盡可能買下整個市場的標的，而不是單獨一個
遵守投資紀律，定期定額投入，並且長期持有，不要浪費時間分析標的、進出場時間、價格到底偏高還偏低
選擇費用率低的指數型基金
設定合理的投資報酬率目標，並做資產配置
記得股息再投入，並且每年再平衡一次

標的選擇 - 台灣市場

指數型股票 ETF

大型股 - 0050, 006208

很抱歉台灣沒有全市場型股票 ETF，台灣的債券 ETF 我之前有買過富邦美債 7-10 年，但發現費用率真的偏高，現在還沒有仔細研究是否有費用率相對低的債券 ETF

標的選擇 - 美國市場

指數型股票 ETF

美國全市場 - VTI, IWV, ITOT
美國大型股 - SPY, VOO, IVV
全世界市場股票 - VT
美國以外市場股票 - VXUS

指數型債券 ETF

全世界債券 - BND
美國國債 - SHY, IEI, IEF, TLT, GOVT

資產配置型 ETF

AOA, AOR, AOM, AOK

不想研究的話，推薦 VT + BND，直接買下全世界公司的股票＋債券

美股 v.s. 台股 v.s. 複委託

	優點	缺點
台股	開戶容易、遺產好處理、不需要電匯費用	基金管理費用高、交易手續費高、市場容易被少數法人影響
美國券商開戶買美股	很方便買下全世界股票＆債券、多數零交易手續費、市場規模大不易被少數法人影響、基金管理費用低	電匯一次 600~1200 台幣、遺產處理不易、一股的價格可能就很高，不易做資產配置
台股複委託買美股	遺產好處理	每次下單都要手續費且很貴

具體來說要如何開始長期投資呢？

台灣股票：到任一證券商開一個證券戶即可
- 注意不要違約交割，不過定期定額的話不會有違約交割的問題
- 一張買不起，可以買零股
- 個人推富邦＆國泰證券，都有定期定額手續費 1 元優惠
美國股票：
- 複委託：去台灣的證券商申請複委託，之後用 App 就可以下單
- 美國券商直接開戶：eToro、德美利證券、第一證券、盈透證券
券商挑選依據：是否有想買的標的，交易手續費、出金、入金的難易度及費用、是否受監管、介面操作、遺產處理

如何檢視自己的投資成效

每年算一次投資報酬率
範例：google sheet

馬上行動

開始記帳
去券商開戶

其他理財經典問題

要買車嗎？
買房子好還是租房子好？
要買儲蓄險/投資型保單嗎？

學習資源

從有趣、好吸收，到比較進階排序如下：

實用工具

Basic Tutorial of Kubernetes

Tue, 30 Mar 2021 19:12:04 GMT

What is Kubernetes (k8s) ?

Photographer: Rafael Cosquiere (https://www.pexels.com/zh-tw/photo/2064123/)

Kubernetes is just like the control panel (flight instrucment) of an aircraft.
For aviators, they have lots of component to control and manage, so there is a control panel for them.
For developers, when we have lots of computer to manage, so there is Kubernetes for us!

In short, Kubernetes is a tool for developers to manage a cluster of computers.

If you see the shape of Kubernetes logo, it's a rudder!

Think of you have lots of service to manage…

Non-offical Twitter System Architecture

You have Kafka, Cassandra, MySQL, Redis, Elasticsearch and many services. For each service, you need:
- Deploy newer version to certain machines, rollback if deployment failed
- Restart the service once it failed
- Scale up when heavy loading
- …

Why should we use Kubernetes ?

self-healing: auto restart services once if failed
automated rollouts and rollbacks
built-in load balancing
easier service discovery
secret and configuration management
it abstracts away the hardware infrastructure and exposes your whole cluster as a single enormous computational resource
better resource allocation: you can specify the CPU & memory for each service, k8s will automatically allocate them for you.
storage orchestration: you don’t need to think where to store your data*

Who invents Kubernetes ?

15 years of experience of building production workloads at Google: Borg, Omega

Before we dive into details

Let’s have a very simple practice today.

Core concepts of Kubernetes

Fundaments

Container: a technique to package our application, and run it in an isolated environment. You can think of that we packed our our application, and run it in a virtualized computer.

Practice time!

Architecture

Node: a real computer or a virtualized machine (e.g. ec2, gce) who has computing resource (CPU, memory)
Cluster: a bunch of real computers or VMs managed by Kubernetes
Pod: basic working unit of kubernetes
Container: a container instance by containerized technology, e.g. docker

A cluster can contain many nodes, a node can contain many pods, and a pod can contain many containers

Important resource types

Pod
Service (NodePort, LoadBalancer) & Ingress
ReplicaSet
Deployment
Persistent Volume

Pod

Purpose: the basic working unit for scaling/deployment
each container in a pod share same host and port space
each pod inside cluster has its own unique IP address

every pod has a unique IP iddress inside cluster (Cluster IP)

we can specify multiple containers you would like to use in a single pod

When we use multiple containers in a pod ?

Sidecar pattern: log collecting
Ambassador/Adapter pattern: proxy / adaptor

When we should NOT use multiple containers in a pod ?

when we want to scale up different applications inside a pod in different scale, we should separate it as different pods

Service

Purpose: make cluster’s internal and external networking more convenient and feasible
Use cases:
- Pod-to-Pod communication
- Pod to connect external service
- External client to connect internal pod

Pod-to-Pod communication

Pod can fail / be deleted / be created at any time, we are not possible to setup our application by IP address mannually
By using service, we can refer to one or more pods by a selector
When a service can to muliple pods, the service can load balancing the requests

Pod to connect external service

External client to connect internal pod

NodePort

LoadBalancer

Ingress

ReplicaSet

Purpose: to maintain a stable number of replica Pods running
Use case:
- High Availability (HA): to ensure service always being available
- Load Balance
- For example: Login service, API service, …

ReplicaSet

Demo time !

Deployment

Purpose: to deploy our application more gracefully
Use case: almost every application
Before introducting Deployment, let’s see what kind of strategies we can use for deploying new version of application:

Delete all old pods, and then create all new pods

Create all new pods, and then delete all old pods

Delete one, and create one, and so on

Create several and delete several, and so on (rolling update)

And actually, Deployment works by ReplicaSet:

Demo time !

Persistent Volume

Pods can be deleted/removed at any time, and all the files inside pod will disappear by default. However, for some of service, persistent storage is crucial. (e.g. DB service)

We need a persistent storage even pod was deleted and re-created

Inside kubernetes, the concept was splitted into PersistentVolume and PersistentVolumeClaim

The work flow of using persistent storage in kubernetes

Demo time !

Important resource types recap

Pod: basic working unit
Service (NodePort, LoadBalancer) & Ingress: for networking
ReplicaSet: to keep stable number of replica pods
Deployment: to deploy application more gracefully
Persistent Volume: to save data persistently

Tips for inspecting issues in Kubernetes cluster while on duty

Common tasks for onduty person:
- ensure applications running correctly
- scale up/down service if needed

How to monitor whether application is running properly ?

Pod: status, age
Monitoring service like Grafana & Prometheus
- worker: understand the source of jobs, usually a queue.
  - how many tasks are there in a queue ?
  - what is the producing / consuming velocity ?
  - what is the oldest task in the queue ?
- server: request per second / latency (response time)
- cronjob: log

Reference

Kubernetes in Action

JS Memory Leak 簡單也不簡單

Sun, 24 Jan 2021 19:12:04 GMT

故事

跑 AIQUA UI unit testing 的時候，發生記憶體不足的問題

FAIL src/.../HtmlCreative.test.js
  ● Test suite failed to run 

  ENOMEM: not enough memory

CI 環境上有 6GB 的記憶體，真的不夠嗎？

實驗與觀察

我們在用的是 Jest 這款 task runner
它有提供兩個指令 --runInBand & --logHeapUsage
--runInBand：只用一個 worker，一個測試跑完才跑下個測試
--logHeapUsage：輸出 heap memory 的使用量

實驗結果

PASS  src/.../JourneyChart.test.js (9.628s, 160 MB heap size)
PASS  src/.../ReachMethodNode.test.js (195 MB heap size)
...
PASS  src/.../validateGoalEvents.test.js (2588 MB heap size)
PASS  src/.../booleanString.test.js (2603 MB heap size)
(End)

其他人也遇到了一樣的問題嗎？

解決方案

降版到 Jest 23 -> 失敗！
Add --expose-gc -> 成功 !?
--max-old-space-size -> 成功 !

`--expose-gc`

執行 Node.js 時，在 global 物件底下新增 gc function
gc = garbage collect
善意提醒 Node.js 清理 unused heap memory
process.memoryUsage()
Q: heapTotal & heapUsed 到底不同在哪邊？

為什麼加 `--expose-gc` 有用？

`--max-old-space-size=SIZE`

當 unused heap memory 接近指定的用量的時候，V8 引擎會花更多時間在 garbage collection 上

 PASS  src/.../JourneyChart.test.js (6.902s, 135 MB heap size)
 PASS  src/.../CreativePanel.test.js (131 MB heap size)
 ...
 PASS  src/.../ScenarioToolbar.test.js (893 MB heap size)
 PASS  src/.../CreativeImagesAction.test.js (916 MB heap size)
 
 (everytime it reachs 1024MB, it will swipe ununsed memory)
 
 PASS  src/.../validateAudiencePlatform.test.js (180 MB heap size)
 PASS  src/.../validateHtmlCreative.test.js (186 MB heap size)
 ...
 (end)

兩種層級的 Memory Leak

Node.js 心裡有偵測到 unused memory 很多，但 Node.js 不說不釋放
Node.js 真的沒偵測到那塊 unused memory

小結

Jest options:
- --runInBand: 讓 Jest 只用一個 worker 跑測試，且一個跑完才跑下一個
- --logHeapUsage: 輸出跑到每一個測試時的 heap 使用量
Node.js options:
- --expose-gc: 讓 Node.js 的 global 變數有 gc 函數，用於要求做 garbage collection
- --max-old-space-size=SIZE: 設定 unused 記憶體的上限，接近上限值時會較頻繁做 garbage collection

更進一步

我們要如何偵測真的 Memory Leak ？
上面提的都是 Node.js 的環境，Browser 環境會不同嗎？

Browser 環境

沒有 global.gc() 可用，基本上沒有任何方法可以要求瀏覽器做 garbage collection
查看 heap 使用量: console.memory / window.performance.memory
devtools

我們要如何偵測真的 Memory Leak？

所謂 ”真的 Memory Leak“，代表的就是我們的 code 沒寫好，有一塊記憶體沒有釋放掉
任何自動化的程式基本上無從得知那一塊沒被釋放掉的記憶體，到底是真的有要用，還是沒有
不過，我們可以用工具提醒我們「可能」有 Memory Leak
我們也可以盡可能知道什麼寫法會造成 Memory Leak

偵測可能的 Memory Leak 方法

node-memwatch: 連續 5 次 garbage collection，heap usage 仍然上升
BLeak: 在 browser 端自動化偵測 Memory Leak 的工具，有 24 頁的論文可以看
3-snapshot technique: Google 當初解 Gmail website memory leak 的方法
- Snapshot 1 -> do stuff -> snapsht 2 -> do same stuff -> snapshot 3 -> Compare snapshot 1, 2, 3
Detect memory leak by puppteer

哪些 Pattern 會造成 memory leak ?

不小心用到全域變數
忘記移除 timer
忘記移除 event listener
closure

總結

兩種層級的 memory leak
沒有自動化的工具告訴我們是否真的有 memory leak ，以及 leak 在哪邊
但 Chrome devtools 很實用
我們也可以記得哪些 pattern 會有 memory leak

待探索

Chrome devtools 的 heap snapshot 功能
自動化在 browser 端檢測 memory leak 的方法，並加入 e2e testing
react 上面會有 memory leak 的 pattern

直白理解什麼是 Dependency Inversion （依賴反轉）

Fri, 04 Dec 2020 16:12:04 GMT

第一次聽到 Dependency Inversion(依賴反轉) 這個詞，是在面試的時候。AmazingTalker 的 take home 專案裡面提到，期待面試者寫出來的程式碼，符合 SOLID 原則。而其中 SOLID 的 D，指的就是 Dependency Inversion。

使用依賴反轉，可以讓程式碼之間減少依賴，寫出維護成本更低的程式碼。

而這一篇文章希望可以用最直白的方法，讓我們更好理解什麼是依賴反轉。

以下的例子來自於無瑕的程式碼：整潔的軟體設計與架構篇(Clean Architecture: A Craftsman’s Guide to Software Structure and Design) 這本書。

情境

“請寫一支程式，可以輸出 Hello World 字串到終端機上”

如果我們用 C 語言寫會是這樣：

#include<stdio.h>

int main() {
  printf("Hello World");
  return 0;
}

很簡單對吧！

那麼，我們有可能改變這樣的依賴關係嗎？

有的，藉由定義一個彼此溝通合作的介面，我們可以某種形式地反轉它。

在 C 語言裡面，其實定義了 FILE type 的指標，必須要實作五個函數 open, close, read, write, seek。只要有實作五個函數，我們使用 fprintf，就可以使用這個指標作為輸出裝置。

終端機實作了這五個函數，作業系統在串接硬碟時也實作了這五個函數，讓我們可以不論是要輸出到終端機，還是檔案，都可以不用修改原本的程式碼。

舉個實例是這樣：

#include<stdio.h>

// 這邊都不用改
void printHelloWorld(FILE *out) {
  fprintf(out, "Hello World");
}

int main() {
  // 想輸出到終端機
  printHelloWorld(stdout);

  // 想輸出到檔案
  FILE *filePointer = ...;
  printHellowWorld(filePointer);

  // 想輸出到其他裝置
  FILE *deviceFilePointer = ...;
  printHellowWorld(deviceFilePointer);

  return 0;
}

如此一來，我們已經改變了依賴關係，這隻程式實際上不再依賴裝置本身，而是依賴介面，而裝置也依賴介面。也就是說，兩隻程式的關係變成這樣：

事實上，依賴關係並不是直接反轉過來，而是兩端依賴一個共用的介面。有了介面之後，我們可以讓兩端可以在不修改內部邏輯的前提下，完成不同的任務。

這樣會方便很多，左邊我們可以改成輸出病例、銀行交易紀錄，右邊可以改成終端機、硬碟、磁帶…。

小小總結

所謂的依賴反轉，就是藉由定義一個溝通的介面，讓兩端的程式碼可以互相合作，以達成不同程式目的，並讓兩端的程式碼不必為了另外一端而做內部修改。
兩端都可以像插件一樣，可以抽換整個模組以達成新的目的，進而達到降低維護成本的目的。

運用 Dependency Inversion 有什麼缺點嗎？

假設我們今天定義出一個很棒的介面，左右兩端各有 10 支程式依賴這個介面，完成 100 個不同的任務。我們用 10+10 的時間完成了原本 100 時間才能完成的任務，聽起來非常棒。

但，如果介面改了呢？

沒錯，就左右兩邊加起來 20 支程式都要改。

商業世界變動快速，我們一定都遇過，業主需求改變、PM 需求改變，老闆今天心情好想加個功能…。各種因素都有可能造成我們原本定義好的介面必須被改變，而這牽一髮動全身。如果原本每一種 case 都分開寫，還有可能不需要改動到 20 支程式。

所以，如何定義好的介面，讓商業邏輯不會動到它，最有效減少程式碼維護的成本，永遠都是身為一名工程師的修煉。

最後是我個人大推 Clean Architecture 這本書，讓我們用更抽象化的層級思考所寫的程式，那些結構的差異，如何影響我們的開發經驗。以及如何降低維護程式碼的成本，擁有更好的生活。

Wei-Ming's Blog

Storage and Retrieval (3) - Column-based storage engine

Preface

Landscape of database storages

Column-based storage engine

OLTP v.s. OLAP

Star Schema

Column-based storage engine

The benefits

The drawbacks

Real world DB

Comparison matrix of Row-based & Column based storage engine

Summary

Storage and Retrieval (2) - B Tree

Preface

Landscape of database storages

Page-oriented storage engine

B Tree

How it works

Pros & Cons

Comparison matrix of Log-structure & Page-oriented Storage engine

About write performance

Summary

Storage and Retrieval (1) - SSTable and LSM Tree

Preface

Why study database storage and retrieval ?

What we are going to learn in this article ?

Landscape of database storages

Log-structured storage engine

High level concept

Very first version of our own DB

Enhancement: adding index

How it works:

Discussions

SSTables & LSM Tree

The benefits of sorted data in segment file

How it works

Terms

Discussions

Summary

希望我 20 歲就有的投資理財懶人包

為什麼投資理財很重要？

具體來說，我們要如何好好為自己投資理財呢？

Step 1. 釐清財務狀況

Step 2. 償還債務

Step 3. 準備緊急預備金

Step 4. 為自己以及家人保險

為什麼要買保險？一定要有保險嗎？

保險的本質是什麼？

所以我們到底應該保哪些？ 額度要多少？

每一種風險相對應的保險

壽險

失能險

長照險

長照險 v.s. 失能險

重大傷病險

癌症險

醫療險

保險的順序

定期 / 平準 / 終身險的差別

買保險的眉角

Step 5. 長期投資

複利的力量 - 七二法則

投資標的選擇

最適合我們的投資方式

為什麼要買「指數型」 ETF?

為什麼要買下全市場或大型股的指數型 ETF？ 而不是買幾間績優公司的股票？ 或是人為管理的主動型基金？

全市場或大型股的指數型股票 ETF 長期會獲利的基礎假設

還有一個理由你不該買人為管理的基金

為什麼還要再買全市場指數型債券 ETF ？

資產配置的原則

為什麼要「定期定額」？

為什麼要長期持有？

長期投資的心法 (總結)

標的選擇 - 台灣市場

標的選擇 - 美國市場

美股 v.s. 台股 v.s. 複委託

具體來說要如何開始長期投資呢？

如何檢視自己的投資成效

馬上行動

所以我們到底應該保哪些？額度要多少？

為什麼要買下全市場或大型股的指數型 ETF？而不是買幾間績優公司的股票？或是人為管理的主動型基金？

如何檢視自己的投資成效

`--expose-gc`

為什麼加 `--expose-gc` 有用？

`--max-old-space-size=SIZE`