꿩이야기

와... 정말 하루 온종일 popup 안뜨게 하려고 이것저것 시도하다가 겨우겨우 스스로 해결했다.

selenium 처음 시작시 참고하면 좋을거 같아서 포스팅을 해본다.

참고로 selenium 버전은 4.8.2이다.

def chrome_driver_dev():
    options = webdriver.ChromeOptions()
    # options.add_argument('--headless')
    # options.add_argument('--no-sandbox')
    # options.add_argument("--start-maximized")
    options.add_argument('--disable-dev-shm-usage')
    options.add_argument("--disable-notifications")
    options.add_experimental_option('excludeSwitches', ['disable-popup-blocking'])

    service = Service('/opt/homebrew/bin/chromedriver')

    return webdriver.Chrome(service=service, options=options)

To be continued.........

Made by 꿩

#덕유산 등산기

오랜만에 등산을 하기 위해

어디를 갈까 블로그를 뒤져보던 중

알레 버스라는 것을 알게 되었다

https://www.alle.co.kr/m/page/bus_list.html

산과 코스가 정해져 있고

편하게 버스를 타고 다녀올 수 있는 서비스였는데

평소 혼자서 등산하는 나에게

차도 없어서 버스 시간표를 알아보고 루트를 정하는 나에게

굉장히 유용한 서비스였다

알레버스의 덕유산 루트는 다음과 같다

안성탐방지원센터에서 출발하여

설천봉에서 케이블카를 타고 내려오는 코스이다

덕유산 초입에는 산악회 버스들과 등산 차량으로 인해

엄청난 인파가 몰렸었다

그 많은 사람들 중

나는 혼자라는 게 좀 슬펐다

뜨거운 여름에 간 덕유산 초입에는 그늘이 많아

그나마 올라가기 편했던 것 같다

여름치곤 등산하기 딱 좋은 날씨였다

중간에 가다보면 칠연폭포 쪽으로 올라가는 길이 있는데

올라갔다 다시 내려와야 하므로 추천하지 않는다

칠연폭포는 물줄기가 7개의 못에 잠시 머무르다 떨어지는 곳이라고 하는데

중간중간 짧은 폭포와 못이 여러개 있었다

다시는 가지 않을 듯!

혼자서 등산하다보니

아무 말없이 아무 생각없이 등산을 했었다

중간 중간 같이 알레버스를 타고 온 등산객이 보이긴 했지만

모르는척 묵묵히 내 갈길을 갔다

나도 언젠간 등산을 좋아하는 친구를 만들어서

주기적으로 같이 등산을 다니고 싶다 ㅠㅠ

동엽령까지는 산을 올라가는 길이다

오랜만에 등산을 해서 그런가

생각보다 조금 힘들긴 했는데

북한산성입구에서 백운대 올라가는 길과 비슷하지 않을까 싶다

동엽령에 다다르면 이제 힘든건 거의 끝났다고 보면 된다

능선을 따라 산을 오르락 내리락 하면 된다

확실히 여름이라 그런가

저 사진 속 수풀 안에 어마어마하게 많은 벌레들이 서식하고 있다

꽃이 많이 피어서

벌들도 어마어마하게 많았다

능선길이지만 아직 올라갈 길이 많이 남아 있긴 했다

그래도 처음보다는 많이 수월해서 천천히 가다보면 정상에 도착하게 된다

날씨가 흐려서 많이 덥지도 않지만

사진이 이쁘게 잘 나오기가 힘들다

날씨가 좋으면 온몸에 땀과 화상을 입을 수 있지만

사진이 매우 이쁘게 나온다

난 후자를 선호하지만 아쉽게도 날씨는 흐렸다

덕유산 정상에 다다르자 구름이 조금씩 걷히고 있었다

좀 빠르게 올라와서

버스 출발시간 전까지 정상에서 노닥거리면서 있었는데

이노무 벌들이...

나를 꽃으로 아나 ...

날 가만두질 않았다;;

참고로 저기서 조금만 내려가면 카페가 있으므로

거기서 쉬는걸 추천한다

