Apollo資料庫，線上低延遲儲存的NoSQL資料庫
區別於面向文件和鍵值的儲存，Apollo是一種修改的資料結構，允許你儲存Map、佇列、樹以及鍵值等等。系統中每個單獨的資料塊都非常小，從1位元組到1MB，而所有的總大小則從1MB到10+PB。它支援的伺服器從最少三臺到數千臺之多。
每個Shard有四個元件。
第一個是Quorum一致性協議。
第二個元件是儲存。目前主儲存基於RocksDB，是一種構建於Google LevelDB的Key/Value儲存結構。雖然它是Key/Value儲存，Facebook使用它來模擬其它資料結構。Apollo被設計為可以儲存未知的結構，開發團隊也正在增加對MySQL的支援以作為一種替代儲存引擎。
第三個元件是客戶端API，它擁有read()和write()方法。Apollo在Shard層執行的所有操作都是原子操作，因此你可以描述前置條件，如果滿足，它返回reads或writes。程式碼示例如下：
read(conditions : {map(m1).contains(x)},
reads : {deque(d2).back()})
上面的程式碼表示“如果Map m1包含x，就返回雙端佇列（Deque）d2的back上的值。”
你能將任意多個條件和任意數量的Read結合在一起。
Write也非常類似，同樣允許你描述條件：
write(conditions : {ver(k1) == v}, reads : {},
writes : {val(k1) := x})
最後一個元件是容錯狀態機（Fault Tolerant State Machine，FTSM）。它們主要由系統程式碼使用，但也可以被使用者程式碼使用。每個FTSM都屬於Shard，例如，在一個有三臺機器的Shard中，它們全部同時執行相同的程式碼。它們能存取每臺機器的持久化儲存。最重要的是，如果一個節點故障，程式碼將按所有節點都同意的正確順序繼續執行。
狀態機還被用於負載均衡、資料遷移、Shard建立和銷燬，以及協調跨Shard事務。狀態機也存在外部副作用，例如它們能傳送RPC請求到遠端機器，但不論何時它們要變更持久化狀態，都必須提交給Raft以取得所有伺服器的同意。
Facebook目前將Apollo用於替換Memcached的一些應用場景，Facebook目前大規模地使用了Memcached。該公司同時正在嘗試使用它作為一種可靠的佇列系統，用於傳送Facebook訊息到iOS、Android和運營商SMS。它也可能用於更快速的分析。
Apollo仍處於開發階段，還沒有開源，不過在不就之後將釋出給所有人，拭目以待咯!