I’m considering using Discourse as the backend for my website and app, but I haven’t seen any documentation on its scaling limits.
What’s the maximum number of categories we can have? Is it 1000? 10,000? 100,000?
I plan to heavily use the API and create a custom frontend for both web and mobile. Part of this is programmatically creating a new Category whenever a user wants to. So it’s more of a backend systems question than the UI.
For example, will the /categories.json endpoint scale? It doesn’t seem paginated.
Thanks @sam! Follow up question – what would the approximate limits be for:
the number of tags
the number of topics in a category
For example, can I have a few million unique tags, as well as a few million topics within a single category?
The tags, topic_tags, and topics tables don’t appear to be sharded, which should work for a few million rows, but I haven’t looked into the queries themselves, nor any UI that could potentially break.
Even with optimal indexing, query speeds will at some point take “too long”. What that is will vary from person to person.
Then there’s Ruby, Ember, bandwidth and browser limits. Feel free to research, but I wouldn’t worry about those.
I think that long before any software limits are reached “sane” limits will have already been passed. And what that would be will vary from person to person and how they interact with the information.
tl;dr You will break your users long before you break any code.
Personally I never subscribe to a site that has 2500 categories.
Virtually you can create all the categories you want but your site will only be confusing and not navigable.
Note that an official answer has already been given to your question and also an alternative to using categories.
The problem of categories in the first place is the problem of transparency and navigation for users. Working previously on the catalogue dmoz.org and making categories for Russian directories, we are faced with the fact that with a large number of categories, problems arise in users. A large number of categories, it’s like there are no more categories. They become unnecessary, impossible to use. Nobody understands the structure of the site, including those who did it. I think that’s the problem.
Navigation should be navigation, and if it loses its functions, it is sad.
UI 관련 사항은 제쳐두고, 범주가 1,000개 이상으로 증가하면 어떤 일이 일어나는지 궁금합니다. 응답 시간이 평균적으로 약간 길어지는 수준인지, 아니면 치명적인 결과가 발생하는 건지 알고 싶습니다. 더 나은 하드웨어를 투입하면 해결할 수 있는 문제일까요?
OP와 마찬가지로, 범주가 수천 개에 달할 수 있는 프로젝트를 진행 중입니다. 이 프로젝트는 그룹 기반 권한을 광범위하게 사용하며, 개별 사용자는 소수의 범주만 볼 수 있습니다(이것이 태그를 사용할 수 없는 이유입니다). 따라서 UI가 지나치게 복잡해지는 것보다는, 범주가 그 정도로 높아졌을 때 병목 현상이 어디에 발생하는지 알고 싶습니다.
이와 관련하여:
카테고리가 수백 개에서 수천 개에 이르는 경우, 검색 결과의 수를 제한할 수 있는 옵션이 있나요?
제 문제는 다음과 같습니다. 카테고리가 너무 많아서 새 토픽을 만들 때 드롭다운을 클릭하거나, 카테고리를 구독할 때 카테고리를 검색하면 긴 지연(수십 초)이 발생합니다.
이러한 시나리오에서 태그의 결과 수를 제한하는 옵션이 있다는 것은 알고 있습니다. 카테고리에도 동일한 기능을 적용할 수 있나요?
저는 300개 이상의 카테고리를 가지고 있습니다(하위 카테고리가 많긴 하지만), 하지만 그렇게 많은 카테고리를 볼 수 있는 사람은 관리자뿐입니다.
드롭다운 메뉴에서 검색할 수는 있지만, 게시글을 올리고 싶은 카테고리의 이름을 미리 알고 있어야 합니다.
제게 가장 큰 '문제’는 홈페이지에서 아래쪽에 있는 카테고리를 스크롤해야 하는 부분인데(검색 기능을 사용하면 쉽게 해결할 수 있습니다).
즉, (거의) 모든 카테고리가 비공개이며 그룹 멤버만 접근할 수 있다는 뜻인가요? 확실하지는 않지만, 이렇게 하면 성능 문제의 상당 부분이 해결될 거라고 생각합니다. 그리고 500개 정도를 유지할 계획이라면, 제 추측이 틀리더라도 괜찮을 수 있습니다. 권장 최대치는 200개 정도라고 생각하지만, 제 사이트는 200~300개를 사용하고 있습니다. 숫자가 너무 커지면 경고 메시지가 표시되므로, 그때 여러 인스턴스로 나누어 관리할 수 있습니다.