나는 그걸 몰라서

꽃으로 빙의해

벌들의 대시를 받으며

인간에게서 받지 못하는 인기를 많이 받으며

이런 저런 생각을 했다

어린왕자에 이런 문구가 있다

"It's the miracle that the person who i like likes me"

내가 좋아하는 사람이 나를 좋아해 주는 건 기적이야

씁쓸함을 느끼면서

내려오다보니 바로 밑에 카페와 케이블카 정류장이 있었다

케이블카는 편도로 14,000원...

눈물을 머금고 결제를 했지만

진짜 케이블카 타고 내려오는 걸 추천한다

진심 케이블카 타고 내려오는 데도 한참이 걸린다

멀미나서 죽는 줄...

이제 집에 갈 시간이다

알레버스를 이용한 덕분에

편하고 혼자서라면 갈 수 없었던 산을 가게 되었다

분명히 좋은 거였는데

마음이 좀 허전했다

나는 혼자서 등산을 하는 것보단

같이 등산을 하는 걸 좋아하나보다

등산모임에 들어가야하나...?

매주... 매달은 가기 힘든데;;

To be continued.........

Made by 꿩

# my.cnf 메모리 설정

MariaDB의 메모리 공간은 글로벌 메모리 영역과 로컬 메모리 영역으로 구분된다

글로벌 메모리 영역은 스레드가 공유해서 사용되는 공간이다

DB 최초 기동시 메모리를 최소한만 사용하다가 설정된 값까지 증가되고

증가한 이후 메모리룰 반환하지 않고 설정된 값 이내에서 사용된다

글로벌 메모리 = innodb_buffer_pool_size + key_buffer_size + innodb_log_buffer_size

로컬 메모리 영역은 각 스레드별로 사용되며 공유되지 않는 공간이다

로컬 메모리 = ( tmp_table_size + sort_buffer_size + read_buffer_size + read_rnd_buffer_size + join_buffer_size + thread_stack + binlog_cache_size) * max_connections

총 메모리 = 글로벌 메모리 영역 + 로컬 메모리 영역 + Mariadb 기본 기동(350MB) + performance_schema data(150MB) + OS / 파일 버퍼링 공간(전체 메모리의 약 10%) 를 고려할 것

[참고자료]
https://www.webcomand.com/docs/admin_guide/configuration/mysqlmariadb/index.html
https://support.skdt.co.kr/ko/support/solutions/articles/42000064656--cloud-z-db-mariadb%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%84%A4%EC%A0%95%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC-%ED%95%98%EB%82%98%EC%9A%94-
MariaDB 공식문서

To be continued.........

Made by 꿩

# Database connection

Python으로 각 DB별 연결 내용 정리

# python3 설치
yum install python3 -y

1. PostgreSQL

# PostgreSQL 드라이버 설치
pip install psycopg2
python3 -m pip install psycopg2

import psycopg2
 
try:
    conn = psycopg2.connect(
        host="192.168.123.50",
        port="5432",
        database="postgres",
        user="user1",
        password="password")
 
    cur = conn.cursor()
 
    cur.execute("select version()")
 
    print(cur.fetchone())
 
except Exception as e:
    print("Error while fetching Schema")
    print(e)
 
finally:
    conn.close()

2. MySQL/MariaDB

# MySQL/MariaDB 드라이버 설치
pip install pymysql
python3 -m pip install pymysql

import pymysql
 
try:
    conn = pymysql.connect(
        host='192.168.123.50',
        port=3306 ,
        user='user1',
        password='password',
        db='mysql',
        charset='utf8'
    )
 
    cur = conn.cursor()
    cur.execute("select version()")
 
    rows = cur.fetchall()
    cur.close()
    conn.close()
    print(rows)
 
except Exception as e:
    print("Error while fetching Schema")
    print(e)

3. ClickHouse

# clickhouse 드라이버 설치
pip3 install clickhouse-driver[lz4]
python3 -m pip install clickhouse-driver[lz4]

from clickhouse_driver import Client
 
