728x90
반응형
728x90
반응형
반응형

pgloader : MySQL, Oracle 등 다양한 데이터베이스를 PostgreSQL로 자동 이관


1. 개요

  • 자체 구축한 데이터베이스(MySQL, SQLite, Oracle 등)를 PostgreSQL로 자동 이관하는 것은 시스템 현대화나 통합 작업에서 매우 중요한 단계입니다.
  • 이를 효율적으로 수행하기 위해 다양한 도구가 존재하는데, 이 중 pgloader 는 오픈소스이면서도 매우 강력한 기능을 제공하여 주목받고 있습니다.
  • 본 글에서는 pgloader를 중심으로 데이터베이스 자동 이관 방법을 자세히 살펴봅니다.


2. pgloader

  • pgloader 는 다양한 데이터베이스를 PostgreSQL로 이관하는 데 최적화된 오픈소스 도구입니다.

  • Common Lisp 언어로 개발되었으며, PostgreSQL 라이선스를 따르는 자유 소프트웨어입니다. 주요 특징은 다음과 같습니다.

    • 스키마 변환, 데이터 복사, 데이터 타입 자동 변환을 지원합니다.
    • 대규모 데이터에 대해서도 병렬 처리를 통해 빠른 이관이 가능합니다.
    • 네트워크 오류 발생 시 Resume 기능을 통해 복구가 가능합니다.
    • 명령어 기반 또는 스크립트 파일(.load) 기반으로 유연하게 이관 작업을 관리할 수 있습니다.
  • 단, pgloaderPostgreSQL로만 이관할 수 있으며, PostgreSQL에서 다른 DBMS로 이관하는 것은 지원하지 않습니다.



3. pgloader가 지원하는 소스 데이터베이스

  • pgloader가 지원하는 주요 소스는 다음과 같습니다.

  • 소스 DBMS 지원 여부 비고
    MySQL 매우 안정적
    SQLite 간단한 파일 기반 이관 가능
    MS SQL Server ODBC 경유
    CSV 파일 파일 직접 이관 가능
    DBF 파일 구형 포맷 지원
    고정폭 텍스트 파일
  • Oracle의 경우, 별도 설명이 필요한데 이는 뒤에서 다루겠습니다.



4. pgloader 사용 방법

4.1 설치 방법

  • Ubuntu, bash

      sudo apt install pgloader
    
  • macOS, bash

      brew install pgloader
    
  • Windows:

    • Windows에서는 공식 지원이 없으므로 WSL 또는 Docker를 통해 사용합니다.

4.2 기본 사용법

  • MySQL에서 PostgreSQL로 이관하는 기본 명령어는 다음과 같습니다.

  • bash

      pgloader \
       mysql://[mysql_user]:[mysql_password]@[mysql_host]:[mysql_port]/[mysql_dbname] \
       postgresql://[pg_user]:[pg_password]@[pg_host]:[pg_port]/[pg_dbname]
    
  • 예시

      pgloader \
       mysql://root:password@localhost:3306/mydb \
       postgresql://postgres:pgpassword@localhost:5432/mydb
    
  • 또는 .load 파일을 작성해 스크립트 기반으로 관리할 수도 있습니다.


4.3 주요 기능

  • 스키마 변환: 테이블, 컬럼, 데이터 타입 자동 변환
  • 데이터 복사: 대용량 데이터 병렬 복사
  • 에러 복구: 중단 시 이어서 복구
  • 최적화: 데이터 입력 시 COPY 명령어를 사용하여 성능 향상
  • 스크립트화: 이관 과정을 코드로 관리 가능


5. pgloader를 사용할 때 주의사항

  • 데이터 타입 변환 : 예를 들어, MySQLTINYINT(1)PostgreSQL에서는 BOOLEAN으로 변환됩니다.
  • AUTO_INCREMENT : PostgreSQL에서는 SERIAL 또는 IDENTITY 컬럼으로 변환됩니다.
  • 인코딩 차이 : MySQLutf8mb4, PostgreSQLUTF8을 사용합니다.
  • 트리거, 저장 프로시저 : 기본 이관 대상이 아닙니다. 수작업 변환 필요합니다.
  • 외래키 제약조건 : 필요에 따라 이관 시점 조정 가능 (WITH include drop 옵션 사용 등).


