החלפתי את JSON בפורמט בינארי מותאם אישית ב-PHP

היינו זקוקים לדרך טובה יותר לאחסן טקסט עשיר (rich text) עבור האפליקציות והאתרים שלנו.

בהתחלה, אחסנו HTML גולמי במסד הנתונים שלנו. מאוחר יותר, עברנו ל-JSON כדי להפריד בין עריכה להדפסה. JSON עבד במשך זמן מה, אך הוא יצר בעיות חדשות ככל שגדלנו.

JSON הפך לאיטי מדי עבור הצרכים שלנו.

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

החלטתי לבנות פורמט בינארי מותאם אישית באמצעות PHP.

מפתחים רבים חושבים ש-PHP לא בנויה לניהול בתים (bytes) ברמה נמוכה. עם זאת, ל-PHP יש פונקציות מובנות לכך:

  • pack(): ממירה מספרים או מחרוזות לבתים גולמיים.
  • unpack(): ממירה את הבתים הללו בחזרה למספרים או מחרוזות.

הפסקתי להשתמש בפעולות מחרוזת מרובות-בתים (multibyte). במקום זאת, התמקדתי בקריאת מקטעי בתים ספציפיים. לדוגמה, מספר שלם (integer) ללא סימן של 64 סיביות דורש בדיוק 8 בתים. דיוק הוא המפתח בעבודה עם נתונים בינאריים.

שיניתי גם את האופן שבו בניתי את מבנה הנתונים.

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

התוצאות מ-10,000 לולאות מראות מנצח ברור:

קידוד JSON ישן: 2.18s פענוח JSON ישן: 0.86s

קידוד בינארי חדש: 1.19s פענוח בינארי חדש: 0.67s

הפורמט החדש מהיר יותר גם בקידוד וגם בפענוח.

הפורמט הבינארי גדול יותר מ-JSON או HTML. הוא תופס בערך פי שניים מהשטח של JSON. מכיוון שאנו משתמשים ברינדור בצד השרת (server-side rendering), העלייה באחסון הזו אינה משפיעה על הביצועים שלנו.

הפשרה הזו משתלמת. כעת אנחנו יכולים לשנות קישורים ולנקות HTML באמצעות פונקציות פשוטות ומהירות.

אם אתם בונים פורמט מותאם אישית, כתבו מפרט (specification) ברור. תצטרכו אותו כשתחזרו לקוד מאוחר יותר.

מקור: https://dev.to/tomj/i-replaced-json-with-a-custom-binary-format-in-php-mok