이번에 커버링 인덱스를 설명하시면서 아 대충 왜 빠르게 조회가 되는지 이해가 되기 시작했습니다. 그런데 최근에 했던 프로젝트 중에 이와 비슷한데 왜 성능이 개선되었는지 모르는 것이 하나 있습니다. 아래 부분인데요.. 일단 created_at 은 index 가 적용되지 않았음을 알려 드립니다. select ep1_0.employee_post_id, ep1_0.access_url, ep1_0.contact, ep1_0.contents, ep1_0.member_id, m1_0.member_id, m1_0.access_url, m1_0.authority, m1_0.birth_day, m1_0.email, m1_0.login_id, m1_0.name, m1_0.nick_name, m1_0.password, m1_0.personal_link, m1_0.personal_statement, m1_0.sex, m1_0.tmp_password, m1_0.twitter_link, m1_0.youtube_link, ep1_0.payment_amount, ep1_0.payment_method, ep1_0.title, wft1_0.work_field_tag_id, wft1_0.name, ep1_0.career_year, ep1_0.created_at, ep1_0.updated_at from employee_post ep1_0 left join work_field_tag wft1_0 on wft1_0.work_field_tag_id=ep1_0.work_field_tag_id join member m1_0 on m1_0.member_id=ep1_0.member_id where wft1_0.work_field_tag_id=1 order by ep1_0.created_at desc, ep1_0.employee_post_id desc limit 0,10; 이것을 explain analyze 한다면 Limit: 10 row(s) (cost=1088 rows=10) (actual time=39.1..39.1 rows=10 loops=1) -> Nested loop inner join (cost=1088 rows=1968) (actual time=39.1..39.1 rows=10 loops=1) -> Sort: ep1_0.created_at DESC, ep1_0.employee_post_id DESC (cost=399 rows=1968) (actual time=39..39 rows=10 loops=1) -> Index lookup on ep1_0 using FK_work_field_tag_TO_employee_post (work_field_tag_id=1) (cost=399 rows=1968) (actual time=0.0949..7.91 rows=1968 loops=1) -> Single-row index lookup on m1_0 using PRIMARY (member_id=ep1_0.member_id) (cost=0.25 rows=1) (actual time=0.011..0.011 rows=1 loops=10) 이렇게 나오고 성능이 무척 안좋은 것을 볼 수 있었습니다(using filesort 가 직접적인 원인) 근데 문제는 member 에 대한 inner join 을 빼면 -> Limit: 10 row(s) (cost=398 rows=10) (actual time=10.5..10.5 rows=10 loops=1) -> Sort: ep1_0.created_at DESC, ep1_0.employee_post_id DESC, limit input to 10 row(s) per chunk (cost=398 rows=1968) (actual time=10.5..10.5 rows=10 loops=1) -> Index lookup on ep1_0 using FK_work_field_tag_TO_employee_post (work_field_tag_id=1) (cost=398 rows=1968) (actual time=0.0712..6.03 rows=1968 loops=1) 위와 같이 나오면서 성능이 무척 개선된다는 점입니다. 제가 보았을 떄 핵심적인 부분은 10 rows per chunk 입니다. 혹시 10 rows per chunk 같은 키워드는 언제 언제 발생하는지 알 수 있을까요??(왜 member에 대한 join 을 빼면 나타나구, wft1_0 을 left outer join 을 하는 것은 영향이 없는지..) mysql 공식 문서를 계속 뒤져도 발견하지 못했습니다. 강의와 관련 없는 부분이라고도 생각하실 수 있는데 이런 질문 해서 정말 죄송합니다.. 관련해서 블로그 정리한 거 혹시 필요한 정보가 있을 수도 있으니 링크 남겨놓겠습니다... https://velog.io/@dionisos198/Query-DSL-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0-%EB%B0%8F-fetch-join-%EA%B3%A0%EC%B0%B0
안녕하세요! Visual Studio Code를 각 각 다른 컴퓨터에 다운 받아서 사용하였는데요! 해당 작업물이 각 각 다르게 나오고 있더라고요.. 각 각 다른 컴퓨터에서 각기 다른 작업을 하는 2개의 Visual Studio Code를 통합하여 어느 컴퓨터에서 사용하든 작업을 이어갈 수 있을까요?
혹시 강의를 처음에는 쭉 보면서 따라하거나 정리하고 다시한번 한입 북스를 스스로 만들어보면서 nextjs흐름을 파악하면서 잘 모르겠거나 막히는 부분 강의 다시 한번 듣고 소스 코드 보고 이렇게 듣는 방식이 젤 괜찮은가요?? 아니면 스타일링이나 단순 리액트 컴포넌트를 구성하는 부분은 혼자서 해보고 강의를 듣는 방식이 더 나을까요?? 감사합니다
RedisConfig 클래스에서 @Bean을 이용해서 @Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> redis = new RedisTemplate<>(); redis.setConnectionFactory(factory); redis.setKeySerializer(new StringRedisSerializer()); redis.setHashKeySerializer(new StringRedisSerializer()); redis.setHashValueSerializer(new StringRedisSerializer()); redis.setValueSerializer(new StringRedisSerializer()); return redis; } 해당 코드를 통해 RedisTemplate를 빈으로 등록한걸 확인했는데요. 근데 왜 RedisCommon 클래스 쪽에선 해당 Bean을 사용하지 않고 RedisTemplate<String,String> 을 사용하나요? Bean으로 등록한건 RedisTemplate<String,Object>인데 그럼 스프링에서는 만들어 놓은 RedisTemplate<String,Object>을 사용하지 않고 새로운 RedisTemplate<String,String>을 만들어서 주입하는 걸로 알고있습니다. 저 Bean으로 등록해놓은 RedisTemplate<String,Object>의 직렬화 및 역직렬화에 사용될 객체를 집어넣어주는 코드는 Redis 전체 설정인가요?? 저렇게 하면 RedisTemplate<String,String>에도 적용이 되는건가요?? - 강사님의 이론편을 안봐서 제가 이해가 잘 안가는 것 일 수도 있습니다 ㅠㅠ 실제로 RedisConfig 클래스에서 정의한 RedisTemplate<String, Object>와 RedisString에서 정의한 RedisTemplate<String,String>의 해시코드를 비교해봤는데 서로 다른 값이 나왔습니다. @Service @RequiredArgsConstructor public class RedisString { private final RedisTemplate<String, String> template; private final RedisTemplate<String, Object> template2; // RedisTemplate@544e3679 RedisConfig에서 스프링의 빈 초기화시 로그 // RedisTemplate@544e3679 RedisString에서 찍은 template2 로그 // StringRedisTemplate@6d5bb599 RedisString에서 찍은 template 로그
const Header = () => { return { <header> <h1>header</h1> </header> }; }; 위의 코드 작성시 속성 할당이 필요합니다. 선언 또는 문이 필요합니다. 식이 필요합니다. 선언 또는 문이 필요합니다. 이 4가지 에러가 표시됩니다.
안녕하세요. 선생님. Email operator 메일 전송 dag 수행 시 아래 오류 발생합니다. 시간 되실 때 내용에 대해 도움 부탁드립니다. *** /opt/airflow/logs/dag_id=dags_email_operator/run_id=manual__2025-02-19T05:59:40.395069+00:00/task_id=send_email_task/attempt=1.log ▲▲▲ Log group end [2025-02-19, 14:59:44 KST] {local_task_job_runner.py:123} ▼ Pre task execution logs [2025-02-19, 14:59:44 KST] {taskinstance.py:2613} INFO - Dependencies all met for dep_context=non-requeueable deps ti=<TaskInstance: dags_email_operator.send_email_task manual__2025-02-19T05:59:40.395069+00:00 [queued]> [2025-02-19, 14:59:44 KST] {taskinstance.py:2613} INFO - Dependencies all met for dep_context=requeueable deps ti=<TaskInstance: dags_email_operator.send_email_task manual__2025-02-19T05:59:40.395069+00:00 [queued]> [2025-02-19, 14:59:44 KST] {taskinstance.py:2866} INFO - Starting attempt 1 of 1 [2025-02-19, 14:59:44 KST] {taskinstance.py:2889} INFO - Executing <Task(EmailOperator): send_email_task> on 2025-02-19 05:59:40.395069+00:00 [2025-02-19, 14:59:44 KST] {warnings.py:112} WARNING - /home/ **/.local/lib/python3.12/site-packages/***/task/task_runner/standard_task_runner.py:70: DeprecationWarning: This process (pid=117) is multi-threaded, use of fork() may lead to deadlocks in the child. pid = os.fork() [2025-02-19, 14:59:44 KST] {standard_task_runner.py:72} INFO - Started process 118 to run task [2025-02-19, 14:59:44 KST] {standard_task_runner.py:104} INFO - Running: ['***', 'tasks', 'run', 'dags_email_operator', 'send_email_task', 'manual__2025-02-19T05:59:40.395069+00:00', '--job-id', '121', '--raw', '--subdir', 'DAGS_FOLDER/dags_email_ operator.py ', '--cfg-path', '/tmp/tmp4a9ijz8k'] [2025-02-19, 14:59:44 KST] {standard_task_runner.py:105} INFO - Job 121: Subtask send_email_task [2025-02-19, 14:59:44 KST] {task_command.py:467} INFO - Running <TaskInstance: dags_email_operator.send_email_task manual__2025-02-19T05:59:40.395069+00:00 [running]> on host 4742acded404 [2025-02-19, 14:59:44 KST] {taskinstance.py:3132} INFO - Exporting env vars: AIRFLOW_CTX_DAG_OWNER='***' AIRFLOW_CTX_DAG_ID='dags_email_operator' AIRFLOW_CTX_TASK_ID='send_email_task' AIRFLOW_CTX_EXECUTION_DATE='2025-02-19T05:59:40.395069+00:00' AIRFLOW_CTX_TRY_NUMBER='1' AIRFLOW_CTX_DAG_RUN_ID='manual__2025-02-19T05:59:40.395069+00:00' [2025-02-19, 14:59:44 KST] {logging_mixin.py:190} INFO - Task instance is in running state [2025-02-19, 14:59:44 KST] {logging_mixin.py:190} INFO - Previous state of the Task instance: queued [2025-02-19, 14:59:44 KST] {logging_mixin.py:190} INFO - Current task name:send_email_task state:running start_date:2025-02-19 05:59:44.157879+00:00 [2025-02-19, 14:59:44 KST] {logging_mixin.py:190} INFO - Dag name:dags_email_operator and current dag run status:running [2025-02-19, 14:59:44 KST] {taskinstance.py:731} ▲▲▲ Log group end
https://velog.io/@ghwns9991/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B6%80%ED%8A%B8-3.2-%EB%A7%A4%EA%B0%9C%EB%B3%80%EC%88%98-%EC%9D%B4%EB%A6%84-%EC%9D%B8%EC%8B%9D-%EB%AC%B8%EC%A0%9C 스프링 3.2 부터 uri 관련 매개변수 어노테이션을 잘 인식하지 못한다고 하나 봅니다. 저는 윗 글의 두 번째(-parameters) 방법으로 해결했습니다.
문의하기에서 접수 완료 후 (현재 기본 로컬~문의완료되었습니다.) 알럿 뜨는거 저번에 배운 게시글 처럼 넣어서 이쁘게 꾸며도 사용상 문제없는거 맞죠? 만약에 참고할만한 알럿 다른 라이브러리나 깃허브 같은건 보통 실무에서 어떻게 참조하나요? 몽고DB랑 AWS_S3로 저희가 이미지 및 데이터를 저장하잖아요, 그럼 실무에서는 그냥 도메인 및 호스팅만 따로 구매해서 넘겨드리고 사용 하시면 된다고 하면서 넘겨드리고, 몽고DB 및 AWS_S3는 제가 한 계정(제 개발계정)에 같이 폴더만 나눠서 관리하는 식으로 많이하나요? 궁금합니다.
https://www.inflearn.com/community/questions/1516484 해당 게시글의 답변중 아래 문장이 이해가 잘 안갑니다 ㅠ 물론, 삭제된 데이터가 극히 적다면, 위 비용은 딱히 문제가 안될 수도 있긴 합니다. 삭제되지 않은 데이터가 훨씬 많다면, 조건에 일치(isDeleted=false)하는 데이터를 빠르게 찾을 수 있으므로, 스캔하는 범위는 어차피 적을테니깐요. 하지만 삭제된 데이터가 많아질수록 조건에 일치하는 데이터를 찾기 위해 스캔하는 범위가 길어질 수 있으므로 , 인덱스를 걸어둬야 빠르게 조회가 가능합니다! 인덱스를 걸지 않았을때 삭제되지 않은 데이터(isDeleted = false)가 훨씬 많다면 스캔하는 범위가 적은 이유 를 잘 모르겠습니다.. 인덱스가 없으면 삭제된 데이터가 많든, 많지 않든 무조껀 풀 스캔을 해서 스캔 범위는 똑같은게 아닌걸까요? 또한, 데이터 연속성도 스캔할시 관련이 있는건지 궁금합니다. 인덱스가 없을때 where isDeleted = false 쿼리 실행시 id가 4번까지만 스캔해서 스캔 범위가 적은걸까요? ㄸ 직전 조건와 같을때 위와 같이 데이터가 흐트러져있다면 풀스캔을 하는 걸까요? 인덱스 공부좀 해야겠네요 흙흙
회원가입 후 로그인 된 상태로 home으로 이동하게 되는데 여기서 useSession정보가 업데이트 되지않아서 Props로 session정보를 넘겨주는 방식으로 사용하셨는데 다르게 처리하는 방법도 있을까요 ? 예를 들면 로그인 모달에서 했던 것 처럼 서버액션을 사용하지 말고 클라이언트 컴포넌트에서 fetch 를 처리한 후 replace(/home) 시키는 방법이요 !