6. Oracle 데이터베이스를 pgloader로 이관하는 경우

  • Oracle 데이터베이스를 pgloader로 이관하는 것은 기본적으로 지원되지 않습니다.
  • 그러나 ODBC 드라이버를 이용한 우회 방법이 존재합니다.

6.1 ODBC를 통한 이관

  • (1) Oracle Instant Client 설치
  • (2) Oracle ODBC 드라이버 설치
  • (3) /etc/odbcinst.ini, /etc/odbc.ini 파일에 Oracle DSN 설정
  • (4) pgloaderODBC 연결을 통해 Oracle에 접근하여 PostgreSQL로 이관

  • 예시:

      pgloader \ 
       odbc://oracle_dsn \
       postgresql://pguser:pgpassword@localhost/pgdb
    
  • 또는 .load 파일:

      LOAD DATABASE
        FROM odbc://oracle_dsn
        INTO postgresql://pguser:pgpassword@localhost/pgdb
      WITH include drop, create tables, create indexes, reset sequences
      SET work_mem to '128MB', maintenance_work_mem to '512 MB';
    

6.2 Oracle 이관시 주의사항

  • NUMBER, CLOB, BLOB 등의 데이터 타입 변환에 주의가 필요합니다.
  • 시퀀스와 트리거 변환이 수작업을 요구할 수 있습니다.
  • 저장 프로시저(PL/SQL)는 PostgreSQLPL/pgSQL 문법에 맞게 직접 변환해야 합니다.
  • 대규모 데이터 이관 시: ODBC를 통한 속도 저하가 발생할 수 있습니다.


7. Oracle 이관에 대한 대안: ora2pg

  • Oracle 데이터베이스를 PostgreSQL로 이관할 때는 pgloader 대신 ora2pg라는 전문 툴을 사용하는 것이 더 일반적입니다.

  • ora2pg 특징:

    • Oracle 스키마를 분석하여 PostgreSQL에 최적화된 스크립트로 변환
    • 트리거, 저장 프로시저 등도 일부 자동 변환
    • 대규모 데이터도 효율적으로 이관 가능
  • 설치 예시:

      sudo apt install ora2pg
    
  • ora2pg를 활용하면 훨씬 안정적으로 Oracle → PostgreSQL 이관이 가능합니다.



8. 요약

  • MySQL, SQLite, MS SQL, CSV 파일 등은 pgloader 를 통해 매우 쉽게 PostgreSQL로 이관할 수 있습니다.
  • Oracle의 경우, pgloader를 사용하려면 ODBC 설정 이 필요하며, 복잡한 이관은 ora2pg 를 사용하는 것이 더 효과적입니다.
  • 이관 시 데이터 타입, 제약조건, 저장 프로시저 등은 주의 깊게 검토하고 테스트하는 것이 매우 중요합니다.

  • 데이터베이스 이관은 단순한 복사가 아니라, 대상 시스템(PostgreSQL)의 특성에 맞춘 최적화 과정 이 동반되어야 한다는 점을 항상 염두에 두어야 합니다.



  • 도움이 되셨으면 하단의 ❤️ 공감 버튼 부탁 드립니다. 감사합니다! 😄
  • 일부 모바일 환경에서는 ❤️ 버튼이 보이지 않습니다.

728x90
반응형
반응형

SQL 인젝션 (SQL Injection)

SQL 인젝션(SQL Injection) 은 공격자가 웹 애플리케이션의 데이터베이스 쿼리를 조작하여 민감한 정보를 탈취하거나 시스템을 손상시키는 보안 취약점입니다.

SQL 인젝션은 잘못된 입력 검증으로 인해 발생하며, 가장 심각한 보안 위협 중 하나로 알려져 있습니다.


SQL 인젝션의 동작 원리

  • 공격자가 SQL 쿼리를 조작할 수 있는 입력값(예: URL, 폼, 쿠키)을 이용.
  • 애플리케이션이 공격자의 입력값을 그대로 SQL 쿼리에 포함시키는 경우, 데이터베이스의 무단 접근, 데이터 조작, 시스템 손상이 가능.

