row-oriented/ column-oriented database

Q. MySAM 이 셀렉트 속도가 빠르니까 vod_list 테이블을 select만 하도록 만들어서 MyIsam을 쓰고

변경이 있는 데이터(조회수 등) 테이블은 InnoDB 를 사용하면 어떻게 됨?

Q. 아무리 셀렉트만 하는 테이블이더라도 새로운 vod가 생기면 insert 발생. 그럴땐 어떡?

=> 그렇더라도 셀렉트 비율이 훨씬 높은경우 insert가 생기기 전까지 쿼리캐시를 활용할 수 있음

Q. full text indexing?

Q. MariaDB와 Percona의 용도?

MariaDB is better for advanced features, the latest security and adapting to new tech. Percona excels at database performance and diagnostics. 

https://blog.appdynamics.com/engineering/what-you-need-to-know-about-the-mariadb-percona-forks-of-mysql/

mysql은 커뮤니티 버전(무료버전)이 쓰레드풀을 지원안함. 마리아디비는 지원함. 

마리아는 xtraDB 에서 InnoDB로 변경. 이유는? 

=> Keeping InnoDB (or XtraDB) up to date with MySQL (Percona) is a complex task. It took us more than half a year to migrate from InnoDB-5.6 to InnoDB-5.7 in 10.2. Doing it again for XtraDB would probably have required only slightly less than this. For us to embark on such project, it must bring significant benefits to our users.

XtraDB had many great improvements over InnoDB in 5.1 and 5.5. But over time, MySQL has implemented almost all of them. InnoDB has caught up and XtraDB is only marginally better. Not enough to justify a multi-month merge that would delay 10.2-GA for everyone.

In particular, the only real improvement that XtraDB 5.7 seems to have is for a write-intensive I/O-bound workload, where innodb_thread_concurrency control is disabled.

With a proper innodb_thread_concurrency, XtraDB is only marginally better. We didn't want to delay 10.2-GA by up to half a year for the sake of those few users who have write-intensive I/O-bound InnoDB workload and don't know how to configure innodb_thread_concurrency.

Note, we still consider incorporating XtraDB optimizations, but as patches, rather than XtraDB as a whole, which no longer has numerous all-over-the-code improvements.

https://mariadb.com/kb/en/library/why-does-mariadb-102-use-innodb-instead-of-xtradb/

모넷디비가 열기반인데 행기반 셀렉트하는 과정이 다름

* 행기반 데이터베이스

특정 행을 읽으려면 먼저 행의 위치를 결정해야 합니다.

행이 고정된 길이를 가진다면 이것은 쉽습니다. 하지만 실제로는 그다지 쉽지 않습니다.

varchar에서는 값의 길이가 가변적일 수 있습니다.

가변 길이 값을 사용하면 행이 어디에서 시작하는지 모르기 때문에 단순히 데이터 파일의 중간에서 점프 할 수 없습니다.

특정 행의 오프셋을 계산하려면 헤더에 저장된 레코드 길이를 사용해야 합니다. 이것은 헤더를 가로지르는 것을 의미합니다. 

데이터 파일은 종종 페이지로 구성됩니다.

특정 행에 대한 데이터를 읽으려면 전체 페이지를 읽어야 합니다.

행이 작을수록 페이지에 더 잘 맞을 것입니다.

실제로는 페이지가 완전히 채워지지 않는 경우가 많습니다.

이렇게하면 페이지 분할이나 이동없이도 나중에 업데이트 할 수 있지만 (비싼 작업임) 공간을 많이 낭비 할 수 있습니다. 

또한 행은 페이지에 맞춰야하며 부품은 사용하지 않고 남겨 둡니다.

row-oriented storage is good if we need to touch one row.

row-oriented storage is beneficial if all or most column of a row need to be read or written. this can be done with a single read/write.

row-oriented storage is very efficient if not all coulmn are needed but a lot of rows need to be read 

full rows are read, including columns not used by a query.

read are done page-wise. not many rows may fit on a page when rows are big.

pages are nomally not fully filled which leads to reading lots of unused areas

record(and somtimes page) headers need to be read. too but do not contain actual row data.

행 지향 스토리지는 한 행을 터치해야하는 경우에 좋습니다.

행 지향 스토리지는 행의 모든 ​​열 또는 대부분의 열을 읽거나 쓸 필요가있을 때 유용합니다. 이 작업은 단일 읽기 / 쓰기로 수행 할 수 있습니다.

행 지향 저장소는 모든 coulmn이 필요하지는 않지만 많은 행을 읽을 필요가있는 경우 매우 효율적입니다.

쿼리에서 사용되지 않는 열을 포함하여 전체 행을 읽습니다.