try:
    client = Client('192.168.123.50',
                user='user',
                password='password',
                verify=False,
                database='default',
                compression=True)
 
    result = client.execute('SELECT now(), version()')
    result2 = client.execute('SHOW databases')
    print(result)
 
except:
    print("Error while fetching Schema")

4. MongoDB

# MongoDB 드라이버 설치
pip install pymongo
python3 -m pip install pymongo

import pymongo
 
try:
    #conn = pymongo.MongoClient('mongodb://{user}:{password}@127.0.0.1:27017')
    conn = pymongo.MongoClient('mongodb://127.0.0.1:27017')
    db = conn.get_database('testdb')
    collection = db.get_collection('testcollection')
 
    for x in collection.find():
        print(x)
 
except Exception as e:
    print("Error while fetching Schema")
    print(e)

5. ElasticSearch

# ElasticSearch 드라이버 설치
pip install elasticsearch
python3 -m pip install elasticsearch

from elasticsearch import Elasticsearch
 
try:
    es = Elasticsearch('192.168.123.50:9200')
 
    # elastic info
    print(es.info())
 
    # get all index
    print(list(es.indices.get_alias().keys()))
 
    print(es.indices.get_mapping("products"))
    print(es.indices.get_mapping("work"))
 
except Exception as e:
    print("Error while fetching Schema")
    print(e)

6. Redis

# Redis 드라이버 설치
pip install scylla-driver
python3 -m pip install scylla-driver

import redis
 
try:
    r = redis.Redis(host='192.168.123.50', port=6379, db=0)
    r.set('k_test','v_test')
    print(r.get('k_test'))
    r.close()
except Exception as e:
    print("error")
    print(e)

7. ScyllaDB

# ScyllaDB 드라이버 설치
pip install scylla-driver
python3 -m pip install scylla-driver

import cassandra
 
print(cassandra.__version__)

To be continued.........

Made by 꿩

# BOM (Bill Of Materials)

데이터를 다루다보면 계층형 데이터들이 있다

대표적으로 카테고리 데이터!!!

카테고리 데이터는 동일한 데이터이지만

서로 부모와 자식 관계를 가질 수 있다

이렇게 계층형 데이터를 DB에 저장할 때

우리가 잘아는 순환 관계로 표현이 된다

위의 모델은 1:M 관계를 표현하지만

M:M 관계를 표현하지 못한다

다시말해서

상위 데이터(1)가 여러 개의 하위 데이터(M)을 가질 수 있다.

(상위 카테고리는 여러 하위 카테고리를 가진다)

그러나

여러 개의 하위 데이터(M)가 여러 상위 데이터(M)를 가질 순 없다.

(하위 카테고리는 여러개의 상위 카테고리에 포함되지 않는다 - parent_category_no 컬럼이 하나)

이를 해결하는 모델이 바로 BOM 모델이다.

BOM 구조는 새로운 관계 엔티티를 추가하여 1:M 관계로 구성된 모델이다.

보통 제조업에서 많이 쓰여서 부품, 조립규칙으로 많이 설명되는데

요즘 식욕이 많아져서...

음식을 조합하는 걸로 예시를 들어보려한다.

샐러드를 만드는 데 기본적으로 채소와 드레싱이 조합이 된다

닭가슴살 샐러드와 일반 샐러드를 만들 때

동일한 채소와 드레싱을 사용하여 만들게 되는데

채소가 닭가슴살 샐러드와 일반 샐러드에 포함이 되고

샐러드가 채소와 드레싱을 포함하는 다대다(M:M)관계가 성립된다

BOM 모델은 이렇게 계층형 데이터들 간의 M:M 순환 구조를 가지고 있는

데이터를 저장하는데 사용되는거라 보면 된다.

[참고자료]
https://ora-sysdba.tistory.com/entry/Seminar-%EC%88%9C%ED%99%98-%EA%B4%80%EA%B3%84-BOMBill-Of-Materials
http://wiki.gurubee.net/pages/viewpage.action?pageId=983056

To be continued.........

Made by 꿩

# SSH 공개키 설정

root 계정으로 서비스를 실행하는 것은 보안상 좋은 습관이 아니다