SQL 인젝션의 주요 유형

  1. 클래식 SQL 인젝션 (Classic SQL Injection)

    • 일반적인 쿼리 조작으로 데이터베이스를 공격.
    • 예시:

      sql

      SELECT * FROM users WHERE username = 'admin' AND password = '';
      
      공격 입력: admin' OR '1'='1
      실행 쿼리:

      sql

      SELECT * FROM users WHERE username = 'admin' OR '1'='1';
      
      결과: 조건이 항상 참이 되어 무단 로그인 성공.
  2. 블라인드 SQL 인젝션 (Blind SQL Injection)

    • 데이터베이스 결과를 직접 확인할 수 없지만, 참/거짓 기반의 응답을 이용.
    • 예시:

      sql

      SELECT * FROM users WHERE id = 1 AND 1=1; -- 참  
      SELECT * FROM users WHERE id = 1 AND 1=2; -- 거짓
      
  3. 에러 기반 SQL 인젝션 (Error-based SQL Injection)

    • 데이터베이스 에러 메시지를 통해 정보를 유출.
    • 예시: UNION SELECT null, @@version;
      결과: 데이터베이스 버전이 노출됨.
  4. UNION 기반 SQL 인젝션 (Union-based SQL Injection)

    • UNION 명령어를 이용해 추가적인 쿼리 결과를 결합.
    • 예시:

      sql

      SELECT name, email FROM users UNION SELECT username, password FROM admin;
      
  5. 타임 기반 SQL 인젝션 (Time-based SQL Injection)

    • 데이터베이스 응답 시간이 느려지는 것을 이용하여 정보를 유출.
    • 예시:

      sql

      SELECT IF(1=1, SLEEP(5), NULL);
      

SQL 인젝션의 주요 피해

  1. 데이터 유출: 사용자의 개인정보, 계정 정보, 민감 데이터 탈취.
  2. 데이터 변경: 데이터베이스 내용 삭제, 수정.
  3. 무단 접근: 관리자 계정 도용을 통한 시스템 제어.
  4. 서비스 중단: 데이터베이스 손상으로 인한 장애 발생.
  5. 백도어 설치: 악성 명령어를 데이터베이스에 삽입하여 추가 공격 수행.

SQL 인젝션 예방 방법

  1. Prepared Statement (사전 준비된 쿼리)

    • 파라미터화된 쿼리를 사용하여 입력값을 별도로 처리.
    • 예시 (Python + MySQL):

      python

      cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))
      
  2. ORM 사용

    • Hibernate, Django ORM 등 SQL 쿼리를 직접 작성하지 않고 안전하게 데이터베이스 처리.
  3. 입력값 검증(Input Validation)

    • 사용자 입력을 철저히 검증하여 허용된 데이터만 처리.
    • 예: 숫자만 필요한 필드에 문자 입력 차단.
  4. 출력값 인코딩(Output Encoding)

    • 데이터베이스 결과값을 안전하게 렌더링.
  5. 최소 권한 부여

    • 데이터베이스 사용자 계정에 최소한의 권한만 부여.
  6. 에러 메시지 노출 금지

    • 클라이언트에 상세한 SQL 에러 정보를 숨김.
  7. 웹 방화벽 사용

    • WAF(Web Application Firewall)를 통해 악성 요청 차단.

SQL 인젝션은 입력값을 신뢰하지 않고 적절히 검증하거나, 안전한 쿼리 작성을 통해 예방할 수 있습니다.

모든 데이터베이스와 연동된 애플리케이션에서 철저히 관리해야 합니다.

728x90
반응형
반응형

SQLite 암호화 방식: OFB 모드와 CCM 모드의 차이점

SQLite 암호화 확장에서 사용할 수 있는 OFBCCM 모드는 AES 암호화의 두 가지 모드입니다. 각 모드는 다른 목적과 특성을 가지며, SQLite Encryption Extension(SEE) 또는 SQLCipher와 같은 암호화 확장에서 사용될 수 있습니다.

