3 백만 개의 제품에 대한 기본 정보를 저장해야합니다. 현재 정보는 180MB CSV이며 분기별로 업데이트됩니다.
하루에 약 30,000 개의 쿼리가 있지만 쿼리는 매우 간단한 키 값 저장소입니다. 제품 ID 만 찾아 나머지 정보 (모두 하나의 레코드에 있음) 만 표시하면됩니다.
이것은 웹용이므로 빠른 성능이 중요합니다.
관계형 데이터베이스가 실제로 필요하지 않더라도 MySQL을 사용해야합니까? 분기마다 3 백만 개의 정적 html 파일을 생성해야합니까? Amazon S3 또는 Rackspace Cloud Files와 같은 제품에 각 제품에 대해 한 줄 CSV를 저장해야합니까? 가장 좋은 방법은 무엇입니까?
답변:
MySQL은 매우 광범위하게 지원되므로 실제로는 그렇게하기가 쉽지 않습니다. 서버에 최소한 몇 GB의 메모리가 없으면 메모리 내 시스템을 사용하는 대신 MySQL을 사용하는 것이 좋습니다.
MySQL이든 다른 데이터이든 데이터베이스에 데이터를 저장하기 시작하면 더 많은 용도를 찾을 수있을 것입니다. 지금은 키 값 쌍에 대해서만 이야기하고 있지만 제품과 관련된 나머지 데이터는 어딘가에 저장해야합니다. 그것이 데이터베이스에 없다면 데이터 스토리지가 매우 효율적이라고 상상할 수 없습니다.
무엇을 하든지 3 백만 개의 파일을 만들지 마십시오 . 우리는 여기서 많은 파일이 생성하는 문제로 인해 이미 많은 질문을 보았습니다.
이러한 종류의 작업에 최적화 된 전용 키-값 유형의 NoSQL 데이터베이스를 사용할 수 있습니다 . 살펴보십시오 :
물론 당신은 MySQL의 또는 기타 관계형 데이터베이스,하지만 솔루션을 사용할 수 있습니다 특별히 제외시켰다 (그렇지 않으면 첫번째 장소에 설계의 포인트는 무엇인가 더 있어야 데이터의 키 - 값 형식에 대한 설계를 가능 훨씬 작아 질 것이라는 사실을 (RAM 및 HDD 측면에서) 솔루션).
그리고 지금 완전히 다른 무언가를 위해 :
주어진:
상자 외부 솔루션 :
각 제품을 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"
혜택:
이것이 나쁜 생각 일 수있는 이유 :
MyISAM이 포함 된 MySQL과 좋은 인덱스가 여기에 완벽하게 들립니다. 물론 다른 많은 옵션이 있지만 MySQL은 모든 상용 웹 호스트에서 매우 광범위하게 (일반적으로는 아님) 지원됩니다. 필요한 속도에 따라 memcached도 살펴볼 가치가 있지만 각 키 / 값 쌍의 크기를 알지 못하면 3 백만 개의 메모리를 메모리에 저장하는 것이 180Mb CSV 파일보다 더 나쁜 아이디어 일 수 있습니다. 180Mb CSV 파일이므로 파일 크기가 얼마나되는지 알 수 있습니다. 파일 크기가 아주 작아야 memcached가 더 좋습니다.
당신은 할 수 없습니다 그것은 심하게 파일 시스템을 다치게 할 것이다, 3 개 백만 정적 HTML 파일을합니다. S3에서도 한 줄 CSV는 같은 문제가 발생합니다. 아무도 폴더에 3 백만 개의 파일을 원하지 않습니다.
So you think MySQL is the way to go, really?아니, 실제로는 아니지만 매우 유연하고 언급했듯이 거의 보편적으로 지원됩니다. 그러나 LazyOne은 위의 좋은 대안을 게시했습니다. 나는 NoSQL이라는 용어를 기억할 수 없었지만 그것은 내 두뇌 어딘가에 떠 다니고있었습니다
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 로딩 시간이 그럴 가능성이 높습니다.
하루에 약 30,000 개의 쿼리가 있지만 쿼리는 매우 간단한 키 값 저장소입니다. 제품 ID 만 찾아 나머지 정보 (모두 하나의 레코드에 있음) 만 표시하면됩니다.
쿼리는 단순한 키 조회이며 이진 검색에서는 최악의 경우 21 회 반복이 필요하며 해시 키를 사용하면 쿼리가 훨씬 빠릅니다. 조인 (또는 다른 직교 제품 유형 작업) 및 선형 검색을 피하는 한 3 백만 개의 레코드는 작습니다 .
거의 모든 것이 잘 될 것이라고 감히 말하고 싶습니다. 하루에 30000 번의 쿼리를로드한다는 것은 하루 동안로드가 일정하다고 가정하면 20 초마다 하나의 쿼리를 수행한다는 의미입니다. 그렇게 나쁘지 않습니다.
가장 익숙한 기술로 구현 한 다음 이것이 실제로 시스템의 병목 현상인지 여부를 측정하는 것이 좋습니다.
이를 수행하는 가장 좋은 방법은 데이터 및 쿼리의 품질과 특성에 따라 다릅니다. 우선, 단일 테이블에있는 제품의 180MB 데이터는 문제가되지 않습니다. 그리고 하루에 30k 개의 쿼리는 문제가 훨씬 적습니다. 올바르게 구성된 데이터베이스를 사용하면 이전 데스크톱에서이로드를 처리 할 수 있습니다.
다른 사람들은 이미 두 가지 주요 옵션 인 MySQL 또는 noSQL 데이터베이스를 지적했습니다.
모든 단일 제품 (예 : 제조업체, 가격, 창고 번호 등)에 존재하는 특정 수의 속성이있는 경우 가장 좋은 방법은 이러한 속성에 대한 열을 갖고 키 / 값 쌍을 플랫 테이블 형식으로 변환하는 것입니다. 대부분의 제품의 경우 모든 속성을 검색하기 위해 하나의 쿼리 만 실행하면되므로 일부 열은 행의 절반 만 사용하더라도 매우 잘 작동합니다. 이것은 제품에 대한 데이터입니다. 이것이 귀하의 데이터 구조 일 가능성이 높습니다.
속성의 존재 여부와 데이터 유형이 다양하면 기존 SQL 데이터베이스보다이 시나리오를보다 효율적으로 처리하는 noSQL 데이터베이스를 사용하는 것이 좋습니다.
성능과 관련하여 : 나는 이전에 전자 상거래 회사에서 근무한 적이 있는데 오랫동안 웹 사이트에 MySQL 서버의 데이터가 제공되었습니다. 이 서버에는 2GB의 RAM이 있으며 총 데이터베이스 수는 약입니다. 5GB 크기와 최대로드시 서버는 초당 수천 개의 쿼리를 처리했습니다. 예, 우리는 많은 쿼리 최적화를 수행했지만 이것이 실제로 가능합니다.