HDFS를 설치할 때 ssh 공개키에 대한 지식이 필요해서 포스팅을 한다

우선, 모든 서버에 hadoop이라는 계정을 생성해보자

groupadd hadoop
useradd -c "Apache Hadoop" -d /home/hadoop -g hadoop -s /bin/bash -u 9000 hadoop
passwd hadoop

ssh는 public key 암호방식을 사용한다

public key 암호방식은 비대칭 키로 양방향 암호화 방식이다.

public key와 private key를 사용한다

public key로 암호화된 데이터는 private key로만 복호화가 가능하다

private key로 암호화 된데이터는 public key로만 복호화가 가능하다

SSH Key를 생성하면 public key와 private key가 만들어진다

# 키 생성
ssh-keygen -t rsa -C "hadoop@localhost"

ssh-keygen이라는 프로그램을 이용하여 키를 생성하면 된다

-t rsa 옵션은 rsa 암호화 방식으로 키를 생성한다

-C 옵션은 코멘트이다

Enter file in which to save the key (/root/.ssh/id_rsa):

ssh 키가 저장될 위치를 말한다

기본 경로는 로그인한 사용자의 홈디렉토리의 {사용자}/.ssh/ 이다.

그냥 엔터 누르면 된다.

Enter passphrase (empty for no passphrase):

passphrase는 암호화시 salt처럼 사용하는 값이다.

The key fingerprint is:
SHA256:uIm++us4lxkLQoQJ3c3tp7ygxFsncmBKtBoN2TLGVWk hadoop@localhost

SHA256 해시 알고리즘을 사용했다는 것을 알려준다

위와 같이 키를 생성하면 public key와 private key가 생성된다.

### Public 키
# cat ~/.ssh/id_rsa.pub
ssh-rsa (키 내용) (코멘트)

### Private 키
# cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----

id_rsa는 private key로 타인에게 노출되면 안되는 키이고

id_rsa.pub은 public key로 remote 서버의 authorized_keys에 입력한다

authorized_keys 파일을 직접 생성할 경우 chmod 644 설정해줘야 한다.

authorized_keys는 public key 값을 저장하는 파일로 remote 서버에 생성하면 된다

HDFS에서는 네임노드가 private key를 가지고 있고

데이터노드가 public key를 가지고 있다고 보면 된다.

추가적으로 확인해야 할 사항이 한가지 더 있다

리눅스 접근 통제(tcpwrapper) 설정이 되어 있으면 허용해줘야 한다

# cat /etc/pam.d/sshd
...
account    required     pam_access.so accessfile=/etc/security/access.conf
...

# cat /etc/security/access.conf
...
-:hadoop:ALL EXCEPT 127.0.0.1 192.168.11.60

# cat /etc/hosts.allow
# cat /etc/hosts.deny

access.conf 파일에서

hadoop 계정으로 접근하는 ip를 허용해준다

더불어서 hosts.allow와 hosts.deny 파일도 체크하고

허용이 필요하면 허용해준다

위의 모든 과정이 끝나면

ssh hadoop@localhost로 비밀번호 없이 접속이 되는지 확인한다

[hadoop@localhost .ssh]$ ssh localhost
Last login: Mon Mar 28 20:12:07 2022 from ip
[hadoop@localhost ~]$

[참고자료]

https://storycompiler.tistory.com/112

https://brunch.co.kr/@sangjinkang/52

https://opentutorials.org/module/432/3742

https://gukii.tistory.com/19

To be continued.........

Made by 꿩

# PostgreSQL Architecture

PostgreSQL = 프로세스 기반의 DBMS

PG는 1개의 connection마다 1개의 backend 프로세스가 생성이 된다.

PostgreSQL의 프로세스 리스트를 보면 다음과 같다.

# ps -ef | grep postgres