1. OFB 모드 (Output Feedback Mode)

  • 특징: OFB 모드는 암호 블록을 직접 암호화하지 않고, 초기화 벡터(IV)와 이전 암호화 블록을 이용해 암호화 스트림을 생성하는 방식입니다.
  • 동작 방식:
    • AES 암호화 알고리즘을 사용하여 IV를 암호화하고, 그 결과를 XOR 연산을 통해 평문에 적용하여 암호문을 생성합니다.
    • 이전 암호화 블록의 출력이 다음 블록의 입력으로 사용되며, 반복적으로 새로운 암호화 스트림을 생성합니다.
  • 장점:
    • 비트 단위 오류 전파가 없고, 병렬 처리가 가능합니다.
    • 암호화/복호화 속도가 빠릅니다.
  • 단점:
    • IV가 동일하면 동일한 암호화 스트림이 생성되므로 IV를 고유하게 설정해야 합니다.
  • 사용 예시: 대규모 데이터를 일정한 속도로 암호화하는 경우에 적합합니다. 데이터베이스에서도 빠른 암호화/복호화가 필요할 때 사용될 수 있습니다.

2. CCM 모드 (Counter with CBC-MAC Mode)

  • 특징: CCM은 암호화와 동시에 무결성 검사를 제공하는 Authenticated Encryption 모드입니다. 암호화와 메시지 인증 코드(MAC)를 결합하여 데이터가 위변조되지 않았음을 보장합니다.
  • 동작 방식:
    • 데이터를 암호화하기 전에 Counter 모드(AES-CTR)를 통해 암호화하고, 동시에 CBC-MAC 모드를 사용해 메시지의 인증 태그를 생성합니다.
    • 암호화된 데이터와 인증 태그를 함께 저장하여, 복호화 시 데이터의 무결성을 검사합니다.
  • 장점:
    • 무결성 검사 기능이 포함되어 있어 데이터가 중간에 위변조되지 않았음을 보장합니다.
    • 높은 보안성을 제공합니다.
  • 단점:
    • 일반적인 암호화보다 복잡하여 속도가 느릴 수 있으며, 병렬 처리에는 적합하지 않습니다.
  • 사용 예시: 보안이 특히 중요한 환경에서 데이터 무결성이 요구되는 경우에 사용됩니다. 데이터베이스에서 데이터의 기밀성과 무결성을 동시에 보장해야 할 때 유용합니다.

요약

  • OFB 모드는 간단하고 빠르며 데이터의 기밀성을 제공하는데 적합하지만 무결성은 보장하지 않습니다.
  • CCM 모드는 암호화와 무결성 검사를 동시에 제공하여 보안성을 강화하지만, 상대적으로 복잡하고 속도가 느릴 수 있습니다.

SQLite에서 SEE나 SQLCipher와 같은 확장을 통해 이들 암호화 모드를 사용할 수 있습니다. 사용 목적과 보안 요구사항에 맞추어 적절한 모드를 선택하면 됩니다.

728x90
반응형
반응형

SQLite 암호화 SQLCipher : 특징, 빌드, 적용 가이드

1. SQLCipher는 왜 필요한가?

  • 데이터베이스는 많은 애플리케이션에서 핵심 역할을 하지만, 민감한 정보를 담고 있을 경우 무단 접근 시 치명적인 문제가 발생할 수 있습니다.
  • 특히 모바일 앱, IoT 기기, 또는 로컬 파일로 저장되는 데이터베이스는 물리적 복제나 탈취 위험이 큽니다.

  • SQLCipher 는 이러한 위험을 해결해 주는 SQLite 기반 데이터베이스 전체 암호화 솔루션 입니다.
  • SQLite의 가벼움과 투명성을 유지하면서, AES-256 암호화 기술을 적용하여 저장 데이터를 보호합니다.


2. SQLCipher 주요 특징

  • AES-256 비트 암호화 : 데이터베이스 전체 파일을 암호화합니다.
  • SQLite API와 완벽 호환 : 기존 SQLite 프로젝트에 손쉽게 적용 가능합니다.
  • PBKDF2 키 스트레칭 : 무차별 대입 공격에 강한 암호화 키 파생 기법 적용.
  • 멀티 플랫폼 지원 : iOS, Android, Windows, macOS, Linux 환경에서 사용 가능.
  • 가벼운 설치 및 유연한 빌드 : 다양한 환경에서 쉽게 컴파일 및 적용 가능.


