3 백만 개의 제품에 대한 기본 정보를 저장해야합니다. 현재 정보는 180MB CSV이며 분기별로 업데이트됩니다.
하루에 약 30,000 개의 쿼리가 있지만 쿼리는 매우 간단한 키 값 저장소입니다. 제품 ID 만 찾아 나머지 정보 (모두 하나의 레코드에 있음) 만 표시하면됩니다.
이것은 웹용이므로 빠른 성능이 중요합니다.
관계형 데이터베이스가 실제로 필요하지 않더라도 MySQL을 사용해야합니까? 분기마다 3 백만 개의 정적 html 파일을 생성해야합니까? Amazon S3 또는 Rackspace Cloud Files와 같은 제품에 각 제품에 대해 한 줄 CSV를 저장해야합니까? 가장 좋은 방법은 무엇입니까?
답변
MySQL은 매우 광범위하게 지원되므로 실제로는 그렇게하기가 쉽지 않습니다. 서버에 최소한 몇 GB의 메모리가 없으면 메모리 내 시스템을 사용하는 대신 MySQL을 사용하는 것이 좋습니다.
MySQL이든 다른 데이터이든 데이터베이스에 데이터를 저장하기 시작하면 더 많은 용도를 찾을 수있을 것입니다. 지금은 키 값 쌍에 대해서만 이야기하고 있지만 제품과 관련된 나머지 데이터는 어딘가에 저장해야합니다. 그것이 데이터베이스에 없다면 데이터 스토리지가 매우 효율적이라고 상상할 수 없습니다.
무엇을 하든지 3 백만 개의 파일을 만들지 마십시오 . 우리는 여기서 많은 파일이 생성하는 문제로 인해 이미 많은 질문을 보았습니다.
답변
이러한 종류의 작업에 최적화 된 전용 키-값 유형의 NoSQL 데이터베이스를 사용할 수 있습니다 . 살펴보십시오 :
- Redis -Redis는 공개 소스, 고급 키-값 저장소입니다. 키는 문자열, 해시, 목록, 세트 및 정렬 된 세트를 포함 할 수 있으므로 종종 데이터 구조 서버라고합니다.
- MemcacheDB -MemcacheDB는 지속적으로 설계된 분산 키-값 스토리지 시스템입니다.
- 기타 (이러한 목록 중 하나는 http://nosql-database.org/ 에서 찾을 수 있습니다 )
물론 당신은 MySQL의 또는 기타 관계형 데이터베이스,하지만 솔루션을 사용할 수 있습니다 특별히 제외시켰다 (그렇지 않으면 첫번째 장소에 설계의 포인트는 무엇인가 더 있어야 데이터의 키 – 값 형식에 대한 설계를 가능 훨씬 작아 질 것이라는 사실을 (RAM 및 HDD 측면에서) 솔루션).
답변
그리고 지금 완전히 다른 무언가를 위해 :
주어진:
- 180MB / 3M 제품 = 평균 62 바이트 / 제품
- 하루 30,000 건 = 초당 0.34 건
- 분기 별 업데이트 = 본질적으로 정적 데이터
상자 외부 솔루션 :
각 제품을 TXT 리소스 레코드로 덤프하여 DNS에 저장합니다. 예 :
$origin products.example.com.
product_1_name IN TXT "product 1 description"
product_2_name IN TXT "product 2 description"
...
product_3000000_name IN TXT "product 3000000 description"
혜택:
- 매우 신뢰할 수 있고 신뢰할 수 있습니다 (매일 이미 의존하고 있습니다)
- 거의 모든 플랫폼에 구축 가능
- 거의 모든 언어가 어떤 형태로든 DNS 쿼리를 지원합니다.
- 다양한 종류의 백엔드 데이터베이스를 지원하는 오픈 소스 및 상업용 서버
- 간단하게 복제 가능 (여러 이름 서버 만 지정)
- 12 개 서버에 복제 된 경우에도 원자 업데이트 처리
- 데이터 무결성을 보장하기 위해 암호화 서명 가능
- 두 번째 속도 당 크기 높은 질의의 주문 (1 만 쿼리를 처리 할 수있는 두 번째는 쉽게 상용 하드웨어로 처리됩니다)
이것이 나쁜 생각 일 수있는 이유 :
- 데이터를 검색해야합니다 (DNS는 순전히 키 / 값 조회입니다)
- 데이터를 숨겨야합니다 (DNS에는 기밀성이 없음)
답변
MyISAM이 포함 된 MySQL과 좋은 인덱스가 여기에 완벽하게 들립니다. 물론 다른 많은 옵션이 있지만 MySQL은 모든 상용 웹 호스트에서 매우 광범위하게 (일반적으로는 아님) 지원됩니다. 필요한 속도에 따라 memcached도 살펴볼 가치가 있지만 각 키 / 값 쌍의 크기를 알지 못하면 3 백만 개의 메모리를 메모리에 저장하는 것이 180Mb CSV 파일보다 더 나쁜 아이디어 일 수 있습니다. 180Mb CSV 파일이므로 파일 크기가 얼마나되는지 알 수 있습니다. 파일 크기가 아주 작아야 memcached가 더 좋습니다.
당신은 할 수 없습니다 그것은 심하게 파일 시스템을 다치게 할 것이다, 3 개 백만 정적 HTML 파일을합니다. S3에서도 한 줄 CSV는 같은 문제가 발생합니다. 아무도 폴더에 3 백만 개의 파일을 원하지 않습니다.
답변
Perl5가 시작된 이래로 힙하지 않은 경우에도 정확하게 이런 종류의 작업을 수행하는 버클리 데이터베이스를 사용할 수 있습니다. Berkeley는 키 값 쌍만 지원하며 전체 db를 해시에 연결하고 이와 같이 액세스합니다.
Berkeley 사용은 선반에있는 많은 이전 Perl 참조에 자세히 설명되어 있거나 BerkeleyDB CPAN 모듈에 대한 Perldoc을 사용해보십시오 . 나는 일반적으로 버클리 DB 사용을 피합니다 (내 고용주는 눈에 띄게 재생되는 고대 코드가 많지만 일부 DB는 귀하의 크기만큼 크지 만). 데이터가 복잡해지면 재미가 없기 때문입니다.
답변
귀하는 귀하의 질문을 Amazon S3로 표시했습니다.
Amazon SimpleDB라는 다른 관련 제품 중 하나에 관심을 기울이고 싶습니다.
SimpleDB 데이터 모델이 애플리케이션 유형에 잘 맞는 것 같습니다.
이것은 플러그 인이 아니지만 Amazon 클라우드 서비스를 사용할 계획이라면 특히 가치가 있습니다.
SDB 데이터 모델은 스프레드 시트와 유사합니다.
자세한 내용은 여기를 참조하십시오 : http://aws.amazon.com/simpledb/
그리고 데이터 모델 : http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/
답변
180MB의 데이터는 모든 관계형 데이터베이스에서 쉽게 처리 할 수 있지만 MongoDB ( http://www.mongodb.org/) 위의 MySQL, Redis, MemcacheDB 및 기타 간단한 키-값 저장소 또는 관계형 데이터베이스. 그 이유는 MongoDB가 이러한 종류의 문제에 대해 가장 빠르고 표현력이 뛰어난 시스템이기 때문에 스키마 제한없이 초고속 동적 업데이트가 가능하므로 원하는 경우 문서의 형식이 다를 수 있습니다. 나는 며칠 전 guardian.co.uk에서 프레젠테이션을했으며 모든 관계형 데이터베이스를 금지하고 뉴스를 제공하기 위해 독점적으로 MongoDB를 사용하는 정책 결정을 내 렸습니다. 1995 년 이후 영국에서 가장 오래된 온라인 신문 인 웹 사이트의 속도와 속도에 대해 알아볼 수 있습니다. 또한 관계형 데이터베이스로 인해 과거에 모든 종류의 병목 현상이 발생했습니다. 180MB의 경우 MongoDB는 메모리 내 모든 것을 제공하므로 하위 ms 로딩 시간이 그럴 가능성이 높습니다.