읽기는 페이지별로 수행됩니다. 행이 큰 경우 많은 행이 페이지에 적합하지 않을 수 있습니다.

페이지는 일반적으로 완전히 채워지지 않아 사용되지 않는 영역을 많이 읽습니다.

레코드 (및 somtimes 페이지) 헤더를 읽을 필요가 있습니다. 실제 행 데이터는 포함하지 않습니다.

row-oriented storage is especially inefficient when only a small amount of coulmns is needed but the table has many column.

example:need only 1 c1, but must read 2 pages to get just 3 values

we'd prefer getting 12 values with  1 read. this would be optimal

행 지향 스토리지는 특히 적은 양의 coulmns 만 필요하지만 테이블에는 많은 컬럼이 있을 때 특히 비효율적입니다.

예 : 1 c1 만 있으면되지만 3 개의 값을 얻으려면 2 페이지를 읽어야합니다.

우리는 1 개의 값으로 12 개의 값을 얻는 것을 선호합니다. 이것이 최적 일 것이다.

* 열기반 데이터베이스

column oriented databases primarily work on columns

all columns are treated indiviaully

this allows array processing the values of column

rows may be constructed from column values later if required

this means column store can still produce row output (table)

values from multiple coulmns need to be  retreived and assembled for that, making implementation of bit more complex

query processors in columnar databases work on column too.

열 기반 데이터베이스는 주로 열에서 작동합니다.

모든 열은 개별적으로 취급됩니다.

이것은 배열이 컬럼의 값을 처리하도록 허용한다.

필요한 경우 나중에 행을 열 값으로 구성 할 수 있습니다.

이것은 열 저장소가 여전히 행 출력 (테이블)을 생성 할 수 있다는 것을 의미합니다.

여러 군데로부터의 가치를 수집하고 수집하여 좀 더 복잡한 구현을해야합니다.

열 데이터베이스의 쿼리 프로세서도 열에서 작동합니다.

column stores can greatly improve the performance of query of that only touch a small amount of columns.

this is becuase they will only access these column's particular data.

simple math : table t has a total of 10GB data with column a(4GB), column b(3GB), column c(2GB), column d(1GB).

if a query only use column d, at most 1GB of data will be processed by a column store.

in a row store, the full 10GB will be processed.

열 저장소는 크게 열의 작은 양만 만지는 쿼리의 성능을 향상시킬 수 있습니다.

이것은이 열의 특정 데이터에만 액세스하기 때문입니다.

간단한 수학 : 테이블 t에는 열 a (4GB), 열 b (3GB), 열 c (2GB), 열 d (1GB)의 총 10GB 데이터가 있습니다.

쿼리가 열 d만을 사용하는 경우 최대 1GB의 데이터가 열 저장소에서 처리됩니다.

행 저장소에서 전체 10GB가 처리됩니다.

column stores store data in column-specific files

simplest case : one data file per column

row values for each column are stored continuously.

열 저장소는 열 특정 파일에 데이터를 저장합니다.

가장 단순한 경우 : 열당 하나의 데이터 파일

각 열의 행 값은 연속적으로 저장됩니다.

with every page read, we can read the values for many rows at once. we'll get more values per I/O than with row-storage.

this is ideal if we want to process most records anyway.

if values are fixed-length, we are also allowed random access to each record's value.

saving header information in the values file is undesired.

can save meta information separately, e.g. null bits as a bit vector per column.

모든 페이지를 읽을 때마다 한 번에 많은 행의 값을 읽을 수 있습니다. 우리는 행 스토리지보다 I / O 당 더 많은 가치를 얻을 것입니다.

대부분의 레코드를 처리하려는 경우에 이상적입니다.

값이 고정 길이이면 각 레코드의 값에 임의 액세스 할 수 있습니다.

값 파일에 헤더 정보를 저장하는 것은 바람직하지 않습니다.