✅ 3. 라이선스 및 상업적 사용

  • SQLCipherBSD-3-Clause 라이선스 로 배포됩니다.
  • 기업 및 상업 프로젝트에서도 무료로 사용 및 배포가 가능합니다만, 다음 조건을 지켜야 합니다:
    • 저작권 및 라이선스 고지 포함
    • 저작권 표시 유지
    • 보증 면책 조항 포함
  • 다만, 법적 확약이 필요하거나 상업용 지원, 기술 컨설팅, SLA 서비스 등이 필요한 경우,
    • Zetetic (SQLCipher 개발사)에서 유료 라이선스 및 지원 계약(연간 약 $6,000 USD부터)을 체결할 수 있습니다.


✅ 4. SQLCipher 빌드 방법 (Linux/macOS/Windows)

4.1. Linux/macOS 빌드

  • bash

      # 빌드 도구 준비 (Ubuntu 인 경우)
      sudo apt-get install tcl autoconf automake libtool
      
      # SQLCipher 소스 코드 얻기
      git clone https://github.com/sqlcipher/sqlcipher.git
      
      # 빌드 및 설치
      cd sqlcipher
      ./configure --enable-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC" LDFLAGS="-lcrypto"
      make
      sudo make install
    

4.2. Windows 빌드 방법

  • A. 준비
    • Visual Studio (C++ 개발 도구 포함)
    • ActiveState Tcl (또는 다른 Tcl 배포판)
    • OpenSSL 빌드 또는 prebuilt 라이브러리
    • SQLCipher 소스
  • B. 빌드 순서
      1. 필요한 라이브러리 준비
      • OpenSSL Windows prebuilt 버전을 다운로드하여 libinclude 경로 준비
      1. SQLCipher 소스 다운로드
      • bash

          git clone https://github.com/sqlcipher/sqlcipher.git
        
      1. 명령 프롬프트(또는 PowerShell)에서 nmake 사용 준비
      • Visual Studio 개발자 명령 프롬프트 실행
      1. 환경 변수 설정
      • cmd

          set PATH=C:\Path\To\OpenSSL\bin;%PATH%
          set INCLUDE=C:\Path\To\OpenSSL\include;%INCLUDE%
          set LIB=C:\Path\To\OpenSSL\lib;%LIB%
        
      1. 빌드 실행
      • cmd

          cd sqlcipher
          nmake -f Makefile.msc
        
      1. 빌드 결과
      • sqlcipher.exe 실행 파일 및 관련 라이브러리(sqlite3.dll, sqlite3.lib) 생성
  • C. Visual Studio IDE로 빌드
    • sqlite3.csqlite3.h(sqlcipher 소스코드 포함)를 Visual Studio 프로젝트에 추가
    • C/C++ > Preprocessor 설정에 SQLITE_HAS_CODEC 추가
    • C/C++ > Additional Include Directories에 OpenSSL include 경로 추가
    • Linker > Additional Library Directories에 OpenSSL lib 경로 추가
    • Linker > Input > Additional Dependencieslibcrypto.lib 추가
    • 빌드 실행 후 생성된 .dll.libexe 파일 사용


5. 암호 키 설정 및 변경 방법

  • 초기 암호 설정
    • sql

        PRAGMA key = '암호';
      

  • 암호 변경
    • sql

        PRAGMA rekey = '새로운암호';
      

주의: rekey는 기존 암호가 올바르게 적용된 상태에서만 성공합니다.



6. iOS 적용 방법

6.1. Podfile에 의존성 추가

  • ruby

      pod 'SQLCipher', '~> 4.5'
    

6.2. 설치

  • bash

      pod install
    

6.3. Swift 코드 예제

  • swift

      import SQLite3
      
      var db: OpaquePointer?
      if sqlite3_open("경로/데이터베이스.db", &db) == SQLITE_OK {
          let key = "암호"
          sqlite3_key(db, key, Int32(key.utf8.count))
          if sqlite3_exec(db, "SELECT count(*) FROM sqlite_master;", nil, nil, nil) == SQLITE_OK {
              print("암호 적용 및 열기 성공")
          }
      }
    


