## HA [これだけは覚えて！「RTO」と「RPO」](https://www.networld.co.jp/solution/learn_first/backup/1st/01_basis/02_rtorpo/) - RPO（Recovery Point Objective）とは、障害発生時、過去の「どの時点まで」のデータを復旧させるかの目標値である。 - RTO（Recovery Time Objective）とは、障害発生時「どのくらいの時間で（いつまでに）」 復旧させるかを定めた目標値である。 10:00 running ←──── RPO ────→ 11:00 Incident ←───── RTO ────→ 12:00 recovered (RPO= 1h = data 1h ago is recoverable) (RTO = 1h = recover system in 1h) ## Database ### RDS Storage models comparision | Engine<div style="width:80px">property</div> | Clustered Index Support? | Heap Support? | Performance Characteristics | |-------|---------------------------|----------------|------------------------------| | **SQL Server** | Optional (clustered index defines physical table order) | Yes | Clustered tables provide strong range scans and PK-driven lookups, with predictable I/O patterns, but random inserts may cause page splits. Heaps offer fast inserts but slower range scans and require additional lookups for ordered access. | | **MySQL**<br/>(InnoDB) | **Always clustered** (mandatory PK-based clustered index) [1](https://dev.to/harry_do/part-2-mysql-vs-postgresql-storage-architecture-2ki1)[2](https://stackoverflow.com/questions/65764630/heap-vs-clustered-index-full-table-scan) | ❌ No | Excellent primary key and range-read performance due to physical ordering, but random inserts are more expensive due to page splits. Every secondary index stores a copy of the PK, increasing index size and lookup cost for wide PKs. [1](https://dev.to/harry_do/part-2-mysql-vs-postgresql-storage-architecture-2ki1) | | **PostgreSQL** | ❌ No true clustered index (CLUSTER is not maintained automatically) [1](https://dev.to/harry_do/part-2-mysql-vs-postgresql-storage-architecture-2ki1)[3](https://dba.stackexchange.com/questions/337831/why-do-databases-use-heap-to-store-table-data-while-other-structure-like-b-tree) | Yes | Very fast inserts and write-heavy performance due to heap storage. However, all indexed lookups require an extra heap fetch (index → TID → row), and range scans are typically slower because data is not physically ordered. | | **Oracle** | Supported via **Index‑Organized Tables (IOT)** (optional) [4](https://www.linkedin.com/pulse/heap-vs-index-organized-table-pranav-pandey)[5](https://use-the-index-luke.com/sql/clustering/index-organized-clustered-index) | Yes | IOTs provide strong PK and range performance via physical ordering. However, inserts are slower because rows must maintain index order. Secondary indexes must store logical PK values instead of physical ROWIDs, increasing overhead. Heaps behave similarly to PostgreSQL: fast inserts but slower ordered reads. | | Workload Type | Best Database Storage Model | |---------------|-----------------------------| | Write-heavy, high-throughput inserts | PostgreSQL HEAP / SQL Server HEAP / Oracle HEAP | | Fast reads by PK, time-series, logging | MySQL InnoDB / SQL Server Clustered / Oracle IOT | | Many secondary indexes, OLTP joins | SQL Server Clustered / PostgreSQL HEAP | | Range scans (date-based reporting) | SQL Server Clustered / MySQL InnoDB / Oracle IOT | | Minimal index overhead | PostgreSQL HEAP |