postgres 11126     1  0  2021 ?        00:00:55 /home/postgresql/bin/postgres -D /home/postgresql/data
postgres 11129 11126  0  2021 ?        00:00:00 postgres: checkpointer 
postgres 11130 11126  0  2021 ?        00:07:01 postgres: background writer 
postgres 11131 11126  0  2021 ?        00:07:20 postgres: walwriter 
postgres 11132 11126  0  2021 ?        00:00:48 postgres: autovacuum launcher 
postgres 11133 11126  0  2021 ?        00:01:49 postgres: stats collector 
postgres 11134 11126  0  2021 ?        00:00:01 postgres: logical replication launcher 
postgres 12671 11126  0 11:03 ?        00:00:00 postgres: postgres postgres [local] idle
root     11245 11198  0 11:02 pts/0    00:00:00 grep --color=auto postgres

여기서 pid가 11126인 프로세스가 바로 Postmaster 프로세스이다.

PostgreSQL를 구동할 때 가장 먼저 프로세스이다

초기 복구 작업, Shared Memory 초기화, Background 프로세스 구동작업을 수행한다.

만약, 당신이 PG에 접속하고 싶은 경우, 이 프로세스가 Backend 프로세스를 생성해 줄 것이다.

 Backend 프로세스는 여러개가 있다.

checkpointer는 체크 포인트 발생시 dirty 버퍼를 데이터파일에 기록하고,

background writer는 주기적으로 dirty 버퍼를 데이터파일에 기록한다.

wal writer는 데이터 파일의 변경 사항을 로그파일로 기록하는데,

이 wal 파일은 데이터베이스에 대한 모든 조작 기록을 보관하고 있다.

이 파일의 존재 이유는 서버가 갑자기 중지되었을 경우

데이터 파일에 적용하지 못한 작업(checkpoint 작업이 안된)을

이 로그에 읽어서 다시 실행하여 서버에 안전하게 복구하기 위해서이다.

wal 파일을 특정 시점까지만 실행하면, 특정 시점 복구도 할 수 있다.

autovacuum launcher는 자동으로 vacuum 하는 프로세스이며

stats collector는 쿼리 최적화를 위해 통계 정보를 수집하는 프로세스이다.

logical replication launcher는 subscriber의 위치에서 테이블을 싱크해주는 프로세스이고

pid 12671인 프로세스는 local에서 누군가가 pg에 접속해 있다는 말이다.

PostgreSQL의 메모리 사용

PG의 메모리 사용 부분을 보면 Shared Memory 영역이 있다.

그 중 Shared Buffer는 사용자가 요청한 데이터 블록을 저장하는 공간이며 공유 메모리 버퍼이다.

 많은 사용자가 동시에 접근할 때 경합을 최소화하고

자주 사용하는 블록이 최대한 오랫동안 버퍼 내에 있는 영역이다.

결국 Shared Buffer의 목적은 디스크 I/O를 최소화 하는 것이다.

WAL Buffer는 데이터의 변경 사항을 잠시 저장하는 버퍼로

WAL writer 프로세스를 통해 WAL 파일에 기록된다.

PostgreSQL의 데이터 구조

각 DBMS별로 데이터 저장 구조는 다 다르다.

PG에서는 데이터베이스 > 스키마 > 테이블의 형태로 데이터가 분류되며

다음의 그림처럼 데이터가 저장이 된다.

데이터가 저장되는 파일들은 여러 개의 페이지들로 구성되며

하나의 페이지는 일반적으로 8KB를 차지한다.

페이지의 구성요소는 다음과 같다.

Page Header는 24bytes로 기본적인 페이지 정보를 저장하며

Item은 4 bytes로 데이터 시작위치, 크기가 저장된 포인터이다.

Tuple = 데이터 row 한 줄

PG는 MVCC 동시성 제어를 위해 MGA 방식을 사용하는데

만약 update나 delete가 발생할 경우

위의 그림에서 Tuple은 삭제되는게 아니라 더이상 사용하지 않도록 표시가 된다.

추후, VACUUM 작업을 해줘야 해당 Tuple들이 삭제될 것이다.

즉, Update와 Delete가 빈번하게 일어나면

테이블의 크기가 점점 늘어나게 될 것이다.

[참고자료]

https://waspro.tistory.com/146

https://d2.naver.com/helloworld/227936