메타 정보를 별도로 저장할 수 있습니다 (예 : 널 (null) 비트는 컬럼 당 비트 벡터입니다.

all data within each column datafile have the same type making it ideal for compression.

usually a much better compression factor can be achieved for single columns than for entire rows.

compression allows reducing disk I/O when reading/writing column data but has some cpu cost.

for data sets bigger than the memory size compression is often beneficial because disk access is slower than decompression.

각 열 데이터 파일 내의 모든 데이터는 동일한 유형이므로 압축에 이상적입니다.

일반적으로 전체 열보다 단일 열에 대해 훨씬 우수한 압축률을 얻을 수 있습니다.

압축을 사용하면 열 데이터를 읽거나 쓸 때 디스크 I / O를 줄일 수 있지만 CPU 비용은 약간 듭니다.

메모리 크기보다 큰 데이터 세트의 압축은 디스크 액세스가 압축 해제보다 느리기 때문에 종종 도움이됩니다.

a good use case for compression in column store is dictionary compression for variable length string values.

each unique string is assigned an integer number.

the dictionary, consisting of integer number and string value, is save as column meta data.

column values are then integers only, making them small and fixed witdh.

this can save much space if string values are non-unique.

with dictionaries stored by column value, this will also allow range queries.

컬럼 스토어에서의 압축을위한 좋은 유스 케이스는 가변 길이 문자열 값에 대한 사전 압축이다.

각 고유 문자열에는 정수가 할당됩니다.

정수형과 문자열 값으로 구성된 사전은 열 메타 데이터로 저장됩니다.

그런 다음 열 값은 정수로만 작고 고정 witdh가됩니다.

문자열 값이 고유하지 않으면 많은 공간을 절약 할 수 있습니다.

사전을 열 값으로 저장하면 범위 쿼리가 허용됩니다.

in a column database, it is relatively cheap to traverse all values of a column.

building an index on a column only requires reading that column's data, not the complete table data as in a row store.

adding or deleting columns is a relatively cheap operation too.

열 데이터베이스에서 열의 모든 값을 트래버스하는 것이 상대적으로 저렴합니다.

컬럼에 인덱스를 작성하는 것은 행 스토리지에서와 같이 전체 테이블 데이터가 아닌 해당 컬럼의 데이터를 읽는 것만을 요구합니다.

열 추가 또는 삭제는 상대적으로 저렴한 작업입니다.

column data in column stores is often grouped into segments/packets of specific size 

meta data calculated and stored seperately per segment, e.g. - min value in segment

- max value in segment

- number of not null values in segment

- histograms

- compression meta data

열 저장소의 열 데이터는 종종 특정 크기의 세그먼트 / 패킷으로 그룹화됩니다

세그먼트별로 계산되고 저장되는 메타 데이터입니다

 (예 : - 세그먼트의 최소값

- 세그먼트의 최대 값

- 세그먼트의 null이 아닌 값의 수

- 히스토그램

- 압축 메타 데이터

* column-oriented storage, segments

segment meta data can be checked during query processing when no indexes are available.

segment meta data may provide information about whther segment can be skipped entirely, allowing to reduce the number of values that need to be processed in the query

calculating segment meta data is a relatively cheap operation (only needs to traverse column values in segment) but still should occur infrequently

in a read-only or read-mostly workload this is tolerable

인덱스가 사용 가능하지 않을 때 쿼리 처리 중에 세그먼트 메타 데이터를 검사 할 수 있습니다.

세그먼트 메타 데이터는 전체 세그먼트를 건너 뛸 수 있다는 정보를 제공하여 쿼리에서 처리해야하는 값의 수를 줄입니다.

세그먼트 메타 데이터를 계산하는 것은 상대적으로 비용이 적게 드는 작업이지만 세그먼트에서 열 값을 트래버스해야하지만 드물게 발생해야합니다.

읽기 전용 또는 대부분 읽기 작업 부하에서 이것은 허용 가능합니다.

* column-oriented processing

column values are not processed row-at-a-time, but block-at-a-time.

this reduces the number of function calls (function call per block of values, but not per row)

operating in blocks allows complier optimisations, e.g. loop unrolling, parallelisation, piplining

column values are nomally positioned in contiguous memory locations, also allowing SIMD operations (vertorisation).

working on many subsequent memory positions also improves cache usage (multiple values are in the same cache line) and reduces pipeline stalls

all of the above make column store ideal for batch processing.

열 값은 한 번에 한 행씩 처리되지 않고 한 번에 한 블록 씩 처리됩니다.

이렇게하면 함수 호출 수가 줄어 듭니다 (블록 당 값은 있지만 행 당 함수 호출은 아닙니다)

블록 단위로 작업하면 컴파일러 최적화가 가능합니다. 루프 풀기, 병렬 처리, 파이핑

열 값은 SIMD 연산 (vertorization)을 허용하면서 인접한 메모리 위치에 정렬됩니다.

많은 후속 메모리 위치에서 작업하면 캐시 사용이 향상되고 (여러 값이 동일한 캐시 라인에 있음) 파이프 라인 설치가 줄어 듭니다.

위의 모든 항목은 배치 처리에 이상적인 컬럼 스토어를 만듭니다.

reading all columns of a row is an expensive operation in a column store, so full row tuple construction is avoided or delayed as much as possible internally.

updating or inserting rows may also be very expensive and may cost much more time than in a row store

some column stores are hybrids, with read-optimised(column) storage and write-optimised OLTP storage.

still column stores are not really made for OLTP workloads, and if you need to work with many columns at once, you'll pay a price in a column store.

행의 모든 ​​열을 읽는 것은 열 저장소에서 값 비싼 연산이므로 전체 행 튜플 구성은 가능한 한 내부적으로 피하거나 지연됩니다.

행을 업데이트하거나 삽입하는 것은 비용이 많이 들고 행 저장소보다 훨씬 많은 시간이 소요될 수 있습니다.

일부 컬럼 스토어는 읽기 최적화 (컬럼) 스토리지 및 쓰기 최적화 된 OLTP 스토리지가있는 하이브리드입니다.

스틸 컬럼 스토어는 실제로 OLTP 워크로드 용으로 만들어지지 않았으며 여러 컬럼을 동시에 사용해야하는 경우 컬럼 스토어에서 가격을 지불하게됩니다.

-----------------------------------------------------------------------------------------------------------------

독일 맥주 양조장에 대한 5 년간의 회계 처리를 한 실험에서이 테이블의 튜플 수는 3,400 만입니다.
기본 행 데이터베이스에서이 특정 테이블의 1 백만 개의 튜플은 약 1GB의 공간을 사용합니다.
따라서 테이블의 크기는 35GB였습니다. 컬럼을 따라 더 효율적인 수직 압축이 있었기 때문에 동등한 컬럼 스토어 테이블 크기는 8GB 밖에되지 않았습니다.
실제 응용 프로그램에서 단일 테이블의 특성 중 10 %만이 일반적으로 하나의 SQL 문에서 사용된다는 것을 고려하면 (그림 1 참조),
이는 총 값을 계산하기 위해 최대 800MB의 데이터를 액세스해야한다는 것을 의미합니다. 
그림 2는 수평 압축 된 행 저장소가 경쟁 할 수 없다는 것을 (개략적으로) 보여줍니다.
처리가 세트 지향이며 열 조작이 필요한 경우 적절한 색인을 사용한다고해도 액세스되는 데이터의 양은 훨씬 더 많습니다.


(Row)
튜플 기반 테이블로 구성되며 단일 튜플은 여러 개의 열(Column, 이하 컬럼)로 구성된다. 질의에 의해 요청된 특정 컬럼에 접근하기 위하여 각 튜플의 오프셋 (헤더로부터 해당 컬럼까지의 거리)이 계산되어야 한다. 
오프셋은 목표 컬럼에 선행하는 컬럼의 길이를 총합하여 구할 수 있다. 컬럼의 길이정보가 컬럼 헤더에 존재하는 경우, 목표 컬럼에 선행하는 다른 컬럼에 직접 접근하게 된다. 이러한 방식은 튜플의 길이가 수 개의 캐시라인에 이를 경우 불필요한 컬럼 데이터를 캐
시에 불러오는 상황을 발생 시킨다. 
(=> 컬럼의 위치에 따라 읽기/쓰기 속도가 달라질수도 있을까?)
최악의 경우 가장뒤의 컬럼 하나에 접근하기 위해 튜플 전체가 캐시에 로드 될 수 있다. 

몇 가지 흥미로운 트레이드가 있습니다.

워크로드의 액세스 패턴에 따라 열 기반 또는 행 지향 실제 레이아웃이 더 적합한 지 여부를 지정합니다.

데이터가 자기 디스크에 저장되면 쿼리가 단일 레코드 (즉, 테이블의 단일 행 속성 전체 또는 일부)에만 액세스해야하는 경우에는 열 저장소가 여러 번 검색해야합니다. 참조 된 테이블의 열 / 파일 쿼리에서)이 단일 레코드를 읽습니다.

그러나 쿼리가 많은 레코드에 액세스해야하는 경우, 그러면 전체 열의 넓은 범위를 읽을 수 있고 검색을 다른 열로 나누어 쓸 수 있습니다. 대조적으로, 기존의 행 저장소에서는 쿼리가 단일 레코드에 액세스 해야 하는 경우 전체 레코드가 연속적으로 저장되기 때문에 하나의 검색 만 필요하고 레코드의 모든 특성을 읽는 오버 헤드가 발생합니다. 현재 쿼리에서 요청한 속성)은

탐색 시간에 비하면 무시할 만하다.

그러나 점점 더 많은 기록 액세스 시간, 전송 시간이 탐색 시간을 지배하기 시작하며,

열 지향 접근법은 행 지향적 접근보다 더 나은 성능을 발휘합니다.

접근. 이러한 이유로 열 저장은 일반적으로 분석에 사용됩니다

응용 프로그램, 개별 테이블의 많은 부분을 스캔하는 쿼리

그들에 대한 집계 또는 기타 통계를 계산할 수 있습니다.