✅ 7. Android 적용 방법

7.1. build.gradle 의존성 추가

  • gradle

       dependencies {
           implementation 'net.zetetic:android-database-sqlcipher:4.5.6@aar'
       }
    

7.2. ProGuard 설정

  • proguard

      -keep class net.sqlcipher.** { *; }
    

7.3. Java 코드 예제

  • java

      SQLiteDatabase.loadLibs(context);
      SQLiteDatabase db = SQLiteDatabase.openOrCreateDatabase(databaseFile, "암호", null);
      db.execSQL("CREATE TABLE IF NOT EXISTS test (id INTEGER PRIMARY KEY, name TEXT);");
      db.close();
    


8. 요약

  • SQLCipher는 민감한 데이터를 안전하게 보호하면서도 SQLite의 장점을 그대로 가져올 수 있는 강력한 도구입니다.
  • 기업 및 개인 개발자 모두 자유롭게 사용할 수 있으며, 필요 시 상업용 라이선스를 통한 안정적인 지원도 가능합니다.
  • 직접 빌드와 적용 과정도 비교적 간단하며, iOSAndroid에서의 통합 또한 공식 라이브러리로 잘 지원됩니다.



  • 도움이 되셨으면 하단의 ❤️ 공감 버튼 부탁 드립니다. 감사합니다! 😄
  • 일부 모바일 환경에서는 ❤️ 버튼이 보이지 않습니다.

728x90
반응형
반응형

https://github.com/dbcli


dbcli
Better CLIs for Databases

 

 

728x90
반응형
반응형

NoSQL 주요 DB 비교: CouchDB와 MongoDB의 차이점과 활용성

NoSQL 분야에서 주요한 두 가지인 CouchDB와 MongoDB는 용도에 따라 여러 차이점이 있습니다. MongoDB는 전통적인 DB의 락 모델을 따르는 반면, CouchDB는 MVCC 기반의 클러스터 기능을 지향합니다. CouchDB는 MongoDB에 비해 처리 속도가 느리다는 평이 있지만, 사용 환경에 따라 평가가 달라질 수 있습니다. MongoDB는 C++과 Boost를 활용해 개발된 반면, CouchDB는 Erlang으로 개발되었습니다.

두 DB 모두 클러스터와 복제 기능을 지원해 클라우드 환경에 적합합니다. MongoDB는 문서화에도 집중하고 있으며, CouchDB는 Memcached 기능을 포함한 Couchbase로 발전했습니다. 국내 오픈 소스 투자 업체로는 NHN과 Daum이 있으며, MongoDB와 CouchDB는 초보자들이 관심을 가져볼 만한 국내에서도 활용 가능한 오픈 소스 그룹입니다.

728x90
반응형
반응형

 

Membase 서버의 기본 네트워크 소켓 포트

Port

Purpose

Membase Server

Membase Client

Administration Client

8091

Web Administration Port

Yes

No

Yes

11211

Data Port

Yes

Yes

Yes

11210

Internal Cluster Port

Yes

No

No

4369

Erlang Port Mapper (epmd)

Yes

No

No

21100 to 21199 (inclusive)

Node data exchange

Yes

No

No

 

… 결론부터 이야기하면, 설정할 때는 8091 포트로 웹 브라우저에 의한 설정이 필요하지만, 어느 정도 구성 후에는 memcached default port 이기도 한 11211 포트로 소켓 통신을 하면 된다.

728x90
반응형
반응형

 

