파이썬 알고리즘 트레이딩 파트2: Interactive Brokers API를 활용한 실시간 알고리즘 트레이딩
안녕하세요 VSC에서 윈도우 버젼 yml설치 중인데요, name: myenv-PairTrading conda env create --file myenv-finance.yml 실행 시 아래 오류가 계속 나네요. Solving environment: failed LibMambaUnsatisfiableError: Encountered problems while solving: 챗GPT에게 물어가며 조치 해 보는데 myenv-finance.yml 에서 버전 고정을 해제합니다: 라고 조언 하는데 버젼을 다 지우고 하면 도움이 될까요?
내 업무를 대신 할 파이썬(Python) 웹크롤링 & 자동화 (feat. 주식, 부동산 데이터 / 인스타그램)
subject_element[9].find_element(By.CSS_SELECTOR," a.link _service > span.service_name").text.strip() 위 코드를 실행하면 잘 실행이 되지만 service_list = [] subject_element = WebDriverWait(driver, 10).until( EC.presence_of_all_elements_located( (By.CSS_SELECTOR, "ul.shortcut_list > li.shortcut_item") ) ) for e in subject_element : service_title = e.find_element(By.CSS_SELECTOR," a.link _service > span.service_name").text.strip() service_list.append(service_title) service_list 해당 코드를 실행하면 span태그를 못 읽습니다. a태그 안에 span태그가 있는 건 확실합니다.
안녕하세요 저희는 기존에 react + node를 사용해서 개발을 하고 있었는데요 python으로 변경하려는 상황입니다. 강의를 보면서 jinja라는 것을 알게 되었는데요. 찾아보니까 react를 사용하면 jinja를 사용하지 않는다고 하더라구요 react를 사용하는게 맞을까요 아니면 jinja를 사용하는게 맞을까요 보통 어떻게 많이 사용하나요?
이번에 커버링 인덱스를 설명하시면서 아 대충 왜 빠르게 조회가 되는지 이해가 되기 시작했습니다. 그런데 최근에 했던 프로젝트 중에 이와 비슷한데 왜 성능이 개선되었는지 모르는 것이 하나 있습니다. 아래 부분인데요.. 일단 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를 통합하여 어느 컴퓨터에서 사용하든 작업을 이어갈 수 있을까요?
안녕하세요. 선생님. 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) 방법으로 해결했습니다.
https://www.inflearn.com/community/questions/1516484 해당 게시글의 답변중 아래 문장이 이해가 잘 안갑니다 ㅠ 물론, 삭제된 데이터가 극히 적다면, 위 비용은 딱히 문제가 안될 수도 있긴 합니다. 삭제되지 않은 데이터가 훨씬 많다면, 조건에 일치(isDeleted=false)하는 데이터를 빠르게 찾을 수 있으므로, 스캔하는 범위는 어차피 적을테니깐요. 하지만 삭제된 데이터가 많아질수록 조건에 일치하는 데이터를 찾기 위해 스캔하는 범위가 길어질 수 있으므로 , 인덱스를 걸어둬야 빠르게 조회가 가능합니다! 인덱스를 걸지 않았을때 삭제되지 않은 데이터(isDeleted = false)가 훨씬 많다면 스캔하는 범위가 적은 이유 를 잘 모르겠습니다.. 인덱스가 없으면 삭제된 데이터가 많든, 많지 않든 무조껀 풀 스캔을 해서 스캔 범위는 똑같은게 아닌걸까요? 또한, 데이터 연속성도 스캔할시 관련이 있는건지 궁금합니다. 인덱스가 없을때 where isDeleted = false 쿼리 실행시 id가 4번까지만 스캔해서 스캔 범위가 적은걸까요? ㄸ 직전 조건와 같을때 위와 같이 데이터가 흐트러져있다면 풀스캔을 하는 걸까요? 인덱스 공부좀 해야겠네요 흙흙
안녕하세요 항상 좋은 강의 해주셔서 감사합니다. 다름이 아니라 제가 프로젝트 중에 유저가 알림 설정한 데이터를 kafka로 받아서 시세 데이터와 조인하여 알림 메세지를 생성하려고합니다. 유저 알림 데이터는 boolean값을 가진 활성화여부와 삭제라는 기능이있습니다. 그래서 kafka내에서 유저 알림 데이터를 최신화하기 위해서 찾아본 결과 compact topic이라는것을 발견하였고 실습중에 있습니다만 결과가 좋지않아서 질문드립니다. sudo docker exec -it kafka-1 kafka-topics --create --bootstrap-server 192.168.56.101:29092 --topic user-alert-set --partitions 6 --replication-factor 2 --config "cleanup.policy=compact" --config "min.compaction.lag.ms=5000" --config "max.compaction.lag.ms=10000 " --config "delete.retention.ms=3000" --config "segment.ms=3000" --config "min.cleanable.dirty.ratio=0.01" 이런식으로 토픽을 생성하여 실습한 결과 1. Key A: value1 넣음 -> [A:value1] 2. Key A: value2 넣음 -> [A:value1, A:value2] 3. Key B: value1 넣음 -> [ A:value2, B:value1] 4. Key B: value2 넣음 -> [A:value2, B:value1, B:value2] 이렇게 진행되었습니다. 삭제를 위한 tombstone메세지 또한 위와같은 형식으로 진행되었습니다. 제가 이해한 바로는 같은 키의 값이 들어오면 들어온 값으로 최신화 혹은 삭제를 하는 설정으로 이해를 해서 이 결과가 저는 이해가 되지않습니다. gpt한테 물어보니 로그 컴팩션은 "head"와 "tail" 두 부분으로 나뉩니다: Tail: 이미 컴팩션이 완료된 부분 (깔끔한 상태) Head: 아직 컴팩션되지 않은 활성 부분 (더티 상태) 예시: 1. A:value1 입력 -> [A:value1] 2. A:value2 입력 -> [A:value1, A:value2] (컴팩션 발생) -> [A:value2] // A는 tail 부분으로 이동 3. B:value1 입력 -> [A:value2, B:value1] // B는 head 부분에 위치 즉, A는 이미 컴팩션되어 tail 부분에 최신 값만 있고, B는 아직 head 부분에 있어서 컴팩션되지 않은 상태로 남아있는 것입니다. 이는 정상적인 동작이며, B도 시간이 지나면 컴팩션될 것입니다. 라는 답변을 받았지만 시간이 지나도 키가 B인 데이터는 여전히 두개로 남아있었습니다. 혹시 이유를 아신다면 설명해주시면 감사하겠습니다.