תחומים - פורום חרדי מקצועי

@מוגן אצלי תקין.

@מוגן זה קורה בגלל מדיניות מניעת הזרקה שנוספה לאחרונה בג'מייל.
הפתרון להוסיף את הקוד הבא:

if (window.trustedTypes && window.trustedTypes.createPolicy) {
  window.trustedTypes.createPolicy('default', {
    createHTML: (string, sink) => string
  });
}

אני מעדכן גם למעלה.

@מוגן שמתי לב לזה.
בעז"ה כשאתפנה אנסה לבדוק את זה.

@איש-ימיני אולי לחבר מיקרופון דש איכותי לכל פלאפון. (לא דבר זול).

@dovid כתב בייעול שאילתת MYSQL:

לפי הפלט שהבאת יש כמעט מיליון שורות מתאימות ליום בודד, זה הגיוני?

לא.

@dovid את האמת, שיש לי פה בעיה עם אינדקס, הטבלה מיועדת 99% לכתיבה...
כנראה מה שאני אעשה בסוף: טבלת מראה בDB אחר עם אינדקסים שיתעדכן פעם בשעה.
השאלה אם האינדקסים יעזור.
אני לא יכול לעשות יותר מידי טסטים כי זה נועל את הטבלה.

@dovid

-> Limit: 200001 row(s)  (actual time=31750.842..31750.842 rows=0 loops=1)
    -> Filter: (sum(cdr.elapsed) > 100)  (actual time=31750.837..31750.837 rows=0 loops=1)
        -> Table scan on <temporary>  (actual time=0.004..0.005 rows=1 loops=1)
            -> Aggregate using temporary table  (actual time=31750.451..31750.453 rows=1 loops=1)
                -> Nested loop inner join  (cost=3766093.75 rows=46610) (actual time=22060.691..31750.388 rows=1 loops=1)
                    -> Filter: ((cdr.end_ts > <cache>(unix_timestamp('2023-7-1 00:00:00'))) and (cdr.end_ts < <cache>(unix_timestamp('2023-7-2 00:00:00'))) and (cdr.elapsed < 7200) and (cdr.t_user is not null))  (cost=3049122.50 rows=932200) (actual time=22042.090..31708.494 rows=11270 loops=1)
                        -> Table scan on cdr  (cost=3049122.50 rows=25176946) (actual time=1.345..29896.727 rows=26187820 loops=1)
                    -> Filter: (grp.group_id = 14)  (cost=0.67 rows=0) (actual time=0.004..0.004 rows=0 loops=11270)
                        -> Single-row index lookup on grp using unique_index (reg_exp=cdr.t_user), with index condition: (grp.reg_exp = cdr.t_user)  (cost=0.67 rows=1) (actual time=0.003..0.003 rows=1 loops=11270)

אבל זה בלי אינדקס כרגע על CDR.

@dovid צודק, לא אני כתבתי את השאילתא... בכל מקרה זה לוקח אותו זמן...

@yossiz עשיתי אינדקס שכולל גם את elapsed זה עדיין לא עוזר על טווח של יותר מחודש, הוא לא משתמש באינדקס אם זה טווח גדול, לא ברור למה.
כאן אני רואה שיש כזה דבר שאם המנוע משער סטטיסטי שזה יהיה יותר מידי רשומות (מעל 30% מהטבלה, במקרה שלי זה לא נכון) הוא לא משתמש באינדקס כי זה לא חוסך כלום, בגלל שאחר כך הוא יצטרך לחפש את כל שאר העמודות בדיסק.

