안녕하세요, 선생님!6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다. 질문 내용은 아래와 같습니다.데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지  일단 강의의 경우, 제가 이해한 내용으로는, 해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다. 이와 같습니다. 저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다.  제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때, 1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다. 2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다. 3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데 4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다. 따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다. 대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지). 이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다! 감사합니다.   

html 여러개를 만들었는데예를 들어 login.html을 누르면지금 url도 바뀌고, 개발자도구에 source도 바뀌는데 body에 바뀐 h1이 안바뀝니다.login.html에 여러개 다른 것도 추가해봤는데 아예 로딩이 안되는 것 같습니다. 왜그럴까요

안녕하세요!시스템 개발 및 설계 과정에서 '대규모 시스템', '분산 환경', '분산 데이터 모델링'과 같은 개념들을 본격적으로 고려하고 도입해야 하는 시점은 언제일까요?실무에서 경험해보지 못해서 '대규모' 라는 말이 막연해서 실무에서 어떤 것을 기준으로 고려하는지 혹은 지표 같은 것을 측정하는 방법이 있는지 궁금해서 질문 드립니다!

예시로 들었던 '게시판 별 게시글' 같은 인덱스 테이블에서 B Tree 인덱스를 사용하면 된다는 식으로 말씀하셨습니다.근데 전통적인 RDBMS에는 샤딩 기능조차 존재하지 않는데, 분산된 데이터베이스에서도 테이블 수준의 B Tree 인덱스처럼 동작하는 것처럼 말씀하신 것 같아, 이것이 맞는지 문의 드립니다.