換句話說，與行相關的所有值都物理地儲存在彼此旁邊。
面向行的dbms的示例是mysql，postgres和ms sql server。
在面向列的dbms中，資料儲存如下：
這些示例僅顯示資料的排列順序。不同列的值分別儲存，同一列的資料儲存在一起。
面向列的dbms的示例：vertica，paraccel（actian matrix和amazon redshift），sybase iq，exasol，infobright，infinidb，monetdb（vectorwise和actian vector），luciddb，sap hana，google dremel，google powerdrill，druid和kdb +。
儲存資料的不同順序更適合於不同的場景。資料訪問場景是指進行了哪些查詢，多長時間以及以何種比例進行查詢;為每種型別的查詢讀取多少資料 - 行，列和位元組;讀取和更新資料之間的關係;資料大小以及如何使用本地資料;transactions是否被使用，以及它們是否隔離;資料replication和邏輯完整性的要求;每種型別的查詢的延遲和吞吐量要求，等等。
系統負載越高，定製系統設定以匹配使用方案的要求就越重要，並且此定製變得越精細。沒有乙個系統同樣適用於明顯不同的場景。如果系統適應各種場景，在高負載下，系統將同樣處理所有場景，或者僅適用於一種或幾種可能的場景。
2.olap場景的關鍵屬性
很容易看出olap場景與其他流行場景（例如oltp或鍵值訪問）非常不同。 因此，如果希望獲得不錯的效能，嘗試使用oltp或鍵值db來處理分析查詢是沒有意義的。 例如，如果嘗試使用mongodb或redis進行分析，則與olap資料庫相比，效能會非常差。
3.為什麼面向列的資料庫在olap場景中更好地工作
面向列的資料庫更適合olap場景：它們在處理大多數查詢時至少快100倍。 原因在下面詳細解釋，但事實更容易在視覺上展示：
面向行的dbms
面向列的dbms
看到不同？
輸入/輸出
例如，查詢「計算每個廣告平台的記錄數」需要讀取乙個「廣告平台id」列，其占用未壓縮的1個位元組。 如果大多數流量不是來自廣告平台，則可以預期此列的壓縮率至少為10倍。 當使用快速壓縮演算法時，資料解壓縮可以每秒至少幾千兆位元組的未壓縮資料的速度進行。 換句話說，可以在單個伺服器上以每秒大約幾十億行的速度處理該查詢。 這種速度實際上是在實踐中實現的。
例子：[bash shell] 純文字檢視 複製**
$ clickhouse-client
clickhouse client version 0.0.52053.
connecting to localhost:9000.
connected to clickhouse server version 0.0.52053.
:) select counterid, count() from hits group by counterid order by count() desc limit 20
select
counterid,
count()
from hits
group by counterid
order by count() desc
limit 20
┌─counterid─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rowsinset. elapsed: 0.153 sec. processed 1.00 billion rows, 4.00 gb (6.53 billion rows/s., 26.10 gb/s.)
:)
cpu由於執行查詢需要處理大量行，因此有助於為整個向量而不是單獨的行排程所有操作，或者實現查詢引擎以便幾乎不需要排程成本。如果不這樣做，使用任何half-decent的磁碟子系統，查詢直譯器將不可避免地停止cpu。將資料儲存在列中並在可能的情況下按列處理它是有意義的。
有兩種方法可以做到這一點：
向量引擎：所有操作都是為向量而不是為單獨的值編寫的。這意味著不需要經常呼叫操作，並且排程成本可以忽略不計。操作**包含優化的內部迴圈。
**生成：為查詢生成的**中包含所有間接呼叫。
這不是在「傳統」資料庫中完成的，因為在執行簡單查詢時沒有意義。但是，也有例外。例如，memsql使用**生成來減少處理sql查詢時的延遲。 （為了進行比較，分析dbms需要優化吞吐量，而不是延遲。）
請注意，對於cpu效率，查詢語言必須是宣告性的（sql或mdx），或者至少是向量（j，k）。查詢應該只包含隱式迴圈，允許優化。
資料庫 資料庫索引
索引是儲存引擎用於快速找到記錄的一種資料結構。索引以檔案的形式儲存在磁碟中。索引可以包含乙個或多個列的值。儲存引擎查詢資料的時候，先在索引中找對應值，然後根據匹配的索引記錄找到對應的資料行。1.b tree索引 2.雜湊索引 myisam和innodb儲存引擎 只支援btree索引，也就是說預設使用...
資料庫 資料庫正規化
關聯式資料庫的設計規範。不同的規範要求被稱為不同的正規化，越高的正規化資料庫冗餘越小。減少資料庫中資料冗餘的過程 1 第一正規化 1nf 在關係模式r中，當且僅當所有屬性只包含原子值，即每個分量都是不可再分的資料項，則稱r滿足1nf。例如表所示的教師職稱情況關係就不滿足1nf。原因在於，該關係模式中...
資料庫 資料庫基礎
什麼是sql 結構化查詢語言 structtured query language sql的作用 啟動mysql.exe，連線伺服器後，就可以使用sql來操作伺服器了。類似php中操作mysql的語句就是sql語句 sql標準 由國際標準化組織 iso 制定的，對dbms 資料庫管理系統 的統一操作...