저는 Stack Exchange 네트워크를위한 Emacs 주요 모드를 작성하는 초기 단계에 있습니다 . Emacs를 정기적으로 사용하면 결국 혜택을 볼 수 있습니다.
Stack Exchange의 API에 대한 호출 횟수를 최소화하고 (하루에 IP 당 10000 개로 제한) 일반적으로 책임있는 시민이되기 위해 네트워크에서 수신 한 정보를 캐시하고 메모리에 저장하려고합니다. 다시 액세스하십시오. 나는이 정보를 저장할 데이터 구조에 정말로 붙어 있습니다.
분명히, 그것은 목록이 될 것입니다. 그러나 데이터 구조와 마찬가지로 어떤 데이터가 저장되고 어떤 방법으로 액세스되는지에 따라 선택이 결정되어야합니다. 이 정보를 모두와 같은 단일 기호로 저장할 수 있기를 원합니다 stack-api/cache. 따라서 더 이상 고민하지 않고 stack-api/cache마지막 업데이트로 키를 낸 결과 목록이 있습니다.
`(<csite> <csite> <csite>)
어디 <csite>있을까
(1362501715 . <site>)
이 시점에서 우리가 한 일은 간단한 연관 목록을 정의하는 것입니다 . 물론 더 깊이 들어가야합니다 .
각각 <site>은 API 매개 변수 (고유)의 목록이며 그 다음에 목록 질문이 있습니다.
`("codereview" <cquestion> <cquestion> <cquestion>)
각각 <cquestion>은 마지막 업데이트 시간에 대한 질문의 단점입니다.
`(1362501715 <question>) (1362501720 . <question>)
<question>(A)의 단점 인 question구조 (다시,와은 consed 답변 목록 자신의 마지막 업데이트 시간) :
`(<question-structure> <canswer> <canswer> <canswer>
그리고`
`(1362501715 . <answer-structure>)
이맥스 리스프 (모든 리스프에서 해당 다르지 않다 당신이 알고 사랑이 데이터 구조 가능성이 가장 정확하게 트리로 설명하지만, 언어를 고려하여이 작업을 수행 할 수있는 더 좋은 방법이 있는지 모르겠어요 전혀 ) . 명백한 결과는 불필요 할 수 있지만 뇌가 더 잘 감쌀 수 있도록 도와줍니다. <csite>예를 들어으로 변할 것이라고 확신합니다 .
(<epoch-time> <api-param> <cquestion> <cquestion> ...)
우려 사항 :
- 이와 같이 잠재적으로 거대한 구조로 데이터를 저장하면 시스템에 대한 성능 상충 관계가 있습니까? 외부 데이터를 저장하지 않으려 고했지만 할 수있는 작업을 수행했으며 데이터 세트가 사람이 읽을 수있는 텍스트이므로 합리적인 비율로 처음부터 (정상 사용의 경우) 그렇게 큰 것으로 생각하지 않습니다. (나는 목록의 머리 부분에있는 시간을 사용하여 오래된 데이터를 컬링 할 계획입니다. 각각의 자식에서 마지막 업데이트 시간을 상속하고 나무 아래로 내려갑니다.이 컬은 어느 정도까지 발생해야합니다. 확실한.)
- 이와 같은 데이터를 저장하는 데 사용해야하는 성능과 상충되는 부분이 있습니까? 즉, 설정 및 검색 작업이 목록의 크기에 영향을 미칩니 까?
더 나은 구조가 어떻게 보일지에 대한 다른 제안이 있습니까?
org); 삽입 <!-- language: blah>위치를 (코드 편집이 이루어졌다되는 모드에 따라) 필요한; 그런 것들. 추가 정보를 원하시면 GitHub의에서 README를 참조과 느낌 대부분의 기능을 제안하는 환영. 사전에 이것에 대해 더 많이 알수록 더 잘 설계 할 수 있습니다. emacs keybindings를 언급하지 않도록 편집 ;)