https://mozi.tistory.com/565

https://dbrang.tistory.com/1579

To be continued.........

Made by 꿩

# MongoDB Sharded Cluster 기본

MongoDB의 sharded cluster를 구성할 때, 3종류의 서버를 알아야한다.

1. mongos(=router)

2. config

3. shard(=replica set)

mongos 서버는 어플리케이션으로부터 쿼리를 받아서 각 샤드로 쿼리를 보내주는 역할이다.

데이터가 저장되어 있진 않고, 말그대로 router 역할을 해주기만 한다.

어플리케이션으로부터 쿼리가 오면 mongos는 config 서버에 메타정보를 요청한다.

이때, 메타정보는 데이터가 저장되어있는 shard 정보 및 sharding key 정보들이다.

만약 그대가 쿼리에 shard key를 고려했다면, mongos는 해당되는 샤드만 접근할 것이다.

mongos는 이러한 정보들을 이용해

특정 replica set에 접근하여 데이터를 요청한다.

각 shard 서버들이 데이터를 주면 mongos는 merge만 한다.

만약 집계와 같이 여러 샤드에서 온 데이터를 병합을 해야한다면,

무작위로 하나의 샤드서버가 선택되어 거기서 모든 데이터가 병합이 된다.

config 서버는 shard들의 메타데이터를 저장하는 서버이다.

메타데이터는 모든 샤드의 chunk 리스트와 chunk의 범위에 대한 정보이다.

mongos서버는 이 데이터를 이용해 적정한 shard에 쿼리를 전달하는데

각 shard들도 config 서버에서 chunk 메타데이터를 읽기도 한다.

shard 서버는 replica set으로 구성되어 있으며 실제 데이터가 저장되는 곳이다.

shard 서버의 데이터는 여러개의 조각으로 파티션되며

이 조각들이 여러 샤드 서버에 분산 저장되는데

이 데이터 조각을 chunk라고 한다.

이 chunk는 각 샤드서버에 균등하게 저장되어야 좋은 성능을 낼 수 있고

한 쪽 샤드에 chunk가 너무 몰려있으면

mongodb 자체적으로 백그라운드로 chunk를 균등하게 balancing 작업을 하기도 한다.

여기서 zone의 개념도 있다.

zone은 shard key에 기반하여 생성하는 것으로

각 샤드의 zone을 설정하여

zone에 포함되는 shard key를 가진 데이터를 저장하도록 유도하는 것이다.

참고로 동일한 zone이 여러 shard에 해당될 수 있고

하나의 shard가 여러 zone을 가질 수 있다.

그리고 각 shard는 replica set으로 구성되어 있는데

보통 primary-secondary-arbiter 혹은 primary-secondary-secondary로 구성된다.

여기서 arbiter는 데이터를 저장하지 않고 오로지 투표 역할만 한다.

이때, replica set은 최소 3개 이상의 홀수개로 구성해야한다.

replica set은 서로 자기들끼리 heartbeat를 보내는데

만약 한서버가 heartbeat를 보내지 않는다면, 죽은 서버로 판단이 된다.

만약 primary가 고장이나면 남은 구성원끼리 투표를 해야하는데

2대뿐이라면 나머지 1대 가지고는 다수결이 안된다.

그리고 남은 1대 secondary는 primary가 되지 못하고 고립된 노드로 남겨진다.

참고로 하나의 replica set은 최대 50개 member를 설정할 수 있으며,

투표 member는 최대 7개밖에 설정할 수 없다.

기본적으로 master-slave로 구성된 서버들은

Write 작업은 master로 Read 작업은 slave로 보내어 부하를 최소화 한다.

MongoDB는 이런 기능이 없을까?

mongo에는 read preference 설정이란게 있다

read 작업을 primary로 할건지 secondary로 보낼지 설정할 수 있다.

디폴트는 primary이다.

당연히 primary로 설정하는게 일관성 측면에서 좋긴 하다.

[참고자료]

MongoDB Document

https://sarc.io/index.php/nosql/1703-mongodb-chunk-1

To be continued.........

Made by 꿩