안녕하세요 저는 F # GPU (예 : C Nivida GPU api typeprovider 사용)를 사용하여 막대한 양의 데이터를 처리하는 데있어 가장 비용 효율적이고 효율적인 방법 인 사람의 경험을 묻고 싶습니다.F # GPU 프로그래밍과 데이터 정리를위한 KDB, 가장 빠른 것은 무엇입니까?
두 가지 모두 상당히 다른 접근 방법이지만 하나 또는 두 기술에 투자하기 전에 양쪽 모두에서 일한 사람들로부터 조언을 얻기를 바랍니다.
GPU 쪽에서는 mongodb와 같은 관계형 DB 또는 NoSQL DB를 단일 테이블 및 2-3 개의 다른 테이블과의 간단한 조인을 사용하여 작동하지 않을 계획입니다.
두 접근법간에 통계 또는 비교 (대부분 속도)를 아는 사람이 있습니까?
다른 사람이 말했듯이 너무 많이 사용 사례에 따라 달라집니다. 쿼리는
KDB 데이터베이스는 significa했다 대부분의 쿼리에서 위에서 언급 한 것보다 훨씬 빠릅니다. 성능면에서 하나의 데이터베이스가 가까웠지만 원하는 계산을 수행하기가 훨씬 어려웠습니다.
아니요. 일부 데이터베이스 공급 업체의 조건에 위배되므로 엄격한 수치를 제시 할 수 없습니다. 그러나 나는 당신이 시스템을 만들려고한다면 팀이 선택한 것에 영향을 미쳐야한다는 것을 강조 할 것입니다. 시스템을 빠르게 변경하고 프로그래밍 할 수있는 능력.
감사합니다. 모두 의미가 있습니다. 따라서 MDB에서 MongoDB와 같은 복잡한 쿼리를 쉽게 작성할 수 있다고 말합니까? – Nikos
"MongoDB와 비슷한 것"보다는 KDB에서 복잡한 쿼리를 작성하는 것이 훨씬 쉽습니다.
나는 F # 팬입니다.
이제 F # 또는 KDB +는 GPU와 호환되는 방식으로 생각할 수 있습니다 (배열 기반, 전체 문제를 한 번에, 덜 선형, 병렬 처리). 어떤 선택을 하든지, 거기에 도달하는 과정과 특정 세계관에 갇혀 있는지 여부를 생각하십시오.
모델링에 관한 한, 컨텍스트는 매우 중요합니다. 실행하려는 모델의 종류와 처리량 요인에 따라 달라집니다.
KDB +의 민첩성, 간결성 및 속도는 최고입니다. 마찬가지로 F #은 유형 안전성과 생명 과학 분야의 연구 기반 자료에 적합합니다.
둘 다 함께 사용하는 것을 방해하는 요소는 없습니다. 아, 32 비트 버전의 KDB +는 상업적 또는 비상업적 인 방법으로 자유롭게 사용할 수 있습니다.
John과 마찬가지로 BerkeleyDB 이상에서 많은 옵션을 시도해 보았습니다. 특히, KDB + 이외의 다른 칼럼 옵션은 성능뿐만 아니라 여러 가지 방법으로 부족했습니다. 필자는 커널 관점에서 살펴 보았고 영업 팀이 포기할 때 커널에서 작업 한 일부 엔지니어와도 이야기했습니다.벤치 마크를 뛰어 넘는 KDB +가 현명한 방법이라는 근본적인 이유가 있습니다.
속도는 응용 프로그램에 따라 다소 차이가 날 수 있습니다. 다른 요인들과 이것이 제품 로드맵과 관련되는 방식은 아마도 보편적 일 수 있습니다.
당신이하고 싶은 일에 대해 좀 더 구체적으로 설명해 줄 수 있습니까? '데이터 크 런칭 (crunching data)'은 여러 가지 일을 의미 할 수 있으며, 원하는 작업이 F #, GPU 또는 KDB의 장점에 부합하는지 알 수있는 방법이 없습니다. –
기본적으로 수백 분의 행 (10-50)의 배치를 1 분 또는 몇 분마다 연속적으로 처리하기를 원합니다. 간단한 통계, 너무 멋진 것은 아닙니다 .. – Nikos
@JackP. 왜 사람들이 이것을 삭제 투표합니까? – Nikos