(원문 : http://www.couchbase.org/wiki/display/membase/Building+Membase+on+Linux+From+Source)

(글 번역도 영어이고, 쓸데없는 내용도 많기에 중간 생략을 하며, 편의상 글도 높임말보다 이래하기 편한 평문으로 구성한다.)

 

membase 는 couchbase 에서 지원하는 memcached의 cluster 버전이다. 라이선스는 현재 아파치 2 라이선스를 적용 중이다. Couchdb 와의 기능을 써도 되지만 안 써도 되는 구조이며, couchbase에서 제시하는 이상적인 사용 전략은 당연히 RDMS à NoSQL à CouchDB 와 cluster/middleware à Membase 이다. 하지만 사용자 취향과 능력에 따라 섞어 짬뽕으로 써도 된다. 실제 membase 의 스폰서 중하나인 nhn도 자체 memcached 클러스터 버전인 arcurs 등을 개발하여 사용한다.

설치본은 community 용은 무료로 설치본을 제공하며, 기업용은 연락처 제시 후 다운로드가 가능하다. 기본 지원으로 redhat rpm, debian deb, windows, mac os x 를 지원한다. (http://www.couchbase.com/downloads/membase-server/community)

물론 소스 코드를 받아서 직접 빌드도 가능하며, 아래는 직접 빌드 방법을 기술한다.

일단 다운로드 싸이트에서 membase-server_src-1.7.0.tar.gz 를 받는다. (현재 1.7임. 1.6.x 도 존재한다.)

 (1) Ubuntu Ubuntu 11.04 사용 시,

# sudo apt-get install erlang libicu-dev libevent-dev libcurl3-dev g++ gcc binutils

…로 필요한 것을 설치함. Couch 계열이 기반 언어가 얼랭이며, memcached를 위해서 libevent는 필요하다. Curl 도 사용하므로 설치 해준다.

 (기본 설치는 /opt/membase/ 에 설치된다.)

(2) Cent OS 5.4 사용 시,

# yum install libevent-devel curl-devel gcc-c++ g++ gcc make

…얼랭 없으면 그것도 설치할 것…

(3) Mac os x

….요건 좀 짜증나는 해설인데,, 거의 알아서 깔아야 한다. MacPorts 등을 이용해서 설치를 하는 방법도 있을 것 같다. (이건 실험 못 해봤음)

(여담으로 본햏도 snow leopard 를 사용하지만, 누가 대용량 서버에 가격대 성능비가 비싼 애플 서버로 도배하것는가?! 99.9%는 리눅스 서버에서 사용할 목적일 것이다. 맥에서 빌드는 그냥 nothing but mac 인 사람에게만 해당된다고 보면 될 듯하다. 이것도 기냥 설치본[기냥 단일 응용 프로그램이다.]을 받아서 깔아서 테스트해보라…)

http://packages.couchbase.com/releases/1.7.0/Membase-Server-Community-1.7.0.zip

 (4) Windows

…mingw, cygwin 등이 먼소리인지도 모르겠다면, 당연히 pre-built 버전을 받아서 설치하라.

http://packages.couchbase.com/releases/1.7.0/membase-server-community_x86_1.7.0.setup.exe

(백신 v3가 있으면 경고를 띄우는데, 신경쓰지 말고 진행하도록 하자 K )

membase는 cluster 와 databse 연동 등도 고려한 구조이기에 memcached 보다는 휠씬 구성이 복잡하다. 따라서 빌드 & 설치가 어려운 사람은 community 버전 것으로 설치하도록 하자.

정상설치 후, 웹 브라우저로 http://서버주소:8091 를 연결하면 membase 구성이 가능하다. 단일 구성도 가능하고, 클러스터 구성도 가능하다. 또한 기존 memcached 만을 사용하는 것도 가능하고, membase 의 주요 컨셉 중 하나인 vBucket 구성도 가능하다. 취향에 맞춰서 구성하도록 하자.

설치 후 테스트는 아래과 같이 텔넷에서 입력 후, 출력도 아래와 같이 나오는 지를 확인해 보면 된다.

$ telnet localhost 11211

set some_greeting 0 0 5

hello

STORED

get some_greeting

VALUE some_greeting 0 5

hello

END

모든 과정이 끝났으면, 이젠 membase 만의 고유 architecture 이해와 클라이언트 개발 방법(전략 및 api )이해로 넘어가면 된다…


728x90
반응형
반응형

SQLite의 장점과 단점: 간단한 데이터베이스 관리 솔루션

SQLite는 가벼운 파일 기반 데이터베이스 관리 시스템으로, 주로 소규모 애플리케이션이나 임베디드 시스템에서 자주 사용됩니다. 배포가 용이하고, 외부 DBMS나 별도 라이브러리 설치가 필요 없어 독립적으로 사용할 수 있다는 것이 주된 장점입니다. 이러한 특성 덕분에 모바일 애플리케이션 개발, 소규모 데이터 관리 등에서 인기를 끌고 있습니다.

SQLite의 주요 장점

  • 컴포넌트 독립성: 외부 DBMS가 필요 없으므로 배포와 설치가 간단합니다.
  • 경량성: 파일 기반 DB로 작동하기 때문에 메모리와 리소스 소비가 적어 작은 규모의 프로젝트에 적합합니다.
  • 빠른 속도: 간단한 CRUD 작업에서는 높은 성능을 보입니다.

SQLite의 한계점

  • 기능 제한: 고급 SQL 기능 (예: 아우터 조인 등)이 부족해 복잡한 쿼리 작성에 한계가 있습니다.
  • 동시성 처리의 한계: 다중 사용자 환경에서의 동시성 처리 성능이 부족하여 대규모 시스템에서는 적합하지 않습니다.

추가 의견

SQLite는 단일 사용자 환경이나 로컬 데이터베이스 관리가 필요한 프로젝트에 적합합니다. 반면, 복잡한 데이터 구조나 동시성 처리가 중요한 시스템에서는 MySQL, PostgreSQL 같은 풀-DBMS를 고려하는 것이 좋습니다.

728x90
반응형
반응형

MySQL 백업 / 복구

MySQL 데이터베이스 백업

  • mysqldump -h서버 -u사용자 -p암호 [백업할 테이터베이스 이름] > [저장할 파일 이름(*.sql )]
mysqldump -hlocalhost -uroot -ppassword testdb1 > testdb1-2007-06-27.sql

MySQL 테이블 백업

  • mysqldump -h서버 -u사용자 -p암호 [테이타베이스] [백업할 테이블 이름] > [저장할 파일 이름(*.sql)]
mysqldump -hlocalhost -uroot -ppassword testdb1 tbl1 > testdb1-tbl1-2007-06-27.sql

MySQL 데이터베이스 복구

  • mysql -h서버 -u사용자 -p암호 [복구할 테이터베이스] < [저장된 파일]
mysql -hlocalhost -uroot -ppassword testdb1 < testdb1-2007-06-27.sql
728x90
반응형
반응형

SQL 내부 조인 사용법 비교: T-SQL vs 표준 SQL

SQL에서 여러 테이블을 결합하여 데이터를 조회할 때 내부 조인(inner join)은 필수적인 기능입니다. 여기서는 T-SQL 방식과 표준 SQL 방식의 내부 조인 문법을 비교하고, 표준 SQL 방식이 권장되는 이유를 살펴봅니다.

1. T-SQL 방식

T-SQL에서는 여러 테이블을 콤마(,)로 나열하고, WHERE 절에서 테이블 간의 조건을 지정하여 조인을 수행합니다.

sql

SELECT * 
FROM tbl1, tbl2, tbl3 
WHERE tbl1.f1 = tbl2.f1 AND tbl1.f1 = tbl3.f1;

위 예제에서는 tbl1, tbl2, tbl3f1 필드 값이 동일한 레코드들만 결과로 반환됩니다.

2. 표준 SQL 방식

표준 SQL에서는 INNER JOIN 문법을 통해 테이블 간의 관계를 명시적으로 나타냅니다. ON 절을 사용해 테이블 간 조인 조건을 지정하는 방식입니다.

sql

SELECT * 
FROM tbl1 
INNER JOIN tbl2 ON tbl1.f1 = tbl2.f1 
INNER JOIN tbl3 ON tbl1.f1 = tbl3.f1;

이 방식은 구조적으로 명확하여 읽기 쉬우며, 표준 SQL 문법을 준수합니다.

결론

두 방식은 동일한 결과를 반환하지만, 가독성과 유지 보수 측면에서 표준 SQL의 INNER JOIN 문법을 사용하는 것이 권장됩니다. 표준 SQL은 여러 DBMS에서도 일관성 있게 동작하여 범용적입니다.

728x90
반응형

+ Recent posts