검색결과 리스트
Database에 해당되는 글 2건
- 2014.08.22 [.NET] Simple.Data (1)
- 2014.01.20 DB 샤딩
글
닷넷 프레임워크 4.0에 도입된 Dynamic 기능을 활용해서 가볍고 동적으로 데이터(DB의)를 접근할 수 있는 컴포넌트
보통
데이터베이스의 데이터를 코드를 쉽게 접근하는 방법으로 ORM 모델을
사용하거나
mini-ORM을 사용하기도 하는데
Simple.Data를 사용하면 코드를 통해서 자동으로 DB 쿼리문이 만들어진다.
오픈소스로 GitHub를 통해서 얻을 수 있다.
https://github.com/markrendle/Simple.Data
public User FindUserByEmail(string email)
{
return Database.Open().Users.FindAllByEmail(email).FirstOrDefault();
}
이 코드는 User 테이블의 Email 필드를 키로 모든 데이터를 가져오는 것이다.
Users.FindAllByEmail은 동적코드로
위의 Database.Open().Users.FindAllByEmail(email).FirstOrDefault();
ADO.NET 코드로 표현하면 아래와 같다.
public User FindUserByEmail(string email)
{
User user = null;
using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["Default"].ConnectionString))
using (var command = new SqlCommand("select id, email, hashed_password,
salt from users where email = @email", connection))
{
command.Parameters.Add("@email", SqlDbType.NVarChar, 50).Value = form.Email);
connection.Open();
using (var reader = command.ExecuteReader())
{
if (reader.Read())
{
user = new User { Id = reader.GetInt32(0), Email = reader.GetString(1),
Password = reader.GetString(2), salt = reader.GetString(3)};
}
}
}
return user;
}
Simple.Data를 사용하면 위의 코드가 아래의 단 한줄로 끝난다 !!!
Database.Open().Users.FindAllByEmail(email).FirstOrDefault();
지원하는 데이터베이스
ADO-based access to relational databases, with providers for:
SQL Server 2005 and later (including SQL Azure)
SQL Server Compact Edition 4.0
Oracle
MySQL 4.0 and later
SQLite
PostgreSQL
SQLAnywhere
Informix
MongoDB
OData
SimpleData에 대해서 더 자세히 알고 싶다면 아래의 문서를 참고한다.
http://simplefx.org/simpledata/docs/
MongoDB
MongoDB는 Simple.Data.MongoDB 라고 따로 분리 되어 있다.
https://github.com/craiggwilson/Simple.Data.MongoDB
주의 사항
1. 몽고디비 컬렉션의 컬럼 이름이 ID 이면 안된다.
이유는 기본으로 몽고디비는 컬렉션에 문서를 만들 때 _id 컬럼을 만드는데 우리가 ID 컬럼을 만들면 Simple.Data.MongoDB에서 이름을 부여할 때 중복된다. -_-
2. 쿼리를 하면 모든 컬럼 값을 다 가져온다. 일부만 가져올 수 없다.
Cast도 그냥 정적 클래스(혹은 구조체)에 담아주는 것이지 일부 컬럼만 가져오는 것이 아님
글
Sharding(샤딩)
- DB 확장성을 위해 장비 업그레이드를 통해서 Scale-Up을 해서 병목을 피해감.
- Scale-Up을 통해서도 병목을 피할 수 없을 경우 Scale-Out을 해야 한다. Scale-Otu의 기술 중 하나 Sharding 이다.
- 샤딩은 데이터베이스가 저장하고 있는 테이블을 테이블 단위로 분리하는 방법(수직 샤딩)과 테이블 자체를 분할 하는 방법(수평 샤딩)이 있다.
- 수직 샤딩에서는 테이블 하나를 서로 다른 column을 가진 테이블로 나누는 방법도 있다.
- 수평 샤딩을 하면 샤딩 이후 DB를 증가 시킬 때 마다 데이터 재분배를 해야 한다.
- SELECT 작업을 할 때 마다 샤드한 테이블 모두를 검색해야 하기 때문에 통계 작업 등에서 꽤 골치 아픔
- 이 부분을 자동으로 해 주는 미들웨어가 있으면 좋음
- 수직 샤딩은 각 테이블 별로 데이터가 잘 나누어지지 않고 한쪽으로 집중되면 샤딩의 의미가 약해진다
- 샤딩의 특징
- 성능 개선
- 신뢰성 개선
- 위치 추상화
- 샤딩은 안하면 안 할 수록 좋다!!!
- 최대한 데이터 구조 개선이나 Scale-Up을 통해서 샤딩을 하지 않는 것이 좋다. 복잡성 증가를 피하기 위해
- 샤딩 이전에 memchaced나 Redis를 통해서 성능 개선을 한다
- 샤딩을 해야 한다면 수직 샤딩을 먼저 시도해 본다.
- 마지막으로 수평 샤딩을 한다.
사례-MongoDB의 샤딩
- 자동 샤딩을 할 수 있다.
- 그러나 DB 요청이 아주 많을 때 라우팅 역할을 하는 서버에 병목이 발생할 수 있다.
- 버전 업 주기가 짧고 버전 업이 될 때 마다 성능 및 기능 개선이 있으므로 언제나 최신 버전을 기준으로 확인 해봐야 한다
- 웹이나 주위의 이전 버전 기준의 이야기를 그대로 들으면 안된다!!!
사례-MasterDB 방식의 샤딩
- MasterDB의 맵핑 테이블을 사용하여 유저마다 사용할 shard를 나누어서 분산하는 방법
- 유저 로그인 시 맵핑 테이블을 조회하면 어디에 있는지 알 수 있음
- AUTO_INCREMENT 값도 맵핑 테이블에서 관리. 샤드마다 중복 값이 생기지 않음
- 데이터 재분배 시 맵팅 테이블을 사용
사례-인스타그램의 샤딩
SQL- Spider fo MySQL을 사용한 샤딩
- 서로 다른 MySQL 인스턴스 테이블을 동일 인스턴스 테이블과 같이 다룰 수 있다.
- xa 트랜잭션을 포함한 트랜잭션을 지원하기 때문에 갱신계 DB 클라스터링으로 이용 할 수 있다
- 테이블 파티션을 지원하고 있기 때문에 파티션 룰을 이용하여 동일 테이블의 데이터를 복수의 서버에 분산 배치 할 수 있다
- spider 스토리지 엔진 테이블을 만들면 MySQL 내부에서는 파일로의 심볼릭 링크 같이 하여 리모트 서버 테이블에 테이블 링크를 생성한다
- 링크처의 테이블 스토리지 엔진에 제한이 없다
- 사용 방법
댓글
하하 ;;;
재미있는 발상이군요