스몰 토크/해변의 데이터 지속성

Question

최근에는 스몰 토크와 해변에 익숙해지는 데 시간을 할애했습니다. 저는 Java EE 세계에서 왔고, 당신이 상상할 수 있듯이 스몰 토크 (Smalltalk) 개념에 대한 생각을 바꾸기는 어려웠습니다. :)

현재 스몰 토크 세계에서 데이터 지속성이 가장 일반적으로 구현되는 방식을 파악하려고합니다. Java 프로그래머로서의 나를위한 가정은 RDMS (즉, MySQL)와 ORM (즉, 최대 절전 모드)을 사용하는 것입니다. 스몰 토크 (최소한 Hibernate 사용)는 그렇지 않다는 것을 이해합니다. Java EE에서 수행되는 방식과 가장 밀접하게 매핑되는 방법을 반드시 찾지는 않습니다.

이미지, 객체 저장소 또는 RDMS에 데이터를 저장하는 것이 가장 일반적입니까? Smalltalk 앱이 RDMS를 사용하는 것이 일반적인 것인가?

여기에 하나의 크기에 맞는 방법이없고 올바른 지속성 전략은 응용 프로그램의 요구 (데이터, 동시성 등)에 따라 다릅니다. 단순하지만 규모를 시작할 수있는 좋은 접근 방법은 무엇입니까?

나는 Avi Bryant의 video이 DabbleDB의 지속성 및 스케일링에 사용한 전략을 논의하는 것을 지켜 봤습니다. 내가 이해 한 바로는 고객의 데이터가 이미지 (고객 당 하나의 이미지)에 바로 저장되었습니다. 고객이 데이터를 공유 할 필요가 없었기 때문에이를 활용했습니다. 이것이 일반적인 접근 방법입니까?

희망이 TLDR을 만들지 않았 으면합니다. Smalltalk 친구들이 내 이전 질문에서 제공 한 통찰력에 많은 감사드립니다. 고맙습니다.

Answer 1

저스틴, 걱정하지 마십시오

는 스몰 토크는이 지역에서 매우 다른 형태로 다른 언어 아니다, 그냥 이미지 기반 지속성 옵션을 추가합니다.

스몰 토크 용 Hibernate와 같은 O/R 매퍼가 있습니다. GLORP와 Pharo 포트 DBXtalk는 요즘 가장 인기있는 것들입니다. 최대 절전 모드를 알고 있다면 이것들은 매우 편안하게 느껴질 것입니다.

그런 다음 GemStone이나 Magma DB 또는 VOSS와 같은 OODB 솔루션과 O/R 매핑 문제를 모두 해결할 수있는 솔루션이 많이 있습니다. 이 중 대부분은 스몰 토크 (Smalltalk) 객체를 저장하는 것으로 제한되어 있으며, 젬스톤은 루비 및 기타 언어에 대한 브릿지를 제공하는 예외입니다.

CouchDB, Cassandra, GOODS 또는 기타와 같은 최신 NoSQL 데이터베이스에 Smalltalk 개체를 저장하는 도구도 있습니다. 여기의 트릭은 Smalltalk 객체 값을 JSON 스트림으로 변환하고 약간의 HTTP 요청을하는 것입니다.

마지막으로 완벽한 스몰 토크 이미지를 저장할 수있는 옵션이 있습니다. 나는 당신이 프로덕션 환경에서 그렇게 할 수 있다고 말하고 싶지만 많은 사람들에게 동등한 표준 또는 선호 방법이 아닙니다. 이미지를 저장하고 저장했을 때와 마찬가지로 모든 오브젝트를 제 위치에 정확하게 두어 작업을 재개 할 수 있기 때문에 많은 작업을 수행 할 수 있습니다.

기본 행은 다음과 같습니다. 알고있는 모든 저장 옵션은 스몰 토크에서도 사용할 수 있습니다.

요아킴은

Answer 2

나는 기본적 DB가 될 것입니다 그것을 처리됩니다 부하의 종류 얼마나 큰에 따라 달라집니다 것 같아요.

필자가 작성한 모든 응용 프로그램은 디스크 직렬화로 이미지 지속성을 사용합니다. 본질적으로 요청시 Fuel을 사용하여 객체를 직렬화하면됩니다.필자의 경우, 중요한 데이터가 처리 될 때마다 그렇게하고, 24 시간마다 직렬화하는 정규 프로세스를 수행합니다. 이미지는 24 시간마다 자동으로 저장됩니다.

이 접근법을 사용하여 작성한 가장 큰 응용 프로그램은 10 명의 직원으로 이루어진 소규모 기업의 비즈니스 프로세스와 1 년 반 동안 매일 사용하고있는 약 50 명의 프리랜서를 처리하는 것입니다. 작업량은 응용 프로그램이 항상 큰 파일을 처리한다는 점을 감안하면 꽤 크며 응용 프로그램은 안정적이고 빠르게 유지됩니다. 새 서버로 전환하고 Pharo 이미지를 업데이트하는 것은 프로젝트를 monticello에서 다시 가져오고 최신 직렬화 된 "데이터베이스"를 구체화하는 것처럼 쉽습니다.

제 생각에는 ORM은 불필요한 고통입니다. 우리는 객체 세계에 있으며 객체를 평평하게 만드는 것은 잘못된 생각입니다. 특히 객체 지향 솔루션이 좋은 경우 더욱 그렇습니다.

귀하의 앱이 상당히 적은 양의 데이터를 처리한다면 간단한 방법이나 SandstoneDB를 제안 할 것입니다. 앱이 막대한 양의 거래와 데이터를 처리한다면, 나는 Gemstone으로 간다.

그냥 내 두 센트.

Answer 3

라몬 레온은 상황, 기본 전략 및 그 절충을 아름답게 묘사합니다. in his blog post.

필자는 자신의 단순 이미지 기반 지속성 프레임 워크에서 시작하여 ported이며 Pharo 1.3에서 사용합니다. 마리아노 마르티네즈 펙 (Mariano Martinez Peck)은 최근 Fuel (동일한 링크)을 사용하기 위해 그것을 채택했습니다. 그것은 매우 간단합니다. 일을하고 내 이미지에서 놀 수있는 자신감을 더해줍니다. 영구적으로 손상 되더라도 모든 데이터가 안전하다는 것을 알고 있습니다. 데이터 폴더를 새로운 이미지 폴더에 복사하고, 패키지를로드하고, 모든 객체가 새 이미지에 살아 있습니다.