@yossiz אבל זה לא עזר אם חוזר הרבה רשומות (בטווח של יום זה כן מייעל, כנ"ל), אם אני משנה את טווח התאריכים לשנה זה עדיין לוקח 30 שניות... כנראה שכן צריך לכלול את elapsed

@yossiz
אלף תודות!
ירד לפחות מחצי שנייה!!
אני ניסתי להוסיף אינדקסים מרובי עמודות, שרק גרעו...

יש לי שאילתא שלוקחת כ 30 שניות.

• הטבלה המדוברת מכילה כמה עשרות מיליון שורות.
  להלן השאילתא וה EXPLAIN ANALYZE שלו:

EXPLAIN ANALYZE 
SELECT
count as כניסות,
  sum as סיכום ,
  A.t_user as משתמש,
    B.group_id as קבוצה
FROM
  (
    SELECT
      sum(elapsed) / 60 as sum,
      t_user,
      COUNT(id) as count
    FROM
      (
        SELECT
          *
        from
          cdr
        WHERE
          end_ts > UNIX_TIMESTAMP('2023-7-1 00:00:00')
          AND end_ts < UNIX_TIMESTAMP('2023-7-2 00:00:00')
          AND elapsed < 7200
      ) as c
    group by
      t_user  ) as A
  INNER JOIN (
    SELECT
      *
    from
      re_grp
  ) as B ON B.reg_exp = A.t_user
  WHERE  sum > 100
  AND B.group_id = "14"
;

-> Limit: 200001 row(s)  (cost=251.27 rows=688) (actual time=24439.014..24439.014 rows=0 loops=1)
    -> Nested loop inner join  (cost=251.27 rows=688) (actual time=24439.012..24439.012 rows=0 loops=1)
        -> Index lookup on re_grp using group_idx (group_id=14)  (cost=10.34 rows=10) (actual time=0.376..1.341 rows=10 loops=1)
        -> Filter: (re_grp.reg_exp = A.t_user)  (cost=0.26..17.90 rows=69) (actual time=2443.766..2443.766 rows=0 loops=10)
            -> Index lookup on A using <auto_key0> (t_user=re_grp.reg_exp)  (actual time=0.002..0.002 rows=0 loops=10)
                -> Materialize  (cost=0.00..0.00 rows=0) (actual time=2443.766..2443.766 rows=0 loops=10)
                    -> Filter: ((sum(cdr.elapsed) / 60) > 100)  (actual time=24436.782..24437.519 rows=58 loops=1)
                        -> Table scan on <temporary>  (actual time=0.003..0.135 rows=1747 loops=1)
                            -> Aggregate using temporary table  (actual time=24436.010..24436.269 rows=1747 loops=1)
                                -> Filter: ((cdr.end_ts > <cache>(unix_timestamp('2023-7-1 00:00:00'))) and (cdr.end_ts < <cache>(unix_timestamp('2023-7-2 00:00:00'))) and (cdr.elapsed < 7200))  (cost=3037453.91 rows=928195) (actual time=15394.662..24430.348 rows=11270 loops=1)
                                    -> Table scan on cdr  (cost=3037453.91 rows=25068783) (actual time=0.575..22594.434 rows=26078024 loops=1)

אין שום אינדקסים, למעט לטבלה re_grp שהוספתי אינדקס שלא עזר הרבה.
ניסיתי להוסיף ל cdr אינדקסים, אבל זה רק עשה יותר גרוע...
אשמח להכוונה מה יכול להאיץ את השאילתא.
תודה!

@איש-ימיני "הבעיה" פשוטה מאד, כשאין לך קליטה / עומס על הרשת / הפלאפון נכבה בצורה לא מבוקרת, רשת התקשורת מנסה כמה שניות לאתר את המכשיר, כי לפעמים לוקח קצת זמן עד שהמכשיר מגיב. בזמן הזה, ברוב החברות שומעים שקט, ובסלקום שומעים צליל חיוג, אך אפשר לשים לב שזה חיווי אחר (ונדמה לי גם צליל שונה) בפלאפון המחייג. (בנוקיה במקום "מתחבר" "מתקשר").

@אביי כתב בעבודה בתכנות ממספר מחשבים:

@מוטי-מן אני משתמש לזה בonedrive (יש לי חשבון ארגוני שלא אני משלם עליו), יצרתי ספריות בכל המחשבים בשם "פיתוח" והגדרתי את המיקום שלהם לתיקיית הonedrive במחשב, וכך זה מסתנכרן לענן ומהענן למחשב בצורה ממש חלקה, לא ממש נתקלתי בבעיות מהסוג שציינת במהלך סינכרון (אני מסנכרן את תיקיות המסמכים, שולחן עבודה, תמונות, הורדות ועוד כמה אישיות..), זה אכן היה פעם, אבל מאז השתנו כמה דברים גם בנטפרי וגם בתוכנה עצמה..

הנסיון שלי רע עם וואן דרייב (אישי). אני מדבר על התקופה האחרונה, זה עושה לי בעיות בקבצי קוד, הוא תמיד מוריד 2 העתקים, לפעמים נתקע ולוקח לו זמן או שלא מצליח להוריד / להעלות קבצים מסויימים, ייתכן שזה קשור לנטפרי.

@חייםיודלביץ בתכנות יש הבדל בין ערך NULL לריק (=מחרוזת באורך 0).
במקרה שלך התאים ריקים אך לא NULL.

@pelephone יש תוספים של קופילוט צ'אט לעורכי הקוד.
הוא עונה נטו רק על תיכנות.
זה בתשלום לאחר תקופת נסיון.

@חראשו כתב בחיבור מכשיר חשמלי לשני שקעים:

האם זה בעייתי שיהיו שני מקורות מתח

ברור שזה בעייתי.
זה יגרום שכשמקור מתח 1 מנותק, מקור מתח 2 יחזיר לו חשמל.

@dovid האמת שחשבתי על זה, ושכחתי...
כנראה אלך על זה, רק עם איזה פתרון לכאלה שה ID שלהם הוא חד ספרתי או דו ספרתי.

עם איזה אלגוריתם מומלץ להשתמש לספרת ביקורת? Luhn כמו במספר זהות?

@avi-rz כתב בקוד נגדי קצר:

אם מפחיד אותך מאוד להשתמש ב db,

לא זה העניין.
אני כבר משתמש ב DB, מדובר בתוכנה גדולה.
אני מנסה לברוח מהצורך לזכור לאכלס עוד שדה של קוד רנדומלי + ספרת ביקורת, בכל הוספת שורה לטבלה (זה קורה מכמה מקומות). מדובר בקוד קיים, שאני רק מוסיף לו איזה פיצ'ר ואני מחפש כמה שפחות לגעת בכאלה דברים...

@dovid כתב בקוד נגדי קצר:

אם זה לחסוך, חבל על הזמן, זה לא אפשרי.

אין מנוס מלהשתמש ב DB.